10 вопросов по QA на собеседовании

Обеспечение качества программного обеспечения (software quality assurance, SQA) представляет собой все виды деятельности и процедуры, которые направлены на процесс разработки ПО. Главная цель – минимизировать риски возникновения дефектов и сбоев в конечном продукте до его выпуска. Для этого разрабатываются, внедряются и поддерживаются процедуры, которые помогают разработчикам и тестировщикам выполнять свою работу наиболее эффективным образом.

Контроль качества программного обеспечения (software quality control, SQC), в отличие от SQA, полностью ориентирован на продукт. Цель SQC – провести тестирование конечного продукта, чтобы подтвердить, что разработанный продукт соответствует потребностям и ожиданиям заказчика.

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

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

• Любое положительное двузначное целое число: число больше 9 и меньше 100 (допустимый ввод)
• Любое одноразрядное целое число: число больше -10 и меньше 10 (положительное или отрицательное) (недопустимый ввод)
• Любое отрицательное двузначное целое число: число меньше -9 (недопустимый ввод)
• Любое трехзначное целое число: число больше 99 (недопустимый ввод)

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

На основе этих четырех классов и границ между ними мы можем разработать следующие тест-кейсы:

• Для техники разбиения на классы эквивалентности: 42 (валидный); -15, 2 и 107 (невалидный)
• Для техники анализа граничных значений: 10 и 99 (валидные); -10, -9, 9 и 100 (невалидные).

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

Для выполнения таких проверок, например, с помощью фреймворка Selenium, мы используем классы команд Assert* и Verify*.

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

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

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

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

1. Правильно ли мы строим систему? (верификация)
2. Создаем ли мы правильную систему? (валидация)

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

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

Серьезность отражает степень тяжести дефекта, а приоритет – степень срочности его исправления.

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

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

Примеры дефектов с высокой степенью серьезности, но низкой приоритетностью:

• Приложение падает при нажатии непонятной кнопки на устаревшей странице, с которой пользователи редко взаимодействуют
• Доступ к неопубликованным постам (черновикам) в админке можно получить без действующего логина, если вручную ввести точный адрес, например, https://www.private.domain/admin/panel/posts/drafts/19380108/edit
• Нажатие на кнопку отправки 50 раз приводит к аварийному завершению работы приложения.

К дефектам с низкой степенью серьезности, но высокой приоритетностью относятся:

• Неправильный логотип компании на целевой странице
• Опечатка в заголовке на целевой странице
• Неправильная фотография товара.

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

• Проверка зависит от человека, выполняющего тест (UI/UX, юзабилити, look-and-feel)
• Функция разрабатывается с постоянными изменениями, и автоматизация приведет к пустой трате ресурсов
• Тест-кейсы чрезвычайно сложны, и их автоматизация была бы пустой тратой ресурсов
• Для получения более глубокого представления о системе требуется, чтобы тестировщики выполняли сеансы вручную

RTM (requirements traceability matrix) – это документ, который показывает связь между тест-кейсами (написанными QA-инженером) и бизнес-/техническими требованиями (указанными клиентом или командой разработчиков). Основная идея RTM заключается в том, чтобы убедиться, что все требования покрыты тест-кейсами. Это должно гарантировать, что ни одна функциональность не останется не протестированной.

Используя RTM, мы можем подтвердить 100-процентное покрытие тестами бизнес- и технических требований, а также получить четкое представление о дефектах. Это, несомненно, высветит все непокрытые требования и/или несоответствия в документации.

RTM позволяют глубже понять работу QA и то влияние, которое оказывает на инженеров QA прохождение тест-кейсов и их повторная обработка.

Например, у нас есть следующие требования:

• R.01: Пользователь может войти в систему
• R.02: Пользователь может открыть страницу профиля
• R.03: Пользователь может отправлять сообщения другим пользователям
• R.04: Пользователь может иметь фотографию профиля
• R.05: Пользователь может редактировать отправленные сообщения

Мы можем разработать следующие тест-кейсы:

• T.01: Проверка возможности входа пользователя в систему
• T.02: Проверка, что пользователь может открыть страницу профиля и отредактировать фотографию профиля
• T.03: Проверка, что пользователь может отправлять и редактировать сообщения

В результате получится следующая RTM, показывающая взаимосвязь между требованиями и тест-кейсами:

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

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

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

Краткий список выходных критериев может быть таким:

• Все тест-кейсы выполнены
• 95 процентов тестов пройдены
• Не осталось ни одного дефекта с высокой приоритетностью или серьезностью

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

Для начала мы нарисуем блок-схему кода:

Чтобы получить количество тест-кейсов для полного, 100-процентного покрытия утверждений, мы должны найти наименьшее количество путей, на которых расположены все узлы. Если мы пойдем по пути 1-A-2-C-3-E-4-F-G-5-I-6-J, то покроем все узлы (1-2-3-4-5-6), тем самым удовлетворив все утверждения в коде одним тест-кейсом. Однако, поскольку два утверждения (узлы 2 и 5) сталкиваются, один тест-кейс не подходит для данного кода. Чтобы полностью покрыть все утверждения, нам потребуется два тест-кейса:

• 1-A-2-C-3-E-4-F-G-5-H
• 1-A-2-B-G-5-I-6-J

Чтобы определить количество тест-кейсов для 100-процентного покрытия веток, необходимо найти минимальное количество путей, которые будут покрывать все возможные истинные и ложные утверждения. Используя те же два пути из полного покрытия утверждений, мы можем добиться почти полного покрытия веток. Единственная ветка, которую эти два пути не покрывают, – это ветка “D”, для которой нам нужен дополнительный путь к двум упомянутым ранее. Таким образом, наши три теста будут покрывать эти пути:

• 1-A-2-C-3-E-4-F-G-5-H
• 1-A-2-B-G-5-I-6-J
• 1-A-2-C-3-D-G-5-H

Учитывая ограничения оператора (X > 0 и X < 0), вот все пути, которые можно пройти:

• 1-A-2-C-3-E-4-F-G-5-H
• 1-A-2-C-3-D-G-5-H
• 1-A-2-B-G-5-I-6-J
• 1-A-2-B-G-5-H (when X = 0)

Тестирование на основе диаграммы переходов состояний – это метод тестирования “черного ящика”, при котором изменения входных условий вызывают изменения состояний тестируемого приложения. Количество 0-switch переходов равно количеству переходов, которые можно осуществить из выбранного состояния. Из диаграммы видно, что возможными переходами из состояния Reopened являются:

Reopened -> In Progress
Reopened -> Resolved
Reopened -> Testing
Reopened -> Closed

Таким образом, мы получаем в общей сложности четыре 0-switch перехода.

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

Reopened -> In Progress -> Closed
Reopened -> In Progress -> Resolved
Reopened -> Resolved -> In Progress
Reopened -> Resolved -> Reopened
Reopened -> Resolved -> Testing
Reopened -> Testing -> Resolved
Reopened -> Testing -> Reopened
Reopened -> Testing -> Verified
Reopened -> Closed -> Reopened
Reopened -> Closed -> In Progress

У нас получился список из 10 возможных 1-switch переход, начиная с состояния Reopened. Но у нас есть ограничение спецификации: если тикет из состояния Reopened переходит в состояние Closed, он может быть восстановлен только в то же состояние Reopened. Поэтому мы можем обозначить последний 1-switch переход (Reopened -> Closed -> In Progress) как недействительный. Таким образом, мы получаем девять 1-switch переходов.