Руководство по тестированию программы

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

• Для проверки соответствия требованиям.
• Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта.
• Обнаружение вариантов использования, которые не были предусмотрены при разработке. А также взгляд на продукт со стороны пользователя.
• Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.

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

• Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
  Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
• Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
  Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
• Принцип 3 — Раннее тестирование (Early testing).
  Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
• Принцип 4 — Скопление дефектов (Defects clustering).
  Большая часть дефектов находится в ограниченном количестве модулей.
• Принцип 5 — Парадокс пестицида (Pesticide paradox).
  Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
• Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

• проверка готовности ПО к релизу;
• проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

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

Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

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

Программный продукт проходит следующие стадии:

1. анализ требований к проекту;
2. проектирование;
3. реализация;
4. тестирование продукта;
5. внедрение и поддержка.

Требования

Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

Атрибуты требований:

1. Корректность — точное описание разрабатываемого функционала.
2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4. Недвусмысленность — требование должно содержать однозначные формулировки.
5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
8. Модифицируемость — в каждое требование можно внести изменение.
9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
2. Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
3. Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
4. Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
5. Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
6. Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
10. Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
11. Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

• Блокирующий (S1 – Blocker)
  тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
• Критический (S2 – Critical)
  критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
• Значительный (S3 – Major)
  не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
• Незначительный (S4 – Minor)
  часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 – Trivial)
  почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

• P1 Высокий (High)
  Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
• P2 Средний (Medium)
  Не критичная для проекта ошибка, однако требует обязательного решения.
• P3 Низкий (Low)
  Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

• Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
• Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
• История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
• Задача (task) — техническая задача, которую делает один из членов команды.
• Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
• Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

• Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
• Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
• Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
• Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
• Продакшн среда (Production Env) – среда, в которой работают пользователи.

Основные фазы тестирования

• Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
• Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
• Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
• Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
• Release: финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

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

2. Классификация по доступу к коду и архитектуре:
   • Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
   • Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
   • Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

3. Классификация по уровню детализации приложения:
   • Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
   • Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
   • Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
   • Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

4. Классификация по степени автоматизации:
   • Ручное тестирование.
   • Автоматизированное тестирование.

5. Классификация по принципам работы с приложением
   • Позитивное тестирование — тестирование, при котором используются только корректные данные.
   • Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

6. Классификация по уровню функционального тестирования:
   • Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
   • Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   • Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.

7. Классификация в зависимости от исполнителей:
   • Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
   • Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.

8. Классификация в зависимости от целей тестирования:
   • Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
   • Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
     1. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
     2. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
     3. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
     4. Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
     5. Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
     6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
     7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
     8. Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
     9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
     10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
     11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
     12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
     13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

1. Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
3. Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
6. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
• Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

Согласно ISTQB, тестирование черного ящика — это:

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

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

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

• Что необходимо протестировать?
• Как будет проводиться тестирование?
• Когда будет проводиться тестирование?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Основные пункты тест плана:

1. Идентификатор тест плана (Test plan identifier);
2. Введение (Introduction);
3. Объект тестирования (Test items);
4. Функции, которые будут протестированы (Features to be tested;)
5. Функции, которые не будут протестированы (Features not to be tested);
6. Тестовые подходы (Approach);
7. Критерии прохождения тестирования (Item pass/fail criteria);
8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
9. Результаты тестирования (Test deliverables);
10. Задачи тестирования (Testing tasks);
11. Ресурсы системы (Environmental needs);
12. Обязанности (Responsibilities);
13. Роли и ответственность (Staffing and training needs);
14. Расписание (Schedule);
15. Оценка рисков (Risks and contingencies);
16. Согласования (Approvals).

Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

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

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (Expected result) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

Работа тестировщика входит в пятерку самых популярных работ в сфере IT, согласно статистике за 2020 год. Рынок растет очень быстро, а IT-компании постоянно создают новые команды тестировщиков. А вот еще немного впечатляющей статистики – на тестирование уходит 50% всего времени и более 50% общей стоимости любого проекта по созданию софта. А это приличный бюджет. Это означает, что налаживание процессов тестирования позволит сэкономить не только время, но и деньги.

Сегодня тестированию обучают в некоторых университетах. Но поскольку это все еще молодая отрасль, будущие специалисты предпочитают знакомиться с инструментами для тестирования программного обеспечения на онлайн-курсах. Онлайн-курсы и самообразование – это самый короткий способ изучить тестирование и начать новую жизнь в профессии. Наше руководство содержит краткий гид по основным инструментам тестирования программного обеспечения.

Тестирование является важнейшим методом контроля качества. Под качеством программного обеспечения мы имеем в виду соответствие программного обеспечения заявленным и предполагаемым требованиям. Основная цель тестирования программного обеспечения состоит в проверке совпадений между фактическими и ожидаемыми характеристиками программы. Ручное и автоматическое тестирование – это два наиболее известных типа тестирования программного обеспечения. Оба типа моделируют возможные сценарии действий пользователей и проверяют, выполняются ли при этом требования. Но в чем разница между ними?

Типы тестирования

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

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

Выбор инструмента и способа тестирования зависит от ваших целей и от желаемого уровня тестирования.  

А какие еще есть типы тестов?

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

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

Динамическое тестирование – это метод, направленный на проверку функциональности программы. Он требует выполнения кода. Этот тип тестирования включает фактическую работу программы и определение ее функциональности для проверки того, оправдываются ли требования. Динамический тип тестирования направлен на тестировку программного обеспечения в режиме реального времени посредством предоставления входной информации и изучения результирующего поведения приложения.

Методы тестирования

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

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

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

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

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

Уровни тестирования

Что касается уровней тестирования, существует модульное тестирование, интегральное тестирование, системное тестирование и приемочное тестирование. Модульное тестирование позволяет проверять правильность отдельных модулей исходного кода программы. Оно включает написание тестов для каждой нетривиальной функции или метода. Это позволяет тестировщику быстро проверить, не привело ли следующее изменение в коде к регрессу, то есть не вызвало ли оно ошибки в уже протестированных частях программы. Более того, это облегчает выявление и устранение таких ошибок. Модульное тестирование – это тестирование отдельных модулей и компонентов программы. Обычно его выполняют сами программисты, это своего рода самопроверка. Обнаруженные таким образом дефекты немедленно исправляются.

Интегральное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы. Есть разные уровни интегрального тестирования – тестирование компонентов интеграции и тестирование системной интеграции. Интеграция снизу вверх касается всех низкоуровневых модулей, процедур и функций, которые собираются вместе и затем тестируются. Такой подход считается удобным, если все или почти все модули разработанного уровня готовы. Интеграция сверху вниз подразумевает тестирование высокоуровневых модулей. Низкоуровневые модули добавляются один за другим.

Системное тестирование проводится на полной интегрированной системе. Его основная цель – проверить, соответствует ли система требованиям. Оно относится к тестированию методом «черного ящика» и, следовательно, не требует знания внутренней структуры. Системное тестирование делится на альфа-тестирование и бета-тестирование.

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

Итак, с чего начать изучение тестирования программного обеспечения? Лучший способ стать тестером – пройти онлайн-курс, который поможет вам понять, как создается программное обеспечение, с какими трудностями сталкиваются программисты и как выглядит процесс устранения ошибок. Наши курсы предоставляют качественное обучение от лучших инструкторов, поэтому присоединяйтесь к нам. Мы поможем вам изучить основы тестировки программного обеспечения и начать карьеру в IT.

Запись на курс Manual QA

‍

‍

 vlada_maestro / shutterstock

Автор в сфере IT, digital, экономики и финансов. Ведёт некоммерческий проект для начинающих писателей «ЛитЦех».

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

---

Это пособие для тех, кто только начинает свой путь в тестировании. Оно дает самые общие представления о профессии, погружает в суть процесса и описывает его простыми словами, без излишнего академизма и трудных для восприятия понятий. Учебник можно рассматривать как некий гейтвей в тестирование, поскольку автор знакомит читателя с основными терминами, соотносит англоязычные понятия с русскими, попутно раскрывая и объясняя каждое из них. Преимущество книги Романа Савина «tестирование dot com» еще и в русском языке оригинала, что исключает проблему неточностей перевода.

---

Фундаментальные концепции менеджмента бизнес-приложений

Книга больше подойдет не новичкам, а специалистам с опытом — как минимум проработавшим в профессии год и близко знакомым с тестированием. Ее можно назвать библией тестировщика: это объемный, сложный, охватывающий все концепции тестирования труд, требующий глубокого вдумчивого чтения. Из-за сложного тяжеловесного языка не многие доходят даже до середины текста.

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

---

Технологии функционального тестирования программного обеспечения и систем

Классический монументальный учебник по поведенческому тестированию Бориса Бейзера. Книга посвящена базовым методикам тестирования приложений. Некоторые из них на сегодняшний день уже устарели, так как книга не переиздавалась с 2004 года, однако общие принципы и подходы остались прежними и все еще актуальны.

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

---

Универсальный учебник, переживший третье переиздание на русском языке; в целом книге уже больше 30 лет, но она дополняется от издания к изданию. Несмотря на столь почтенный возраст, она не теряет в актуальности благодаря глубине изложенного материала. Книга посвящена не методикам или языкам тестирования. Авторы поставили своей целью рассказать об основополагающих принципах:

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

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

---

Оптимизация ресурсов и временных затрат на тестировании — важная и острая тема для команд разработки. Книга Рекса Блэка через контроль рисков рассказывает о 12 процессах тестирования.

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

---

Практическое руководство для тестировщиков ПО и гибких команд

