1. Что такое обеспечение качества ПО и контроль качества ПО?
Обеспечение качества программного обеспечения (SQA) – это совокупность действий и методов, направленных на все этапы процесса разработки ПО. Его цель – свести к минимуму риски возникновения дефектов и сбоев в конечном продукте до его выпуска. Это достигается методом разработки, внедрения и поддержки процессов, которые помогают разработчикам и тестировщикам выполнять свою работу наиболее эффективным способом.
Контроль качества программного обеспечения (SQC), в отличие от SQA, полностью ориентирован на продукт. Целью SQC является проведение тестирования конечного продукта для подтверждения его соответствия потребностям и ожиданиям заказчика.
Ищите работу Junior QA? Тогда вам в наш телеграм канал QA Вакансии. Каждую неделю 7 лучших вакансий с телеграм контактом HR компании.
БОЛЬШЕ ВОПРОСОВ С СОБЕСЕДОВАНИЙ В НАШЕМ ТЕЛЕГРАМ КАНАЛЕ QASOBES
2. У вас есть поле ввода, которое принимает целое число. Допустимый ввод – положительное двузначное целое число. Укажите тест-кейсы в соответствии с методами эквивалентного разбиения и анализа граничных значений.
Довольно часто бывает невозможно протестировать все возможные тест-кейсы для всех сценариев. В случае, когда допустимым вводом является положительное двузначное целое число, уже существует 90 возможных позитивных тестовых проверок, а негативных гораздо больше. В таких ситуациях нам нужно выбирать более оптимальные методы тестирования, при этом удостовериться в максимальном тестовом покрытии.
Тестирование методом эквивалентного разбиения – это техника, которая разбивает входные тестовые данные на группы таким образом, чтобы при вводе любого значения из выбранной группы система вела себя одинаково. Для нашего примера мы можем создать четыре класса чисел:
- Любое положительное двузначное целое число: больше 9 и меньше 100 (валидный ввод)
- Любое однозначное целое число: число больше -10 и меньше 10 (положительное или отрицательное, невалидный ввод)
- Любое отрицательное двузначное целое число: число меньше -9 (невалидный ввод)
- Любое трехзначное целое число: число больше 99 (невалидный ввод).
Тестирование с помощью анализа граничных значений – это метод, который проверяет поведение ПО, используя крайние значения входных данных или граничные значения между разделами данных.
Используя эти четыре раздела и границы между ними, мы можем разработать следующие тест-кейсы:
- Проверками для эквивалентного разбиения являются: 42 (достоверно); -15, 2 и 107 (недопустимо).
- Проверки для анализа граничных значений: 10 и 99 (действительные); -10, -9, 9 и 100 (недействительные).
3. В автоматизации тестирования мы используем команды assert и verify. В чем разница между ними, и когда они используются?
Важной частью тестирования является проверка результатов. При автоматизации тестирования мы проводим проверку результатов каждого тест-кейса, чтобы убедиться в их правильности.
Чтобы выполнить эти проверки, например, с помощью фреймворка Selenium, мы используем классы команд Assert* и Verify*.
Обе группы команд assert и verify проверяют, истинны ли заданные условия. Разница лишь в том, что происходит, если условие ложно и проверка неверна. При неудачном срабатывании команды assert следующий за ней код не будет выполнен, и тест сразу же прервется. В то же время, при неудаче команды verify код выполнится в любом случае.
Мы используем команды класса assert, когда код, следующий за ними, зависит от успешности их выполнения. Например, мы хотим совершать какие-либо действия на странице, только если мы вошли в систему в роли администратора. В этой ситуации мы будем утверждать, что текущий пользователь, авторизованный в системе, равен администратору, и тестовый код будет выполняться только при выполнении этого условия. В противном случае в этих действиях нет смысла, поскольку мы знаем, что тестируем на неправильном окружении.
Мы используем команды verify, когда код после них может быть выполнен независимо от выполнения условия. Например, проверка заголовка веб-страницы: мы просто хотим убедиться, что он соответствует ожидаемому, и занесем результат выполнения команды verify в журнал. Неправильный заголовок сам по себе не должен влиять на другие тестируемые зоны.
4. В чем разница между верификацией и валидацией?
Верификация и валидация – два фундаментальных термина в обеспечении качества, которые часто ошибочно путают. Когда речь идет о точной формулировке, мы можем задать себе два вопроса:
- Правильно ли мы делаем продукт? (верификация)
- Создаем ли мы правильный продукт? (валидация)
Сначала мы проверим, что продукт, который мы создаем, работает, в нем есть все необходимые элементы в соответствии с заданными требованиями. Этот процесс называется верификацией. Затем, на финальных этапах разработки программного обеспечения, мы убедимся, что наш продукт удовлетворяет потребностям и ожиданиям конечного пользователя. Этот процесс называется валидацией.
И верификация, и валидация жизненно важны в процессе обеспечения качества, так как они позволяют находить разные дефекты. Верификация выявляет дефекты в документации спецификации, а валидация – в реализации программного обеспечения.
5. В чем разница между серьезностью и приоритетом? Приведите примеры багов с высокой серьезностью и низким приоритетом в сравнении с багами с низкой серьезностью и высоким приоритетом.
Серьезность и приоритет – атрибуты, которые характеризуют влияние дефекта на работоспособность продукта. Серьезность означает уровень критичности проблемы, а приоритет – то, насколько срочно необходимо ее решить.
Серьезность – это характеристика, которая точно определена, поскольку она основана на том, как проблема влияет на конечных пользователей. Если пользователь сможет нормально взаимодействовать с приложением, и использование приложения не будет затруднено чем-либо, то серьезность проблемы будет оценена как низкая. Но если пользователь столкнется со сбоями в работе приложения или прочими проблемами при его использовании, серьезность возрастает до более высокого уровня.
Значение приоритета, в отличие от серьезности, определяется индивидуальным суждением ответственного лица в соответствии с указанными требованиями. Обычно приоритет растет по мере того, как повышается вероятность столкновения пользователя с проблемой.
Проблемы высокой серьезности, но низкого приоритета включают следующие случаи:
- Приложение аварийно завершает работу при нажатии на непонятную кнопку на устаревшей странице, с которой пользователи редко взаимодействуют.
- Доступ к неопубликованным постам (черновым версиям) в админке возможен без действующего логина, если ввести точный адрес вручную (например, https://www.private.domain/admin/panel/posts/drafts/19380108/edit).
- Нажатие на кнопку отправки 50 раз подряд приводит к сбою в работе приложения
Проблемы низкой серьезности, но высокого приоритета включают в себя такие примеры:
- Неправильный логотип компании на главной странице
- Опечатка в заголовке на главной странице
- Отображается неправильная фотография товара
6. Когда нежелательна автоматизация тестирования?
У автоматизации тестирования имеется много плюсов, и тест-кейсы должны быть автоматизированы, когда это возможно и целесообразно. Однако существуют определенные сценарии, когда автоматизация тестирования нежелательна, а ручное тестирование является предпочтительным выбором:
- Когда проверка зависит от человека, выполняющего тест (например, тестирование UI/UX).
- Когда функция разрабатывается с постоянными изменениями, и автоматизация будет означать лишь потерю времени и средств.
- Когда выполнить тест-кейсы чрезвычайно сложно, и их автоматизация будет пустой тратой ресурсов
- Когда QA инженерам нужно провести ручное тестирование, чтобы получить более детальное представление о системе.
7. Что такое матрица трассируемости, каковы ее преимущества?
RTM (Requirement Traceability Matrix) – это документ, который описывает связь между тестовыми сценариями (написанными QA инженером) и бизнес-/техническими требованиями (указанными клиентом или командой разработчиков). Основная идея RTM заключается в том, чтобы оценить, насколько плотно продукт покрыт тест-кейсами, гарантируя таким образом, что ни одна функциональность не останется непроверенной.
Используя матрицу трассируемости, мы можем подтвердить 100-процентное покрытие тестами бизнес- и технических требований, а также получить четкое представление о дефектах и статусе выполнения проверок. Её применение, несомненно, выявляет любые недостающие требования и/или несоответствия в документации.
RTM позволяет глубже понять работу QA и то влияние, которое оказывает на инженеров QA прохождение тест-кейсов и их повторная обработка.
Предположим, у нас есть следующие требования:
- R.01: Пользователь может войти в систему.
- R.02: Пользователь может открыть страницу профиля
- R.03: Пользователь может отправлять сообщения другим пользователям
- R.04: У пользователя может быть установлена фотография профиля
- R.05: Пользователь может редактировать отправленные сообщения.
Затем мы можем разработать следующие тест-кейсы:
- T.01: Проверить, что пользователь может войти в систему.
- T.02: Убедиться, что пользователь может открыть страницу профиля и отредактировать изображение профиля
- T.03: Убедиться, что пользователь может отправлять и редактировать сообщения.
В результате получится следующая RTM, показывающая взаимосвязь между требованиями и тест-кейсами:
8. Что такое критерии выхода, и как определить, какими они должны быть?
Теоретически, для некоторых продуктов и случаев тестирование может потребовать огромного количества ресурсов, а также бывает невозможным или нецелесообразным. Чтобы иметь надлежащий процесс обеспечения качества, при котором мы сможем с уверенностью сделать вывод, что продукт готов для конечного пользователя – мы должны четко понимать, в какой момент нужно заканчивать тестирование.
Именно здесь мы применяем документ с критериями выхода, в котором перечислены условия, которые должны быть выполнены до релиза продукта. Эти критерии определяются на этапе планирования тестирования. Они позволяют QA менеджерам и тестировщикам наладить эффективный и результативный процесс QA, который будет соответствовать заданным условиям, обеспечивая соответствие разрабатываемого ПО требованиям и его своевременный выпуск.
Критерии выхода могут состоять из: покрытия тест-кейсами, оставшихся проблем по приоритету и/или серьезности, охвата функциональностей, сроков, бизнес-требований и т.д.
Список критериев выхода может быть следующим:
- Все тестовые случаи были выполнены
- 95 процентов тестов пройдено
- Больше нет проблем с высоким приоритетом и высокой степенью серьезности
- Любые изменения в пользовательских историях задокументированы.
Из примера видно, что критерии выхода должны быть строгими, но разумными. Нереально ожидать, что 100 процентов всех тестов будут прогоняться постоянно. Тем не менее мы должны убедиться в отсутствии критических ошибок, которые могут привести к сбоям в работе системы или к тому, что пользователь не сможет использовать систему ожидаемым образом.
9. Определите минимальное количество тест-кейсов, необходимых для полного покрытия утверждений, ветвей и путей для следующего фрагмента кода:
Read X
Read Y
IF X > 0 THEN
IF Y > 0 THEN
Print "Positive"
ENDIF
ENDIF
IF X < 0 THEN
Print "Negative"
ENDIF Сначала мы начнем с построения блок-схемы кода:
Чтобы получить нужное количество тест-кейсов для полного, 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
Получение нужного количества тест-кейсов для полного покрытия ветвей означает нахождение минимального количества путей, которые будут охватывать все возможные истинные и ложные утверждения. Используя наши два пути из полного покрытия операторов, мы сможем достичь практически полного покрытия ветвей. Единственная ветвь, которую эти два пути не покрывают, это ветвь “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 (когда X = 0)
Перевод статьи «10 Essential QA Interview Questions».