Подписаться
Главная / Блог / QA automation INTERVIEW PART 1

Собеседование на должность
QA Automation Engineer.
Теория тестирования.

[ Часть 1 ]
Собеседование на должность
QA Automation Engineer.
Теория тестирования.

Smartiqa Article
Часть 3
Собеседование на должность QA Automation Engineer.
Web, SQL, Linux, Git, сети.
Часть 2
Собеседование на должность QA Automation Engineer.
Основы программирования.
  • Дата: 23 августа 2023
  • Автор: Евгений Поваров
Мы поспрашивали коллег, почитали статьи, посмотрели видео на ютубе. И как итог, сформировали список вопросов (и кратких ответов), который поможет вам подготовиться и успешно пройти собеседование на роль QA Automation Engineer.

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

1. ПО и его качество

  1. Жизненный цикл ПО (Software Development Life Cycle, SDLC). Этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция, эксплуатация и поддержка.
  2. Каскадная модель разработки ПО (Waterfall model). В данной модели разработчики переходят от одного этапа к другому строго последовательно и только после окончания предыдущего. Фазы: определение требований, проектирование, кодинг, тестирование и отладка, поддержка.
  3. Гибкая методология разработки (Agile). Это итеративный подход к управлению проектами и разработке ПО. Разработка сводится к серии коротких циклов (итераций) по 2-3 недели. После каждой итерации продукт готов к выпуску. И также после каждого цикла пересматриваются требования на актуальность. Примеры: SCRUM, Kanban.
  4. SCRUM. Одна из гибких методологий. Основные артефакты: Product Backlog, Sprint Backlog, Sprint Goal, Sprint Burndown Chart.
  5. Что такое качество ПО? Степень близости продукта к ожидаемому результату (требованиям).
  6. Quality Assurance. Комплекс мероприятий на тему: каким должно быть качество, как достичь данного качества, обеспечение качества, как улучшить качество.
  7. Quality Control. Действия, которые помогают понять, готово ли ПО к релизу, соответствует ли требованиям.
  8. Testing. Проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. Это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). Это верификация + валидация + поиск ошибок.
  9. Verification/Validation. Верификация — проводится практически всегда, выполняется методом проверки характеристик продукции с заданными требованиями, результатом является вывод о соответствии продукции. Соответствует вопросу: "Правильно ли мы строим здание?". Валидация — проводится при необходимости, выполняется методом анализа заданных условий применения и оценки соответствия характеристик продукции этим требованиям, результатом является вывод о возможности применения продукции для конкретных условий. Соответствует вопросу: "Правильное ли мы строим здание?". Например, лекарство: верификация - создали лекарство по требованиям, валидация - можно ли их употреблять конкретному человеку.
  10. Цели тестирования. 1. Соответствие требованиям. 2. Очищение от багов

2. Тестовая документация

  1. Что такое спецификация? Текстовый файл с описанием того, что нужно протестировать в тестовых данных. Получается на основе анализа требований заказчика.
  2. Что такое требования? Это совокупность утверждений относительно программы, которую нужно создать. Могут быть текстовые и графические.
  3. Что такое Use Case? Это такой формат описания требований, который используют бизнес-аналитики. Use case представляет собой законченную последовательность действий пользователя. Например: Открыть браузер, ввести логин/пароль. Нажать кнопку. Попасть на страницу Home. Use case похож на End-to-End тест кейс.
  4. Что такое тест кейс? Текстовое описание процесса проверки функциональности части программы. Включает: идентификатор, название, приоритет, компоненты, степы, результат.
  5. Что такое тест план? Документ, который описывает весь объем работ по тестированию.
  6. Что включает в себя тест план? Название, версия/сборка, объект тестирования, стратегия, полезные ссылки, риски, приоритеты, покрытие, инструменты, распределение тест кейсов по персоналу, критерии начала и окончания.
  7. Как понять, что тестирование закончено? Достигнут дедлайн, процент успешно выполненных тестов, все дефекты исправлены, все тест-кейсы пройдены, бюджет исчерпан.
  8. Что такое баг? Несоответствие между фактическим и ожидаемым поведением продукта.
  9. Жизненный цикл бага. Open, In Progress, Ready For QA, QA In Progress, Closed. Этап Closed может быть выполнен с разными резолюциями: Fixed, Won't fix, Needs more info.
  10. Из каких компонентов состоит баг-репорт? Идентификатор, название, версия, окружение, Priority, Severity, шаги + результат, логи/скрины.
  11. Priority/Severity. Severity - на сколько серьезной является ошибка с точки зрения работоспособности продукта. Priority - как быстро надо пофиксить баг.
  12. Пример высокого Priority и низкого Severity. Опечатка в слове Google на главной странице поисковика.
  13. Эффект пестицида. Если часто проводить одни и те же тестовые сценарии, то баги перестанут находиться.