Книга посвящена методике гибкого тестирования: это использование квадрантов гибкого тестирования, набор средств для него, требования к команде QA-специалистов, итерация гибкой разработки и факторы успеха применяемой стратегии. Рекомендуется ведущим тестировщикам и специалистам среднего уровня.

---

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

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

---

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

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

---

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

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

---

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

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

---

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

---

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

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

---

Вторая книга Витакера — пошаговое руководство по тестированию безопасности приложений. Ее лучше читать после «How to break web software».

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

Автор рассказывает о верхнеуровневых классах проверок, например, на уровне кода или GUI, и приводит 19 атак на защищенность приложения. Каждое описание атаки или инъекции состоит из вводной части, описания случаев применения и руководства по нему.

---

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

Автор приводит реальные типичные ошибки в подходах, а учиться на ошибках — самое полезное дело. В совместной работе специалисты часто переводят стрелки друг на друга и отказываются фиксить и документировать баг, ссылаясь на то, что это не их зона ответственности. Что с этим делать и как с этим жить — в том числе рассказывает Gerald M. Weinberg.

---

Мы предложили вам 15 испытанных временем книг по тестированию программного обеспечения, которые помогут освоиться в этой профессии. А еще рекомендуем наш обучающий курс по тестированию. Здесь в доступной интерактивной форме под руководством наставников вы изучите актуальный материал, научитесь использовать его на практике и получите новую профессию с возможностью трудоустройства.

Научитесь: Профессия Инженер по тестированию
Узнать больше

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

Нужны ли мне какие-то знания для работы с учебником?

Учебник рассчитан на начинающих тестировщиков с небольшим опытом в QA (или вообще без опыта).

Содержание

• 👶 Основы тестирования
• ↔️ Типы тестирования
• 📄 Тестовая документация
• 📁 Тест-кейсы
• 🛠️ Техники тест-дизайна
• 🐞 Все о багах
• ⚙️ Автоматизация
• 🚄 Тестирование производительности
•  📱 Тестирование мобильных приложений
• 🛠️ Инструменты тестировщика
• 💬 Софт-скиллы
• 👨‍💼 Собеседование
• 🔥 Интересное
• ✅ Тесты для самопроверки
• 📚 Чтение для отдыха

👶 Основы тестирования

Основы профессии — разбираемся с основополагающими понятиями — что такое тестирование, из каких видов оно состоит. Смотрим, на каких этапах разработки применяется, изучаем этапы и уровни.

Читать	Тестирование. Что это такое, описание, виды тестирования
Читать	Путь тестировщика: скиллы, зарплата, перспективы
Читать	Большая дорожная карта развития тестировщика
Читать	Семь главных принципов тестирования
Читать	STLC — жизненный цикл тестирования приложений. Этапы, критерии начала и окончания
Читать	V-модель тестирования
Читать	Этапы тестирования
Читать	Уровни тестирования
Читать	Функциональные и нефункциональные требования

↔️ Типы тестирования

Разбираемся в видах и типах тестирования — важно понимать особенности каждого из них. Чем отличается модульное тестирование от smoke-тестирования? Что такое альфа-, бета-, гамма-тестирование? Чем функциональное тестирование отличается от нефункционального? Ответы на все эти и многие другие вопросы в статьях ниже.

Читать	Виды и типы тестирования: подробный разбор
Читать	Тестирование белого ящика vs тестирование черного ящика
Читать	Тестирование серого ящика
Читать	Что такое ручное тестирование?
Читать	Что такое статическое и динамическое тестирование
Читать	Негативное тестирование: что это
Читать	Юзабилити-тестирование — большой гайд
Читать	Тестирование GUI: мини-гайд
Читать	Что такое функциональное тестирование? Мини-гайд
Читать	Нефункциональное тестирование — гайд
Читать	Интеграционное тестирование
Читать	Сквозное (E2E) тестирование
Читать	Что такое регрессионное тестирование?
Читать	Что такое системное тестирование?
Читать	Приемочное тестирование
Читать	Санитарное тестирование (sanity testing) — небольшой гайд
Читать	𝛼 Что такое альфа-тестирование?
Читать	β Что такое бета-тестирование?
Читать	Что такое monkey-testing? Чем отличается от ad-hoc тестирования? Что такое torture тестирование?
Читать	Что такое smoke-тестирование?
Читать	Что такое риск-тестирование?
Читать	Что такое ad-hoc тестирование?
Читать	Что такое тестирование доступности?
Читать	Что такое кросс-браузерное тестирование?
Читать	Тестирование конфигураций
Читать	Тестирование масштабируемости
Читать	Инсталляционное тестирование
Читать	Тестирование пиков нагрузки
Читать	Исследовательское тестирование
Читать	Повторное тестирование

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

