Оценка времени на тестирование
- ФИО: Алексей
- Город: планета Земля
Отправлено 28 февраля 2007 — 15:54
Возможно эта тема и поднималась, но я ее попросту не нашел.
Не могли бы вы подсказать мне, есть ли какие-нить централизованные инструменты или методики, для оценки требуемого для тестирования времени.
Пример простой: есть ТЗ с требованиями и ЮЗ кейсами, и мне надо сказать сколько времени может занять тестирование.
С моей стороны, могу сказать, что я не думаю, что можно как-то стандартизировать оценку время для тестрования. Можно лишь на примере собственного опыта сделать первоначальные оценки. Но как и все я могу ошибаться. 🙂
В любом случае буду рад услышать ответ, а также подискутировать на данную тему.
Алексей Булат
Про Тестинг
#2 
Clauster
- ФИО: Худобородов Валерий
- Город: Espoo
Отправлено 28 февраля 2007 — 20:32
ага, я поднимал тут подобную тему. Плохо искали http://forums.softwa. hl=трудозатраты
Bugsclock
#3 Boltick
- ФИО: Алексей
- Город: планета Земля
Отправлено 01 марта 2007 — 06:59
Да, спасибо. Тему я прочитал.
Но мой вопрос остался не отвеченным. Я спрашивал про стандартные инструменты и методики. И есть ли они вообще 🙂
Алексей Булат
Про Тестинг
#4 van
- ФИО: Ваулин Артем Николаевич
- Город: Россия, Санкт — Петербург
Отправлено 01 марта 2007 — 14:05
Стандартных нет.
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования
#5 Clauster
- ФИО: Худобородов Валерий
- Город: Espoo
Отправлено 01 марта 2007 — 20:42
А что значит стандартные? RUP, MSF, различные agile-методологии и т.д., везде по-своему.
Bugsclock
#6 Alfa
Отправлено 02 марта 2007 — 09:50
Как-то в умной книге (не помню какой) читал, что нулевая оценка на время тестирования — это время потраченное на разработку. Ну и дальше идет первый порядок, тут надо думать.
Плюс все сильно зависит от того какого качества продукт хотите получить.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#7 Yury
Отправлено 04 марта 2007 — 01:55
Пример простой: есть ТЗ с требованиями и ЮЗ кейсами, и мне надо сказать сколько времени может занять тестирование.
А что Вы, собственно говоря, хотите рассчитать?
Сколько вам нужно тестеров на данный проект, или за сколько времени имеющиеся тестеры смогут его протестировать?
Обычно работает армейская методика: «Тестирование проводится от забора и до обеда.»
#8 Roman Klochkov
Roman Klochkov
Отправлено 06 марта 2007 — 11:13
Не назвал бы это простым примером. То есть пример ничего, только вопрос поставлен не очень корректно.
1. Если интересует «сколько времени может занять тестирование проекта», то ответ один — сколь угодно много (т.е. что у заказчика продукта кончится раньше — терпение или деньги). Продуктов без багов не бывает, бывают терпимые (низко-приоритетные). Не знаю у кого как, мы давно смирились и честно пишем для 90% типов тестов в разделе «критерий окончания тестирования» — завершение тестирования проекта. Просто чем ближе срок релиза, тем больше багов закрываются с комментарием «by design». Хотя в тестировании ПО может всё по другому, не в курсе 🙂
2. Ну а если интересует «сколько времени займёт один прогон всех имеющихся тестов» — тогда конечно можно получить конкретную цифру.
Хотя мне почему-то кажется что вы спрашивали о первом варианте 🙂
#9 Boltick
- ФИО: Алексей
- Город: планета Земля
Отправлено 13 марта 2007 — 08:12
Не назвал бы это простым примером. То есть пример ничего, только вопрос поставлен не очень корректно.
1. Если интересует «сколько времени может занять тестирование проекта», то ответ один — сколь угодно много (т.е. что у заказчика продукта кончится раньше — терпение или деньги). Продуктов без багов не бывает, бывают терпимые (низко-приоритетные). Не знаю у кого как, мы давно смирились и честно пишем для 90% типов тестов в разделе «критерий окончания тестирования» — завершение тестирования проекта. Просто чем ближе срок релиза, тем больше багов закрываются с комментарием «by design». Хотя в тестировании ПО может всё по другому, не в курсе 🙂
2. Ну а если интересует «сколько времени займёт один прогон всех имеющихся тестов» — тогда конечно можно получить конкретную цифру.
Хотя мне почему-то кажется что вы спрашивали о первом варианте 🙂
Как раз таки меня нитересует пункт [2] а именно: расчет времени в человекочасах 🙂
Если это все достаточно субъективная оценка, которая делается за счет личного опыта, опыта тестировщиков, а также интуитивно, то тогда у меня вопросов нет. А если есть какие-нить секретные формулы, то мне это очень даже интересно 🙂
Алексей Булат
Про Тестинг
#10 Green
Отправлено 13 марта 2007 — 10:36
Я рекомендую пользоваться следующим подхождом.
1. Декомпозировать систему (разбить функц. требования на логические блоки)
2. Оценить количество тестов по каждой компоненте (блоку)
3. Для каждого теста определеить два параметра:
— время прохождения теста без выявления дефекта
— время прохождения теста с выявлением дефекта
Очевидно, что вслучае обнаружения дефекта время на выполнение теста требуется больше, так как необходимо не просто увидеть дефект, но и постараться выявить закономерности и возможные области проявления. Так же можно предусмотреть время на обсуждение дефекта с разработчиком, если такое практикуется, на повторение в других конфигурациях и т.п.
Далее начинаем обратный путь.
1. Находим среднее время (я встречал рекомендации — 2/3) для каждого теста (успешного и неуспещного варианта)
2. Суммируем все полученные результаты (средние для каждого теста)
Получаем предположительное время тестирование системы при условии соотношения багов к тестам — 1/2 (т.е. баг обнаруживается в каждом втором тесте).
Собирая статистика по соотношению кол-во найденных дефектов к кол-ву выполненных тестов, вы сможете уточнить временные затраты на тестирование в заданном объеме (т.е. количество тестов заранее известно).
Если количество тестов заранее не определено, то вступают вероятностные характеристики. Сколько тестов у вас предположительно? Сколько шагов они имеют в среднем? Как следствие, сколько времени нужно на выполнение теста в среднем? И т.д.
Как правильно оценивать время на тестирование?
Вопрос для тестировщика из собеседования. Как бы вы ответили на такое? Больше никакого контекста или пояснений нет (веб-приложение это или же сервис, или десктопное — видимо не уточняется..).
- Вопрос задан более трёх лет назад
- 7239 просмотров
Комментировать
Решения вопроса 1
Первое, что стоит сказать: на такой вопрос нельзя ответить правильно, т.к. слишком размытая формулировка. Это как «как правильно писать код?».
Касательно самих оценок.
Как уже выше озвучивали, есть вариант с оценкой на тестирование исходя из времени на разработку. Хотя с формулой:
QATime = (DevTime*0.35)*0.3;
Я категорически не согласен. Более реальной оценкой выглядит 0.3 от времени на разработку.
Второй вариант — отталкиваться от количества тестовых сценариев.
Я предпочитаю рассчитывать именно так.
1) Оцениваем объемы задачи.
2) Прикидываем примерное количество тест-кейсов (проверок) на данную задачу.
3) Умножаем кол-во на примерное среднее время прохождение кейсов (для веба это в районе 4х минут, дальше зависит от специфики отрасли).
4) Закладываем риски в 0.66 от оценки
Ну, в целом как-то так.
5 способов оценки времени на тестирование
Серьезный тестировщик
По моим наблюдениям, сроки тестирования определяются по следующим критериям:
- знание продукта;
- количество сессий тестирования;
- тип тестирования;
- компетентность;
- исправление багов.
Давайте погрузимся в каждый из них.
Знание продукта
К примеру, оценка времени тестирования будет отличаться между тестировщиком, который знаком с продуктом месяц и тестировщиком, который знаком с продуктом год, просто потому, что последнему известно больше деталей и подводных камней. Второй тестировщик нырнул глубже, чем первый. Конечно, бывает и так, что второй тестировщик страдает батофобией и продолжает плавать на поверхности в надувных нарукавниках. Но, предположим, что перед нами всё-таки храбрый тестировщик.
Количество сессий тестирования
Некомпетентный ответ: это займёт день/два дня/неделю. Подозрительно точно, не так ли? Вы же не перемещались в будущее, если, конечно, у вас нет машины времени. Вам ведь может понадобиться куда больше времени из-за непредсказуемых обстоятельств или внешних причин, от которых будет зависеть время тестирования.
Прежде, чем приступить к фактическому тестированию, тестировщику предстоит выполнить массу действий:
- Прочесть документацию (если таковая присутствует).
- Пообщаться с командой, чтобы узнать больше о продукте.
- Подготовить всё для тестирования (тестовые данные, инструменты, тестовые сценарии, настройка тестовой среды, получить доступ к нужным сервисам и т.д.).
- Провести первый этап тестирования и создать заметки по багам.
- Дождаться исправления багов, выполнить второй этап тестирования, убрать заметки с исправленными багами и создать новые.
- Повторить шаг 4 и 5, пока продукт не будет выглядеть без сучка и без задоринки. Что называется, «с иголочки».
Допустим, менеджер хочет услышать прозрачную оценку времени на тестирование (шаги 4, 5, 6). Даже здесь рамки процесса всё ещё размыты. Представим, что у нас есть функционал, который можно протестировать за пару дней. Это не значит, что тестировщик будет трудиться все пару дней над продуктом, не вставая из-за стола. Любому человеку понадобятся перерывы, чтобы проводить тестирование более эффективно.
Во время каждого этапа тестирования, у вас может быть несколько сессий тестирования (30 минут, час, 90 минут и т.д.). Между сессиями, у вас есть другие дела (общение в чатах, с коллегами, совещания, обед, кофе-брейки, отдых и тому прочее). В итоге, два дня тестирования могут растянуться на целую неделю. Нереально достичь такого же эффекта, проводя тестирование два дня подряд. Тестировщику нужны эти перерывы.
Какую же оценку передать менеджеру? Два дня или пять? Чисто тестирование займёт пару дней, но чтобы выполнять его более эффективно и продуктивно, нужно растянуть процесс поэтапно. Что бы вы не сказали, ваш менеджер должен быть в курсе вашего подхода к тестированию, так вы сможете отстоять свою позицию.
Мудрый ответ: в случае отсутствия багов, мне понадобится столько-то времени, чтобы протестировать такую-то часть функционала. Время на тестирования, отчеты о багах и последующее тестирование будет варьироваться в зависимости от того, насколько сырой продукт. Все мы знаем, что не бывает продукта без багов. Даже если вы думаете, что выявили все баги, это не так. В любом случае, список багов, обнаруженных на первом этапе (или при любом другом) тестирования отсрочивает день презентации готового продукта. Поэтому, называйте нужный вам интервал времени, а не точное количество часов.
Тип тестирования
Применяемый тип тестирования напрямую влияет на время тестирования. Диапазон времени варьируется в зависимости от типа тестирования и его глубины. Будь то тестирование UI или API, дымовое, приемочное, или регрессионное.
К примеру, если ваше тестирование сравни исследованию поверхности воды (просто, чтобы узнать температуру воды), оно займет совсем немного времени. Но если вы собираетесь погрузиться на глубину в купальнике и с баллоном на спине, вам потребуется больше времени, чтобы тщательно исследовать конкретный участок.
Нужно больше подготовки, чтобы более медленно и тщательно анализировать пространство, двигаясь со скоростью воздушных пузырей под водой. Может быть, для исследования вам понадобится несколько раз сменить водолазный баллон или понадобится больше людей.
Компетентность
Если вы профессионал в API-тестировании, времени на выполнение уйдёт меньше, чем у тестировщика, у которого меньше знаний в этом типе тестирования. Тоже самое с тестированием безопасности, производительности и т.д. Всё более популярными становятся T-shaped специалисты. Но не ждите, что работа будет выполнена столь же быстро, как это может сделать профессионал. Убедитесь, что задачу будет выполнять тот же человек, который оценивал время её выполнения. Если же оценку давал кто-то другой (например, ваш QA-руководитель), он/она должен учитывать уровень профессионализма каждого QA-инженера в команде.
Как бы не оценивались сроки, кое-что нужно иметь в виду:
- всегда прикидывайте запас времени (20%-30%);
- будьте готовы к тому, что тестирование завершится быстрее ожидаемого (менеджеры будут в восторге);
- будьте готовы к тому, что тестирование может выйти за рамки сроков (но это уже отдельная тема).
Исправление багов
Хочу отдельно раскрыть шаг 6 среди подходов к сессиям тестирования (итеративный подход). Работа тестировщика, проводящего тестирование вместе со сборкой, выглядит следующим образом:
- есть 1-ая сборка для тестирования;
- после первой сессии тестирования вы готовите отчёт о багах;
- затем, у вас есть 2-ая сборка;
- вы проверяете исправление багов и продолжаете вторую сессию тестирования (возможно, снова готовите отчёт о багах)
Тестирование будет проводиться в несколько этапов, до тех пор, пока продукт не будет выглядеть без сучка и без задоринки, что называется, «с иголочки».
Как видите, у нас остаются временные промежутки для исправления багов. Вы не можете оценить и предугадать сколько понадобится времени на каждое исправление бага. Следовательно, невозможно предугадать, когда получится новая сборка после первой сессии тестирования. Даже если вы профи в оценке тестирования и знаете наверняка сколько понадобится времени на тестирование, вы всё равно не предвидите насколько, возможно, придется отсрочить тестирование для исправления багов. Вы, конечно, можете заместить время ожидания сборки другими делами, но, в конце концов, все хотят видеть прогресс и видимые результаты. Но когда это наступит?
Вы не можете предсказать, на сколько, возможно, придется отсрочить тестирование для исправления багов.
Нам нужно различать время тестирования и время стабилизации сборки. Время стабилизации сборки может варьироваться, за это отвечает вся команда. На практике, запас времени, который каждый из команды вкладывает в свою оценку, должен частично включать время стабилизации сборки. Главный вопрос заключается в том, сколько времени команда может себе вообще позволить, учитывая сумасшедший график релизов в Agile-мире.
Безусловно, существуют и другие способы выполнить точную оценку. Но я включил те, которые наиболее заслуживают внимания, с моей точки зрения.
Тебе пришла задача в тестирование как будешь оценивать время на проверку
Наверняка многие тестировщики хотя бы раз сталкивались с ситуацией, когда времени на тестирование совершенно нет. Даже если им чуточку повезло, и хоть какое-то время осталось, то его все равно не хватит на проверку всего продукта. И не столь важно, почему так получилось (неправильно спланирована работа, заказчик захотел «прикрутить вон ту фичу» в самый последний момент, тестировщиков поздно подключили к проекту), – главное в том, что выходить из положения как-то нужно.
Итак, что же делать, когда времени вовсе не осталось, а тестировать хочешь не хочешь, но надо? Можно искать виноватых, кивать друг на друга, бегать в панике, но, как мне кажется, каждый понимает, что это неконструктивный подход. В этой статье я расскажу о своем опыте, позволяющем справиться с тесными временными рамками. Ниже я составила список подходов, которые можно применить в условиях сжатых сроков.
Что же делать, когда времени нет?
1. Приоритизация
Пожалуй, это первое, что нужно сделать в том случае, когда времени на тестирование совсем или почти не осталось. Для начала следует определить, какие функциональности являются наиболее важными с точки зрения бизнеса, а также что именно ни в коем случае нельзя предоставить пользователям в «сыром виде». Эти части приложения и станут основой для составления тестов с высоким приоритетом. Если же тесты уже составлены, то достаточно будет посмотреть на них и отобрать только те, которые покрывают наиболее критичные пользовательские сценарии. Таким образом, у вас появится возможность проверить функциональности, действительно важные для целевой аудитории, – собственно, то, ради чего и будут покупать продукт.
2. Смоук-тестирование
Этот пункт тесно связан с предыдущим, поскольку для смоук-тестов всегда выбираются наиболее важные бизнес-сценарии. Каждая команда тестирования должна всегда иметь наготове такие проверки. В ситуации, когда времени для выполнения тестов совсем не выделили, вам будет достаточно просто прогнать смоук для того, чтобы убедиться в корректности поведения критичных функциональностей или выявить проблемы неудачного релиза, способные привести проект к финансовым потерям.
3. Тестирование затронутых функциональностей + регрессия
Существует еще один способ быстрой проверки готовности новой версии продукта к релизу – тестирование только измененных и «свежих» функциональностей («старые» при этом поверхностно проверяются регрессионными тестами, например, смоуком). В этом случае не стоит забывать, что подробные проверки лучше оставить на тот момент, когда времени будет достаточно; по самому же главному в новых и затронутых «фичах» пробежаться все-таки стоит.
4. Исследовательское тестирование
Казалось бы, нет ничего хорошего в том, чтобы вообще не использовать никаких тестов: как же тогда документировать результаты проверок? Выход есть! Определите ключевые сценарии в тестируемом приложении и в ходе проверки составляйте тесты, попутно записывая каждый из них. Так вы будете знать, что проверили, и что получилось в результате. Исследовательский подход не только позволит вам сэкономить время на составлении тестов, но и даст возможность быстро проверить то, что действительно важно для текущего релиза.
5. Каждая функциональность – привыкшему к ней тестировщику
Допустим, каждую из функциональностей всегда проверяет какой-то определенный тестировщик. Он отлично знаком с ней, знает каждый уголок и может с ходу рассказать о существующих проблемах. Прекрасно! Оставьте ему проверку привычной «фичи», не отдавайте ее кому-то другому. Таким образом вы не только сократите время тестирования, но и сможете быть уверенными в действительно качественной проверке функциональности. Эксперименты и ротации оставьте на тот момент, когда у вас будет возможность разнообразить устоявшийся процесс.
6. Требования вместо тестов
Требования на проекте всегда поддерживаются в актуальном состоянии? Это настоящее везение в тех случаях, когда времени на тестирование не осталось! Благодаря качественному ТЗ можно существенно уменьшить срок проведения тестирования – достаточно лишь проверить функциональности по требованиям, не составляя никаких проверок. Конечно, этим способом не стоит злоупотреблять (поскольку тесты все-таки позволяют протестировать приложение более качественно), но для сжатых сроков такая проверка вполне подходит. В дополнение к требованиям можно также исследовательски пройтись по «фичам» для закрепления результата.
7. Только позитивные тесты
Да-да, именно так! Не имеет смысла углубляться в тестирование и ломать продукт в том случае, если времени в обрез. Это грозит ситуацией, когда вы вроде бы все протестировали, но в то же время не проверили ничего. Если времени слишком мало, негативные тесты только усугубят ситуацию. Даже если они приведут к дефектам, исправлять такие баги никто не будет до тех пор, пока самое важное не заработает так, как нужно. Именно поэтому в условиях сжатых сроков лучше тестировать только позитивные сценарии. В конце концов, пользователи хотят, чтобы продукт выполнял их задачи; они редко ставят себе цель сломать его (если, конечно, речь идет не о банковском ПО, где ситуация несколько иная).
8. Планирование
Очень часто времени не хватает именно потому, что изначально неправильно определены трудовые затраты, а также не учтены все задачи, которые потребуется выполнить. Я сама оказывалась в такой ситуации, когда из-за ошибки в подсчете времени на тестирование приходилось спешить, стараясь уложиться в срок. Не говорю уже о том, что частым спутником плохого планирования является сверхурочная работа. Каждый раз при планировании своего времени старайтесь брать его с запасом. Прибавьте 30-50% – лучше ошибиться в большую сторону и оставить зазор на более тщательную проверку (или другие задачи), чем тестировать с постоянной оглядкой на часы. Придерживаясь этого правила, вы всегда уложитесь в срок или вообще завершите работу раньше, что само по себе неплохо.
Вывод
Отсутствие времени на тестирование – это всегда неприятно, ведь тестировщикам так хочется как можно качественнее проверить продукт, выполнить как можно больше проверок и в итоге порадовать конечных пользователей прекрасным результатом. Но недостаток времени вовсе не означает, что продукт обязательно получится плохим. Как видите, всегда есть выход – достаточно просто собраться с мыслями и правильно спланировать работу в такой нелегкой ситуации.
Проверьте самое главное, подключите исследовательское тестирование, сверьте продукт с требованиями, отбросьте второстепенное – и тогда вы сможете спать спокойно, зная, что сделали все возможное. Главное – не бояться и идти в бой, смело бросая вызов страшному зверю по имени «Нет времени».