В чем заключаются основные подходы к тестированию, в чем их сильные и слабые стороны? Ян Яап Каннегитер рассказывает о том, как определить, какой метод лучше использовать в каждом конкретном случае.
В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.
Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).
Действительно, в те времена именно это называлось тестированием. Я применял на практике то, чему она меня учила, и был успешен в этом. Сегодня, спустя почти 20 лет, я изменил свое мнение о тестировании. Я считаю, что не существует единого подхода, который бы работал для всех и давал бы возможность провести самое лучшее тестирование. Выбранные методы зависят от ваших проектов, от ситуации, от вашей организации, от системы, с которой вы работаете.
Я расскажу о разных подходах к тестированию и постараюсь научить вас определять, какой из них лучше всего подойдет в вашем случае.
Двадцать лет назад разработка почти всех систем происходила примерно одинаково. Между системами не было таких серьезных различий, как в наши дни. Вот основные изменения, которые произошли с тех пор:
Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).
Основная особенность сценарного тестирования в том, что вы начинаете с того, что делите задачу на этапы (подготовка, выполнение, завершение и пр.) и затем стараетесь производить все действия согласно этим этапам. То есть этот подход можно охарактеризовать как «я думаю на этим заранее и затем выполняю».
Исследовательское тестирование подразумевает совершенно иной подход – разработка процесса тестирования происходит непосредственно во время работы. Тестирование начинается с некой важной точки, в процессе появляются другие важные точки тестирования, и каждый раз специалист решает, какая из них наиболее важна и в каком направлении двигаться дальше. То есть продумывание и запуск тестов происходят в постоянном взаимодействии.
Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Я думаю, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.
Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.
Почему я расположил их в таком порядке? Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.
Профессиональный тестировщик должен знать о каждом из этих подходов и понимать, какой из них лучше всего подойдет в каждом конкретном случае.
Разберем эти направления в тестировании подробнее.
В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.
Если мы тестируем, скажем, почту, то подробное сценарное тестирование может выглядеть так:
Для этого же примера сценарий общего тестирования может выглядеть так:
Если человек, который готовит тесты и выполняет их, – одно и то же лицо, не имеет никакого смысла делать их слишком детализированными. Поэтому подумайте, стоит ли тратить столько времени на подготовку подробного сценарного тестирования? Возможно, сценария общего тестирования будет вполне достаточно.
В те времена, когда исследовательское тестирование только появилось, многие не понимали, чем занимаются тестировщики. Они начинали работу без предварительного планирования, без объяснений относительно того, что и как они собираются делать. Поэтому для многих людей исследовательское тестирование представлялось одним огромным облаком. Позже кто-то умный решил разделить это облако на небольшие облака, соответствующие сессиям. Так и возникло сессионное тестирование.
При использовании этого подхода у тестировщика есть точки тестирования, с которыми он собирается работать на протяжении одной сессии, небольшой объем документации, которому он должен следовать. Но при этом у него гораздо больше свободы, чем в случае с подробным сценарным тестированием, и это делает его счастливым (именно поэтому я поместил улыбки на иллюстрации).
Сессионное тестирование предусматривает наличие:
Поиск багов имеет много общего с сессионным тестированием, но есть и важные отличия. В поиске багов принимают участие не только тестировщики, но и разработчики, а также пользователи.
Сессия поиска багов может длиться дольше, чем сессия тестирования. Так, для сессии поиска багов нормальной считается продолжительность от трех до четырех часов, а при сессионном тестировании уже через два часа, как правило, необходимо делать перерыв. Кроме этого, во время поиска багов работа обычно ведется парами (тестировщик плюс пользователь), и целью такой сессии является не только получение информации, но и одобрение системы пользователями.
В интернете можно прочитать, что исследовательское тестирование – это такой прием тестирования. На самом деле это не просто прием, а полноценный подход к тестированию, позволяющий выполнить полное тестирование систем.
Некоторые говорят, что исследовательское тестирование не имеет структуры. Это тоже неправда. После завершения тестирования вы можете иметь столько документации, сколько захотите, просто вы не разрабатываете ее наперед.
При проведении исследовательского тестирования акцент делается на личной свободе и ответственности тестировщика. Оно предполагает постоянный поиск ответов на вопросы: «как сделать лучше?», «какие тесты сейчас наиболее важны?». Вы не просто делаете то, что написано в сценарии, вы постоянно думаете. Кроме этого, все этапы тестирования (проектирование, выполнение, интерпретация результатов и пр.) проходят не последовательно, а параллельно на протяжении всего проекта.
При проведении исследовательского тестирования иногда бывать сложно сфокусироваться на чем-то конкретном. И в этом случае помогают исследовательские туры. Туры отражают основные цели и задачи, которые ставятся при проведении тестирования.
В этой связи я хотел бы привести цитату Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».
В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:
Итак, основные отличия исследовательского тестирования от сценарного представлены в таблице ниже:
Каждый раз, когда я провожу эту презентацию, я делаю одну и ту же ошибку – у всех возникает чувство, что исследовательское тестирование лучше сценарного. Это не так. Сценарное тестирование так же ценно, как и исследовательское, но тут все зависит от ситуации.
Однако эффективность исследовательского тестирования все же выше, чем сценарного. Это доказывается различными исследованиями. В частности, в 2007 году проводилось исследование, в котором принимало участие две команды. Они одновременно работали над тестированием одного и того же приложения, причем первая использовала сценарное тестирование, а вторая – исследовательское. Затем они тестировали второе приложение, но теперь первая команда использовала исследовательское тестирование, а вторая – сценарное. Это исследование показало, что при исследовательском тестировании эффективность обнаружения ошибок была намного выше. Подобные результаты были получены и при проведении других исследований эффективности методов тестирования.
По своему опыту могу сказать, что на выбор подхода к тестированию влияет множество факторов. Среди них: время, бюджет, цели, цели тестирования, навыки тестировщиков, система, метод разработки, документация, тип организации.
В таблице ниже я привожу некоторые особенности организаций и систем, а также распространенные цели. Вы можете увидеть, какой из методов подходит лучше в каждой ситуации, но стоит иметь в виду, что во многих случаях имеет смысл применять оба метода, даже если это не указано в таблице. Всегда старайтесь мыслить критически и адаптировать информацию к вашей ситуации.
Так какой из подходов к тестированию работает лучше всего? Ответ очевиден: все зависит от ситуации. Но я считаю, что в будущем тестирование программного обеспечения будет представлять собой комбинацию автоматизированного и исследовательского тестирования. Поэтому каждому специалисту стоит изучить, хорошо знать и применять оба метода.
Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:
В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.
Почему существуют разные подходы к тестированию?
Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).
Действительно, в те времена именно это называлось тестированием. Я применял на практике то, чему она меня учила, и был успешен в этом. Сегодня, спустя почти 20 лет, я изменил свое мнение о тестировании. Я считаю, что не существует единого подхода, который бы работал для всех и давал бы возможность провести самое лучшее тестирование. Выбранные методы зависят от ваших проектов, от ситуации, от вашей организации, от системы, с которой вы работаете.
Я расскажу о разных подходах к тестированию и постараюсь научить вас определять, какой из них лучше всего подойдет в вашем случае.
Двадцать лет назад разработка почти всех систем происходила примерно одинаково. Между системами не было таких серьезных различий, как в наши дни. Вот основные изменения, которые произошли с тех пор:
- Гибкость в разработке преобладает над четким планированием.
- Мы больше ориентируемся на мастерство, чем на методы.
- Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
- Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
- Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.
Основные подходы к тестированию
Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).
Основная особенность сценарного тестирования в том, что вы начинаете с того, что делите задачу на этапы (подготовка, выполнение, завершение и пр.) и затем стараетесь производить все действия согласно этим этапам. То есть этот подход можно охарактеризовать как «я думаю на этим заранее и затем выполняю».
Исследовательское тестирование подразумевает совершенно иной подход – разработка процесса тестирования происходит непосредственно во время работы. Тестирование начинается с некой важной точки, в процессе появляются другие важные точки тестирования, и каждый раз специалист решает, какая из них наиболее важна и в каком направлении двигаться дальше. То есть продумывание и запуск тестов происходят в постоянном взаимодействии.
Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Я думаю, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.
Промежуточные подходы к тестированию
Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.
Почему я расположил их в таком порядке? Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.
Профессиональный тестировщик должен знать о каждом из этих подходов и понимать, какой из них лучше всего подойдет в каждом конкретном случае.
Разберем эти направления в тестировании подробнее.
Подробное сценарное и общее сценарное тестирование (Detailed Scripting & Global scripting)
В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.
Если мы тестируем, скажем, почту, то подробное сценарное тестирование может выглядеть так:
- Перейдите на стартовую страницу
- Нажмите на кнопку «Новый»
- В поле «Кому» напишите j.cannegieter@squerist.nl
- Нажмите на кнопку «Файл»
- Выберите документ «Тест1»
- В поле «Тема» напишите «Тестовое вложение <дата>»
- Откройте почтовый ящик jcannegieter
- Проверьте, доставлено ли сообщение и вложение.
Для этого же примера сценарий общего тестирования может выглядеть так:
- Создайте и отправьте письмо с вложением одному получателю
- Проверьте, доставлено ли сообщение и вложение
Если человек, который готовит тесты и выполняет их, – одно и то же лицо, не имеет никакого смысла делать их слишком детализированными. Поэтому подумайте, стоит ли тратить столько времени на подготовку подробного сценарного тестирования? Возможно, сценария общего тестирования будет вполне достаточно.
Сессионное тестирование и поиск багов (Session Based Testing & Bug Hunts)
В те времена, когда исследовательское тестирование только появилось, многие не понимали, чем занимаются тестировщики. Они начинали работу без предварительного планирования, без объяснений относительно того, что и как они собираются делать. Поэтому для многих людей исследовательское тестирование представлялось одним огромным облаком. Позже кто-то умный решил разделить это облако на небольшие облака, соответствующие сессиям. Так и возникло сессионное тестирование.
При использовании этого подхода у тестировщика есть точки тестирования, с которыми он собирается работать на протяжении одной сессии, небольшой объем документации, которому он должен следовать. Но при этом у него гораздо больше свободы, чем в случае с подробным сценарным тестированием, и это делает его счастливым (именно поэтому я поместил улыбки на иллюстрации).
Сессионное тестирование предусматривает наличие:
- Сессий тестирования.
- Миссии и точки тестирования / идей для тестирования.
- Заметок во время сессии.
- Отчета после сессии (что мы обнаружили, каково качество системы и пр.).
Поиск багов имеет много общего с сессионным тестированием, но есть и важные отличия. В поиске багов принимают участие не только тестировщики, но и разработчики, а также пользователи.
Сессия поиска багов может длиться дольше, чем сессия тестирования. Так, для сессии поиска багов нормальной считается продолжительность от трех до четырех часов, а при сессионном тестировании уже через два часа, как правило, необходимо делать перерыв. Кроме этого, во время поиска багов работа обычно ведется парами (тестировщик плюс пользователь), и целью такой сессии является не только получение информации, но и одобрение системы пользователями.
Исследовательское тестирование и туры (Exploratory Testing & Test Tours)
В интернете можно прочитать, что исследовательское тестирование – это такой прием тестирования. На самом деле это не просто прием, а полноценный подход к тестированию, позволяющий выполнить полное тестирование систем.
Некоторые говорят, что исследовательское тестирование не имеет структуры. Это тоже неправда. После завершения тестирования вы можете иметь столько документации, сколько захотите, просто вы не разрабатываете ее наперед.
При проведении исследовательского тестирования акцент делается на личной свободе и ответственности тестировщика. Оно предполагает постоянный поиск ответов на вопросы: «как сделать лучше?», «какие тесты сейчас наиболее важны?». Вы не просто делаете то, что написано в сценарии, вы постоянно думаете. Кроме этого, все этапы тестирования (проектирование, выполнение, интерпретация результатов и пр.) проходят не последовательно, а параллельно на протяжении всего проекта.
При проведении исследовательского тестирования иногда бывать сложно сфокусироваться на чем-то конкретном. И в этом случае помогают исследовательские туры. Туры отражают основные цели и задачи, которые ставятся при проведении тестирования.
В этой связи я хотел бы привести цитату Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».
В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:
- Тур по функциям – протестировать все функциональные возможности приложения.
- Тур по требованиям – протестировать на предмет того, соблюдены ли коммерческие требования.
- Тур по данным – протестировать обработку данных.
- Тур по вычислениям – протестировать все вычисления.
- Тур по процессам – протестировать поддержку рабочих процессов приложением.
- Тур по экранам – протестировать все экраны.
- Тур по плохим частям – протестировать те части приложения, которые ранее имели много ошибок.
- Тур по интерфейсам – протестировать все интерфейсы.
- Асоциальный тур – протестировать некорректное использование.
- Тур грабителя – протестировать на предмет того, можно ли получить неавторизованный доступ.
Основные различия методов тестирования и сравнение их эффективности
Итак, основные отличия исследовательского тестирования от сценарного представлены в таблице ниже:
| Сценарное тестирование |
Исследовательское тестирование |
| Сфокусировано на подготовке |
Сфокусировано на действии |
| Сфокусировано на планировании |
Гибкое |
| Опирается на методы |
Прагматичное |
| Подчиняется процессу |
Ставит в центр внимания тестировщика |
| Сфокусировано на документации |
Сфокусировано на выполнении тестов |
Каждый раз, когда я провожу эту презентацию, я делаю одну и ту же ошибку – у всех возникает чувство, что исследовательское тестирование лучше сценарного. Это не так. Сценарное тестирование так же ценно, как и исследовательское, но тут все зависит от ситуации.
Однако эффективность исследовательского тестирования все же выше, чем сценарного. Это доказывается различными исследованиями. В частности, в 2007 году проводилось исследование, в котором принимало участие две команды. Они одновременно работали над тестированием одного и того же приложения, причем первая использовала сценарное тестирование, а вторая – исследовательское. Затем они тестировали второе приложение, но теперь первая команда использовала исследовательское тестирование, а вторая – сценарное. Это исследование показало, что при исследовательском тестировании эффективность обнаружения ошибок была намного выше. Подобные результаты были получены и при проведении других исследований эффективности методов тестирования.
Как решить, какой метод тестирования подходит лучше
По своему опыту могу сказать, что на выбор подхода к тестированию влияет множество факторов. Среди них: время, бюджет, цели, цели тестирования, навыки тестировщиков, система, метод разработки, документация, тип организации.
В таблице ниже я привожу некоторые особенности организаций и систем, а также распространенные цели. Вы можете увидеть, какой из методов подходит лучше в каждой ситуации, но стоит иметь в виду, что во многих случаях имеет смысл применять оба метода, даже если это не указано в таблице. Всегда старайтесь мыслить критически и адаптировать информацию к вашей ситуации.
| Категория |
Ситуация |
Сценарное |
Исследовательское |
| Система |
Много вычислений |
+ |
|
| |
Ориентирована на интерфейс |
|
+ |
| |
Ориентирована на бэкенд |
+ |
|
| |
Мобильное приложение |
|
+ |
| Цели тестирования |
Проверка на соответствие требованиям |
+ |
|
| |
Проверка ценности системы |
|
+ |
| |
Юзабилити |
|
+ |
| |
Тестирование бизнес-правил |
+ |
|
| |
Производительность |
+ |
|
| |
Проверка автоматизации |
+ |
|
| |
Безопасность |
+ |
+ |
| Организация |
Ориентирована на планирование и подготовку |
+ |
|
| |
Энергичный современный стартап |
|
+ |
| |
Иерархическая, традиционная |
+ |
|
| |
Приветствует самоуправление |
+ |
+ |
| Документация |
Много подробной документации |
+ |
+ |
| |
Немного документации |
|
+ |
| |
Требования / документация постоянно меняются |
|
+ |
| Разработка |
Каскадная модель |
+ |
+ |
| |
Agile |
|
+ |
| Бюджет |
Большой |
+ |
+ |
| |
Небольшой |
|
|
| Время |
Включение в работу на ранних сроках |
+ |
+ |
| |
Включение в работу на поздних сроках |
|
+ |
| |
Много времени |
+ |
+ |
| |
Мало времени |
|
+ |
| Навыки тестировщиков |
Аналитические, скрупулезные |
+ |
|
| |
Критическое мышление (сомневаются во всем) |
|
+ |
| |
Гибкость |
|
+ |
| |
Профессиональные тестировщики |
+ |
+ |
| |
Непрофессиональные тестировщики |
+ |
+ |
Вместо заключения
Так какой из подходов к тестированию работает лучше всего? Ответ очевиден: все зависит от ситуации. Но я считаю, что в будущем тестирование программного обеспечения будет представлять собой комбинацию автоматизированного и исследовательского тестирования. Поэтому каждому специалисту стоит изучить, хорошо знать и применять оба метода.
Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:
- Автоматизация в Геймдеве: как боты WorldOfTanks поднимали (Александр Шуков, Wargaming.net)
- Белый ящик Пандоры (Никита Макаров, Одноклассники)
- TestContainers: интеграционное тестирование Java-приложений (Антон Архипов, ZeroTurnaround)