Все о тестовой документации и о том, как ее писать.

Читать	Что такое тестовая документация и зачем она нужна?
Читать	Тестовые артефакты
Читать	Что такое тест план и как его написать?
Читать	Что такое use case? Теория и примеры
Читать	Что такое тестовый сценарий?
Читать	Что такое user story и как ее писать?
Читать	Что такое стратегия тестирования
Читать	Матрица сопоставления требований с тест-кейсами
Читать	Стратегия обеспечения качества и вопросы в процессе ее составления

📁 Тест-кейсы

Руководства по написанию тест-кейсов.

Читать	Техники тест-дизайна: теория и примеры
Читать	Как писать тест-кейсы: полное руководство
Читать	Основные методики создания тест-кейсов
Читать	Тестовый набор (тест-свит, тест-сьют)

Техники тест-дизайна

Классы эквивалентности, таблицы решений, предугадывание ошибок и многое другое — раздел о техниках тестирования.

Читать	Что такое предугадывание ошибок?
Читать	Что такое классы эквивалентности?
Читать	Анализ граничных значений
Читать	Что такое таблица решений?
Читать	Попарное тестирование

🐞 Баги

Баги, их классификация и баг-репорты — обо всем этом в разделе.

Читать	Жизненный цикл бага
Читать	Как искать баги — гайд
Читать	Что такое баг-репорт?
Читать	Как составить баг-репорт: мини-гайд
Читать	Как написать классный баг-репорт
Читать	Серьезность и приоритет багов — в чем разница?
Читать	Верификация и валидация: что это и в чем разница?
Читать	Баг-трекинговые системы: Jira и альтернативные варианты

⚙️ Автоматизация

Читать	Что такое автоматизированное тестирование?
Читать	Что такое автоматизированное тестирование? Гайд по основам
Читать	Что такое ручное тестирование. Основные подходы и инструменты
Читать	В чем разница между ручным и автоматизированным тестированием?
Читать	Почему не получается автоматизация — 100 причин (на самом деле меньше)
Читать	Как не надо автоматизировать
Читать	Как стать автоматизированным тестировщиком? Небольшой план действий
Читать	Автоматизация кроссбраузерного тестирования на Java/Python/JS — гайд
Читать	Решаем, что и когда автоматизировать, и нужно ли
Читать	Как выбрать инструменты автоматизации (с таблицей)
Читать	Три типичных ошибки автоматизатора
Читать	Определяем, нужно ли автоматизировать тест-кейс? Чеклист, который вам поможет.
Читать	Признаки ХОРОШЕГО автотеста
Читать	Траблы автоматизации — как их избежать
Читать	Автоматизированное тестирование НИКОГДА не заменит ручное
Читать	Лучшие open-source инструменты для автоматизированного тестирования
Читать	Автоматизация: актуальные инструменты (и статистика)
Читать	5 самых популярных инструментов автоматизации тестирования в 2022 году

🚄 Тестирование производительности

Читать	Тестирование производительности веб-сервисов — теория и инструменты
Читать	Что такое нагрузочное тестирование
Читать	Что такое объемное тестирование?
Читать	Что такое стресс-тестирование: мини-гайд
Читать	Тестирование стабильности
Читать	Тестирование производительности в Postman
Читать	Планируем нагрузочное тестирование
Читать	Топ-15 бесплатных инструментов для нагрузочного тестирования

📱 Тестирование мобильных приложений

Обучающие материалы по мобильному тестированию.

Читать	Тестирование мобильных приложений: шаги и процедуры
Читать	Большой гайд по тестированию Android-приложений
Читать	Appium — гайд
Читать	Автоматизация жестов в Appium: блиц-практикум
Читать	Моки в инструментальных тестах Android
Читать	Большой гайд по автоматизации в XCUITest
Читать	Подбор устройств для тестирования совместимости

🛠️ Инструменты

Читать	Chrome Developer Tools для тестировщика
Читать	Docker — быстрый гайд
Читать	Bugzilla: экспресс-гайд
Читать	Playwright: полный гайд + FAQ
Читать	Playwright: экспресс-гайд
Читать	SoapUI: тестирование SOAP и REST API
Читать	Puppeteer — большой гайд
Читать	Пять расширений Google Chrome для тестировщиков
Читать	Гайд по Selenium. Часть 1. Установка Selenium WebDriver
Читать	Большой гайд по тестированию с Postman для начинающих
Читать	TestNG — большой гайд
Читать	Тестирование производительности API с помощью K6
Читать	Туториал по Pytest
Читать	100 (да, сто) бесплатных советов по Java-инструментам QA
Читать	Что такое Cypress: Введение и архитектура
Читать	Как ускорить тесты Selenium — полный гайд
Читать	Ошибки в Selenium — гайд по exceptions
Читать	Плюшевый Cypress: 5 советов
Читать	Что удобнее, Cypress или Selenium
Читать	E2E-тестирование в Cypress
Читать	Бесплатные онлайн-генераторы тестовых данных
Читать	Десять классных генераторов тестовых данных
Читать	Автотесты и Docker: блиц-практикум
Читать	Обзор фреймворков для iOS тестирования
Читать	Как ускорить тесты с помощью сypress-grep
Читать	Регрессионное тестирование: подборка инструментов
Читать	Эмуляторы и симуляторы: в чем разница?
Читать	Playwright config — смотрим в деталях
Читать	Кажется, Playwright уже лучше чем Cypress
Читать	curl — учимся тестировать API

