Вопросы про виды тестирования на собеседовании в QA: как к ним относиться?
Когда вы приходите на собеседование на позицию QA-инженера, вам могут задать самые разные вопросы. Иногда они будут касаться теории, например, классификации и видов тестирования. На первый взгляд такие вопросы кажутся стандартными, но, по мнению Стаса Васенкова, основателя школы QA.Guru, они редко помогают оценить реальные навыки кандидата.
«Если нечего спросить, то спрашивают про виды тестирования и прочие вещи о теории», — говорит Стас. Вопросы о теории тестирования чаще задают специалисты с размытым представлением о том, с чем на самом деле сталкивается QA-инженер в своей работе. И на практике интервьюировать кандидата на позицию тестировщика могут специалисты из самых разных отделов компании: от менеджмента до бэкенда.
Вот почему стоит иметь представление об основных концепциях QA, но гораздо важнее уметь рассказать о своих практических достижениях.
Когда я сам как автотестер провожу собеседование с автотестером, меня больше всего интересует ответ на вопрос: “Каким из последних разработанных тестов ты гордишься?”
Стас отмечает, что часто собеседование превращается в формальную церемонию, оторванную от реальных задач. В идеале, если вас собеседует опытный тестировщик, разговор будет больше о вашем практическом опыте.
Тем не менее, подготовиться к вопросам по теории тестирования всё же стоит. В этой статье мы попытаемся максимально просто раскрыть тему видов тестирования.
Содержание статьи
Начнем по порядку. А чем вообще занимается тестировщик?
Хотя главным преимуществом QA-инженера является портфолио, не все ребята с несколькими внушительными кейсами за плечами могут внятно ответить на вопрос об основных обязанностях тестировщика. Искать дефекты программ, приложений и сайтов, а потом составлять отчёты — далеко не всё, что в них входит. Зачем, кроме этого, проводится тестирование?
- Чтобы соотнести результат разработки и запрос заказчика. Процесс создания проекта в it-сфере — сложная штука, для которой нужно выполнить сотни, а порой тысячи задач. Занимается ими целая команда людей. Каждый из них может в какой-то момент интерпретировать требования задачи на свой лад, какими бы конкретными и однозначными они ни казались. Если не чекать на каждом этапе “А туда ли мы идём?” и проверять только ошибки, мы рискуем получить рабочее приложение, но совсем не такое, каким его хотел видеть заказчик.
- Чтобы сэкономить бюджет компании. Чем раньше обнаружены ошибки и несоответствие требованиям, тем меньший бюджет уйдет на исправление косяков.
- Для дополнения функциональности. Допустим, заказчик хотел приложение с тремя основными функциями. А в результате тестов выяснилось, что пользователь ожидает от такого приложения ещё минимум 2. Чтобы продукт умел больше и пользовался спросом на рынке, его дорабатывают.
- Чтобы не испортить репутацию бренда заказчика. Один некачественный продукт, выпущенный на рынок с багами и без проработки удобства пользовательского интерфейса, может навсегда снизить доверие к бренду и его прибыль.
На фоне этого примерно очерченного круга задач становится понятно, что само по себе тестирование — один из инструментов инженера по обеспечению качества.
Разделение на ручных тестировщиков и автоматизаторов неправильно. Есть профессия QA-инженер, инженер по обеспечению качества. И автоматизация — это один из скилов его fullstack-набора. Но запросто может оказаться, что самым дорогим вашим навыком окажется менеджмент (управление командой) или нагрузочное тестирование, и вы в этом себя найдете.
А теперь подробнее о ручном, автоматизированном, нагрузочном и т.д. 🙂
Виды тестирования
По разным классификациям существует около 30 видов тестирования. Мы не хотим никого запутать и постараемся рассказать об основном понятно.
Организуем это как список из 6 вопросов, которые помогают определить вид тестирования. Начнём.
1. Нам нужно протестировать большой объём данных и много сценариев?
✅ Да
Автоматизированное тестирование. Позволяет проверить и быстро проанализировать, как будет вести себя программа, если сразу много пользователей будут одновременно выполнять в ней какие-то действия. Тестировщик при этом в формате кода формулирует задание для автотеста. В QA Guru это учат делать на Java, Python и JavaScript.
❌ Нет
Ручное тестирование. Тестировщик лично шаг за шагом проходит путь пользователя по разным сценариям. Хотя такое тестирование намного медленнее, оно помогает глубоко оценить, насколько приложение удобно для реального человека.Также мануальное тестирование применяется для проверки частных необычных сценариев, которые трудно автоматизировать.
Казалось бы, что такое протестировать интернет-магазин? Ну десяток каких-то сценариев важных: авторизация работает, поиск работает, корзина работает. Ну, значит, продукт скорее жив, чем мертв. Но вокруг каждого из этих сценариев вырастает еще 10-20 других, положительных и негативных.
На практике получается: чтобы провести регрессивное тестирование интернет-магазина, часто нужно составить план из около 300 сценариев и потратить на полный процесс проверки вручную около 25 часов. Каждый день делать одни и те же действия тяжело. Но ручные тестировщики всегда хорошо знают продукт. И когда передо мной стояла задача ввести автоматизацию всех процессов, я опирался на них.
2. Нам показали код программы?
✅ Да
Тестирование “белого ящика”. У нас есть доступ не только к лицу, но и к изнанке продукта. Это позволяет провести более тщательную проверку, чем тестирование только интерфейса. Такой подход включает глубокий анализ кода и помогает выявить потенциальные баги на ранних стадиях.
❌ Нет
Тестирование “черного ящика”. В тестирование отдали только интерфейс. Мы можем анализировать его только как пользователь. В таких условиях возможно не заметить скрытые проблемы кода, которые могут проявить себя позже в нестандартных ситуациях использования программы.
🌗 Частично.
Тестирование “серого ящика”. Тестировщик имеет доступ к структуре и коду только некоторых компонентов. Такой подход представляет собой компромисс, когда необходимо соблюсти требования политики конфиденциальности проекта заказчика и провести достаточно глубокую проверку соответствия основным требованиям. Доступ к коду может открываться частично, когда нужно провести интеграцию отдельных новых модулей программы.
3. Пользователь будет вести себя предсказуемо?
✅ Да
Тестирование позитивных сценариев. В таком тестировании наш гипотетический пользователь — умничка отличник, который нормально регистрирует свой профиль, нормально делает заказ и по ожидаемому сценарию использует другие функции программы. Если при этом сам продукт в ответ ведёт себя как запланировано, то всё в порядке. Здесь важно, чтобы система корректно обработала все запросы и уровень работоспособности программы соответствовал требованиям.
❌ Нет
Тестирование негативных сценариев. А тут мы проверяем, что будет, если пользователь будет всё делать через… жажду безудержного креатива 😈: вводить абракадабру вместо контактных данных, пытаться заказать доставку продуктов общим весом 120 кг, пытаться уйти от оплаты чека, загружать неприемлемый контент и т.д. В процессе такого тестирования мы хотим увидеть, как программа запрещает определенные действия и обрабатывает ошибки. Мы ищем любую возможность выявления критических уязвимостей системы.
4. Нам нужно запускать программу, чтобы её тестировать?
✅ Да. Динамическое тестирование.
❌ Нет. Статическое тестирование. В рамках него анализируют код и документацию продукта. Такое тестирование требует особых методов и программ для определения возможных ошибок без фактического запуска программы. Обычно такой вид тестирования выполняют программисты, а не тестировщики.
5. Какие части программы мы тестируем?
Основные функции
Функциональное тестирование. Мы проверяем, работает ли то, для чего этот продукт был создан. Чтобы это выяснить, проводят:
- Модульное (unit) тестирование. Каждый модуль разрабатываемой программы проверяют на ранней стадии разработки. Это делается и вручную, и автоматизированно. Как правило, такое тестирование проводят сами разработчики. Но вы можете попасть в команду, где за это отвечает тестировщик.
- Интеграционное тестирование. Проверяют, правильно ли отдельные модули, связанные зависимостями, работают вместе. Этот вид тестирования, направленный на эффективность взаимодействия всех компонентов, важен для обеспечения стабильности продукта.
- Системное (end-to-end) тестирование. Программа тестируется целиком, как готовый (или почти готовый) продукт. Для этого разрабатывается необходимый набор тестов. Проверяются разные сценарии пути пользователя от входа в приложение до результата: заказа доставки, товара, брони жилья и т.д. В том числе тестируются негативные сценарии (отказа, ошибки и т.д.). Это тестирование поможет убедиться, что все ранее принятые в процессе разработки и тестирования решения позволяют применять продукт правильным, изначально запланированным образом.
- Приемочное тестирование. Как говорится, принимайте товар :) Это тестирование проводит команда заказчика, чтобы понять, насколько качественный результат они получили. Здесь оценка функциональных характеристик конечного продукта зависит от требований бизнеса.
Характеристики за пределами исправности главных функций
Ок, всё основное работает, но насколько быстро, удобно и безопасно? Сможет ли оно работать на всех устройствах? А если заказов будет не сто, а сто тысяч в день? Рассмотрим это подробнее.
К нефункциональному тестированию относятся:
- Нагрузочное тестирование. С помощью инструментов автоматизированного тестирования приложение испытывают большим количеством пользователей, данных, заказов и т.д. При этом нагрузка повышается плавно, имитируется ожидаемые показатели поведения пользователей. Важно предусмотреть ресурсы, чтобы система успешно обрабатывала запросы в случае повышенных нагрузок.
- Стресс-тестирование. Похоже на нагрузочное, но приложение тестируется на предельно допустимых объемах обработки данных с целью выявить слабые места. Имитируются резкие всплески активности пользователей, которые могут появиться, например, после проведения крупных рекламных кампаний. Это позволяет определить точки, в которых потребуется дополнительная поддержка системы.
- Тестирование безопасности. Имитируется хакерская атака или заражение вирусом с целью выявить лазейки, через которые могут быть украдены персональные данные пользователей или совершены другие вредоносные действия. В том числе уделяется внимание защите при использовании внешних браузеров.
- Тестирование совместимости. Программа должна нормально работать на различных устройствах, платформах и операционных системах. Учитываются не только разрешения экранов и технические характеристики оборудования. Для мобильных приложений, например, есть требования к визуальному оформлению. Они описаны в гайдах iOS и Android. Если интерфейс будет совсем далеко от этих рекомендаций, продукт могут не допустить или исключить из магазина приложений. Выполняется тестирование совместимости с помощью автоматических инструментов и с помощью ручной проверки на различных типах устройств.
- Тестирование на отказоустойчивость. Что будет, если пропадет интернет или какой-то из внутренних сервисов даст сбой? Как будет выглядеть работа приложения для пользователя в этот момент? Не потеряет ли программа всю базу данных клиентов? Пользователь должен либо вовсе не заметить временных внутренних неполадок, либо увидеть спокойное объяснение причин ограничений в работе. В моменты сбоев программы важно показать клиенту, что всё под контролем и всё скоро починят.
- UI-тестирование (тестирование интерфейса). Когда пользователь открывает приложение или программу, что он видит? Удобно ли представлена информация, понятно ли без инструкций, как всем этим пользоваться? Не сольется ли экран в одно неразборчивое пятно для людей с особенностями зрения? Меню, поля ввода, корзина, кнопка “Заказать”, функция выхода и другие важные элементы должны находиться в привычных для пользователя местах, а не там, где решит безудержный креатив.
- Тестирование на восстановление. Насколько быстро программа сможет восстановить нормальную работу, если произойдет что-то критичное: например, временно оборвется связь с базой данных?
- Тестирование надёжности. С помощью инструментов автоматического тестирования на приложение в течение длительного времени подаётся ожидаемая нагрузка (например, 1000 заказов в день). Цель — выявить будут ли возникать сбои при стабильной значительной нагрузке.
- Инсталляционное тестирование. Проверяется корректность и удобство этапов установки, настройки, обновления или удаления приложения. Здесь важно предусмотреть все аспекты взаимодействия пользователя с установочными файлами и параметрами, чтобы минимизировать вероятность ошибок и проблем при выполнении этих действий.
- Тестирование локализации. Приложения, сайты и программы не только переводятся на языки стран, в которых они доступны. Важно адаптировать текстовые формулировки, символы (например, валют) и порой даже логику функций так, чтобы это было привычно для местного населения.
6. На каком этапе развития продукта мы проводим тестирование?
- Альфа-тестирование. Продукт ещё в ранней версии. Тестирование при этом проводится, как правило, в команде разработчика.
- Дымовое тестирование. Быстрое тестирование самых важных функций программы, когда ее ещё нельзя считать стабильной версией. Если при таком тестировании “по верхам” уже выявляются ошибки, то продукт возвращают в разработку и не передают на более глубокие тесты. Цель — сэкономить время, затраченное на тестирование.
- Регрессионное тестирование. Прошла первая волна тестирования, и в код были внесены правки. Теперь надо проверить, не сломали ли эти изменения те области, которые мы не трогали. Проведение такого тестирования важно после любых существенных изменений исходного кода.
- Приёмочное тестирование. Мы говорили о нём ранее. Проводится, когда продукт уже готов и команда заказчика его принимает.
- Бета-тестирование. К программе или приложению дают доступ ограниченному числу пользователей, чтобы получить отзывы и внести финальные доработки. После выпуска версии для бета-тестирования можно взаимодействовать с пользователями через блог и комментарии на странице продукта.
Держим фокус на практике
Знать о видах тестирования полезно для подготовки к собеседованию. Однако даже на рабочем интервью больше шансов у тех, кто может показать свои практические навыки. Каждый курс по автоматизации тестирования в QA.Guru даёт более 100 часов практики, охватывающей тестирование веб-приложений, мобильных приложений и API. Студенты работают с примерами реальных задач, применяют принципы тестирования, а не зубрят их.
На программы часто приходят ребята, которые уже знакомы с ручным тестированием или хотят сменить сферу в IT. Но стать инженерами по тестированию в QA.Guru могут не только те, кто уже уверенно пишут код. Для начинающих в IT есть специальная учебная группа для изучения основ, которая проходит параллельно с занятиями по выбранному направлению.
Учебная среда школы ориентирована на поддержку и удобство обучения. В дополнение к занятиям в прямом эфире есть записи и конспекты, которые можно читать в общей базе знаний. Вопросы студентов всегда разбирают в чате или лично. Также бывают дополнительные мастер-классы, которые помогают разбирать сложные темы.
В сообществе школы регулярно проводят бесплатные практические занятия, анонсы которых публикуют в Telegram-канале QA.GURU. На сайте школы можно узнать больше о программах обучения тестировщиков и QA-инженеров, а также записаться на пробный урок. Такой формат отлично подходит для тех, кто только решает, привлекает ли его/её карьера в тестировании.
тестирование программного обеспечения | QA инженер | профессия QA инженер | программирование для автоматизации тестирования | тестирование приложений | интеграционное тестирование | функциональное тестирование | автоматизация тестирования | нагрузочное тестирование | приемочное тестирование | виды тестирования | курсы QA инженера | курсы QA тестировщика | тестирование производительности | тестирование базы данных | ручное тестирование | тестирование без знания языка программирования | тест отказоустойчивости | тестирование без знания кода | тестирование совместимости | тестирование мобильных приложений | нефункциональное тестирование | тестирование интерфейса | тестирование белого ящика | тестирование серого ящика | тестирование черного ящика | разработка тестовых сценариев | тестирование на Python | языки программирования для QA | тестирование программ | программа обучения для QA тестировщиков | QA auto testing