Процесс, который камень точит.... (источник: https://alexeybulat.blogspot.com/2011/10/blog-post.html)
Старик убрал седые волосы с морщинистого лба и взглянул на сидящих учеников. Минуту стояла тишина, перебиваемая лишь шорохом ветра.
- Я расскажу вам, что вас ждет, что вам надо будет выучить и что - сделать. Слушайте внимательно и не упускайте ни одной мелочи...
Тестирование начинается не с того момента, когда вам дали рабочее приложение, а намного раньше - как только пошли слухи, что команда будет работать над проектом, можно считать, что вы уже приступили. В голове начинают полниться и томиться мысли-вопросы о том:
- какой ОН - этот проект?
- какие у него будут фичи?
- какие тесты вы проведете?
- какие интересные дефекты вы там найдете?
Вы уже предвкушаете кайф, который чувствует ребенок, получая новую долгожданную игрушку.
И вот пришло время, вы получаете первый комплект артефактов: спецификации, мокапы, планы...
Старик замолчал на мгновение, вспоминая свой первый тест план.
- Учитель, а что же дальше? Что дальше? - зашептали ученики почти в один голос.
- Не перебивайте, будьте терпеливей. - сказал старик и продолжил...
Как заправские тестировщики, имеющие за спиной, как боль поражений, так и радость побед, прошедшие сотни сражений с разными заказчиками, менеджерами, разработчиками, админами и с самим собой, вы начинаете готовиться. Пишите тест план, разрабатываете тест кейсы, оцениваете необходимость использования автоматизации, как нагрузочного, так и функционального тестирования.
- Учитель, а что такое автоматизация? - перебил его очкарик в первом ряду.
- Это невиданная сила, это дракон, запертый в ящик пандоры, это то, о чем я вам расскажу, когда вы будете готовы. - сказал старый учитель, доставая из кармана курительную трубку...
Время прошло, и вся документация готова. На каждую ситуацию у вас есть готовая процедура, на каждую функцию готовый комплект тест кейсов. Время расписано по часам. Осталось совсем немного - воплотить, разработанный план в жизнь, и не упустить ничего из виду.
Разработчики подготовили первый билд и небрежно кидают его вам, и просят левым глазком взглянуть на него. Не проходит и часа, как вы уже возвращаете его назад и говорите, что "ЭТО" тестировать невозможно, что через клик приложение "валится", да и ни одна функция не работает, как того требует спецификация. Говорите, что все найденные дефекты записаны в багтрекер и отправляете отчет "smoke test failed!!!"
Проектный менеджер вроде бы доволен, что тестировщики знают свое дело, но вот если так и дальше пойдет, то в сроки проект не впишется. Температура его мозга начинает подниматься...
Руководитель разработки уже не рад, что взял на этот проект двух студентов без опыта, а ведущего программиста отправил в отпуск... Но что поделать, надо работать...
- Учитель, а зачем надо дефекты в багтрекер заносить? Ведь эту версию-то все равно возвращаем обратно. - Спросила рыжая девочка с ярко зеленым глазами.
- Всегда надо иметь то, на основании чего мы должны принять приложение в тестирование. Назовем это критериями начала тестирования. В данном случае эти критерии не выполнены, так как основные функции работают крайне плохо или не работают вообще. Если вы просто скажете, что все плохо, то разработчики не будут знать, что им надо исправить. А записав дефекты в багтрекер вы всем показываете, что именно не работает и на основании чего вы не приняли приложение в тестирование. - спокойно сказал учитель, затягивая сладкий табак в легкие.
- Учитель, а зачем вообще нужен этот smoke test? Неужели без него нельзя? - спросил паренек в малиновом пиджаке.
- Без него то, конечно можно. Но с ним как-то сподручнее. Дымовой тест - делается для того, чтобы понять, можно ли вообще тестировать приложение или нет, соответствует ли оно требуемым критериям качества для начала тестирования или нет. Нет смысла проверять то, как далеко стреляет лук, если тетива на нем не натянута, да и стрела кривая. - с ухмылкой ответил учитель и продолжил...
К утру следующего дня вам дают новый билд, однако уже с ним приходит письмо со списком того, что якобы готово на 100%, а что пока трогать нет смысла, т.к. ребята в поте лица стараются сделать все, что в их силах, но пока "никак не выходит у них каменный цветок".
На этот раз Вас не обманули - все критические баги, находящиеся на поверхности, были исправлены. С гордостью за разработчиков и за их труды вы отправляете отчет, что smoke test passed.
Менеджер проекта доволен, руководитель разработки улыбается, т.к. он единственный кто знает, что творится в коде :)
Вы же, открыв багтрекер, начинаете регрессионное тестирование (Regression testing) и санитарное тестирование (Sanity testing). Вы перепроверяете дефекты, которые разработчики перевели в статус Fixed (Исправлено), Rejected, Can't Reproduce и т.д. Замечу, что статусы Rejected и Can't Reproduce для вас самые неприятные - это явное свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не очень понятно описали шаги для воспроизведения, либо разработчик поленился воспроизвести ситуацию.
- Учитель, а как надо закрывать дефекты и причем тут эти “регрессионное и санитарное” тестирования? - поинтересовалась девочка с iPhone-ом в руке
- Дефект проверить не проблема - проходите все описанные шаги, проверяете результат и все. Однако, исправив одно, разработчик мог сломать что-то другое. Проверив четко по шагам, надо сделать еще несколько тестов, чтобы убедиться в том, что вокруг тоже все работает как и раньше. Вот для этого мы и проводим эти самые “регрессионное и санитарное тестирования”. - Поучительно сказал старик, сделав очередную затяжку курительной трубки.
Покончив с закрытием и пере-открытием дефектов, вы переходите к основной работе - централизованному тестированию по тест кейсам и/или (если вы адепт исследовательского тестирования) вы начинаете упорно исследовать приложение :)
И вот больше тестировать нечего, и все, что было запланировано, пройдено. В итоге, вы имеете результаты прогона тест кейсов, баг репорты, вопросы к аналитикам и заметки на полях своих тетрадей. Основываясь на всем этом, вы составляете отчет по проведенному тестированию и отправляете его на проектную группу.
Менеджер проекта закипает от количества дефектов и ужасного качества, не обращая внимания на то, что это всего навсего вторая попавшая в тестирование версия.
Руководитель разработки начинает проникаться уважением к тестировщикам, нашедшим несколько десятков интересных дефектов. Легким движением багтрекера он назначает их на разработчиков, и понеслось все сначала...
- Учитель, а-а что лучше: т-тестирование по т-т-тест кейсам или и-и-исследовательское? Какой путь в-в-выбрать? - заикаясь спросил кучерявый ботаник на первой парте.
- На протяжении века идет спор. Лучшие тестировщики нового и старого света уходили ни с чем с поля боя. У каждого из них были свои доводы и результаты, но никто из них не смог доказать свою правоту. Что посоветую вам я, так это совместить оба подхода, всегда планировать как тестирование по тест кейсам, так и исследовательское тестирование. Пройдя все тест кейсы, потратьте несколько часов на “свободный полет”, проверьте все, что по-вашему можно проверить еще. И будет вам почет и уважение. - сказал старик, вспоминая дефекты найденные по тест кейсам и во время исследования.
Дальше все идет по накатанной: новые билды, пройденные и не пройденные дымовые тесты, то закипающий, то остывающий мозг проектного менеджера, то гнев, то милость руководителя разработки. Однако, через какое-то время сойдётся "задачка с ответом" - результаты тестирования сойдутся, с прописанными в плане тестирования, критериями окончания тестирования.
* * * * * * * * * * * *
- На этом мы закончим сие поверхностное описание процесса тестирования. Надеюсь что вы запомнили, последовательность выполненных видов тестирования: