Тестирование является неотъемлемой частью жизненного цикла программного обеспечения. Само по себе тестирование – длительный процесс проверок на соответствие ожидаемого результата. Нельзя выделить какой-то один этап как важный, каждый из них имеет одинаковый вес. При создании продукта тестировщик не просто играет важную роль, а участвует на каждом этапе разработки от концепции до выхода продукта в свет.

Как уже было отмечено, тестирование – неотъемлемая часть жизненного цикла продукта, однако необходимо понимать, с чего стоит начинать тестирование, и когда оно заканчивается. Например, неопытные специалисты ошибочно думают, что после релиза они могут переключаться на другой проект.

1. Работа с требованиями. Знакомство с требованиями заказчика, что должен из себя представлять итоговый продукт, обсуждение.

2. Разработка стратегии тестирования. Оценка сроков тестирования, выявление среды тестирования, объединение всей информации, полученной при работе с требованиями.

3. Создание тестовой документации. Написание сценариев, которые позволят проверить функционал.

4. Тестирование прототипа. Тестирование основного функционала продукта, корректировка целей, добавление фичей.

5. Основное тестирование. Выполнение общей проверки продукта.

6. Стабилизация. На данном этапе происходит работа над устранением багов.

7. Эксплуатация. Проводится регресс-тестирование, устранение ошибок, которые нашел конечный пользователь.

Прежде, чем переходить к описанию каждого цикла тестирования, необходимо запомнить важное правило: переход к следующему этапу допустим лишь после полного завершения работы на предыдущем. Теперь поговорим о каждом этапе тестирования отдельно.

Команда тестирования знакомится с требованиями заказчика, функционалом продукта. На данном этапе важно непрерывное общение команд, необходимо задавать вопросы разработчикам.

• выявить противоречия в требованиях;

• помочь определить потенциальные дефекты в функционале.

 Общение является ключевым аспектом в разработке продукта, а продуманный roadmap (дорожная карта, стратегический план по реализации функционала продукта по определенным датам) позволит устранить нелогичность будущих внесенных изменений в продукт.

Данный этап важен для лидов или менеджеров, поскольку от понимания полученной на предыдущем этапе информации зависит качество тестирования.

1. резюмировать полученную информацию,

2. оценить сроки тестирования,

3. разработать стратегию тестирования: определить виды тестирования, которые можно применить к проекту, проанализировать имеющиеся среды и ресурсы, что имеется для проведения тестирования, описать приоритеты для непредвиденных ситуаций, как и где будет вестись тестовая документация;

4. определение среды тестирования: какое оборудование необходимо для тестирования,

5. составить план, который содержит описание, с чего начинается и чем заканчивается тестирование, и что будет тестироваться.

Цель данного этапа – создать документацию, объем которой будет охватывать детализацию, ход работ, а также вносить ясность для заказчика.

Общение с другими командами, понимание желаний заказчика напрямую влияют на качество тестовой документации. После проведенного тестирования можно проанализировать его успешность.

• тестовых сценариев: что и как будет проверяться при регресс-, дымовом и приемочном тестированиях;

• отчетности: результаты тестирования, списка багов и их серьезность;

• методологий тестирования.

Детализация тестовой документации зависит от проекта, поэтому она может отличаться и по охвату, и по формату, и по объему. Для тестировщика важно поддерживать документацию в актуальном виде, вносить любые изменения, связанные с изменением итогового продукта.

При создании и тестировании прототипа продукта необходимо выявить основные отклонения от ожидаемого результата и соответствие с бизнес-стратегией. Здесь же выявляются ошибки в работе логики основного функционала, устраняются найденные уязвимости и дефекты, допущенные на этапе разработки. Заказчик может сам участвовать в процессе тестирования прототипа, чтобы он мог оценить, на каком этапе находится разработка продукта. После тестирования выдвигаются пожелания со стороны заказчика. Новые пожелания необходимо задокументировать, оценить сроки, внедрить в проект и передать на осмотр заказчику.

Самый подходящий метод тестирования прототипа – проведение закрытого бета-тестирования, когда продукт тестирует продукт малое количество людей, которые в итоге будут использовать его после релиза. Это помогает учесть пожелания конечных пользователей.

Очень важно лиду или менеджеру проекта передавать информацию тестировщикам и разработчикам о пожеланиях заказчика, на какие частые сбои в продукте натыкались пользователи для того, чтобы сделать его более понятным.

Тестирование программного обеспечения является самым длительным и объемным процессом. Здесь формируются репорты о найденных дефектах, выполняется набор тестовых сценариев, создается тестовая среда, выполняется тестирование, виды которого были задокументированы на этапе создания тестовой документации. Смоук- и регресс-тестирования являются одними из основных видов тестирования, которые проводятся на данном этапе.

Важно понимать: невозможно найти все ошибки в продукте. Но и не найти ошибки при тестировании можно считать провалом. Главная цель — не сделать идеальный продукт без ошибок, а найти максимальное количество дефектов, которые потенциально могут сломать систему.

Наверное, самый непонятный с точки зрения формулировки этап. На нем заканчивается работа с пожеланиями заказчика и фиксируются найденные баги. Он является связующим звеном между командой тестирования и командой разработчиков. На протяжении создания онлайн-ресурса команда разработчиков занималась своими делами, реализуя «хотелки» заказчика, а тестировщики репортили о новых дефектах. А на этапе стабилизации разработчики начинают слушать тестировщиков, устраняя то, что уже работает, но некорректно.

Если продукт существует в какой-то большой системе, то на данном этапе также проверяется коммуникация системы и продукта, то есть проводится интеграционное тестирование.

Пожалуй, самый волнительный период. После устранения дефектов команда разработчиков переходит в этап тестирования продукта в продакшн-среде. Так как многие ставят точку на проекте после релиза, очень важно подметить, что здесь происходит не только релиз продукта, но и пост-релизовая поддержка.

При всем желании нельзя учесть все нюансы использования, воссоздать ту среду, в которой будет использован продукт. Поэтому на данном этапе необходимо сделать акцент на том, что говорят пользователи, важно прислушиваться к их мнению, поскольку они участвуют не только в использовании продукта, но и тестировании, натыкаясь на ненайденные ошибки. Ваш продукт становится частью жизнедеятельности людей, поэтому устранение дефектов и их поиск проводятся быстро, но тщательно. Не всегда конечный пользователь может предоставить информацию о том, что он сделал для получения ошибки, поэтому за повторение дефекта берется QA-команда.

Изучив все этапы тестирования сложно выделить главный – каждый из них важен по-своему. Тестирование является долгим и кропотливым процессом, результатом которого является выявленная ошибка в системе. Тестировщик должен четко формулировать свою позицию, почему найденная ошибки — действительно дефект, должен прислушиваться после релиза к позиции конечного пользователя и помнить, что ничто в этом мире не идеально.