Home

Оригинальная публикация

Автор: Евгений Ефимов, QA Manager, DataArt

Посмотреть запись выступления Евгения на эту тему

…Или, другими словами, как посчитать время на тестирование так, чтобы все поверили? Ведь на самом деле у нас обычно — две цели. Первая — посчитать время так, чтобы не ошибиться и правильно распределить ресурсы — скорее всего, поначалу сделать это хорошо все равно не получится. Вторая цель более реальна: посчитать время на тестирование так, чтобы доказать кому-то, что вам нужны еще люди в команде, объяснить, почему вы не успеваете и т. д. Как ни странно, после того, как раз 50 сделаете второе, то и первое будет получаться!

Давайте теперь посмотрим, как считать время на тестирование, на конкретных примерах.

Случай 1: «Вот ТЗ, сколько времени уйдет на написание тестовых случаев?»

Допустим, приходит нам приходит объемная папка с хорошо прописанным техническим заданием (ТЗ). Нас спрашивают, сколько времени уйдет, чтобы написать тестовые сценарии (ТС) ко всему этому делу.

Прежде чем мы сможем ответить на этот вопрос, нам хорошо бы знать:

• Кто будет писать ТС?
  • Каков уровень человека, который будет писать ТС: у него меньше или больше опыта, чем у вас? Если у него меньше опыта, понятное дело, ему понадобится больше времени. Если у него столько же опыта, сколько у вас, тогда ваши оценки сходятся. Если человек круче вас, тогда вообще непонятно, почему вас попросили рассчитывать время.
  • Каков уровень знания технологий? Сможет ли человек провести низкоуровневое тестирование, хорошо во всем разобраться, будет ли он понимать, что происходит с базой, например?
  • Каков уровень знания предметной области? Это еще важнее, чем уровень знания технологии, потому что, если нам, например, нужно тестировать какое-то навороченное финансовое приложение, а мы не понимаем вообще, что такое бонды и опционы, — много времени уйдет на понимание предметной области. Понять без этого, насколько сложно ТЗ, насколько сложен продукт и, в итоге, насколько объемными и какими вообще должны быть ТС, довольно трудно.
• Зачем и для кого пишутся ТС?
  • Для себя — если мы тестируем нашу внутреннюю разработку. У нас свой продукт, своя команда, и мы пишем ТС именно для своего продукта.
  • Для клиента. Иногда клиент заказывает только тестирование, а иногда — только ТС. Иногда он просит протестировать один раз, а потом оставить ему артефакт, по которому он сможет протестировать сам. ТС для клиента могут быть и менее детализированными, и детализированные, но иначе, чем если бы мы писали ТС для себя. Так, сами мы хорошо понимаем все термины тестирования, но нам, может быть, нужно будет подробно прописывать в ТС всякие сложные вещи из предметной области. Клиент может отлично понимать предметную область, но он может не знать, что такое валидация формы, и ему нужно будет это объяснять.
  • Для приемочного тестирования — в этом случае ТС писать еще сложнее, чем для клиента, потому что это тестирование, результаты которого клиент может и не принять, если не захочет. Поэтому ТС для приемочного тестирования мы пишем сильно более формальными — не должно быть никаких формулировок типа «все работает нормально», потому что по такому ТС клиент может не принять у вас ничего и никогда.
  • Для автоматизации. Тут мы должны думать про тестирование, управляемое даннми, о том, как это автоматизировать и т. д.
  • Для души. В это случае мы просто хотим разобраться и нет запроса от команды на тестирование.
• Где пишутся, в какой системе управления тестированием?
  • Знакомая среда.
  • Незнакомая среда. В незнакомой среде, конечно, нам нужно будет больше времени.

От ответов на все эти вопросы зависит, сколько времени уйдет на написание одного позитивного тестового случая — T1. Также стоит учитывать время на написание одного негативного ТС (он будет обозначаться как T-1). Мой опыт говорит, что негативные ТС обычно пишутся дольше — также их обычно нужно больше. Конечно, здесь бывает по-разному, но мне кажется, что, чем лучше мы знаем предметную область, чем лучше разбираемся в приложении, чем лучше понимаем, где и как оно может упасть, тем больше у нас будет негативных ТС. Если у вас, например, на три позитивных ТС приходится один негативный, возможно, вы недопонимаете приложение. Если на один позитивный вы можете придумать 500 негативных ТС, это — хорошая работа. У меня соотношение позитивных и негативных ТС — обычно от ½ до 1/5.