💬 Софт-скиллы

Читать	Как войти в QA: cоветы QA Lead
Читать	Пять технических и пять нетехнических навыков хорошего QA
Читать	Как стать QA-лидом
Читать	Как QA общаться с разработчиками? Что делать ✅ и чего не делать ❌

👨‍💼 Собеседование

Материалы для подготовки к собеседованиям — вопросы и ответы по самым разным темам.

Читать	Что можно и чего нельзя делать на собеседовании по тестированию
Читать	Тестировщик без опыта — советы по резюме
Читать	Вопросы на собеседовании тестировщика — стажер/джуниор
Читать	Вопросы на собеседовании тестировщика: джуниор++/миддл
Читать	Собеседование тестировщика — cкользкие вопросы
Читать	Вопросы по SQL и базам данных на собеседовании тестировщика (+ ответы)
Читать	Собеседование QA — что спрашивают о CI/CD
Читать	О чем спрашивают на собеседовании QA Junior: Selenium
Читать	Собеседование QA: тестирование API
Читать	Идем на собеседование на позицию тестировщика — 36 частых вопросов по Postman
Читать	QA-интервью: как решить любую задачу
Читать	Метод STAR на собеседовании
Читать	Собеседование тестировщика в Евросоюзе и США/Канаде: вопросы
Читать	Тайтлы в QA

🔥 Интересное

Читать	Языки программирования, которые тестировщик обязан знать
Читать	Пирамида уровней тестирования — виды, типы, проблемы
Читать	Нестабильные тесты. Почему они существуют и что с ними делать
Читать	Тестирование API
Читать	ChatGPT для тестировщика — как создавать тесты и документацию
Читать	Экономия на тестировщиках? Что такое Lean QA
Читать	Вильфредо Парето говорит: сосредоточься на главном
Читать	Бритва Оккама: как тестировщик решает вопросы правильно и быстро
Читать	Что такое CI/CD (непрерывная интеграция и доставка)
Читать	Юнит-тесты. Очень глубокое погружение
Читать	Тестирование баз данных — полный гайд
Читать	Почему Google не нанимает тестировщиков
Читать	Причины провала ИТ-проектов
Читать	Методологии разработки ПО
Читать	Сбор требований — краткое руководство
Читать	Что такое тестовое покрытие (test coverage)
Читать	Покрытие кода
Читать	Релизим в пятницу без валидола — советы для безопасных релизов
Читать	Как ускорить регрессионное тестирование
Читать	Структуры данных — большой гайд
Читать	Что такое BDD? Опыт с Cucumber/Gherkin + вопросы на собеседовании
Читать	Контролируем тестовые девайсы (и тестировщиков) в Slack
Читать	Владелец продукта и скрам-мастер: в чем разница?
Читать	Советы для проведения эффективного ретро
Читать	Осваиваем Data-driven Testing в Selenium
Читать	Английский для тестировщиков. Грамматика с Джеймсом Виттакером, Ли Коуплендом и другими мэтрами тестирования
Читать	Большой гайд по Page Object Model
Читать	Юнит-тесты vs интеграционные тесты
Читать	JavaScript QA — делаем все правильно с самого начала
Читать	Кто такие стейкхолдеры? Определения, типы и примеры
Читать	Мутационное тестирование. Теория + практикум
Читать	Бэклог продукта и бэклог спринта: краткое руководство
Читать	QA-команда и DevOps: что делать
Читать	10 советов по управлению проектами
Читать	Типичные вопросы для собеседования на проджект менеджера и как на них отвечать
Читать	Юнит-тесты и Jest: toBe or not.toBe
Читать	Как тестировать формы? Мини-руководство
Читать	В чем разница между QA и QC?
Читать	13 вопросов и ответов на собеседовании на scrum-мастера
Читать	Борьба с задержкой тестов в Selenium: пример из практики
Читать	E2E-тестирование в Cypress
Читать	Параметризация тестов: JUnit
Читать	Искусственный интеллект в функциональном тестировании
Читать	Сказ о ненатуральном эджайле
Читать	Как тестировать GraphQL API? Гайд для начинающих
Читать	Введение в тестирование блокчейна
Читать	6 готовых оправданий, чтобы не писать юнит-тесты
Читать	Что такое Test-Driven-Development?
Читать	Unit-тесты на фронтенде. Best practices

