Зачем вам нужен QA и как это позволит сэкономить деньги

В этой статье речь пойдёт не о том, как QA-инженеры делают свою работу. Мы поговорим о том, почему обеспечение качества (Quality Assurance, QA) — незаменимая часть процесса разработки.

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

Дефект или баг — фрагмент кода с ошибкой, из-за которого система не может выполнять свою функцию. Это не всегда означает, что всё не работает. Оно может работать, но не так, как надо.

Так чем занимаются QA-инженеры? Они:

• Выявляют слабые места и несоответствия в продукте на всех этапах разработки;
• Помогают определить требования к проекту;
• Предоставляют исчерпывающую информацию о качестве продукта;
• Тестируют продукт на протяжении всех фаз жизненного цикла разработки системы (software development lifecycle, SDLC).

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

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

Когда вам нужен QA?

В этой части статьи мы опишем, что и когда делают QA. Этапы, описанные ниже, являются общими (и обобщёнными) частями цикла тестирования программного обеспечения (software testing life cycle, STLC).

Сбор требований

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

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

1. Анализ и принятие решения о том, совместимы ли между собой требования, и могут ли они быть реализованы в рамках одной системы.
2. Оценка того, какие решения будут работать, а какие — нет.
3. Планирование необходимых методов тестирования (подробнее об этом ниже).

Валидация — процесс оценки проекта до начала разработки с целью выяснить, удовлетворяет ли потенциальный продукт требованиям пользователей и стоит ли вкладывать в эту идею усилия.

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

До прохождения валидации продукт может и не дойти до потребителя, даже если он отлично сделан с технической точки зрения. Также на этом этапе проверяется, принесёт ли продукт пользу клиенту. Иначе зачем вообще этим заниматься?

Планирование тестирования

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

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

Разработка тестов

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

Выполнение тестов

Этот этап многие считают единственной задачей QA — выполнение всех тест-кейсов по плану. Если какая-то часть системы работает хорошо, мы отмечаем её как прошедшую тестирование. Таким образом мы можем удостовериться, что ничего не пропустим и на выходе получим качественный продукт.

Если тест-кейс прошёл неудачно, значит в коде есть ошибка, и QA отправляют отчёт разработчикам, чтобы они проверили, что не так.

Отчёт о результатах

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

Что такое цикл тестирования? Это частота, с которой мы проводим эти пять этапов тестирования.

Особенности работы QA

Множество компаний-разработчиков программного обеспечения работают спринтами — даётся список задач и две недели на их выполнение. Во время каждого спринта мы реализуем определённую часть требований к продукту и проходим через все пять стадий тестирования. Важно понимать, что тестирование не подразумевает только проверку каждого способа взаимодействия с продуктом. Конечно, и это тоже, но зачастую с системой можно сделать гораздо больше.

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

Теперь, когда мы знаем о циклах тестирования, можно вкратце рассказать, почему каждой команде нужен QA:

• Безопасный бизнес. У вас есть платёжная система, и она работает нормально. Пользователь платит за услугу и получает её. Однако вы не проверили все возможные случаи, и деньги идут не вам, а на случайный банковский счёт. Такой недочёт может очень дорого обойтись;
• Экономия денег. На приведённой ниже диаграмме хорошо видна взаимосвязь между этапами жизненного цикла и затратами. Гораздо дороже исправить ошибку, чем предотвратить её. Исправление одной ошибки может повлечь за собой другие, поэтому количество ваших проблем будет быстро увеличиваться;
• Защита репутации. Если выпустить багованный продукт и пользователи не будут довольны работой с ним, в дальнейшем их будет сложно убедить, что проблема решена и они могут снова им пользоваться. Первое впечатление сложно изменить, поэтому предоставьте качественный продукт. Если он не был протестирован вдоль и поперёк, то продукт может работать неправильно или не работать вовсе. Тестирование требует теоретических знаний, поэтому будет сложно обеспечить качество, если вы не профессионал;
• Контроль процесса. Если процесс разработки не контролируется и идёт вразрез с установленными требованиями, итоговый продукт может сильно отличаться от запланированного.

Вы могли заметить, что часто упоминается тестирование. Это потому, что есть такая отдельная дисциплина, как контроль качества (Quality Control, QC). Далее мы поговорим о работе QA, о разнице QA и QC, взаимосвязи SDLC и STLC, а также дадим детальное описание некоторых методов тестирования, используемых QA-инженерами.

QA

Обеспечение качества и контроль качества

Контроль качества (Quality Control, QC) охватывает всю деятельность, направленную на то, чтобы убедиться, что продукт хорошего качества и отвечает заданным требованиям. QC-инженеры занимаются поиском дефектов в продукте до его выпуска. Можно сказать, что обеспечение качества включает в себя контроль качества.

Есть случаи, когда продукт не требует QA, а только QC. Например, если команда получает продукт, разрабатываемый другими людьми, с целью проверить, соответствует ли код требованиям.

В некоторых командах QA и QC совмещаются с другими ролями. Иногда разработчики пытаются проверить свой собственный код. Тем не менее, это сказывается на качестве, так как гораздо сложнее найти ошибки в своём коде, чем в чужом.

Цикл разработки программного обеспечения и цикл тестирования

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

Надеемся, нам удалось вас убедить в важности одновременного проведения SDLC и STLC. Теперь мы перейдём к некоторым популярным методам составления тестов, которые QA-инженеры используют для обеспечения качества.

Методы составления теста

Тест-кейс (или просто тест) — пошаговый подход к тестированию функциональности программного продукта. По сути сюда входят тестируемый объект и способ тестирования.

Метод составления теста — процесс выбора тестов, которые подтвердят, что продукт соответствует спецификациям до его релиза.

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

На картинке ниже представлены основные методы составления теста:

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

Статический. Этот метод тестирует исходный код, функциональные спецификации и спецификации требований до выполнения кода (до выхода в релиз). Этот метод определяет структурные недостатки. Это не одноразовая работа, поэтому мы стараемся начать её на ранних этапах процесса разработки.

На основе структуры. Мы используем такой метод, когда у нас есть полный доступ к коду. Проще говоря, он касается внутренней логики и структуры кода. Такие тесты помогают определить неправильную или отсутствующую логику и опечатки в коде.

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

На основе опыта. Это больше вспомогательный метод, который позволяет QA тестировать программное обеспечение на основе их предыдущего опыта работы с подобными системами.

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

В заключение

Неважно, каким простым кажется продукт, ведь в основе его качества лежит тонна проделанной работы. Как заметил Дон Норман, «Хороший дизайн гораздо сложнее заметить, чем плохой». В большинстве случаев QA-инженеры дают людям возможность наслаждаться продуктом, проверив, что всё работает хорошо.

Обеспечение качества включает много всего, от тестирования до анализа результатов. Большинству программных продуктов нужны QA-инженеры, чтобы:

1. Контролировать процесс разработки.
2. Предотвращать ошибки в системе до того, как их найдут пользователи.
3. Обеспечивать качество выпускаемого продукта.

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