Иногда очень хочется что-то протестировать «по-быстрому». Чаще всего это плохо работает, если только вы не знаете точно, что делаете и зачем.
Вы руководите разработкой продукта в небольшой компании. Процесс разработки построен на базе двухнедельных итераций, периодически проводятся демо готовых вкусняшек для заказчика. Разработчики у вас достаточно сильные и опытные, продукт не выглядел чересчур сложным, так что тестировщиков на проекте изначально не было, и сейчас тоже нет.
За уже прошедшие со старта полгода вы неплохо поработали, заказчик в целом доволен ходом работ, хотя, конечно, падения и неадекватное поведение продукта во время демонстраций его смущают. Последняя демонстрация особенно удалась – из-за возникших технических проблем показать новые фичи не получилось. Заказчик потребовал больше внимания уделять стабильности и качеству продукта.
По планам до завершения проекта осталось три с половиной итерации, время разработчиков уже распланировано, и вы решаете нанять тестировщиков – чтоб они быстренько все протестировали, выгребли хотя бы основные проблемы и помогли тем самым выпустить достаточно хороший продукт.
Эй, это не сработает!
Даже если предположить, что в момент, когда вы решили нанять тестировщиков, дежурный домовой положил вам на стол список подходящих кандидатов – вам надо связаться с каждым из них и позвать к себе. Тем надо уволиться с текущего места работы, а придя к вам – потратить день на настройку рабочего места. Короче, между принятием решения и появлением тестировщиков на проекте пройдет две с половиной недели. Осталось две итерации.
Первая итерация у тестировщиков уйдет на знакомство с продуктом и понимание – а что мы тут вообще делаем? Ну ладно, пусть даже половина итерации – неделя это все-таки довольно много.
То есть в отведенные сроки хоть какую-то пользу тестировщики смогут приносить только в последние три недели. И– это будет довольно хаотическая польза, ведь едва ли вы дадите им время на анализ ситуации и уточнение ожиданий. Хорошо еще если получится определиться с приоритетами.
Итак, три недели. Но тестировщики только находят проблемы и рассказывают о них другим. Чинить проблемы придется разработчикам, время которых, как мы помним, было распланировано еще месяц назад.
Часть найденных проблем будут вызваны неверным пониманием работы продукта – вы же не ожидаете, что нюансы логики, разрабатывавшейся полгода, станут ясны новому человеку за неделю? А нюансы наверняка есть, иначе не возникало бы проблем на демонстрациях продукта заказчику. Короче, часть проблем – мусор. Но кто-то должен потратить время и понять, есть тут баг или нет.
И кстати, вы же не собираетесь чинить все, что тестировщики накопают? Кто-то должен еще и приоритеты найденным багам расставлять.
Опять же из-за слабого знакомства с продуктом есть шанс найти кучу мелочей, но не обнаружить серьезную проблему, на которую заказчик наступит на второй день.
В общем, слишком много вопросов и суеты ради трехнедельной работы неизвестных людей с неизвестным результатом.
Исходные данные те же, разница только одна: вы решили нанять опытных тестировщиков, знакомых с предметной областью: они-то смогут быстрее включиться в работу и принесут больше пользы.
Нет, не сработает.
В этот раз все-таки спрошу: где вы их будете искать, таких опытных и полезных? А когда найдете – как будете зазывать к себе?
В тестировании, как и в программировании (да и любой другой профессии), опытные, адекватные профессионалы ценятся. Скорее всего, им и на текущем месте работы хорошо. На рынке труда (особенно открытом) эти специалисты появляются не так часто.
Что вы им сможете предложить такого, что они пойдут к вам? Полтора месяца работы на горящем проекте и туманную перспективу, что потом, мол, еще будет работа? Превращение в руководителя отдела тестирования (на те же полтора месяца)? Кстати, а вам самим-то нужен неопытный руководитель, еще вчера бывший пусть ведущим, но инженером?
А ведь это только начало: под нанятых тестировщиков придется перестраивать процесс разработки, налаживать коммуникации между тестировщиками и программистами, искать железо для рабочих машин и тестовых лаб.
Нет, не за полтора месяца :).
Другая ситуация.
Тестировщики уже есть и работают. Процессы отлажены (ну, более-менее), есть отдельное тестовое окружение и т.д. Базовые потребности, так сказать, удовлетворены.
Работа кипит, проект идет своим чередом, все в порядке в общем-то.
Только очень хочется еще одну фичу. Ну вот она нужная такая, и всего одна. И завершение проекта – оно же уже виднеется, и вроде укладываемся. Ну давайте и эту тоже – сделаем.
Программисты обещают сделать в предпоследней итерации. И – протестируем по-быстрому.
Не надо! Не сработает!
Во всяком случае не в виде «все будет точно так же, только еще плюс вот эта фича». Не будет так же.
Будет – немножко неясности в требованиях. Чуть дольше поработают программисты. Всплывут пара неучтенных зависимостей в продукте. Область тестирования слегка увеличится, доступное время на тестирование уменьшится. Младший тестировщик заболеет. Все будут торопиться и что-то упустят.
Классика.
И очень хороший результат – это если ваша маленькая фича не пустила корни глубоко в продукт. Иначе (почти всегда) проблемы появятся где-то еще, немного в стороне, куда и посмотреть-то забудут.
Хорошие автотесты с приличным покрытием помогут, но, боюсь, не спасут: тестировать-то начали в последний момент, времени на починку мало, а надо же еще и потом фикс проверять…
В общем, будьте готовы, что качество продукта в итоге просядет. И хорошо, если фича того стоила. А еще лучше – заранее решить, чем вы готовы поступиться ради такой замечательной фичи, и – заранее же отрезать.
А то ж обман какой-то самих себя получится иначе.
Вообще – да, хотя в этом деле много вопросов и нюансов, конечно.
Даже протестировать «по-быстрому» может оказаться очень разумным решением – все зависит от приоритетов и задач на самом деле.
Но лучше лишний раз не вносить нестабильность в эту и так вполне себе хаотическую систему.
И last but not the least стоит помнить, что тестирование само по себе никому ничем не поможет. Тестировщики могут найти проблему, но чинить ее придется другим людям. Привлечение тестировщиков ничего не изменит, если они будут жить в своем вакуумном шарообразном мире. Сила приходит с эффективным взаимодействием всех участников процесса – программистов, тестировщиков, руководителей и прочих аналитиков.
1.
Вы руководите разработкой продукта в небольшой компании. Процесс разработки построен на базе двухнедельных итераций, периодически проводятся демо готовых вкусняшек для заказчика. Разработчики у вас достаточно сильные и опытные, продукт не выглядел чересчур сложным, так что тестировщиков на проекте изначально не было, и сейчас тоже нет.
За уже прошедшие со старта полгода вы неплохо поработали, заказчик в целом доволен ходом работ, хотя, конечно, падения и неадекватное поведение продукта во время демонстраций его смущают. Последняя демонстрация особенно удалась – из-за возникших технических проблем показать новые фичи не получилось. Заказчик потребовал больше внимания уделять стабильности и качеству продукта.
По планам до завершения проекта осталось три с половиной итерации, время разработчиков уже распланировано, и вы решаете нанять тестировщиков – чтоб они быстренько все протестировали, выгребли хотя бы основные проблемы и помогли тем самым выпустить достаточно хороший продукт.
Эй, это не сработает!
Даже если предположить, что в момент, когда вы решили нанять тестировщиков, дежурный домовой положил вам на стол список подходящих кандидатов – вам надо связаться с каждым из них и позвать к себе. Тем надо уволиться с текущего места работы, а придя к вам – потратить день на настройку рабочего места. Короче, между принятием решения и появлением тестировщиков на проекте пройдет две с половиной недели. Осталось две итерации.
Первая итерация у тестировщиков уйдет на знакомство с продуктом и понимание – а что мы тут вообще делаем? Ну ладно, пусть даже половина итерации – неделя это все-таки довольно много.
То есть в отведенные сроки хоть какую-то пользу тестировщики смогут приносить только в последние три недели. И– это будет довольно хаотическая польза, ведь едва ли вы дадите им время на анализ ситуации и уточнение ожиданий. Хорошо еще если получится определиться с приоритетами.
Итак, три недели. Но тестировщики только находят проблемы и рассказывают о них другим. Чинить проблемы придется разработчикам, время которых, как мы помним, было распланировано еще месяц назад.
Часть найденных проблем будут вызваны неверным пониманием работы продукта – вы же не ожидаете, что нюансы логики, разрабатывавшейся полгода, станут ясны новому человеку за неделю? А нюансы наверняка есть, иначе не возникало бы проблем на демонстрациях продукта заказчику. Короче, часть проблем – мусор. Но кто-то должен потратить время и понять, есть тут баг или нет.
И кстати, вы же не собираетесь чинить все, что тестировщики накопают? Кто-то должен еще и приоритеты найденным багам расставлять.
Опять же из-за слабого знакомства с продуктом есть шанс найти кучу мелочей, но не обнаружить серьезную проблему, на которую заказчик наступит на второй день.
В общем, слишком много вопросов и суеты ради трехнедельной работы неизвестных людей с неизвестным результатом.
2.
Исходные данные те же, разница только одна: вы решили нанять опытных тестировщиков, знакомых с предметной областью: они-то смогут быстрее включиться в работу и принесут больше пользы.
Нет, не сработает.
В этот раз все-таки спрошу: где вы их будете искать, таких опытных и полезных? А когда найдете – как будете зазывать к себе?
В тестировании, как и в программировании (да и любой другой профессии), опытные, адекватные профессионалы ценятся. Скорее всего, им и на текущем месте работы хорошо. На рынке труда (особенно открытом) эти специалисты появляются не так часто.
Что вы им сможете предложить такого, что они пойдут к вам? Полтора месяца работы на горящем проекте и туманную перспективу, что потом, мол, еще будет работа? Превращение в руководителя отдела тестирования (на те же полтора месяца)? Кстати, а вам самим-то нужен неопытный руководитель, еще вчера бывший пусть ведущим, но инженером?
А ведь это только начало: под нанятых тестировщиков придется перестраивать процесс разработки, налаживать коммуникации между тестировщиками и программистами, искать железо для рабочих машин и тестовых лаб.
Нет, не за полтора месяца :).
3.
Другая ситуация.
Тестировщики уже есть и работают. Процессы отлажены (ну, более-менее), есть отдельное тестовое окружение и т.д. Базовые потребности, так сказать, удовлетворены.
Работа кипит, проект идет своим чередом, все в порядке в общем-то.
Только очень хочется еще одну фичу. Ну вот она нужная такая, и всего одна. И завершение проекта – оно же уже виднеется, и вроде укладываемся. Ну давайте и эту тоже – сделаем.
Программисты обещают сделать в предпоследней итерации. И – протестируем по-быстрому.
Не надо! Не сработает!
Во всяком случае не в виде «все будет точно так же, только еще плюс вот эта фича». Не будет так же.
Будет – немножко неясности в требованиях. Чуть дольше поработают программисты. Всплывут пара неучтенных зависимостей в продукте. Область тестирования слегка увеличится, доступное время на тестирование уменьшится. Младший тестировщик заболеет. Все будут торопиться и что-то упустят.
Классика.
И очень хороший результат – это если ваша маленькая фича не пустила корни глубоко в продукт. Иначе (почти всегда) проблемы появятся где-то еще, немного в стороне, куда и посмотреть-то забудут.
Хорошие автотесты с приличным покрытием помогут, но, боюсь, не спасут: тестировать-то начали в последний момент, времени на починку мало, а надо же еще и потом фикс проверять…
В общем, будьте готовы, что качество продукта в итоге просядет. И хорошо, если фича того стоила. А еще лучше – заранее решить, чем вы готовы поступиться ради такой замечательной фичи, и – заранее же отрезать.
А то ж обман какой-то самих себя получится иначе.
Гм. А вообще – хоть когда-то тестирование сработает?
Вообще – да, хотя в этом деле много вопросов и нюансов, конечно.
Даже протестировать «по-быстрому» может оказаться очень разумным решением – все зависит от приоритетов и задач на самом деле.
Но лучше лишний раз не вносить нестабильность в эту и так вполне себе хаотическую систему.
И last but not the least стоит помнить, что тестирование само по себе никому ничем не поможет. Тестировщики могут найти проблему, но чинить ее придется другим людям. Привлечение тестировщиков ничего не изменит, если они будут жить в своем вакуумном шарообразном мире. Сила приходит с эффективным взаимодействием всех участников процесса – программистов, тестировщиков, руководителей и прочих аналитиков.