Читайте также

[ Часть 2 ] Собеседование на должность QA Automation Engineer. Основы программирования.
Вопросы и ответы по темам: проектирование, языки программирования, ООП, алгоритмы, задачи, Python

3. Виды/уровни тестирования

  1. Уровни тестирования. 1. Unit тестирование. 2. Интеграционное 3. Системное 4. Acceptance (приемочное) - соответствие требованиям заказчика. 5. Альфа и бета тестирование
  2. Что такое пирамида тестирования? Это концепция, в соответствии с которой количество тестов должно уменьшаться начиная от нижнего уровня: unit тесты > интеграционные тесты > системные тесты. То есть unit-тесты легкие и быстрые - их должно быть много. Системные тесты сложные и долгие - их должно быть мало.
  3. Виды тестирования. 1. Smoke 2. Functional 3. Regression 4. Configuration 5. UI 6. Installation 7. Internationalization & Localization 8. Performance (Load, Stress, Stability) 9. Compatibility 10. Usability 11. White / Black box 12. Positive / Negative 13. Verification / Validation.
  4. Тестирование методом черного ящика. Не имеем доступ к коду программы. Пример: тестирование UI/UX, тестирование установки.
  5. Тестирование методом белого ящика. Тестировщик имеет доступ к коду (Unit тестирование). Часто такое тестирование отражает ошибки в коде, а не в функциональном поведении.
  6. Тестирование методом серого ящика. По-прежнему не имеем доступ к коду, но зато в целом представляем логическую структуру приложения, можем поделить его на модули.
  7. Статическое тестирование. Анализируем требования и программный код без его запуска. Динамическое - запускаем.
  8. Функциональное тестирование. Проверяем, что ПО выполняет все функции, описанные в спецификации. Нефункциональное - то, что не связано с конкретными действиями пользователя. Например, надежность, перформанс, нагрузочное, безопасность.
  9. Тестирование на основе рисков. Определяем самые важные части системы. Устанавливаем порядок их тестирования. Тестим.
  10. Что такое тестирование End-to-End (сквозное)? Тестирование с точки зрения наиболее часто выполняющихся пользовательских сценариев.
  11. Позитивное тестирование. Проверка на то, что система функциональна. Такой подход также известен как "Тест на прохождение". Поведение пользователя не выходит за рамки "нормальности".
  12. Негативное тестирование. Выдает ли система ошибку, когда должна / не должна. Пример. Вводим неверный пароль с запрещенными символами. Жмем кнопку несколько раз. Негативное тестирование позволяет найти наибольшее количество багов.
  13. Monkey testing. Тестирование без какого-либо плана, тестирование выборочных мест.
  14. Тестирование производительности. Нагрузочное(высокая нагрузка), стресс-тестирование(ограниченные ресурсы) и тестирование стабильности(тестируем в течение промежутка времени).
  15. Что такое тестирование глобализации (Globalization Testing)? Возможность запуска приложения вне зависимости от его географической и культурной среды.
  16. Bucket Testing, или A/B-тестирование. Две версии сайта запускаются на одной или нескольких веб-страницах, чтобы определить разницу в кликах.
  17. Test-driven development (Разработка через тестирование, TDD). Пишем тест, за ним пишем код, далее делаем рефакторинг с постоянной оглядкой на то, что ранее пройденные тесты должны по-прежнему проходить.
  18. Behaviour-driven development (BDD). Позволяет совместить технические интересы и интересы бизнеса - используем предметно ориентированный язык, понятный и менеджерам и программистам. Пример такого языка: Gherkin.

