Привет, Хабр! На связи Евгений Гусинец — QA Engineer из Бизнес‑Инфо (Минск), автор ТГ канала о тестировании и IT‑технологиях QA❤️4Life

Возможно вы уже успели познакомиться и добавить себе в закладки такие популярные публикации как: Большую подборку тестовых площадок («песочниц») и ресурсов для начинающих и опытных QA а также SQL для всех: от новичка до профи. Полный гид по тренажерам, курсам и песочницам 

На этот раз мне захотелось поделиться с вами "Шпаргалкой по основам тестирования".
Подобные ресурсы я давно создаю и размещаю в своём Telegram-канале, но они не являются доступными для более широкого круга читателей и пользователей. В этой связи решил попробовать запустить такой проект. Если он найдёт поддержку и признание, то в таком случае я выпущу все части, которые запланированы. Желаю всем успешно готовиться к собеседованиям, повторять и изучать теорию и практику тестирования и получать свои заветные офферы. Аминь!

Содержание

1. Основные понятия

2. Ключевые термины QA

3. Принципы тестирования ISTQB

4. Уровни, виды и подходы к тестированию

1. Основные понятия

1.1. Что такое тестирование

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

Результат тестирования не сводится к списку багов. Он помогает принять решение: выпускать ли сборку, что исправлять первым, где риск для пользователя выше всего и каких данных ещё не хватает для решения.

Тестирование отвечает на три группы вопросов:

• Соответствие требованиям. Работает ли функция так, как зафиксировано в требованиях, макетах, контрактах API и правилах бизнеса?

• Пользовательская ценность. Помогает ли продукт человеку решить его задачу без лишних препятствий?

• Готовность к выпуску. Какие известные риски остаются, кто принимает их и приемлемы ли они для этого релиза?

Важная граница

Успешный прогон тестов означает только одно: в выполненных проверках не найдено отклонений. Он не доказывает, что дефектов во всём продукте нет.

Мини-сценарий

Интернет-магазин принимает заказ и показывает сообщение «Оплата прошла». Формально функция работает. Но при повторном клике создаются два платежа. Тестирование должно увидеть и основной путь, и риск двойного действия. Иначе команда получит ложное чувство готовности.

1.2. Цели и ценность тестирования

Тестирование приносит пользу, когда его результаты меняют решение команды.

Цели тестирования зависят от продукта. Для банковского перевода важны корректность сумм, безопасность и аудит. Для учебного приложения критичнее понятность интерфейса и работа на разных устройствах. Универсального набора проверок нет.

Как превратить цель в проверяемую задачу

Плохая формулировка: «Проверить оплату».

Рабочая формулировка: «Проверить оплату картой для успешного платежа, отказа банка, повторного клика, отмены операции и возврата пользователя из банка. Убедиться, что заказ и статус платежа не расходятся».

Так команда понимает границы работы, а тестировщик получает материал для отчёта о рисках.

1.3. Стоимость качества

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

Чем позже команда находит проблему, тем больше в неё уже вложено работы. Неясное правило скидки, найденное на ревью требования, меняют в одном документе. То же правило после выпуска может затронуть код, тесты, платежи, поддержку и бухгалтерию.

Практика для QA

На груминге полезно искать три вещи:

1. Неопределённые слова: «быстро», «удобно», «безопасно», «поддерживать все устройства».

2. Пропущенные условия: что будет при отмене, повторном действии, пустом значении, недоступной внешней системе.

3. Непроверяемые требования: по каким признакам команда поймёт, что работа завершена.

Так QA помогает предотвратить дефекты до того, как они попадут в код.

1.4. Фундаментальный процесс тестирования

В ISTQB тестирование описано как набор связанных активностей. На небольшом проекте один человек может выполнять их все. На крупном - они распределены между аналитиками, разработчиками, тестировщиками и руководителем тестирования.

На что смотреть новичку

Перед началом проверки ответьте себе на пять вопросов:

• Какая версия продукта и какие изменения в ней есть?

• Что именно нужно проверить в первую очередь и почему?

• Какая среда, учётная запись и тестовые данные нужны?

• Какой результат будет считаться успешным?

• Кому и как сообщить о блокере или найденном риске?

Если на два или три вопроса ответа нет, проблема обычно не в тест-кейсах. Сначала стоит уточнить условия работы.

1.5. Верификация и валидация

Эти понятия близки, но отвечают на разные вопросы.

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

