Тестирование исследовательское и по сценариям
Итак в тестирование также есть два подхода:
● Тестирование по готовым сценариям
● Исследовательское тестирование
Тестирование с использованием сценариев, т.е. тест-кейсов относится к подходу, который называется тестирование по сценариям. Второй подход является противоположностью сценарного подхода. Но не стоит думать, что результаты исследовательского тестирования будут разительно отличаться от результатов сценарного подхода, так как они оба вполне хорошо сочетаемы. Некоторые компании применяют два подхода одновременно на одном проекте. И все же, различия между ними существенны.
Исследовательское тестирование предполагает параллельную разработку и выполнение кейсов, то есть отсутствие четкого сценария тестирования. Этот метод практически никак не структурирован и предоставляет много свободы в действиях для тестировщика. Также, в ходе его проведения нельзя
быть полностью объективным, как при тестировании по кейсам.
Исследовательское тестирование в частности используется, когда информации о проекте недостаточно, или же вовсе в качестве подготовительного этапа перед созданием тестовых сценариев.
При сценарном подходе перед началом проведения тестирования тесты предварительно формально описываются в виде тест-кейсов. При данном подходе оценка тестового покрытия не вызывает никаких проблем. Все части системы перечислены с необходимым тестовым покрытием, что позволяет четко определить количество времени на работы по тестированию.
|
|
|
Сценарный подход механизирует весь процесс тестирования, тем самым сводя к минимуму мыслительные процессы
Вникнув в суть данных подходов, самое время провести сравнительный анализ. Как всегда, для начала рассмотрим положительные моменты обоих подходов.
Преимущества исследовательского похода:
● Дает больше свободы тестировщику, развивает его навыки. Позволяет поработать и развить новые техники и стратегии тестирования.
● Все время выделено только для проведения тестирования.
● Тестировщик более глубоко исследует и вникает в программный продукт.
● Нет дополнительных затрат на актуализацию тест-кейсов. Преимущества сценарного подхода:
● Сокращение времени на освоение продукта при подключении нового сотрудника на проект. Эффективный способ быстро ввести в курс дел нового сотрудника, подключившегося к проекту, в любой момент есть возможность «вспомнить», что было сделано месяц или год назад.
● Тестирование проектной документации ещё до выхода первого билда.
● Значительное ускорение процесса регрессионного тестирования.
|
|
|
● Возможность работы специалистов менее высокой квалификации при тестировании по сценариям.
● Легко оценить тестовое покрытие.
● Контроль качества продукта с течением времени и сохранение истории работ по тестированию.
● Структурированный системный подход к тестированию снижает вероятность пропуска ошибки.
● Выполнение тестов не требует дополнительного времени на общение с разработчиками и аналитиками, работу с требованиями.
Не может все быть так радужно в случае со сценарным походом. Выше мы уже говорили, что наличие тест-кейсов расслабляет тестировщика, рассмотрим и остальные недостатки.
Недостатки исследовательского подхода:
● Тестировщику с небольшим опытом труднее на первых этапах работ, отсутствует наглядное представление о том, что и как тестировать.
● Сложности в оценке тестового покрытия, а так же в расчете временных затрат.
● Требуется большое количество времени для изучения продукта. Недостатки сценарного подхода:
● Тестирование по тест-кейсам приглушает творчество и свободу в действиях специалиста по качеству.
● Вырабатываются привычки проводить шаблонные проверки, которые были описаны в сценариях.
|
|
|
● Постоянное тестирование по шаблонам для тестировщика может быть утомительно.
● Требует много времени на поддержку тестовых сценариев: обновление, удаление, исправление
Таким образом, и у того, и у другого похода есть видимые преимущества и недостатки. Однако, как мы видим, тестирование по тест-кейсам все же выигрывает. Но это вовсе не означает, что данный подход будет хорош для любого проекта и для любой компании. При промышленном тестировании крупных проектов использование сценарного подхода принесет вам больше пользы и будет целесообразным. Прежде чем писать тест-кейсы следует в первую очередь оценить объем и сложность проекта, частоту
изменения требований и дизайна. Если такой анализ был проведен, внедрение тестовых сценариев на проекте будет максимально эффективным для обеспечения высокого качества продукта.
Чит-листы
Что такое чит-листы?
Зачастую нам нужно осуществлять однотипные проверки в разных местах: проверка ввода в текстовое поле, валидация поля e-mail, ограничения в числовых полях, SQL и XSS инъекции и т.д. Для этих случаев, чтобы не забыть «что нужно проверить», и создаются чит-листы (иногда их ещё называют cheat sheets).
|
|
|
Существуют стандартные чит-листы. К примеру, подборка тестов для тестирования web-элементов или набор тестов для проверки регистрации. Каждый тестировщик с опытом вырабатывает свои собственные чит-листы для различных условий. Кто-то пытается держать их в голове, а кто-то выписывает в виде списка, чтобы не забыть.
Более того, во многих компаниях есть свои собственные стандарты в разработке интерфейса, которые тоже постепенно включаются в разряд необходимых проверок: например, «каждое поле ввода должно быть со округлениями», «все сообщения системы должны появляться в виде поп-апов, а не отдельных окон» и т.д.
В результате у тестировщиков появляются наборы проверок, которые можно многократно переиспользовать: формы регистрации одинаково проверяются в разных проектах, SQL и XSS инъекции одинаково проверяются в разных полях ввода. Держать всё в голове? Неэффективно, голова нужна для того, чтобы думать, а не для того, чтобы хранить множество избыточных данных.
Именно поэтому тестировщики пишут чит-листы: списки повторяющихся проверок, которые можно переиспользовать в разных условиях.
Что дают чит-листы?
● Используя чит-листы, вы освобождаете свой разум для более важных задач.
● Задокументировав чит-листы, их можно обсудить с коллегами: разработчиками, руководителями проектов.. Расширив чит-листы на основании их идей, вы сможете пропускать меньше ошибок.
● Чит-листы можно подсматривать, чит-листами можно делиться. Вы можете найти стандартные чит-листы по XSS, SQL, или чит-листы от Элизабет Хендриксон и Джеймса Баха. Изучая
чит-листы коллег, можно учиться!
● Чит-листы создаются только один раз, после этого они лишь расширяются. А это значит, что когда у вас появится новый проект со схожим функционалом, или новое поле с аналогичными требованиями, вам не надо будет ломать голову «как его тестировать». У вас будет время чтобы подумать «как улучшить тестирование этого элемента?».
● Создание чит-листов — отличное времяпрепровождение в команде тестировщиков. Их можно совместно их обсуждать, прорабатывать. В диалоге мы учимся, выслушивая идеи друг друга, а в результате получаем продуманное покрытие и хорошие результаты.
Подготовка тестовых данных
Проводя тестирование, никак не обходится без тестовых данных. В одних случаях нам нужно сгенерировать просто ФИО пользователей или какие-то числовые или строковые значения. В других случаях нам может понадобиться корпоративная иерархия сотрудников компании или данные с
датчиков температур химический анализ алюминия. Создание тестовых данных может быть кропотливой и очень творческой задачей. При тестировании очень важно уточнять, как пользователь будет работать с ПО и какие данные он будет вводить и использовать. Если есть возможность получить хотя бы часть реальных данных, то таким шансом непременно следует воспользоваться
Однако не всегда бывает возможность опробовать реальные данные, что же делать в таких случаях? Стремиться к подобию реальных данных. При тестировании очень важно вникнуть в предметную область ПО и понимать, как и что будет делать пользователь. Когда тестировщик не старается имитировать реальную работу пользователей в ПО, то при вводе в эксплуатацию всплывают различные неприятные ошибки, которые можно было найти раньше.
Возьмем для примера поле ФИО. Быает так, что на тестовых стендах можно увидеть пользователя с ФИО «1 1 1», ведь нет ничего страшного в таком пользователе, правда?. Но это не правильно. Тестовые данные должны быть похожи на реальные, даже в таких данных как ФИО. Что же делать, когда кончается фантазия, а количество Ивановых И.И. зашкаливает в базе? Пользоваться инструментами!
Существует не мало различных генераторов, например http://freegenerator.ru/fio.
Очень часто ПО отправляют письма на адреса электронной почты: для подтверждения регистрации, восстановления пароля, рассылок и уведомлений. Для тестирования получения писем не следует использовать не существующие почтовые адреса, но и свой единственный адрес использовать много раз не получится. В большинстве ПО адрес электронной почты должен быть уникальным. И что же нам делать? Есть несколько вариантов. Воспользоваться одноразовыми адресами электронной почты, например, используя ресурс http://temp-mail.org/.
Однако если вам нужен адрес электронной почты на продолжительное время, вариант одноразовой почты не подойдет. Но есть и другие возможности. Например, из одного адреса gmail почты сделать много. Как это сделать? Очень просто: после имени почтового ящика нужно поставить знак «+» и что-то дописать, а потом как обычно @gmail.com. Например? у нас есть почтовый адрес devtest@gmail.com.
А письма, отправленные на адреса:
● devtest+user@gmail.com
● devtest+customer@gmail.com
● devtest+admin@gmail.com
то они будут приходить на адрес devtest@gmail.com, где их можно отфильтровать по разным папкам на основе адреса, куда они были отправлены.
Дополнительные материалы
● Ссылки на чит-листы http://tmguru.ru/baza-znanij/upravlenie-testami/cheat-sheet
● Статья про исследовательские туры http://tmguru.ru/baza-znanij/upravlenie-testami/testing-tour/
● http://software-testing.ru/library/5-testing/66-top-13- i----
Используемая литература
1. http://www.luxoft-training.ru/blog/veni_vidi_vickie/534.html
2. http://www.luxoft-training.ru/blog/veni_vidi_vickie/540.html
3. http://www.luxoft-training.ru/blog/veni_vidi_vickie/541.html
4. http://okiseleva.blogspot.ru/2014/08/blog-post.html
5. http://qawebmart.ru/blog/nuzhny-li-testkejsy.html
6. http://wiki.software-testing.ru/%D0%A7%D0%B5%D0%BA-%D0%BB%D0%B8%D1%81%D1
%82
7. http://okiseleva.blogspot.ru/search/label/%D0%BF%D0%BE%D0%B4%D0%B3%D0%BE%D1
%82%D0%BE%D0%B2%D0%BA%D0%B0%20%D1%82%D0%B5%D1%81%D1%82%D0%B E%D0%B2%D1%8B%D1%85%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Дата добавления: 2018-08-06; просмотров: 2736; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!