4. Техники составления тест кейсов

  1. Что такое матрица тестирования? Матрица, в которой колонки - это требования к системе, строки - тест кейсы. Такая матрица является одним из способов оценки покрытия.
  2. Техники составления тест-кейсов. Классы эквивалентности, проверка граничных значений, таблица принятия решений, pairwise, диаграммы изменения состояний.
  3. Классы эквивалентности. Классы эквивалентности - данные, на которых (как мы ожидаем) программа будет вести себя одинаково. Этапы: 1. Разбиваем входные данные на классы эквивалентности. 2. Выбираем одного представителя из каждого класса. 3. Выполняем тест.
  4. Проверка граничных значений. Это методология составления тест-кейсов, при которой мы тестируем на значениях, близких к границам допустимых диапазонов. Проверяем 3 значения: значение перед границей, граничное значение, значение после границы. Этапы: 1. Выделяем классы эквивалентности. 2. Определяем граничные значения классов. 3. Проводим тесты для значения до, на, после границы.
  5. Таблица принятия решений. Этапы: 1. В колонку записываем Условия, ниже Действия. 2. Считаем количество столбцов для Выполнения / Невыполнения условий. <количество_столбцов> = 2 в степени <количество_условий>. Например, если имеем 3 условия, то добавляем в таблицу 8 столбцов. 3. Заполняем столбцы/строки. Первая строка: True, False, True, False, True, False, True, False. Вторая строка: True, True, False, False, True, True, False, False. Третья строка: True, True, True, True, False, False, False, False. 4. Отсеиваем лишние проверки условий (например, если Условие 1 ложно, то Условие 3 проверять нет смысла). 5. Отсеиваем лишние столбцы (дублируются условия).
Decision table
Таблица принятия решений. Пример: проверяем пароль по трем условиям
6. Попарное тестирование (Pairwise testing). Значения каждого параметра должны встретиться с всеми значениями другого параметра. Этапы:
  1. Предположим, что имеем 3 входных параметра, каждый из которых может принимать 2 значения.
  2. Перебираем все комбинации 1го параметра со 2м (значение первого параметра фиксируем).
  3. Перебираем 1й параметр с 3м (значение 2го фиксируем).
  4. Перебираем 2й параметр с 3м (значение 1го параметра фиксируем).
  5. Из полученных 12 строк удаляем дубликаты, получаем 7 кейсов.
  6. Проводим дальнейшие оптимизации, если это возможно/необходимо.
Pairwise
Метод попарного сравнения (Pairwise). Пример: подбираем тест кейсы для проверки автомобиля по трем параметрам.
7. Диаграмма изменения состояний. Этапы:
  1. Составляем диаграмму состояний объекта.
  2. Составляем списки всех состояний и всех действий.
  3. Комбинируем все действия и все состояния.
  4. Из полученных комбинаций выделяем 3 группы тестов: позитивные, негативные, невалидные.
  5. Удаляем невалидные.
State change diagram
Диаграмма изменения состояний. Пример: Работа с платформой размещения объявлений

5. Тестируем формы

Важный момент: для клиент-серверных приложений валидация форм делится на два типа:
1. Валидация со стороны сервера
2. Валидация со стороны клиента
То есть валидацию нужно проверять и для клиента и для сервера.

Элементы форм:

1. Текстовые поля и области (Text Field, Text Area)
Проверки:
  1. Обязательность полей (оставляем пустыми поочередно и вместе)
  2. Вводим минимально/максимально допустимые значения (на 1 меньше, само значение и на 1 больше).
  3. Ввод разного типа символов (латиница, кириллица, Unicode, цифры, спецсимволы, пробелы в разных местах строки, html тэги, данные из буфера обмена).

2. Ссылки (Links)
Проверки:
  1. Префиксы: пустой, разные протоколы (http, https, ftp).
  2. Далее аналогично текстовым полям.

3. Чек боксы (Check box)
Проверки:
  1. Выбираем разное количество(ничего, один, два, все).
  2. Наличие галочки Check all (для большого количества чек боксов).
  3. Область возле чек-бокса тоже должна быть кликабельной.

4. Radio button
Проверки:
  1. Один всегда выбран
  2. Не могут быть выбраны оба
  3. Область возле кнопки тоже должна быть кликабельной.

5. Загрузка файла (File uploader)
Проверки:
  1. Не выбираем файл
  2. Загрузка файлов разных размеров (меньше, ровно по ограничению, больше ограничения на размер, очень маленький файл)
  3. Валидность формата файла
  4. Как работает, если можно вводить в поле путь до файла
  5. Далее аналогично текстовым полям

6. Телефон, Почта (Phone, Email)
Проверки:
  1. Проверяем как текстовые поля
  2. Наличие плейсхолдера (подсказки).
  3. Отдельно проверяем допустимые спецсимволы (+, (), @, @@,)
  4. Наличие маски

7. Логин, пароль (Login, Password)
Проверки:
  1. Проверяем как текстовые поля
  2. Требования к сложности пароля (содержит/не содержит все/одно условия)

