Чтобы помочь вам подготовиться к предстоящему собеседованию, мы собрали наиболее актуальные вопросы для собеседования на позицию тестировщика. Вопросы будут как для новичков, так и для опытных QA-инженеров.
Если хотите сразу перейти к вопросам для своего уровня, вот краткая навигация:
А если вы предпочитаете идти по порядку, давайте сперва разберемся с основным термином, который значится в названии позиции тестировщика.
Ищите работу Junior QA? Тогда вам в наш телеграм канал QA Вакансии. Каждую неделю 7 лучших вакансий с телеграм контактом HR компании.
БОЛЬШЕ ВОПРОСОВ С СОБЕСЕДОВАНИЙ В НАШЕМ ТЕЛЕГРАМ КАНАЛЕ QASOBES
Что такое QA?
QA расшифровывается как Quality Assurance. В переводе на русский – “обеспечение качества”.
Определение “качественный” применимо к продукту или услуге, которые “пригодны для использования по назначению”. Обеспечение – создание уверенности в том, что продукт или услуга будут работать успешно. Это гарантия, что продукт будет работать безупречно и в соответствии с ожиданиями или критериями.
В 2015 году компания Starbucks потеряла миллионы долларов прибыли из-за проблемы с ежедневным обновлением системы. Это привело к закрытию касс во многих точках продаж по всей территории США и Канады. Пока системы не были перестроены и восстановлены, кофейни были вынуждены раздавать бесплатные напитки. Это наглядно демонстрирует, насколько важно, чтобы система была превосходного качества.
В тестировании программ “QA” описывается как метод обеспечения качества программных продуктов или услуг, предоставляемых компанией для клиентов. Любой системный процесс проверки продукта или услуги на соответствие заявленным требованиям известен как обеспечение качества.
Обеспечение качества направлено на то, чтобы сделать процесс разработки более эффективным и результативным в соответствии со стандартами качества, установленными для программных продуктов.
Тестирование – популярный термин для обозначения QA. Обеспечение качества – это проактивная процедура, которая определяет стратегии предотвращения ошибок в процессе разработки ПО. В фазе тестирования жизненного цикла разработки ПО должны участвовать не только тестировщики, но и заинтересованные лица, бизнес-аналитики, разработчики.
Описывая и устанавливая требования к процессу разработки ПО и стандарты качества, процесс тестирования способствует повышению производительности команды проекта. Система обеспечения качества призвана повысить доверие потребителей и надежность программы, а также улучшить рабочие процедуры. Это позволит компании более эффективно конкурировать на рынке.
Вопросы по тестированию для новичков
1. Каков жизненный цикл процесса тестирования?
Каждый процесс тестирования связан с циклом PDCA (Plan Do Check Act: Планирование-Действие-Проверка-Корректировка), известным также как цикл Деминга. Ниже перечислены фазы этого цикла:
- Планирование. Организация должна спланировать и разработать процедурные цели, а также методы, необходимые для обеспечения высокого качества конечного продукта. Здесь QA гарантирует, что при планировании учитывается качество продукции.
- Действие. Эта фаза включает в себя разработку и тестирование процессов, а также внесение изменений в процессы. Здесь QA гарантирует, что процедуры разработки поддерживают качество продукта.
- Проверка. На этом этапе процессы контролируются, изменяются и проверяются на предмет достижения намеченных целей. Здесь QA гарантирует, что процессы тщательно проверяются, чтобы не пропустить никаких дефектов.
- Корректировка. На этом этапе тестировщик должен предпринять шаги, необходимые для улучшения процессов.
Прохождение этих этапов призвано гарантировать, что процедуры организации оцениваются и улучшаются на регулярной основе.
2. Чем QA отличается от тестирования?
Тестирование программного обеспечения – это метод исследования программного продукта, направленный на проверку его соответствия требованиям и ожиданиям клиентов и выявление потенциальных недостатков. Чтобы протестировать продукт, найти ошибки и проверить, были ли они исправлены, используются различные методы. При помощи тестирования заказчики могут убедиться, что созданный продукт соответствует их ожиданиям в дизайне, совместимости и функциональности.
Проверка соответствия продукта спецификациям и требованиям клиента, а также обнаружение недостатков и сообщение о них – все это является частью процесса тестирования. Для выявления недостатков программ используются различные виды тестирования, такие как функциональное, нефункциональное и приемочное. Цель тестирования ПО – убедиться, что все обнаруженные недостатки полностью исправлены без каких-либо побочных эффектов перед передачей готового продукта клиенту.
В следующей таблице перечислены отличия обеспечения качества от тестирования:
| Обеспечение качества | Тестирование |
|---|---|
| Это подмножество жизненного цикла разработки программного обеспечения (SDLC). | Это подмножество контроля качества (QC). |
| Ориентировано на процесс. | Ориентировано на продукт. |
| Носит превентивный характер (пытается предотвратить появление дефектов в продукте). | Корректирующий характер (тестирование направлено на исправление дефектов, присутствующих в продукте). |
| Обеспечение качества проводится для предотвращения дефектов в продукте. | Тестирование проводится для поиска и устранения дефектов в продукте. |
| Обеспечение качества гарантирует наличие процессов и процедур, которым следует команда. | Тестирование подтверждает соответствие продукта требуемым спецификациям. |
| При обеспечении качества основное внимание уделяется процессам, которые работают с продуктом. | При тестировании основное внимание уделяется конечному продукту. |
| Это проактивный процесс (проактивная стратегия направлена на предотвращение возникновения проблем). | Это реактивный процесс (реактивный подход фокусируется на реагировании на события после их возникновения). |
| Обеспечение качества должно осуществляться всей командой. | При тестировании этим занимается только команда тестировщиков. |
3. Назовите отличия тест-плана от стратегии тестирования
- Тест-план – это документ, который описывает процесс тестирования, цель, график, оценки и ожидания, а также ресурсы, необходимые для тестирования. В нем нужно определить объем работ, необходимый для проверки тестируемого приложения. План тестирования предназначен для управления тест-кейсами. С его помощью менеджер по тестированию тщательно отслеживает и контролирует процесс. Идентификатор тест-плана, области тестирования, тестовые системы, лица, ответственные за тесты, основные критерии успеха или провала, ожидания от тестирования, обязанности, сроки и так далее – все это включается в план тестирования.
- Стратегия тестирования. В тестировании ПО стратегия – это набор руководящих принципов, которые определяют подход к тест-дизайну и контролируют процесс тестирования. Цель стратегии тестирования – определить системный подход к тестированию, чтобы обеспечить качество, тестовое покрытие и надежное планирование.
В следующей таблице перечислены отличия тест-плана от стратегии тестирования:
| План тестирования | Стратегия тестирования |
|---|---|
| План тестирования программного проекта - это документ, определяющий объем, цель, подход и акценты процесса тестирования программного обеспечения. | Стратегия тестирования - это набор правил, который описывает, как разрабатывать тесты и как их проводить. |
| Элементы плана тестирования: - идентификатор плана тестирования - функции, подлежащие тестированию - процедуры тестирования - задачи тестирования - критерии прохождения или провала функции - результаты тестирования - обязанности - график. | Компоненты стратегии тестирования: - цели и объем - форматы документации - методологии тестирования - структура отчетности команды - стратегия коммуникации с клиентом |
| Спецификации процесса тестирования описаны в плане тестирования. | Общие подходы описаны в стратегии тестирования. |
| Менеджер или руководитель тестирования выполняет план тестирования, в котором указывается, как тестировать, когда тестировать, кто и что будет тестировать. | Стратегию тестирования реализует менеджер проекта. В ней указывается, какой подход использовать и какой модуль тестировать. |
| Изменения в плане тестирования возможны после его создания. | Стратегию тестирования после ее создания невозможно изменить. |
| Планирование тестирования проводится для выявления рисков путем определения потенциальных проблем и зависимостей. | Это долгосрочный подход. Для создания стратегии тестирования можно использовать информацию, не относящуюся к конкретному проекту. |
| План тестирования может существовать отдельно. | Стратегия тестирования часто встречается как элемент плана тестирования в небольших проектах. |
| Устанавливается на уровне проекта. | Настраивается на организационном уровне и может использоваться в разных проектах. |
4. Что вы понимаете под терминами “сборка” и “релиз”? Чем они отличаются?
- Сборка (англ. build) – это программа или приложение, готовое к тестированию. Разработчики создают программное обеспечение, которое затем передают тестировщикам для тестирования. Это широкое понятие, которое относится к любому приложению, которое будет проверяться. Разработчики могут либо создать новую программу, либо добавить новую функцию в уже существующее приложение. Затем это приложение с новой функциональностью называется “сборкой”, которая проверяется тестировщиками.
- Релиз (англ. release). После разработки и тестирования релиз – это окончательно разработанное приложение. Команда тестировщиков проверяет программу и после этого отдает ее заказчику. Релиз основывается на сборках, а их может быть несколько.
В следующей таблице перечислены различия между сборкой и релизом:
| Сборка | Релиз |
|---|---|
| Сборка относится к версии программного обеспечения или приложения, которую команда разработчиков передает команде тестирования. | Релиз - это программное обеспечение, которое команда тестирования передает конечным клиентам. |
| Версия сборки программного обеспечения должна быть протестирована. Как правило, версия сборки проходит санитарное тестирование. | Релизная версия программного обеспечения больше не требует тестирования. |
| Версии сборки ПО создаются чаще, чем версии релиза. | Релизные версии ПО создаются реже, чем версии сборки. |
5. Что вы понимаете под bug leakage и bug release?
Bug leakage можно перевести как “утечку бага”. Когда конечный пользователь находит баг, который существовал во время тестирования, но не был обнаружен тестировщиком, это bug leakage.
Bug release можно перевести как “выпуск бага”. Бывает, что приложение выпускается с набором дефектов, о которых известно команде. Это bug release. Он допускается, когда компания не может себе позволить отложить выход приложения на рынок и решает исправить проблемы в следующих версиях.
Баги такого типа часто имеют низкую серьезность и (или) приоритетность. В большинстве случаев они указываются в примечаниях к релизу.
6. Что вы понимаете под матрицей отслеживаемости?
Матрицу отслеживаемости также называют матрицей трассируемости/трассировки – от англ. Traceability Matrix. Это документ, объединяющий требования по модели “многие-ко-многим” для обеспечения тестового покрытия. Эта матрица используется для отслеживания требований и обеспечения их выполнения в текущем проекте.
Ниже перечислены три основных компонента матрицы отслеживаемости:
- Прямая отслеживаемость. Эта матрица используется для определения того, развивается ли проект в правильном направлении. Она гарантирует, что к продукту применены все спецификации и что каждое требование адекватно протестировано. Она связывает тест-кейсы с требованиями.
- Обратная или реверсивная отслеживаемость. Используется для проверки того, что текущий продукт остается на правильном пути. Ее цель – убедиться, что мы не расширяем объем проекта, добавляя код, дизайн, тестирование или другие действия, не указанные в требованиях. Она связывает требования с тест-кейсами.
- Двунаправленная отслеживаемость. Эта матрица отслеживаемости гарантирует, что все критерии покрываются тест-кейсами в обоих направлениях (вперед и назад). Она рассматривает влияние изменений требований, возникших в связи с дефектами продукта, и наоборот.
7. Что вы понимаете под коэффициентом утечки багов?
В качестве метрики для определения эффективности тестирования часто используется коэффициент утечки багов (Defect leakage ratio, DLR). Это отношение дефектов, пропущенных тестировщиками и обнаруженных на последующих стадиях, к общему количеству дефектов.
DLR служит для вычисления процента дефектов, просачивающихся с одного этапа тестирования на другой, а также для демонстрации эффективности тестирования. Чем меньше показатель DLR, тем эффективнее команда тестировщиков.
8. Чем QA отличается от QC?
Контроль качества (англ. Quality Control, QC) – это системный набор методов, позволяющих убедиться в качестве программных продуктов или услуг. Путем тестирования и анализа функциональных и нефункциональных требований к программному продукту, процесс контроля качества гарантирует, что продукт соответствует требуемым стандартам.
В следующей таблице перечислены различия между обеспечением качества (QA) и контролем качества (QC):
| Обеспечение качества QA | Контроль качества QC |
|---|---|
| Это метод, направленный на обеспечение заданного качества. | Это метод, направленный на достижение желаемого уровня качества. |
| Цель - избежать дефектов. | Цель - найти и исправить недостатки. |
| Это способ отслеживания качества (верификация) | Это метод проверки качества (валидация) |
| Не требует запуска программного обеспечения. | Всегда требует запуска программного обеспечения. |
| Это проактивная мера (метод профилактики). | Это реактивная мера (метод исправления). |
| Это метод подготовки результатов. | Это техника обеспечения правильности результатов. |
| QA участвует во всем процессе разработки программного обеспечения. | QC участвует во всем процессе тестирования программного обеспечения. |
| Контроль качества устанавливает стандарты и процессы для достижения ожиданий клиента. | В процессе работы над продуктом контроль качества обеспечивает соблюдение стандартов. |
| Проводится до контроля качества. | Проводится только после завершения деятельности по обеспечению качества. |
| Это низкоуровневая деятельность, которая может обнаружить ошибки и неточности, чего не может сделать контроль качества. | Это деятельность высокого уровня, потому что она может обнаружить ошибки, которые не может обнаружить контроль качества. |
| Обеспечение качества гарантирует, что все сделано правильно, поэтому оно классифицируется как деятельность по верификации. | Контроль качества гарантирует, что все, что мы делаем, соответствует требованиям, поэтому он классифицируется как деятельность по валидации. |
| SPC, или статистический контроль процессов, - это статистический метод, используемый в обеспечении качества. | SQC, или статистический контроль качества, - это статистический метод, используемый в контроле качества. |
9. Что такое monkey testing?
Обезьянье тестирование – это метод тестирования ПО, при котором тестировщик вводит в приложение случайные входные данные без заранее определенных тест-кейсов и наблюдает за поведением программы. Целью обезьяньего тестирования является выявление проблем в программных продуктах при помощи экспериментальных методов.
Monkey testing – это своего рода тестирование по методу черного ящика, которое включает в себя ввод случайных входных данных в систему, чтобы проверить ее поведение на предмет сбоя.
Обезьянье тестирование не требует создания тест-кейсов. Оно также может быть автоматизировано, в том смысле, что для получения случайных входных данных разрабатываются программы или скрипты.
Эта техника может пригодиться при проведении стрессового или нагрузочного тестирования.
“Обезьяны” делятся на две категории:
- Умные обезьяны. Это люди, знающие приложение на базовом уровне. Они знают, куда ведет та или иная страница и являются ли вводимые ими данные валидными. Если они обнаруживают баг, им хватает ума сообщить о нем. Они также знают о меню и кнопках.
- Глупые обезьяны. Это люди, которые совершенно не разбираются в приложении. Они понятия не имеют, куда ведут страницы приложения. Глупые обезьяны вводят случайные данные и не имеют ни малейшего понятия о начальной и конечной точках приложения. Несмотря на отсутствие знаний о приложении, они обнаруживают такие ошибки, как сбой среды разработки или технический сбой. Знания глупых обезьян о работе приложения и пользовательском интерфейсе также ограничены.
10. Что вы знаете о Gorilla Testing?
Gorilla Testing – это метод тестирования программного обеспечения, при котором модуль многократно тестируется на основе случайных входных данных. Тестирование проводится вручную, что очень утомительно, поэтому этот вид тестирования также называется “пыточным” (Torture Testing).
В горильем тестировании тестировщики и разработчики работают совместно.
11. Чем отличаются Monkey Testing и Gorilla Testing?
В следующей таблице перечислены отличия горильего тестирования от обезьяньего:
| Горилье тестирование | Обезьянье тестирование |
|---|---|
| Метод тестирования программного обеспечения, при котором модуль часто тестируется на основе некоторых случайных входных данных, что гарантирует проверку работы модуля и отсутствие проблем в нем. | Метод тестирования программного обеспечения, при котором оценивается поведение системы и проверяется, произойдет ли сбой, на основе некоторых случайных входных данных и без тест-кейсов. |
| Основная цель - определить, правильно ли функционирует модуль. | Основная цель - определить, произойдет ли сбой системы. |
| Это вид ручного тестирования, которое проводится многократно. | Это вид случайного тестирования, которое не включает тест-кейсы. |
| Этому тестированию подвергаются только несколько отдельных модулей системы. | Это тестирование проводится над всей системой. |
| В модульном тестировании в основном используется метод горильего тестирования. | При системном тестировании в основном используется метод обезьяньего тестирования. |
| Пыточное тестирование, тестирование на отказоустойчивость и фрустрирующее тестирование - все эти термины используются для описания горильего тестирования. | Случайное тестирование, fuzz-тестирование и стохастическое тестирование - все эти термины используются для описания обезьяньего тестирования. |
12. Объясните, что такое testware
Testware можно перевести как тестовое обеспечение. К testware относится набор программного обеспечения, созданного специально для тестирования.
Все утилиты и прикладное программное обеспечение, которые применяются для тестирования программного кода, но не обязательно способствуют достижению эксплуатационных целей, называются testware.
То есть testware – это только рабочее окружение для прикладного ПО или его частей, а не статическая конфигурация.
Тестовое обеспечение также включает артефакты, созданные в процессе тестирования и необходимые для планирования, разработки и выполнения тестов. Например, документация, сценарии, входные данные, ожидаемые результаты, процессы настройки и очистки, файлы, базы данных, среда и любое другое программное обеспечение или инструменты, используемые во время тестирования.
Тестовое обеспечение, как и программное, состоит из кода и двоичных файлов, а также тест-кейсов, тест-планов и отчетов о тестировании. Testware должно храниться и добросовестно поддерживаться при помощи системы управления конфигурациями.
13. Что вы понимаете под тестированием, управляемым данными?
Управляемое данными тестирование (Data-driven Testing) – это техника тестирования ПО, при которой тестовые данные хранятся в табличном формате. Тестировщики могут ввести один тестовый скрипт, способный запускать тесты для всех тестовых данных из таблицы, и ожидать, что результаты тестирования будут возвращены в той же таблице. Это также известно как параметризованное тестирование или тестирование, управляемое таблицами.
Поскольку у тестировщиков обычно несколько наборов данных для одного теста, тестирование, управляемое данными, является критически важным. Создание разных тестов для каждого набора данных может отнимать много времени. Data-driven testing позволяет хранить данные отдельно от тест-кейсов, а одни и те же сценарии тестирования могут быть запущены для нескольких комбинаций входных тестовых данных, что приводит к более эффективным результатам тестирования.
На рисунке выше показан процесс тестирования, управляемого данными. Тестовые данные берутся из файла и тестируются в приложении, а затем полученный результат сравнивается с фактическим.
14. Как убедиться в том, что ваше тестирование тщательное и всестороннее?
Матрица отслеживаемости требований и матрица тестового покрытия помогут нам определить, достаточно ли наши требования покрыты тест-кейсами.
При помощи матрицы отслеживаемости мы узнаем, достаточны ли условия тестирования для выполнения всех требований. А с помощью матрицы покрытия мы увидим, достаточно ли тест-кейсов для удовлетворения всех условий тестирования из матрицы отслеживания требований.
Образец матрицы отслеживаемости требований:
Образец матрицы тестового покрытия:
15. К каким артефактам вы обращаетесь при написании тест-кейсов?
При написании тест-кейсов мы можем ссылаться на следующие артефакты:
- спецификация функциональных требований
- документ, объясняющий, что собой представляют требования
- вайрфреймы
- юзкейсы
- пользовательские истории
- приемочные критерии
- тест-кейсы пользовательского приемочного тестирования.
16. Что такое тест-кейс? Какие техники написания хороших тест-кейсов знаете?
Тест-кейс – это совокупность действий, выполняемых для проверки правильной работы определенной функции или операции вашей программы. Это набор тестовых процедур, данных, пред- и пост-условий, созданный для конкретного тестового сценария для проверки какого-либо требования. Тест-кейс содержит определенные переменные или условия, которые тестировщик может использовать для сравнения ожидаемых и фактических результатов, чтобы оценить, соответствует ли программный продукт потребностям клиента.
Ниже приведены методы написания хороших тест-кейсов.
- Тест-кейсы должны быть простыми и понятными. Делайте свои тест-кейсы как можно более простыми. Дело в том, что не всегда их выполняет автор, поэтому они должны быть понятными. Используйте глаголы в повелительном наклонении: “перейдите на главную страницу”, “введите данные”, “нажмите здесь” и так далее. Это облегчает понимание этапов тестирования и ускоряет работу.
- Создавайте тест-кейсы, учитывающие интересы конечного пользователя.
- Следует избегать повторения тест-кейсов. Тесты не должны повторяться. Если тест необходим для выполнения другого теста, используйте для ссылки на него идентификатор тест-кейса в графе с предварительным условием.
- Следите за полнотой тестового покрытия. Удостоверьтесь, что вы написали тест-кейсы, которые покрывают все требования к программному обеспечению, указанные в спецификации. Чтобы убедиться, что ни одна функция или условие не остались непроверенными, используйте матрицу отслеживаемости.
- Не делайте предположений. При создании тест-кейса не делайте предположений о функционировании и возможностях вашего приложения. Следуйте спецификациям в документах.
- Самоочищение. Написанный вами тест-кейс должен возвращать тестовую среду в прежнее состояние и не должен приводить ее в негодность. Это особенно важно, когда речь идет о тестировании конфигурации.
Вопросы для опытных тестировщиков
17. Что вы понимаете под регрессионным тестированием? Какие тест-кейсы должны быть отобраны для регрессионного тестирования?
Регрессионное тестирование – это вид тестирования программного обеспечения, при помощи которого проверяется, что недавно добавленная фича или изменение кода не нарушили существующую функциональность.
Регрессионное тестирование – это полное или частичное повторное выполнение ранее выполненных тест-кейсов для подтверждения того, что текущая функциональность работает правильно. Это тестирование гарантирует, что новые модификации кода не вносят непредвиденные изменения в текущую функциональность. Оно гарантирует, что после внесения изменений старый код продолжает работать должным образом.
Согласно данным по отрасли, большая часть дефектов, о которых сообщают клиенты, была вызвана исправлениями ошибок в последнюю минуту, что повлекло непредвиденные последствия. Это возводит отбор тест-кейсов для регрессионного тестирования в ранг искусства.
Для создания эффективных регрессионных тестов можно отобрать следующие тест-кейсы:
- с большим количеством багов
- охватывающие часто используемый функционал
- проверяющие основные функции продукта
- проверяющие недавно или значительно измененные функции
- все интеграционные
- все сложные
- тесты граничных значений.
18. Объясните понятие риска в контексте QA. Какие пять аспектов риска вы знаете?
Когда речь идет о тестировании, риски – это возможные проблемы, которые ставят под угрозу цели заинтересованных сторон проекта. Это вероятность плохого или неблагоприятного результата. Риск – это то, что еще не произошло и может никогда не произойти, это потенциальная проблема. Вероятность того, что риск станет результатом, пропорциональна степени риска, связанного с возможностью негативных последствий.
Большинство людей, например, в какой-то момент своей жизни заболевают простудой, причем неоднократно. Но относительно здоровый человек переболеет без каких-либо серьезных последствий. В результате общий риск простудиться у такого человека невелик. С другой стороны, для пожилого человека, имеющего проблемы с дыханием, риск простудиться значителен.
Ниже перечислены пять аспектов риска в контексте разработки ПО:
- Расписание. Нереалистичные графики, пропуск важных мероприятий по составлению графика и другие факторы могут помешать завершению проекта в срок. Если тестирование проводится в отдаленной локации, то нестабильная связь может рассматриваться как потенциальный риск.
- Клиент. Двусмысленное описание требований, отсутствие ясности в вопросах, частые изменения требований и другие факторы могут привести к хаосу в ходе выполнения проекта.
- Человеческие ресурсы. Нехватка специалистов с требуемым уровнем квалификации для проекта, убывание специалистов. Для решения этой проблемы необходимо разработать соответствующие графики обучения людей, чтобы сбалансировать уровень знаний при утечке мозгов. Недооценивание процесса обучения может оказать негативное влияние на завершение проекта в срок.
- Системные ресурсы. Невозможность получить или задержка в получении всех основных технических ресурсов, таких как аппаратные и программные средства или лицензии на программное обеспечение, оказывает негативное влияние на проект.
- Качество. Сочетание таких проблем, как нехватка ресурсов, сжатые сроки поставки и частые изменения требований, окажут влияние на качество тестирования продукта.
19. Что вы понимаете под серьезностью и приоритетностью бага?
- Серьезность бага определяется как степень его влияния на общую функциональность программного обеспечения. Серьезность бага – это метрика, которая показывает, насколько он критичен и как сильно он влияет на функциональность программного обеспечения.
- Приоритетность – это параметр, определяющий порядок устранения багов. Дефекты с более высоким приоритетом должны быть устранены в первую очередь.
В таблице перечислены отличия серьезности и приоритетности:
| Серьезность | Приоритетность |
|---|---|
| Серьезность бага - показатель того, насколько он может влиять на общую работу тестируемого продукта. | Приоритет - это критерий, используемый для определения того, какие дефекты должны быть устранены в первую очередь. |
| Степень серьезности пропорциональна стандарту качества. | Приоритет связан с графиком решения проблемы. |
| Уровень серьезности дефекта определяется инженером по тестированию. | Приоритеты дефектов устанавливает менеджер продукта. |
| Серьезность бага показывает, насколько сильно он влияет на функциональность. | Приоритет относится к тому, как быстро баг должен быть устранен. |
| Имеет объективную ценность. | Ценность относительна. |
| Оценка остается постоянной с течением времени. | Оценка колеблется с течением времени. |
| Классификация багов по серьезности: - blocker (блокирующая ошибка) - critical (критическая ошибка) - major (существенный баг) - minor (незначительный баг) - trivial (тривиальный баг). | Приоритет бывает низкий, средний и высокий. |
20. Что вы понимаете под аудитом качества?
Аудит качества – это проверка, насколько продукция, дизайн, процесс или система соответствуют стандартным спецификациям и процедурам. Такие проверки проводят штатные или внешние аудиторы через заранее определенные промежутки времени, чтобы убедиться, что методы внутреннего контроля системы в учреждении четко определены и успешны.
Аудит качества состоит из двух частей. Первая – это проверка системы, с помощью которой создается продукция или услуги. Вторая – аудит качества самой продукции или услуг.
21. Как определить необходимый объем тестирования каждой части ПО?
Для определения того, сколько тестирования требует каждая часть нашего приложения, используется цикломатическая сложность. Эта техника помогает ответить на три вопроса, связанные с функционалом или программой в целом:
- Возможно ли протестировать функцию или программу?
- Все ли знают о функции/программе?
- Можно ли доверять функции/программе?
Мы можем использовать эту технику для определения “уровня” тестирования, необходимого для нашего приложения.
Обычно часть функционала считается сложной, если коэффицент цикломатической сложности больше или равен определенному числу. На основании этого QA-специалист приходит к выводу, что часть кода или функционала требует углубленного тестирования. Если коэффицент цикломатической сложности меньше, QA делает вывод, что функциональность менее сложная, и соответствующим образом корректирует объем тестирования.
Тут важно понимать весь жизненный цикл тестирования и быть готовым к изменению подхода при необходимости. Цель заключается в доставке качественного программного обеспечения, поэтому QA должен предпринимать все необходимые меры для улучшения процесса тестирования.
22. Чем нагрузочное тестирование отличается от стресс-тестирования?
- Нагрузочное тестирование – это тип тестирования, который оценивает производительность системы, программного продукта или приложения в условиях реальной нагрузки. Оно также демонстрирует поведение приложения в условиях повышенного сетевого трафика и использования большим количеством пользователей.
- Стресс-тестирование – это вид тестирования программного обеспечения, при котором проверяется стабильность и надежность системы. Тестировщики проверяют устойчивость системы и обработку ошибок в условиях чрезвычайно высокой нагрузки.
В следующей таблице перечислены отличия нагрузочного и стресс-тестирования:
| Нагрузочное тестирование | Стресс-тестирование |
|---|---|
| Нагрузочное тестирование используется для проверки того, как система справляется с большой нагрузкой, чтобы определить верхний предел системы. | Стресс-тестирование используется для определения устойчивости системы к чрезмерным нагрузкам и того, как она восстанавливается после сбоя. |
| Предел нагрузки - это точка, в которой при нагрузочном тестировании происходит поломка. | Предел нагрузки при стресс-тестировании выше, чем порог поломки. |
| Нагрузочное тестирование предполагает испытание программного обеспечения большим количеством пользователей. | Стресс-тестирование предполагает испытание системы на прочность при работе с различными объемами данных. |
| Нагрузочное тестирование используется для определения максимальной мощности системы или приложения. | Стресс-тестирование используется для определения того, как ведет себя система, когда на нее оказывается давление. |
| В ходе нагрузочного тестирования оценивается производительность. | Во время нагрузочного тестирования изучаются надежность и стабильность ПО. |
| Нагрузочное тестирование определяет эксплуатационные возможности системы или приложения. | С помощью нагрузочного тестирования обеспечивается безопасность системы. |
23. Чем функциональное тестирование отличается от нефункционального?
- Функциональное тестирование – это вид тестирования ПО, который включает в себя проверку системы на соответствие функциональным требованиями и спецификациям. Функциональное тестирование гарантирует, что приложение соответствует всем критериям или стандартам, указанным в техническом задании. Этот вид тестирования ориентирован на конечный продукт. Он направлен на моделирование стандартного использования системы без знания ее кода.
- Нефункциональное тестирование – это вид тестирования ПО, который включает проверку приложения на соответствие требованиям, не относящимся к функционалу. Оно охватывает все аспекты, которые не охватываются функциональным тестированием.
В таблице перечислены различия функционального и нефункционального тестирования:
| Функциональное тестирование | Нефункциональное тестирование |
|---|---|
| Проверяет, все ли функции приложения работают должным образом. | Проверяет поведение приложения. |
| Основано на потребностях клиента. | Основано на ожиданиях клиента. |
| Помогает улучшить функциональность приложения. | Способствует повышению производительности приложения. |
| Функциональное тестирование вручную проводить просто. | Вручную выполнять нефункциональное тестирование сложно. |
| Оценивает функциональность продукта. | Выясняет, на что способен продукт. |
| Основой для функционального тестирования является бизнес-требование. | Основой для нефункционального тестирования является требование к производительности. |
| Примеры ФТ: модульное, регрессионное, дымовое тестирование. | Примеры НТ: нагрузочное тестирование, стресс-тестирование, тестирование производительности. |
24. Что такое тестирование “черного ящика” и “белого ящика”? Чем они отличаются?
- Тестирование “белого ящика” изучает внутреннюю структуру программного обеспечения, включая используемые структуры данных, внутренний дизайн, структуру кода и то, как он работает. Оно также известно как структурное тестирование, тестирование “чистого ящика” или тестирование “стеклянного ящика”.
- Тестирование “черного ящика” – проверка того, что продукт соответствует функциональным требованиям. При этом внутренняя функциональность ПО тестировщику неизвестна, тестирование проводится без знания кода продукта. Для проведения тестирования “черного ящика” можно использовать следующие методы:
- Синтаксическое тестирование. Этот метод тестирования используется для систем, которые могут быть представлены синтаксически, при помощи языка. Например, компиляторы – это тип языка, который можно описать, используя бесконтекстную грамматику. В данном случае тест-кейсы создаются таким образом, чтобы каждое грамматическое правило применялось хотя бы один раз.
- Эквивалентное разбиение. Многие типы входных данных работают одинаково, поэтому их можно сгруппировать и использовать в тестировании только один инпут из каждого класса. Суть в том, что если тест-кейс в одном классе приводит к ошибке, другие тест-кейсы в том же классе также приведут к ошибке.
Данная таблица иллюстрирует отличия тестирования “белого ящика” и “черного ящика”:
| Тестирование "белого ящика" | Тестирование "черного ящика" |
|---|---|
| Это метод тестирования, при котором тестировщик знает внутреннюю структуру системы. | Это метод тестирования, который не требует знания внутренней структуры программы или приложения. |
| Также известно как структурное тестирование, тестирование на основе кода или тестирование в стеклянном ящике. | Тестирование на основе данных, функциональное тестирование - эти термины используются для описания тестирования методом черного ящика. |
| Поскольку внутренняя работа системы известна, тестировщик может проверить ее. | Внутреннее поведение приложения неясно, поэтому тестирование основано на внешних ожиданиях. |
| Тестирование лучше подходит для тестирования на низших уровнях, таких как модульное и интеграционное тестирование. | Более высокие этапы тестирования, такие как системное и приемочное тестирование, выигрывают от такого подхода. |
| Тестирование "белого ящика" требует рабочего понимания программирования. | Тестирование "черного ящика" не требует знания программирования. |
| Автоматизировать тестирование "белого ящика" очень просто. | Автоматизировать тестирование "черного ящика" сложно. |
| Фундаментальная цель тестирования "белого ящика" заключается в обеспечении высокого качества кода. | Основная цель такого тестирования - определить, какими функциями обладает тестируемая система. |
| К тестированию можно приступать после завершения подготовки документа по детальному проектированию. | К тестированию можно приступать после подготовки документа по спецификации требований. |
| Для выполнения тестирования методом "белого ящика" вам потребуется тестировщик с большим опытом. | Тестировщики низкой квалификации могут протестировать приложение, не имея предварительного представления о языке программирования или реализации операционной системы. |
25. Что такое “триаж багов”?
Триаж багов – это их сортировка. Термин “триаж” используется в тестировании ПО для описания серьезности и приоритетности новых дефектов.
Цель триажа багов заключается в рассмотрении, определении приоритетов и принятии решений по багам. Команда должна подтвердить серьезность дефекта, внести необходимые изменения, сделать вывод о баге и назначить отвественных за его исправление.
Этот метод в основном используется в гибкой методологии управления проектами. Частота проведения совещаний по сортировке багов не является фиксированной. Она зависит от обстоятельств проекта.
Ниже перечислены некоторые ключевые факторы, влияющие на частоту проведения совещаний по триажу багов:
- график проекта
- количество багов в системе
- расписания членов команды
- состояние проекта в целом.
26. Что вы знаете о заглушках и драйверах? Назовите их отличия
Заглушки
Заглушки создаются разработчиками для использования вместо модулей, если соответствующие модули не были созданы, отсутствуют на стадии разработки или недоступны во время тестирования.
Заглушка – это модуль, который имитирует функциональность недоступного модуля.
Заглушки используются, когда требуются модули более низкого уровня, но в настоящее время они недоступны. Например, предположим, что у вас есть три различных модуля: Login, Home и User. Предположим, что модуль Login готов к тестированию, но два второстепенных модуля Home и User, которые вызываются модулем Login, недоступны. На этом этапе для копирования недоступных функций пишется фиктивный код. Заглушки – это фиктивные части кода.
Драйверы
Похожи на заглушки, поскольку служат той же цели, но драйверы более сложные и используются в интеграционном тестировании “снизу вверх”.
Драйверы применяются при тестировании конкретного модуля в условиях, когда из-за непредвиденных обстоятельств отвутствуют основные модули. То есть, когда отсутствуют высокоуровневые модули, используются драйверы. Но они также могут использоваться при отсутствии модулей более низкого уровня.
Давайте воспользуемся тем же примером, что и раньше. Предположим, что модули User и Home на этот раз готовы к тестированию, а модуль Login – нет. Поскольку модуль Login передает данные в Home и User, разрабатывается фиктивный фрагмент кода для эмуляции модуля Login.
В таблице перечислены отличия заглушки и драйвера:
| Заглушка | Драйвер |
|---|---|
| При интеграционном тестировании сверху вниз используются заглушки. | При интеграционном тестировании снизу вверх используются драйверы. |
| Заглушки аналогичны программным модулям, находящимся на стадии разработки. | Драйверы обычно вызывают компонент, который необходимо протестировать. |
| Заглушки в основном используются, когда недоступны низкоуровневые модули. | Драйверы в основном используются для замены высокоуровневых модулей, в отдельных случаях они также могут быть использованы для замены низкоуровневых. |
| Их также называют "вызываемыми программами". | Их также называют "вызывающими программами". |
| Для тестирования возможностей и функциональности модулей используются заглушки. | Если к моменту тестирования не разработан основной модуль программы, используются драйверы. |
| Если тестирование модуля верхнего уровня завершено, но разработка модуля нижнего уровня продолжается, учитываются заглушки. | Если тестирование модуля нижнего уровня завершено, а разработка модуля верхнего уровня продолжается, учитываются драйверы. |
| Заглушки используются для тестирования основного модуля, когда модули более низкого уровня отсутствуют или находятся в частично завершенном состоянии. | Когда модули более высокого уровня отсутствуют или находятся в частично собранном состоянии, а мы хотим протестировать нижний (под)модуль, мы используем драйверы. |
Заключение
Хорошая QA-стратегия позволяет разрабатывать программные продукты высокого качества и без багов. Однако QA подразумевает нечто большее. Помимо поиска багов и способов улучшения продукта обеспечение качества жизненно важно для многих других сторон бизнеса, таких как взаимодействие с клиентами и репутация компании на рынке.