Ситуация часто встречающаяся и всем известная - "восемь девок, один я" - много разработчиков и мало тестировщиков. Что делать, куда бежать?
Вариант 1. Самый простой, очевидный, никого не напрягающий.
- "Останусь-ка я подольше".
Но потом зачастую выясняется, что и это не спасает.
Вариант 2. Иногда не дающий положительного эффекта.
Привлекаем тестировщиков с других проектов или из других команд. Хоть на день, хоть по два часа в день в течение недели. И то будет помощь в разгружке наших плечей.
Как правило, работает для важных и приоритетных тасок.
Вариант 3. Часто вызывающий сопротивление со стороны разработчиков.
Привлекаем разработчиков для помощи в тестировании. Создание тестовых данных, регистрация аккаунтов, настройка системы, иногда даже непосредственно тестирование - может быть переложено на сильные плечи наших добрых программистов.
Вариант 4. Почти сказочный.
Договариваемся о переносе сроков в связи с тем, что функционал не будет как следует протестирован к назначенному сроку.
Мини-памятка:
Когда происходит частое изменение условий работы (например, на тестирование в процессе работы над уже оговоренным скоупом в него добавляются новые таски) - следует не забывать
- каждый день мониторить изменения
- заново оценивать необходимое на тестирование время, исходя из изменений
- не стесняться просить о помощи
- пытаться подключать к работе всех, кого только можно (безусловно, если таска достаточно важная).
Showing posts with label эстимейт. Show all posts
Showing posts with label эстимейт. Show all posts
September 8, 2011
May 12, 2010
Иди туда, не знаю куда, проэстимейть то, не знаю что
Передо мной встал вопрос эстимейта всего тестирования нового продукта, что для меня впервые. Почитав в интернете об этом нелегком деле, так и не решила, как же мне его эстимейтить. Предлагали много вариантов:
- 0-400% от времени разработки (как-то слишком неопределенно)
- 40-50% от времени разработки (что меня тоже не устроило, потому что продукт будет разрабатывать Джуниор-программист без опыта нормальных эстимейтов)
- рассчитать примерно и умножить на два (хороший метод для больших проектов, однако если сделать так в маленьком - предполагаемый бюджет может испугать кастомера)
- привязываться к модулям и примерному количеству тестов (этот вариант мне понравился больше, однако эстимейты будут очень"примерные", потому что,как правило, тестировщику трудно увидеть все подводные камни,на которые натолкнется программа после ее реализации, а не "на бумаге").
Я проэстимейтила все вручную,разбив задание на более мелкие:
1. Выявление требований
2. Создание спецификации
3. Последующая поддержка спецификации
4. Написание тест плана
на каждый вид тестирования,который будет проводиться, было выделено время отдельно, также как и на написание плана на фичу\модуль
5. Ревью и поддержка тест плана
учитывая,что проект небольшой, для экономии времени я приняла решение, что ревьювер должен сам исправлять и добавлять тесты, просто отмечая их другим цветом, например, в экселе или просто включить Review Changes в мапе)
6. Полное тестирование первого билда
Первый проход всех тестов нвоого проекта составляет больше времени,чем следует выделять на регресионное тестирование одного билда, поэтому я выделила это время в отдельную ветку.
7. Регресионное тестирование
Обсудив с SEO количество билдов, которое предполагается в данном проекте, методом "пальцев в небо" было выбрано количество, которое составляло среднее значение между тем, на сколько рассчитывал SEO, программист и я :) Теперь я знаю, что самый большой оптимист - SEO :))
Так вот,вернемся к эстимейтам. Взяв выбранное количество билдов, я умножила время прохождения тестов по одному модулю\фиче на их количество. Исключение составили такие штуки как Инсталляция и Лицензирование - в нашей компании эти модули не тестируются в каждой итерации, так что время регрессионного тестирования на них я выделила как Время прохождения тестов модуля *Количество билдов\2.
8. Проверка багфикса.
Программист отвел себе на багфикс 1 день, что меня улыбнуло :)
Я же прикинула так - на каждый билд по 3 часа на проверку тикетов (это значение будет зависеть от сложности проекта. Мой, как я уже говорила, маленький и довольно простой).
Ну и, конечно, каждую часть множила не на два, а на 1.25-1.3, из расчета, что проект могу тестировать не я, а падаваны :)
В заключение хочу сказать,что мой эстимейт превысил время разработки проекта, но я никак не могу придумать, где могу сократить. А значит, оставим, как есть и посмотрим через пару месяцев, насколько эстимейт был правильным :)
- 0-400% от времени разработки (как-то слишком неопределенно)
- 40-50% от времени разработки (что меня тоже не устроило, потому что продукт будет разрабатывать Джуниор-программист без опыта нормальных эстимейтов)
- рассчитать примерно и умножить на два (хороший метод для больших проектов, однако если сделать так в маленьком - предполагаемый бюджет может испугать кастомера)
- привязываться к модулям и примерному количеству тестов (этот вариант мне понравился больше, однако эстимейты будут очень"примерные", потому что,как правило, тестировщику трудно увидеть все подводные камни,на которые натолкнется программа после ее реализации, а не "на бумаге").
Я проэстимейтила все вручную,разбив задание на более мелкие:
1. Выявление требований
2. Создание спецификации
3. Последующая поддержка спецификации
4. Написание тест плана
на каждый вид тестирования,который будет проводиться, было выделено время отдельно, также как и на написание плана на фичу\модуль
5. Ревью и поддержка тест плана
учитывая,что проект небольшой, для экономии времени я приняла решение, что ревьювер должен сам исправлять и добавлять тесты, просто отмечая их другим цветом, например, в экселе или просто включить Review Changes в мапе)
6. Полное тестирование первого билда
Первый проход всех тестов нвоого проекта составляет больше времени,чем следует выделять на регресионное тестирование одного билда, поэтому я выделила это время в отдельную ветку.
7. Регресионное тестирование
Обсудив с SEO количество билдов, которое предполагается в данном проекте, методом "пальцев в небо" было выбрано количество, которое составляло среднее значение между тем, на сколько рассчитывал SEO, программист и я :) Теперь я знаю, что самый большой оптимист - SEO :))
Так вот,вернемся к эстимейтам. Взяв выбранное количество билдов, я умножила время прохождения тестов по одному модулю\фиче на их количество. Исключение составили такие штуки как Инсталляция и Лицензирование - в нашей компании эти модули не тестируются в каждой итерации, так что время регрессионного тестирования на них я выделила как Время прохождения тестов модуля *Количество билдов\2.
8. Проверка багфикса.
Программист отвел себе на багфикс 1 день, что меня улыбнуло :)
Я же прикинула так - на каждый билд по 3 часа на проверку тикетов (это значение будет зависеть от сложности проекта. Мой, как я уже говорила, маленький и довольно простой).
Ну и, конечно, каждую часть множила не на два, а на 1.25-1.3, из расчета, что проект могу тестировать не я, а падаваны :)
В заключение хочу сказать,что мой эстимейт превысил время разработки проекта, но я никак не могу придумать, где могу сократить. А значит, оставим, как есть и посмотрим через пару месяцев, насколько эстимейт был правильным :)
Subscribe to:
Posts (Atom)