Т. ч. нам нужно посчитать время на написание позитивного ТС, прикинуть соотношение позитивных и негативных, и посчитать время целиком.

Варианты оценки:

• Грубая экспертная. Например, мы знаем, что обычно на одну страницу ТЗ мы пишем 5 ТС. Обычно один ТС мы пишем 20 мин. В техническом задании 300 страниц. 5 x 20 x 300 = 30000 — вот сколько минут навскидку мы будем писать ТС.

  • 

    X тестовых случаев на страницу, T1 минут на ТС, Y страниц  (T-1 – негативный ТС)
• Грубая дедуктивная. Допустим, у нас есть план проекта, есть сроки, есть команда. И мы представляем, какое соотношение разработчиков к тестировщикам должно быть в проекте. Например, проект на полгода. Разработчиков — пятеро (значит, нужны два тестировщика на эти полгода). Мы видим, что писать ТС будем примерно четверть времени от всего времени, отведенного на тестирование. Это грубый, но быстрый способ подсчета.
  • Тестирование занимает X времени от времени проекта.

  • 

    Написание тестовых случаев Y времени от времени на тестирование
• Индуктивно-опытная. Это медленный способ оценки, но он хорошо работает. Тут мы пробуем написать ТС для каждой части ТЗ. Делать это лучше с той степенью подробности, с которой будем их писать дальше. Впрочем, можно сделать хотя бы высокоуровненые ТС. Это может занять день, два, неделю, но зато поможет понять, сколько времени уйдет вообще.
  • Разбиваем ТЗ на однородные части (например, по функционалу) и пробуем писать ТС для каждой части
  • Смотрим, сколько времени ушло на написание ТС для такого-то количества страниц каждой части, исходя из этого вычисляем, сколько всего времени должно уйти на написание ТС для каждой части
  • Складываем посчитанное для каждой части время

    

Пример

Давайте теперь посмотрим, как работают эти методики, на конкретном примере. Например, мы пишем социальную сеть для домашних питомцев. У нас есть ТЗ на эту соцсеть, всего 47 страниц. Допустим, мы его разбили на однородные части. Вот что мы в итоге имеем:

• ТЗ:
  • Аккаунт хозяина (5 страниц).
  • Профиль животного (15 страниц).
  • Фоточки, видео (12 страниц).
  • Друзья (8 страниц).
  • Сообщения (5 страниц).
  • Нефункциональные требования (2 страницы, 12 штук).
• Программисты: четыре человека.
• Срок: шесть месяцев.
• Грубая экспертная оценка (принятая в нашей компании): два позитивных ТС на страницу, 0,5 часа — на позитивный ТС, 45 мин. — на негативный

Теперь попробуем посчитать, сколько часов у нас примерно уйдет на написание ТС (но, обратите внимание, не на тестирование вообще):

• Грубая экспертная оценка: (0,5 + 3 x 0,75) x 2 x 47 = 258 часов.
  Комментарий: негативных ТС здесь 3 к одному позитивному. Два позитивных ТС на одну страницу, всего 47 страниц. 0,75 — это 45 мин.
• Грубая дедуктивная оценка: (176 x 4 x 6) / 3 / 4 = 352 часа.
  Комментарий: 176 часов в месяц, четыре программиста на шесть месяцев, разделить на три (отношение программистов к тестировщикам — примерно 1,5 тестировщика на проекте (4/1,5 ≈ 3)) и разделить на четыре (четверть времени от всего тестирования будет уходить на написание ТС).
• Индуктивно-опытная оценка: (1 x 10) + (3 x 15) + (6 x 12) + (2 x 16) + (1 x 10) + (3 x 12) = 205
  Комментарий: мы потратили час на аккаунт хозяина, успели покрыть половину страницы, а этих половин у нас 10 (1×10). Мы потратили 3 часа на профиль животного, за три часа покрыли одну страницу (3×15). Мы потратили 6 часов на покрытие одной страницы фото/видео (так много потому, что тут, допустим, всё очень сложно). 2 часа потратили на друзей и сделали за это время пол страницы (2×16). 1 час потратили на сообщения, сделали за час пол страницы (1×10). Нефункциональные требования мы тут решили смотреть не по страницам, а по самим требованиям: потратили 3 часа на одно требование (3×12). Всё это заняло у нас 16 часов — значит, за 2 дня мы оценили время в 205 часов.