✅ Тесты для самопроверки

Читать	Тест по основам тестирования
Читать	Блиц-тест ISTQB — Основы
Читать	Тест по основам тестирования (in English)
Читать	Тестовый экзамен ISTQB Foundation Level (на английском)

📚 Чтиво

По теме. Почему QA-инженеры (все еще) нужны и к чему приводит плохое тестирование.

Читать	7 эпичнейших багов в истории человечества
Читать	Баги войны
Читать	Баги войны: вторая часть
Читать	«Грудь выскочила наружу, не могу убрать ее обратно» — о багах в играх и отношении к джунам на примере Cyberpunk 2077
Читать	В России растут зарплаты тестировщиков. Смотрим, кому, где и сколько платят
Читать	Тестирование легче программирования? Мой путь из программиста в QA
Читать	Обычный день твоего лида
Читать	Пузырь популярности ИТ скоро лопнет. Глобальное сокращение на горизонте
Читать	Тренды тестирования 2021. Правда и мифы

О чем речь? Тестирование программного обеспечения – это необходимый процесс в ходе разработки, во время которого выявляются все проблемы в работе софта. Какими бы классными не были программисты, ошибки будут всегда, поэтому необходима регулярная проверка.

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

Необходимость тестирования программного обеспечения

Перечислим классические программные ошибки:

• Пользователь вбивает в поле ответ на вопрос и жмет клавишу Далее программа завершает работу, а информация не сохраняется. То же самое происходит и при следующей попытке.
• Пользователь играет в шутер. Вдруг персонажи начинают странно двигаться, подергиваться и т.д. Сначала программа попросту не реагирует на нажатие клавиш, а потом и вовсе выдаёт «Game over».
• Пользователь заходит в личный кабинет интернет-магазина и нажимает «Оплатить». Однако его перебрасывает на главную страницу. Кроме того, в аккаунт приходится заново входить.

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

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

Формы тестирования программного обеспечения

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

Скачать
файл

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

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

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

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

Виды тестирования ПО

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

Функциональное и нефункциональное

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

Как правило, тестируются только готовые функции, которые уже должны правильно работать. Однако объектами проверки могут стать и «неожидаемые» функций и варианты поведения приложения.

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

Статическое и динамическое

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

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

Обе эти стадии являются необходимыми.

Прочие разновидности тестирования

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

• Нагрузочное. Речь идёт о тестировании программы в условиях высоких нагрузок, которые могут быть больше, чем планировали разработчики. Эти тесты обязательны для онлайн-сервисов, которые должны правильно работать даже при наличии большого числа посетителей на пиковой или регулярной основе (онлайн-магазины во время распродаж, новостные ресурсы при резонансных событиях и т.д.).
• Тестирование UX. В этом случае специалист сосредотачивается на пользовательском опыте. Тестировщику необходимо поставить себя на место клиента. На основе составленных им замёток в процессе взаимодействия с приложением будут вноситься соответствующие изменения.
• Конфигурационное. Это проверка совместимости программы с аппаратным обеспечением и прочими software-элементами (различными версиями OS и процессоров). Конфигурационное тестирование необходимо для межплатформенных программ и в процессе перехода поставщика платформы на принципиально новую аппаратную базу (яркий пример — появление ноутбуков с чипами М1 от Apple).

Тестирование «белого ящика» и «чёрного ящика»

При проверке программного и аппаратного обеспечения термины «тестирование белого ящика» и «тестирование чёрного ящика» указывают на то, есть ли у разработчика тестов доступ к исходному коду программы (если нет, то проверка выполняется посредством пользовательского интерфейса или прикладного программного интерфейса, предоставленного тестируемым модулем).

Тестирование белого/прозрачного ящика (от английского white-box testing) подразумевает, что у разработчика теста есть доступ к исходному коду приложения и он имеет возможность писать код, связанный с библиотеками тестируемого ПО. Такое положение дел часто встречается при юнит-тестировании (англ. unit testing). В этом случае проверке подвергаются лишь определенные элементы системы.

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

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

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

Чаще всего такое тестирование выполняется с применением спецификаций или иных документов, в которых указаны требования к системе. Критерий покрытия формируются из покрытия структуры входных данных, покрытия требований и покрытия модели (при проверке на базе моделей).

Понятия «альфа-тестирование» и «бета-тестирование» связаны с этапом до выпуска продукта, объёмом тестирующего сообщества и ограничениями по способам проверки. Тестирование «белого ящика» и «чёрного ящика» относятся к методам, которыми пользуется специалист.

