Блог сайта

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

1. Анализ документации: бизнес требований и функциональных спецификаций

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

2. Оценка и планирование тестирования

• Основываясь на знаниях, полученных на этапе анализа мы оцениваем время тестирования. Оценка также обширная и важная тема, ей посвящен целый раздел данного руководства (Требования к тестировщику ч.9: оценка времени на тестирование)
• Далее выполняется планирование. Подробно про планирование я расскажу в статье для менеджеров и руководителей групп тестирования. Однако, тестировщику необходимо знать, что на этом этапе формируются (обычно тест менеджером) стратегия и план тестирования, в которых сводиться воедино вся информация о том, какой функционал мы тестируем, на каком окружении, с какими данным, кто участвует в процессе, какие критерии качества используем и т.д. Подробно – в статье про тестовую стратегию. На интервью тестировщику часто задают вопрос, что такое стратегия тестирования, из чего она состоит и для чего нужна. Поэтому рекомендую ознакомиться с материалом, чтобы получить представление.

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

3. Разработка сценариев тестирования

На данном этапе мы описываем сценарии, по которым будем тестировать продукт. Здесь важны две темы: как определить необходимые сценарии и как их описать.

• Для того, чтобы определить какие проверки необходимо выполнить существуют множество техник и способов. В этой статье я не буду их описывать (можно по названию найти подробное описание на WiKi), только перечислю некоторые из них:
  • Traceability matrix
  • Decision Table
  • Boundary value analysis and Equivalence partitioning
  • Pairwise Technique
  • Use-Case

Для прохождения интервью самое главное ответить на вопросы:

1. Как планируете формировать список проверок?
2. Как поймете насколько полно этот список проверок охватывает функционал, который необходимо проверить?

Если какими-то техниками раньше не пользовались, интервьюеру сразу будет ясно, что знания только теоретические, а вы можете легко запутаться. В этом случае обязательно разберитесь с методом тестирования граничных значений и классами эквивалентности (Boundary value analysis and Equivalence partitioning) и отталкивайтесь от функций ПО. Следите, чтобы на каждую функцию и состояние продукта был как минимум один тест. Если у функциональности сложная логика работы, то делайте проверку на каждое условие алгоритма. Также обязательно ориентируйтесь на бизнес смысл функционала, на то как ПО в реальности будет использоваться (Use-Case), создавая тест на каждый сценарий.

• Описание сценариев тестирования или тест дизайн, также имеет множество реализаций: от использования специальных программных средств типа HP ALM до описания сценариев в Excel или Word. Здесь важно четко понимать основные параметры теста, которые должны быть всегда, вне зависимости от инструмента. Скорее всего вам зададут примерно следующий вопрос: «Как выглядит идеальный тест кейс? Из чего он состоит?». Собственно основные составляющие теста следующие:
  • Версия тестируемого ПО, ссылка на требования, автор тест кейса
  • Начальные условия, шаги для подготовке к тестированию: состояние системы, настройки среды, данные
  • Заголовок тест кейса с его основной идеей
  • Шаги тестирования, включающие: действие, ожидаемый результат, фактический результат
  • Статус тест (тут также необходимы дата выставления статуса и кто его поменял)
  • Ссылки на обнаруженные ошибки
  • Действия по возвращению системы в исходное состояние

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

4. Выполнение тестирования ПО

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

• Smoke testing и Sanity testing – предварительная проверка системы и поставки ПО. На этом этапе наша задача убедиться, что тестовая среда настроена и работает, а полученный билд содержит необходимый функционал или изменения и с ним можно продолжать работать. Т.о. мы делаем самые основные, базовые проверки.
• Functional & non-functional testing – основной этап тестирования, который включает в себя все многообразие проверок разных типов разобранных в разделе «3 - Базовые знания по тестированию», направленных на изменения, добавленные в рамках поставки. На этом этапе мы проводим несколько циклов тестирования, как правило более 2.
• Regression testing – проводим цикл регрессионного тестирования и проверяем, что новые фичи и изменения не сломали текущий функционал. Тут также несколько циклов. В принципе этот этап можно считать второй фазой предыдущего блока - Functional & non-functional testing.
• Integration & end-to-end testing – на этом этапе мы проверяем как наш модуль, система или продукт будет взаимодействовать с другими модулями, системами и продуктами. Здесь мы проверяем всю цепочку действий пользователя при работе с системой. Например, пользователь делает заявку через сайт интернет магазина, далее заявка записывается в базу, далее обрабатывается и передается в систему для закупок и т.д. В этом случае мы должны настроить необходимое окружение и проверить весь жизненный цикл заявки, даже если мы доработали только одну систему в цепи.
• Demo testing & User Acceptance Testing – этап демонстрации ПО заказчику \ пользователям, которые в свою очередь также могут (и в идеале должны) проводить свое тестирование продукта – UAT

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

5. Подведение итогов и подготовка результатов тестирования

На этом этапе мы делаем следующее:

• Проводим качественный и количественный анализ обнаруженных во время тестирования ошибок и проблем
• Формализуем эти результаты в виде метрик тестирования
• Готовим отчет о результатах тестирования с заключением рекомендуется ли данный билд к поставке в продуктив, какие есть риски, какие меры необходимо предпринять для того, чтобы предотвратить или минимизировать сбои

В качестве результатов и метрик тестирования мы можем использовать такие показатели как (подробнее про метрики тестирования в отдельной статье):

• Количество открытых дефектов по уровню их критичности

Например, у нас могут быть четкие критерии, что с открытыми дефектами уровня Critical мы не выходим в продуктив, а открытый дефект уровня High может быть только один и при этом должна быть дополнительная инструкция как бороться с его последствиями и план по устранению

• Количество открытых дефектов к общему числу дефектов

Так мы показываем какая часть ошибок не исправлена и какое количество таких ошибок, чтобы принять решение о продолжении тестирования или релизе ПО

• Количество дефектов к общему числу тестов

Эта метрика показывает среднюю эффективность одного теста

• Число раз, которое в среднем переоткрывался дефект

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

6. Поддержка во время установки в продуктив

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

7. Поддержка во время сопровождения продукта

• Анализ и воспроизведение ошибок, найденных на продуктивной среде
• Выполнения регрeсcионных проверок после исправления ошибок