Пример с калькулятором. Приложение правильно считает сумму, но стирает результат через десять секунд. Техническая формула работает, но пользователь не успевает использовать ответ.

Частая ошибка

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

1.6. Статическое и динамическое тестирование

Статическое тестирование проверяет рабочие артефакты без запуска программы. Это могут быть требования, макеты, тест-кейсы, код, схемы базы данных или настройки.

Динамическое тестирование проверяет поведение выполняющейся системы с тестовыми данными.

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

Рабочая привычка

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

2. Ключевые термины QA

2.1. Ошибка, дефект и отказ

Одна проблема часто проходит три стадии.

Цепочка не всегда доходит до отказа. Дефект может долго не проявляться, пока не совпадут нужные данные, нагрузка или действия пользователя.

Пример цепочки

Разработчика отвлекли во время работы. Он неправильно описал границу допустимого значения. В коде появился дефект. При системном тестировании поле ввода отвергает корректное значение на границе диапазона - это уже отказ системы.

Различение терминов помогает не искать «виноватого». Цель анализа - понять, какой барьер не сработал: требования, ревью, тесты, мониторинг или процесс передачи знаний.

2.2. Обеспечение качества, контроль качества и тестирование

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

Тестирование часто входит в практики контроля качества, но не исчерпывает их. А обеспечение качества начинается раньше тестового стенда: когда команда делает требования понятными и процесс повторяемым.

Аналогия со строительством

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

2.3. Отчёт о дефекте

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

Серьёзность и приоритет - разные шкалы

Серьёзность показывает техническое и пользовательское влияние дефекта. Приоритет показывает, насколько быстро команда хочет его исправить.

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

Самопроверка перед отправкой

• Повторяются ли шаги на чистой сессии?

• Нет ли в одном отчёте двух независимых проблем?

• Отличаются ли фактический и ожидаемый результаты?

• Понятно ли по заголовку, что сломано?

• Достаточно ли данных, чтобы другой человек воспроизвёл проблему?
  

3. Принципы тестирования ISTQB

Принципы не заменяют стратегию и тест-дизайн. Они помогают не тратить усилия там, где тестирование не даст полезного результата.

3.1. Тестирование показывает наличие дефектов, а не их отсутствие

Успешные тесты снижают неопределённость, но не дают абсолютной гарантии. Проверка охватывает только выбранные сценарии, данные и среду.

Что делать. Формулируйте результат точно: «В проверенных сценариях критических дефектов не найдено». Сообщайте, какие зоны не проверяли и почему.

Ловушка. Говорить «в продукте нет багов», потому что зелёный прогон завершился успешно. Такой вывод невозможно защитить, если пользователь найдёт неучтённый сценарий.

3.2. Исчерпывающее тестирование невозможно

Количество комбинаций быстро становится огромным. У формы регистрации есть разные устройства, браузеры, языки, статусы пользователя, типы ввода и сетевые условия. Проверить все сочетания в реальном проекте нельзя.

Что делать. Сначала выделяйте риски: деньги, персональные данные, критический путь, часто меняющийся модуль, сложная логика. Затем выбирайте представительные данные и границы.

Ловушка. Тратить неделю на редкие комбинации, когда основной путь оплаты ещё не проверен.

3.3. Раннее тестирование экономит время и деньги

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

Что делать. Участвуйте в обсуждении задачи до начала разработки. Проверяйте правила, исключения, ограничения и критерии приёмки.

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

3.4. Дефекты склонны группироваться

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

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

Ловушка. Делить время строго поровну между всеми экранами. Равномерная работа не равна разумному распределению риска.

3.5. Парадокс пестицида

Один и тот же набор тестов перестаёт находить новые дефекты. Команда исправляет всё, что он умеет ловить, а новые изменения приносят другие риски.

Что делать. Обновляйте регрессионный набор после инцидентов, добавляйте новые данные и негативные сценарии, проводите исследовательские сессии. Каждый найденный дефект задаёт вопрос: какую проверку стоит добавить, чтобы он не вернулся?

Ловушка. Много месяцев запускать неизменный чек-лист и считать нулевое число найденных дефектов признаком высокого качества.

3.6. Тестирование зависит от контекста

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

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

Ловушка. Применять один тест-план ко всем проектам без адаптации. Формальная полнота документа не делает набор проверок уместным.

3.7. Отсутствие найденных ошибок не означает ценность продукта

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

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

Ловушка. Считать релиз успешным только по числу закрытых дефектов и покрытию тестами.

Быстрый алгоритм применения принципов

Перед релизом спросите:

1. Что мы ещё не проверяли и какой риск там остаётся?

2. Какие сценарии важнее всего для пользователя и бизнеса?

3. Где в этом релизе уже находили дефекты?

4. Какие старые тесты пора дополнить?

5. Какие требования надо перепроверить с пользователем или владельцем продукта?

Эти вопросы связывают принципы с ежедневной работой QA-инженера.

4. Уровни, виды и подходы к тестированию

4.1. Уровень и вид тестирования - две разные координаты

Уровень тестирования показывает, на каком масштабе продукта выполняется проверка: отдельная функция, связка компонентов, система целиком или продукт с точки зрения заказчика.

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

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

Типичная путаница

«Системное» и «функциональное» не конкурируют между собой. Первое описывает масштаб проверки, второе - цель проверки.

4.2. Четыре уровня тестирования

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

4.3. Пирамида тестирования

Пирамида показывает разумное соотношение проверок по стоимости и скорости обратной связи.

• Компонентные проверки обычно быстрые и дешёвые. При падении часто сразу видно конкретное место в коде.

• Интеграционные проверки медленнее: нужны несколько компонентов, данные или тестовые двойники.

• Сквозные проверки через интерфейс дают уверенность в пользовательском пути, но работают медленнее и часто ломаются из-за изменений интерфейса или среды.

• Исследовательское ручное тестирование остаётся полезным: оно помогает заметить неожиданное поведение, которое не попало в заранее написанный сценарий.

Перевёрнутая пирамида

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

4.4. Проверки функциональности и изменений

Эти проверки отвечают на разные вопросы, хотя в реальной работе часто идут одной цепочкой.

Как не путать проверки

Дымовая проверка идёт вширь: она поверхностно затрагивает несколько главных функций. Санитарная идёт вглубь: она подробно смотрит на узкую изменённую область.

Подтверждающая проверка смотрит на место фикса. Регрессия ищет побочный ущерб от этого фикса в ранее работавших частях системы. После исправления серьёзного дефекта обычно нужны обе.

4.5. Дымовая и санитарная проверки - рабочий пример

Представьте новую сборку интернет-магазина.

1. Сначала QA выполняет дымовую проверку: открывается ли сайт, доступен ли вход, загружается ли каталог, добавляется ли товар в корзину, начинается ли оформление заказа. Если сборка падает уже здесь, глубокое тестирование откладывают.

2. Разработчик меняет блок выбора валюты. QA выполняет санитарную проверку: подробно смотрит отображение валюты на разных экранах, смену валюты в корзине, округления и связь с итоговой ценой.

3. Если исправляли дефект с повторным списанием, QA повторяет исходные шаги - это подтверждающая проверка. Затем проверяет другие способы оплаты и отмену платежа - это регрессия.

Такой порядок помогает быстро отсеять нерабочую сборку и не терять время на полный прогон там, где продукт ещё не готов.

4.6. Нефункциональные виды тестирования

Функциональная проверка отвечает на вопрос «что делает система». Нефункциональная - «насколько хорошо она это делает в заданных условиях».

Нефункциональное требование должно быть измеримым. Фраза «страница должна быть быстрой» не годится для проверки. Годится: «при ожидаемой нагрузке девяностый процентиль времени ответа страницы каталога не превышает трёх секунд».

Почему метрики обязательны

У нефункциональных характеристик редко бывает простой ответ «работает» или «не работает». Без численного критерия QA и разработчик могут смотреть на один экран и спорить: одному страница кажется быстрой, другому - медленной. Метрика превращает спор в проверку.

4.7. Подходы к тестированию

Подход показывает, сколько тестировщик знает о внутреннем устройстве продукта.

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

Как применять материал в работе

Перед началом проверки новой задачи:

1. Прочитайте требование и найдите неясные правила, исключения и измеримые критерии.

2. Определите главный риск: деньги, данные, доступ, критический пользовательский путь, совместимость или скорость.

3. Выберите масштаб проверки: компонент, интеграция, система или приёмка.

4. Подберите виды проверок: функциональные, связанные с изменениями, нефункциональные, исследовательские.

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

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

Литература

1. ISTQB Certified Tester Foundation Level Syllabus.

2. Куликов С. С. «Тестирование программного обеспечения. Базовый курс».

3. Бейзер Б. «Тестирование чёрного ящика».

4. Амманн П., Оффутт Дж. «Введение в тестирование программного обеспечения».

5. Уиттакер Дж. «Как тестируют в Google».