Бета-тестирование ограничивается техникой чёрного ящика (однако постоянная часть тестировщиков, как правило, продолжает проверку белого ящика одновременно с бета-тестированием). Исходя из этого, понятие бета-тестирования описывает этап реализации программного продукта (ближе к выпуску, чем «альфа») или определенную команду тестировщиков и процесс, выполняемый этой командой.

Таким образом, тестировщик может проводить мероприятия по тестированию белого ящика даже после того, как программа перейдет на этап «бета». Однако это возможно в том случае, если специалист не является частью «бета-тестирования» (группы/процесса).

Место тестирования в процессе создания ПО

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

Многое зависит и от принятой модели развития. К примеру, модель «Водопад» предполагает, что формальное тестирование выполняется на этапе тестирования. Если же используется инкрементальная модель, то проверка осуществляется в конце каждого приращения/итерации и вся программа тестируется на конечном этапе.

Тестирование программного обеспечения выполняется в различных формах на каждой стадии SDLC:

• На стадии сбора требований тестированием является проверка этих требований.
• На стадии проектирования тестированием является проверка проекта для повышения качества дизайна.
• После написания кода тестированием считается итоговая проверка.

Этапы тестирования программного обеспечения

Анализ тестирования

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

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

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

На данной стадии тестировщики рассматривают и анализируют требования, а также формируют соответствующие тесты. Кроме того, они определяют приоритеты для проверки — членов команды.

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

Планирование и подготовка теста

На этой стадии разрабатываются план тестирования, тестовый набор, данные теста. Кроме того, выполняется подготовка среды тестирования.

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

Параллельно с этим специалисты подготавливают тестовые наборы и тестовые данные.

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

Это делается с помощью матрицы прослеживаемости требований (RTM) — документа, который сравнивает требования с тестовыми примерами. Нужно это для того, чтобы удостовериться в полноценном выполнении проверки.

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

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

Подготовка тестовой среды — крайне важная стадия. После написания фрагмента кода его необходимо проверить с помощью инструмента управления конфигурацией. Далее подготавливается тестовая сборка.

Выполнение теста

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

Закрытие теста

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

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

Документация для тестирования ПО

Тест план (Test Plan) представляет собой документ, в котором указываются все необходимые для тестирования мероприятия. В нем описываются объект, стратегии, расписания, критерии начала и завершения проверки, указывается требуемое оборудование и специальные знания, а также выполняется оценка рисков.

В данном документе должны иметься ответы на нижеперечисленные вопросы:

• Что нужно протестировать?
• Каким образом должно осуществляться тестирование?
• Когда будет выполняться проверка?
• Каковы критерии начала тестирования?
• Каковы критерии завершения тестирования.

Важнейшие разделы:

• Идентификатор тест плана (Test plan identifier).
• Введение (Introduction).
• Объект тестирования (Test items).
• Функции, которые следует проверить(Features to be tested).
• Функции, которые не нужно проверять (Features not to be tested).
• Тестовые подходы (Approach).
• Критерии прохождения тестирования (Item pass/fail criteria).
• Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements).
• Результаты тестирования (Test deliverables).
• Задачи тестирования (Testing tasks).
• Ресурсы системы (Environmental needs).
• Обязанности (Responsibilities).
• Роли и ответственность (Staffing and training needs).
• Расписание (Schedule).
• Оценка рисков (Risks and contingencies).
• Согласования (Approvals).

Нельзя не упомянуть чек-лист (check list). В данном документе указываются объекты, которые необходимо протестировать. При этом чек-листы могут различаться по степени детализации.

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

Тестовый сценарий (test case) представляет собой артефакт, в котором описывается комплекс мероприятий, определенных условий и параметров, требуемых для проверки реализации тестируемой функции или её элемента.

Перечислим составные части тест кейса:

• Предусловия (PreConditions). Это перечень операций, которые необходимы для приведения системы к пригодному для выполнения основного теста состоянию. Иногда под PreConditions подразумевается набор условий, реализация которых указывает на то, что система пригодна для проведения основного теста.
• Шаги (Steps). Речь идет о перечне операций, с помощью которых одно состояние системы сменяется другим. Это нужно для того, чтобы получить результат, с помощью которого можно будет сделать вывод об удовлетворении реализации поставленным требованиям.
• Ожидаемый результат (Expected result). Это то, что необходимо получить в конечном итоге.

Правила качественного тестирования ПО

Перечислим правила, которым нужно следовать для эффективного выполнения проверки:

• Не стоит пренебрегать ручным тестированием. Автоматические проверки помогут отыскать лишь те ошибки, которые предусмотрены в скрипте тестирования. С помощью ручных методов можно найти непредсказуемые дефекты.
• Следует писать тестовые примеры на простом языке или псевдокоде вместе с вашим кодом. В противном случае новым специалистам и менеджерам придётся тратить много времени на синтаксический анализ сценария проверки.
• Необходимо применять только контролируемые изолированные испытательные среды во избежание влияния извне. Если вы будете пользоваться ПК или открытым облаком, то на тесты могут повлиять посторонние факторы. Это скажется на производительности и результате.
• Нужно выбирать конкретные метрики, которые подвергаются количественной оценке. Показатели должны описывать лишь один атрибут и строиться из чисел, дабы упростить процесс формирования отчетов. Это относится как к спецификациям, так и к тестовым случаям.
• Стоит провести тестирование до того, как вы приступите к проверке качества. Благодаря такому подходу вы распределите рабочую нагрузку тестирования по всему процессу и снизите потери времени на исправление ошибок в центральном компоненте.
• Не забывайте про пошаговые тесты. Разработайте подусловия в своих тестах. Это позволит выявить места, в которых приложение не проходит проверку.
• Лучше обеспечить как можно большее тестовое покрытие. Если вы проверите все варианты применения программы, то продукт будет готов к самым разным входам и средам.

Навыки и качества специалиста по тестированию программного обеспечения

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

• Усидчивость и настойчивость. Специалист должен быть достаточно терпеливым, чтобы длительное время выполнять поиск ошибок. Профессионал своего дела знает, что не существует безошибочных приложений. Если в программе не было найдено никаких дефектов, то это указывает на низкое качество тестирования.
• Критическое мышление, способность работать с информацией.
• Умение подмечать даже самые, на первый взгляд, незначительные детали. Тестировщику необходимо проверять все возможные сценарии.
• Коммуникабельность и навыки командной работы. Специалисту нужно будет общаться с разработчиками, дизайнерами, бизнес-аналитиками, представителями заказчика.
• Самоконтроль. Разработчики далеко не всегда настроены на исправление дефектов, поэтому тестировщикам приходится по нескольку раз повторять, что была найдена ошибка. Таким образом, специалист должен сочетать в себе настойчивость и дипломатичность.
• Ответственность и педантичность. Благодаря этим качествам тестировщик будет пытаться довести свою работу до конца.
• Способность грамотно формулировать свои мысли. Это позволит разработать качественный план и тест-кейс. При обнаружении дефекта специалисту необходимо донести до разработчиков все нюансы его появления.
• Желание оттачивать свои навыки. Специалист должен быть нацелен на обучение новым техникам тестирования. Для этого ему нужно работать с соответствующей литературой, ездить на конференции, семинары, проходить курсы и т.д.

Профессионал должен знать:

• основы тестирования, его разновидности и техники;
• способы разработки тест-кейсов, тест-планов;
• языки запросов SQL, базы данных;
• языки программирования;
• системы контроля версий: Git, CVS ипр.

Плюс ко всему, специалист должен уметь работать с инструментами ручного и автоматического тестирования, к которым относятся:

• Системы для разработки тест-кейсов и обнаружения ошибок.
• Файловые менеджеры, текстовые и XML-редакторы.
• Генераторы тестовых данных итак далее.

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

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

Лучшие курсы по специальности тестировщика ПО

• Инженер по тестированию PRO

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

• Инженер по ручному тестированию

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

• Инженер по тестированию Мастер

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

• Инженер по тестированию

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

• Инженер по автоматизированному тестированию

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

• Специалист по тестированию

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

7 книг о тестировании программного обеспечения

• Р. Калбертсон, К. Браун, Г. Кобб «Быстрое тестирование»

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

• С. Круг «Не заставляйте меня думать»

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

• А.Купер «Психбольница в руках пациента»

Отличная литература, в которой объясняется, каким образом можно улучшить юзабилити программ посредством проектирования. Изучение данной книги поможет не только тестировщикам, но и программистам, аналитикам, руководителям многопрофильных команд.

• Дж. Арбон, Дж. Каролло, Дж. Уиттакер «Как тестируют в Google»

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

• Э. Дастин, Д. Рэшка, Дж. Пол. «Автоматизированное тестирование программного обеспечения»

В пособии описываются различные детали процесса автоматического тестирования. Книга освещает тему увеличения скорости тестовых процедур на web-серверах. При этом авторы объясняют различные нюансы проектирования, разработки и выполнения тестов.

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

Известный автор в мире IT сформировал пособие, в котором неопытные тестировщики смогут найти примеры всевозможных техник, подсказки в формате чек-листов, перечни тест-кейсов. Кроме того, вы сможете ознакомиться с важнейшими элементами работы в данной сфере – требованиями, планированием, отчетностью.

• С. Слукин «Введение в тестирование программного обеспечения»

Очень информативная книга, с помощью которой вы сможете улучшить навыки работы с объектно-ориентированным ПО. В этом курсе указаны тестовые требования, изложены практические примеры, планы и образцы отчетов.

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