Иногда очень хочется что-то протестировать «по-быстрому».
Чаще всего это не работает, если вы точно не знаете, что делаете и почему.
1.
Вы возглавляете разработку продукта в небольшой компании.Процесс разработки построен на основе двухнедельных итераций; Для заказчика периодически проводятся демонстрации готовых вкусностей.
Ваши разработчики достаточно сильные и опытные, продукт не выглядел слишком сложным, поэтому тестировщиков на проекте не было изначально, нет тестировщиков и сейчас.
За прошедшие с момента старта полгода вы проделали хорошую работу, заказчик в целом доволен ходом работ, хотя, конечно, сбои и неадекватное поведение продукта во время демонстраций его смущают. Последняя демонстрация прошла особенно удачно — из-за технических проблем не удалось показать новые возможности.
Заказчик потребовал уделять больше внимания стабильности и качеству продукта.
По планам, до завершения проекта осталось три с половиной итерации, время разработчиков уже запланировано, и вы решаете нанять тестировщиков, чтобы они быстро все протестировали, убрали хотя бы основные проблемы и тем самым помогли выпустить достаточно хороший продукт. ?-э, это не сработает! Даже если предположить, что в тот момент, когда вы решили нанять тестировщиков, дежурный домовой положил вам на стол список подходящих кандидатов — вам нужно связаться с каждым из них и пригласить к себе.
Те, кому необходимо покинуть нынешнее место работы, и придя к вам, потратить день на обустройство рабочего места.
Короче говоря, между принятием решения и появлением тестировщиков на проекте пройдет две с половиной недели.
Осталось две итерации.
Первая итерация позволит тестировщикам ознакомиться с продуктом и понять — что мы здесь делаем? Ну да ладно, даже если пол-итерации — это неделя, всё равно это достаточно большой срок.
То есть в отведенный срок тестировщики смогут принести хоть какую-то пользу только за последние три недели.
И это будет довольно хаотичная выгода, ведь вы вряд ли дадите им время на анализ ситуации и уточнение ожиданий.
Хорошо, если вы сможете определиться со своими приоритетами.
Итак, три недели.
Но тестировщики лишь находят проблемы и рассказывают о них другим.
Разработчикам предстоит исправить проблемы, время которых, как мы помним, было запланировано еще месяц назад. Часть обнаруженных проблем будет вызвана неверным пониманием того, как работает продукт — вы же не ожидаете, что нюансы логики, разрабатывавшейся за полгода, станут понятны новому человеку через неделю? И наверняка есть нюансы, иначе не было бы проблем при демонстрации продукта заказчику.
Короче говоря, часть проблемы — это мусор.
Но кто-то должен потратить время и понять, есть баг или нет. И кстати, вы ведь не собираетесь исправлять всё, что накопали тестировщики? Кто-то также должен расставить приоритеты в отношении найденных ошибок.
Опять же из-за плохого знакомства с продуктом есть шанс найти кучу мелочей, но не обнаружить серьезную проблему, которую клиент обнаружит на второй день.
В общем, слишком много вопросов и суеты для трёх недель работы неизвестных людей с неизвестным результатом.
2.
Исходные данные те же, есть только одно отличие: вы решили нанять опытных тестировщиков, знакомых с предметной областью: они смогут быстрее приступить к работе и принести больше пользы.Нет, это не сработает. На этот раз я еще спрошу: где вы их будете искать, таких опытных и полезных людей? И когда вы его найдете, как вы пригласите их прийти к вам? В тестировании, как и в программировании (да и в любой другой профессии), ценятся опытные, адекватные специалисты.
Скорее всего, у них все хорошо на нынешнем месте работы.
Эти специалисты не так часто появляются на рынке труда (особенно открытом).
Что вы можете им предложить, что заставит их прийти к вам? Полтора месяца работы над горящим проектом и туманная перспектива, что потом, мол, работы будет больше? Трансформация в руководителя отдела тестирования (на те же полтора месяца)? Кстати, вам самому нужен неопытный менеджер, который еще вчера был хоть и руководителем, но инженером? Но это только начало: наемным тестировщикам придется перестраивать процесс разработки, налаживать коммуникации между тестировщиками и программистами, искать оборудование для рабочих машин и тестовых лабораторий.
Нет, не через полтора месяца :).
3.
Другая ситуация.Тестировщики уже есть и работают. Процессы отлажены (ну более-менее), есть отдельная тестовая среда и т. д. Базовые потребности, так сказать, удовлетворены.
Работа идет полным ходом, проект идет в обычном режиме, в целом все в порядке.
Мне просто очень нужна еще одна функция.
Что ж, она та, которая вам нужна, и она только одна.
А завершение проекта – оно уже на горизонте, и мы, похоже, к этому приближаемся.
Что ж, давайте сделаем и это.
Программисты обещают сделать это на предпоследней итерации.
И давайте быстренько это проверим.
Незачем! Это не сработает! По крайней мере, не в виде «все будет точно так же, только плюс эта особенность».
Это будет не то же самое.
В требованиях будет небольшая двусмысленность.
Программисты поработают еще немного.
Появится пара неучтенных зависимостей в продукте.
Площадь тестирования немного увеличится, а доступное время тестирования уменьшится.
Младший тестировщик заболеет. Все будут спешить и что-то упускать.
Классика.
И очень хороший результат, если ваша маленькая фича не приживётся глубоко в продукте.
Иначе (почти всегда) проблемы появятся где-то еще, немного в стороне, куда забудут посмотреть.
Хорошие автотесты с приличным покрытием помогут, но, боюсь, не спасут: тестирование начали в последний момент, времени на исправление не хватает, да и исправление придется проверять потом.
В общем, будьте готовы, что качество продукта со временем ухудшится.
И хорошо, если функция того стоила.
А еще лучше заранее решить, чем вы готовы пожертвовать ради такой замечательной функции, и заранее отрезать ее.
Иначе какой-то обман самих себя получится иначе.
Хм.
И вообще, будет ли тестирование когда-нибудь работать? В целом да, хотя в этом вопросе, конечно, много вопросов и нюансов.
Даже тестирование «на скорую руку» может быть очень разумным решением — все зависит от приоритетов и целей в реальности.
Но лучше лишний раз не вносить нестабильность в эту и без того достаточно хаотичную систему.
И последнее, но не менее важное: стоит помнить, что тестирование само по себе никому не поможет. Тестировщики могут обнаружить проблему, но исправлять ее придется другим людям.
Привлечение тестировщиков ничего не изменит, если они живут в своем вакуумном сферическом мире.
Мощность приходит при эффективном взаимодействии всех участников процесса — программистов, тестировщиков, менеджеров и других аналитиков.
Теги: #тестирование #планирование #Тестирование ИТ-систем
-
Выпущена Java Se 7
19 Oct, 24 -
Новый Мировой Рекорд: 2 Км На Ховерборде
19 Oct, 24 -
Выбор Зоны Для Вашего Домена
19 Oct, 24 -
Использование Go В Правительстве
19 Oct, 24 -
Еще Одна «Новая Жизнь» Героев
19 Oct, 24
