Содержание:
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Цикл ручного тестирования
Чтобы понять цикл ручного тестирования или жизненный цикл тестирования ПО (STLC), прежде всего, необходимо понять жизненный цикл разработки ПО (SDLC), о котором, мы уверены, вы уже имеете представление.
Обычно люди рассматривают их как отдельные вещи, но сомневаются, могут ли они действительно сосуществовать, поскольку они настолько тесно взаимосвязаны. Cтоит отметить, что существует множество различных версий этих циклов, созданных и распространяемых в интернет-пространстве, и они в значительной мере различаются в зависимости от выбранной модели разработки.
Поскольку в наши дни большая часть мира переходит на Agile, мы будем упрощать представление информации, фокусируясь на Agile-подходе.
Ниже приведена последовательность действий, которые необходимо предпринять для успешного проведения ручного тестирования:
1. Сбор данных о требованиях
Бизнес-аналитик (человек/группа, ответственная за сбор требований) документирует требования. Они используют для документирования все, что им подходит, не ограничиваясь традиционными платформами, такими как MS word doc, современными платформами, такими как Jira/Rally и новыми инструментами , такими как Trello.
2. Обсуждение требований
Затем бизнес-аналитик должен поделиться документированными требованиями с командой разработчиков, командой тестирования и командой UX (при необходимости). Обычно это происходит на формальном совещании, где анализируются все требования.
В здоровой рабочей среде требования обсуждаются со всех сторон, и каждый участник встречи может задавать вопросы и высказывать сомнения. Когда все вопросы сняты, и необходимые изменения в требованиях внесены, этот этап можно считать завершенным. Название данного совещания/этапа и его документация могут отличаться в каждой компании. Например, документация может иметь разные названия, такие как SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point и т.д.
После этого совещания одновременно запускаются два шага, без особого порядка, см. следующие два шага.
3. Проектирование
Команда разработчиков приступает к техническому проектированию сразу после обсуждения требований и при отсутствии серьезных нерешенных вопросов. То, что делается на этом этапе, опять же отличается в разных компаниях.
Эта фаза может включать в себя следующие задачи:
- Принятие решения о подходе к разработке
- Подготовка проектной документации
- Разработка блок-схем
- Оценка усилий
- Определение влияния нового требования на существующий функционал.
- Необходимость внести исправления в существующие данные и т.д.
Команда UX также может быть вовлечена в этот этап, если необходимо изменить пользовательский интерфейс (UI). Команда UX помогает команде разработки и команде тестирования создать прототип GUI для обсуждаемой функциональности/фичи. Это может быть документ Photoshop, простое изображение, презентация PowerPoint или что-то еще, что поможет команде разработчиков понять, как должны быть разработаны экраны.
Примечание: Эти экраны или, по крайней мере, их черновые версии показываются на сессии обсуждения требований для того, чтобы помочь команде получить более глубокое понимание требований. Они помечаются в исходном требовании, чтобы к ним можно было обратиться в любой момент.
4. Разработка тестового сценария/тест-кейса
Параллельно с фазой проектирования команда тестирования начинает создавать тестовые сценарии и тест-кейсы на основе обсуждаемых требований. Порядок написания тестовых сценариев и их разбиение на тест-кейсы не является постоянным.
Документируете вы сценарии тестирования или нет, они всегда предшествуют тест-кейсам. Тестовый сценарий – это, можно сказать, ваша точка опоры, она позволяет детализировать дальнейшие действия. После завершения написания тест-кейса его можно передать команде разработчиков, чтобы они имели представление о масштабах тестирования, а также убедиться, что разработка, которая уже произошла или продолжается, соответствует написанным тест-кейсам.
Тест-кейсы после написания должны быть рассмотрены руководителем тестирования или коллегами с разных сторон, включая :
- Охват требований
- Орфографию и грамматику
- Стандарты написания тест-кейсов (как шаблон, которым руководствуется команда/компания)
- Обратная совместимость
- Совместимость с платформой
- Ссылки на тестовые данные
- Типы планируемого тестирования и т.д.
Только после проверки и внесения необходимых изменений, они передаются команде разработчиков.
В процессе тестирования возможно обнаружение дефектов в случайных (но намеренных) действиях (monkey-testing) и в некоторых редких сценариях. Существует вероятность, что вы упустите некоторые из них. Однако тщательный анализ тест-кейсов и структурированный подход к их написанию могут помочь избежать этого.
Зачастую тестировщик или команда тестировщиков продолжает добавлять все больше и больше тест-кейсов к уже существующим по мере более глубокого и детального осознания требований.
Информация, которая должна быть закреплена на данном этапе:
- Цель тестирования: Требования, обратная совместимость, платформы, устройства и т.д.
- Лицо/команда, которая будет проводить тестирование
- Оценка усилий по тестированию
- Ограничения: Любые предварительные предположения или принятые ограничения.
- Люди дополнительно документируют критерии входа, критерии выхода, риски и т.д.
- Критерии входа (когда начинать тестирование): Одни начинают, когда есть определенная часть функционала, доступная для тестирования. Другие ждут, пока весь функционал будет готов к тестированию. После того, как основной поток работы был проверен и признан функционирующим, начинается тестирование.
- Критерии выхода (когда закончить тестирование): Тестирование может быть остановлено, когда отсутствуют блокирующие, критические и значительные (существенно влияющие) дефекты на этапе открытого тестирования. Или, находясь на середине пути, тестирование может быть прекращено соответствующими заинтересованными сторонами, когда обнаруживается чрезмерное количество дефектов.
- Риск: Бизнес-риск или функциональный риск, если тестирование не будет проводиться в соответствии с документированным планом.
5. Фаза разработки
Команда разработчиков после этапа проектирования приступает к фактической части разработки и модульному тестированию. Они могут передавать функциональность на тестирование по мере ее реализации или передавать всю функциональность сразу.
Формальный обзор кода и тестирование “белого ящика” проводятся до передачи разработанной функциональности на тестирование. Кроме требований и документов по проектированию, команда разработки должна также обращаться к тест-кейсам, предоставленным командой тестирования.
6. Фаза тестирования
Как упоминалось ранее, начало этой фазы отличается от компании к компании, от команды к команде.
Тестирование начинается командой тестирования либо после разработки тестируемой части всего требования (части, которая может быть протестирована независимо), либо после полной разработки всех требований.
Важными задачами на данном этапе являются:
- Тестировщик/команда тестировщиков начинают с проведения тестового цикла (исследовательское тестирование и выполнение написанных тест-кейсов) и обнаружения дефектов.
- Команда разработчиков решает их в соответствии с приоритетом.
- Новая сборка кода развертывается в тестовой среде для проведения тестирования.
- Устраненные дефекты затем проверяются тестировщиками/командой тестирования и отмечаются как исправленные.
- Этот цикл продолжается до тех пор, пока не будет достигнут критерий выхода.
- Некоторые дефекты также помечаются как недействительные, дублирующиеся, а также могут быть отнесены к категории улучшений.
Еще одним отличием между компаниями является количество этапов тестирования. Например, в некоторых случаях первый этап тестирования проводится на небольших частях функционала по мере их готовности, а затем, после разработки всех требований, проводится сквозное тестирование в другой среде.
Первой целью проведения нескольких этапов тестирования является проверка функциональности в различных средах, а второй – проведение сквозного тестирования после разработки всех SP (Story Points). Обычно санитарное тестирование проводится для быстрого подтверждения работоспособности, когда все SP в релизе разработаны и протестированы независимо друг от друга.
7. Ревью бизнес-аналитика (BA)
Бизнес-аналитик проверяет требуемую функциональность, либо ссылаясь на результаты тестирования, либо ссылаясь на результаты тестирования плюс играя с приложением, чтобы получить реальное представление.
BA может просмотреть объем всего релиза за один раз или по частям. В зависимости от этого, данный шаг может быть выполнен до окончательного санитарного тестирования или после окончательного санитарного тестирования, проведенного командой тестирования.
Вышеперечисленные 7 шагов выполняются для всех пользовательских историй/требований, которые должны быть выполнены в конкретном релизе. Как только все эти шаги будут выполнены для всех требований, релиз считается готовым к отправке.
8. Релиз
После успешной проверки бизнес-аналитиком релиз помечается как готовый к отправке.
Типы ручного тестирования
Если говорить об общих видах тестирования в цифрах, то существует более 100 видов тестирования с разными названиями.
Ручное тестирование – тестирование функциональности приложения на соответствие заданным требованиям с помощью человеческих усилий и интеллекта. Далее оно делится на несколько типов в зависимости от масштаба и целей тестирования. Типы перечислены в следующем пункте.
В зависимости от объема и программы тестирования оно подразделяется на несколько типов.
Ниже приведен список некоторых популярных и важных видов тестирования, которые которые требуют непосредственного участия человека:
- Ручное функциональное тестирование: Тестирование функциональности приложения на соответствие заданным требованиям с использованием человеческих усилий. Далее подразделяется на несколько типов в зависимости от объема и программы тестирования, таких как системное тестирование, юнит-тестирование, дымовое тестирование, санитарное тестирование , интеграционное тестирование, регрессионное тестирование, UI- тестирование и т.д.
- Тестирование производительности: Классифицируется как нефункциональное тестирование. Но опять же, это человек, который реализует его, хотя выполнение осуществляется либо человеком, либо инструментом. Тестировщик должен, по крайней мере, провести это тестирование в отношении времени отклика (чтобы убедиться, что оно является приемлемым).
- Тестирование совместимости браузеров/платформ: Тестируемое приложение должно выглядеть и работать так, как ожидается (очевидно, могут быть незначительные различия в зависимости от движка браузера) во всех браузерах и платформах (или устройствах, если это мобильное приложение).
- Тестирование юзабилити: Как тестировщики мы должны, по крайней мере, сообщать или подчеркивать, если мы находим что-то менее удобным для использования, или делиться своим мнением.
- Тестирование безопасности: Это снова очень обширный тип тестирования, требующий большого практического опыта. Тестировщик должен попытаться изучить и выполнить хотя бы базовые тесты, такие как подмена URL (URL tampering), межсайтовый скриптинг (XSS), SQL-инъекции (SQL injection), перехват сеанса (Session hijacking) и т.д. в зависимости от имеющихся знаний и в соответствии с конкретными требованиями.
- Тестирование многопользовательских приложений: Если ваше приложение поддерживает многопользовательский режим (multi-tenancy), то такое тестирование является обязательным. Независимо от явного упоминания в требованиях, это должно быть выполнено. Отображение данных одного клиента другому является своего рода преступлением в разработке и тестировании.
Примечание: Рекомендуем вам ознакомиться с обширным списком типов тестирования для получения знаний и следовать/использовать их, если вы считаете это необходимым. Независимо от того, используете вы что-то или нет, вы все равно должны обладать некоторыми знаниями о широко используемых концепциях в вашей области.
Перевод статьи “7-Step Practical Implementation Of Manual Testing Before Production Release”.