8. Выпадающий список (Dropdown)
Проверки:
  1. Проверяем как текстовые поля
  2. Выбираем разные элементы.
  3. Поиск по элементам (вводим первую букву - должен выбирать соответствующий элемент)
  4. Сортировки
  5. Отдельно проверяем, если этот список запоминает предыдущие значения

6. Вопросы для QA лида

1. Какие задачи будете выполнять на старте работы с новым проектом?
  • Проанализировать требования
  • Спланировать и запустить процесс передачи знаний о проекте между тестировщиками, лидом, разработчиками и т д
  • Собрать и консолидировать все вопросы команды тестировщиков и уточнить их на уровне менеджмента
  • Провести kick-off meeting, на котором мы должны убедиться, что у всей команды есть понимание того, чем мы собираемся заниматься
2. Какие этапы вы бы выделили в процессе планирования тестирования?
  • Отобрать необходимые тесты (определить scope). Зависит от такого, какой вид тестирования мы хотим провести (functional, performance, security), сколько у нас времени и других факторов.
  • Разработать стратегию тестирования в соответствии со скоупом тестов и принятыми у вас в компании стандартами. Так же важно, какие фичи/требования нужно протестировать, какие есть ограничения с точки зрения тестового окружения.
  • Продумать, какие средства будут задействованы для тестирования (test automation & test management)
  • Оценить ресурсы (размер команды, опыт, временные рамки)
  • Составить "дорожную карту" (roadmap): создать тикеты, отследить зависимости, назначить исполнителей.
  • Определить и создать необходимое для тестирования окружение (hardware, software, network)
  • Определить тестовые метрики, которые будет необходимо предоставить вышестоящему руководству/клиенту.
  • Задокументировать тест план. Провести review тест плана с командой и руководством.
3. Как вы будете информировать остальную часть команды (разработчиков, менеджеров, конечных юзеров, support менеджеров) о прогрессе вашей команды?
  • Общение на митингах, переписка через email/месенджер
  • Отслеживание выполнения задач/тикетов в соответствии с предполагаемым графиком
  • Репортить текущий статус всем заинтересованным (процент выполнения, существующие issues, )
  • Собрать, проанализировать и дать выжимку результатов тестирования
4. Как вы себе представляете ежедневные задачи QA лида?
  • Просмотреть/ответить на переписку
  • Просмотреть новые/измененные тест кейсы, обсудить при необходимости
  • Просмотреть новые/измененные требования/фичи продукта, выполнить соответствующие действия со стороны тест кейсов/тестового фреймворка.
  • Убедиться, что тестовое окружение функционирует корректно, подумать, как можно решить текущие проблемы и какие улучшения можно сделать, для более эффективной работы с окружением.
  • Промониторить Test Management System
  • Создать тикеты/назначить их тестерам/закрыть завершенные. Убедиться, что каждый член команды имеет оптимальный объем работы.
5. Как отследить, что тестировщики эффективно заводят/проверяют баг тикеты?
  • Просматривать созданные баг репорты, следить, чтобы они вовремя попадали в работу
  • Быстро отслеживать возвращаемые тикеты, разбираться в причинах. Пример - тестировщик не предоставил необходимых данных, из-за чего разработчик не смог воспроизвести баг.
  • Проверять, чтобы все возвращаемые от разработчиков тикеты с фиксами были протестированы снова.
6. Как вы бы мотивировали свою команду?
  • Всегда быть на связи
  • Планировать и проводить совместные митинги, убеждаться, что все договоренности, к которым пришли в ходе встречи, были выполнены сотрудниками. Разбирать проблемы, которые есть у членов команды на текущий момент времени.
  • Ревьювить текущие статусы членов команды.
7. Какие действия предпринимаете, чтобы прокачивать свои навыки?
  • Слежу за появлением новых техник тест дизайна, тестовых стратегий, фреймворков автоматизации, тестовых утилит
  • Прохожу онлайн курсы
  • Стараюсь быть в курсе того, какие еще проекты есть/появились проекты в рамках вашей компании
  • Стараюсь прокачиваться в тайм менеджменте
23 АВГУСТА / 2023
Часть 3
Собеседование на должность QA Automation Engineer.
Web, SQL, Linux, Git, сети.
Часть 2
Собеседование на должность QA Automation Engineer.
Основы программирования.
Как вам материал?
ПОКАЗАТЬ КОММЕНТАРИИ

Читайте также