Оценки у нас не сходятся, но это нормально — по крайней мере, мы сумели посчитать примерно. А если у нас достаточно времени на оценивание, можем сделать оценку несколькими способами.

Считаем время при использовании Agile

Теперь поговорим о гибких методологиях разработки, когда нет технического задания. Тут не очень понятно, как оценивать, но все же можно выделить кое-какие подходы. Например, можно:

• просто пройтись по бэклогу;
• написать высокоуровневые ТС;
• выписать все действия внутри спринта и попробовать оценить, сколько они будут занимать времени — этот подход разберем ниже.

Отступление для QA-менеджеров

Теперь небольшое отступления для QA-менеджеров, менеджеров проектов. Все действия по созданию и по запуску тестовых случаев мы можем разделить на следующие компоненты:

Сколько всего времени тогда занимает тестирование, мы видим в формулах внизу таблицу — в них все понятно и без комментариев.

Случай 2: «Вот кусок функционала, сколько времени уйдет на тестирование?»

Сколько времени уйдет на тестирование той или иной части функционала? Чтобы это прикинуть, есть разные способы:

• 

  Можно смотреть, сколько времени обычно у нас уходит на тестирование похожего функционала.
• Можно смотреть на тот же функционал, если мы уже раньше тестировали такой. Это очень удобно! Если вы, конечно, записали в прошлый раз, сколько это времени заняло.

  

• Дедуктивная оценка — если мы знаем, сколько этот функционал занимает места в общем функционале (если мы, например, уже знаем, сколько времени занимает полная регрессия), мы просто видим, что тестирование этой функционала займет, например, пятую часть от всего времени.

  

• Индуктивная оценка — мы помним, сколько времени мы тратим на каждый ТС. Мы смотрим на этот функционал и понимаем, что нам для его тестирования нужно 10 – 15 ТС.

  

Что в данном случае важно помнить? Что новый функционал может снова затребовать время на подготовку среды. Важно помнить о существовании коэффициента на знакомство с системой: больше времени на тесты уходит, если прогоняешь их в первый раз, чем если ты их прогоняешь второй или третий раз. Но если второй раз наступает через месяц, то ты его всё равно прогоняешь, как будто в первый раз — впрочем, это у каждого по-своему.

Случай 3: «Почему вы ничего не успеваете?!»

Следующий, весьма распространенный вопрос, который задают тестировщикам: «а что это вы вообще делаете, почему вы ничего не успеваете, почему вам нужно помогать с автоматизацией, почему вы не хотите, чтобы мы каждый день выпускали новые версии — ведь багов-то новых нету?..»

Чтобы показать, чем мы занимаемся, можем для каждого проекта выписать все-все задачи, которые выполняются за один спринт, и расписать их по дням: посчитать, сколько времени уходит на каждую задачу в тот или иной день. Так можно увидеть среднюю, максимальную и минимальную загрузку.

Пример такой таблицы:

Когда я её сделал, я увидел, что не всегда нагрузка может быть оптимально распределена — иногда загрузка большая, а иногда пол дня вообще нечего делать. Это позволяет сделать определенные выводы и как-то оптимизировать процесс, распределить нагрузку — например, какие-то вещи делать заранее, даже если это не совсем согласуется с логикой процесса. Например, если в начале спринта у нас много свободного времени, мы можем уже начать писать пользовательские истории к следующему спринту. Хоть мы и не знаем структуру следующего спринта, все же мы, скорее всего, можем предугадать, что вот эти вот две-три истории в него точно войдут — обычно они самые критичные, обычно их все равно приходится переписывать, поэтому это хорошее упражнение.

Итак:

1. Определили список задач.
2. Определили «входные параметры».
3. Определили время на каждую задачу.
4. Размазали задачи по спринту .

Получили загрузку в часах по дням. И если получается, что каждый день нужно 24 часа тестирования, а у нас всего два человека… Значит, однозначно нужен третий тестировщик!

Случай 4.1: «Выпускаем сборку в пятницу, а то и раньше — так сколько вам нужно времени на тестирование»?

В таком случае процесс тестирования строится так:

1. Дымовой тест + тест на полную регрессию x на кол-во важнейших платформ + тест на базовую функциональность на все платформы + тесты на полную регрессию по платформам (см. матрицу).
2. Повторное тестирование: дымовой тест + валидация xвсе платформы.

Тесты на полную регрессию по платформам проводятся в этом случае следующим образом (Cr, FF и т. д. здесь — разные платформы, в данном случае — браузеры):

По этой матрице мы видим, что для каждой платформы тестируем какую-либо часть функционала: в итоге получается, что мы и всю функциональность проверили, и опробовали работу на каждой платформе. Мы также можем сдвигать эту матрицу — в итоге получится, что за определённое количество прогонов мы каждую функцию на каждой платформе всё равно проверим. Это еще простая схема — а ведь может быть и 20 конфигураций без возможности автоматизировать их тестирование — конечно, в таком случае мы все не успеем проверить, и будем тестировать по такой матрице.

В итоге получаем следующую формулу:

ΣT = (Tprec + Treg) x (Qmain + 1) + (Tprec + Tbase +Tsmoke) x Qconf + (Tsmoke + Tvalidation) x Qconf x Qreturns

Qmain – количество главных конфигураций, на которых тестируем всё.
Qreturns – количество возвратов.

По этой формуле понятно, сколько всего времени у нас уйдет. По ней же можно попробовать следить за временем, смотреть, на какое тестирование уходит больше всего времени. Также будет понятно, где и что лучше автоматизировать — мы поймём, где автоматизация сэкономит нам больше всего времени.

Случай 4.2: «Слишком много тестов! Давайте быстрее».

Если от нас требуют выполнить тестирование быстрее, мы можем урезать количество тестов по следующим принципам:

• Смотрим на приоритеты:
  • тестовых случаев — если мы расписываем приоритеты ТС. Тогда мы будем работать лишь с самыми высокоприоритетными ТС;
  • пользовательских историй или багов, если наши ТС к ним привязаны.
• Смотрим на заметки к выпуску (release notes), куда входит:
  • критически важный функционал, без которого приложение не будет работать и никому не нужно;
  • заявленный новый функционал — так как его публично объявляют, пользователи его обязательно проверят;
  • исправления критических ошибок (скорее всего, ошибки будут уже проверены);
  • заявленные исправления ошибок — мы заявили, что мы что-то исправили, и мы это проверяем;
  • известные проблемы (known issues) – как ни парадоксально, но мы обязательно должны перетестировать те ошибки, которые мы заявили как ошибки, с которыми мы выпустили продукт. Зачем это делать? Во-первых, нужно проверить, что их воздействие ровно такое же, какое мы описали. Во-вторых, мы проверяем, работает ли тот обход этой ошибки, который мы предлагаем.
• Вместо уменьшения объёма тестирования можно увеличивать команду:
  • Добавить программистов — лучше всего из своего же проекта. Например, они могут писать генераторы данных и прочее — всё для автоматизации или полуавтоматизации. Они делают это хорошо, а ответственность за тестирование всё равно не на них — поэтому они не страдают оттого, что их код плохо работает. По той же причине, можно просить одних программистов проверить код других программистов.
  • Позвать тестировщиков из других проектов, или с этого проекта, но занимающихся чем-то другим.

Вообще реальный процесс тестирования можно представить в виде треугольника. Углы этого треугольника — это:

1. Объем тестирования.
2. Количество человек в команде.
3. Срок, за который необходимо выполнить тестирование.

Скорость и качество тестирования зависят от этих трех аспектов — именно над ними нужно думать, чтобы успешно спланировать работу. Так, например, если нам предлагают протестировать продукт за нереально короткий срок, и мы точно не уложимся, или отказываемся от такой работы (если не хотим выпустить некачественный продукт, конечно), или работаем с вышеперечисленными аспектами. Тогда мы можем:

1. Сократить объем тестирования.
2. Увеличить количество человек в команде.
3. Попросить увеличить срок на тестирование.

Последний способ — пожалуй, самый надежный: ведь людей в команду могут дать неумелых, а сокращение объема тестирования может привести к выпуску сырого продукта.

Также здесь работает способ — спросить, почему такие сроки. Может быть, нужна всего одна функция для одного клиента — тогда сделаем ему частный релиз, а позже протестируем все остальное.

И еще случай напоследок: доработка уже вышедшего проекта

Если проект уже вышел, но поступило требование доработать его, как тогда рассчитать время на тестирование, на разработку и т. д.? Время в таком случае рассчитываем как обычно, но при этом умножаем его на два, потому что все люди уже всё забыли, уже в других проектах — нужно время на знакомство с системой. Кроме того, добавление может быть вне стандартного цикла, поэтому, кроме тестирования этого добавления, может понадобиться полная регрессия — тогда добавляем время на полную регрессию.