В чем цель тестирования

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

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

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

Тестирование программного обеспечения (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). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

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

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

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

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

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

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

Верификация (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 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):

• 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, тестирование белого ящика — это:

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

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

Согласно 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).

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

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

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

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

Резюме

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

• теория
• теория тестирования
• основные определения тестирования

• Тестирование IT-систем
• Тестирование веб-сервисов
• Тестирование мобильных приложений
• Тестирование игр

Обзор целей тестирования ПО

Как стать тестировщиком — путь к успеху

End-to-End тестирование в деталях и примерах

Unit тестирование в Java

Автоматизация тестирования: перспективно ли?

Как строить карьеру фрилансеру тестировщику

Какие виды тестирования существуют

Мобильное тестирование: что это и какие перспективы

Тестирование программного обеспечения (ПО) является неотъемлемой частью разработки любого проекта. Это процесс, который помогает обнаружить ошибки и дефекты, улучшить качество продукта и уверенно выпустить его на рынок. Цели тестирования заключаются в обеспечении надежности, функциональности и безопасности ПО, чтобы пользователи могли полноценно воспользоваться всеми его возможностями.

Общие цели тестирования ПО

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

Другие важные цели тестирования включают:

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

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

• Соответствие требованиям: проверка того, соответствует ли ПО требованиям, которые были установлены и соответствовало ожиданиям пользователей и бизнес-потребностям.

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

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

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

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

�� Регистрируйтесь на онлайн-курс менторинга QA Automation от компании FoxmindEd и начните свой путь к экспертности в тестировании ПО! ��

Обязанности тестировщика

Что делает тестировщик и что входит в его обязанности? Это — достаточно широкий спектр задач, начиная от ручного тестирования до использования автоматизированных инструментов и методов.

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

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

1. Обнаружение и документация ошибок

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

1. Взаимодействие с командой разработчиков

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

Похожие материалы
Как стать тестировщиком — путь к успеху
End-to-End тестирование в деталях и примерах
Unit тестирование в Java
Автоматизация тестирования: перспективно ли?
Как строить карьеру фрилансеру тестировщику
Какие виды тестирования существуют
Мобильное тестирование: что это и какие перспективы
Зачем необходимо тестирование?

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

Какие основные цели функционального тестирования?

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

Что такое негативное тестирование?

Это тестирование, направленное на проверку реакции системы на некорректные входные данные.

В чем цель нагрузочного тестирования?

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

Почему важно проводить регрессионное тестирование?

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

Какова цель юзабилити-тестирования?

Оценить удобство и интуитивность пользовательского интерфейса для конечного пользователя.

Тестирование: цели и принципы

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

Все статьи будут выходить с хештегом #базоваятеория@zapiskisedogotestera. Это позволит найти их среди прочих.

Предлагаю начать с определения тестирования, его целей и принципов.

Откуда вообще возникла необходимость в тестировании? Люди совершают ошибки. Одни из них могут быть незначительными, другие иметь самые разрушительные последствия. Все, что производится человеком, может содержать ошибки (так уж мы, люди, устроены). Именно поэтому любой продукт нуждается в проверке – тестировании.

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

Тестирование — это …

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

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

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

Цели тестирования

Цели тестирования сильно зависят от целей самого проекта. Но можно выделить основные общие цели:

1. Проверка, все ли указанные требования выполнены.
   Что это значит? У каждого продукта есть техническое задание (ТЗ) в том или ином виде. Именно оно определяет, как будет выглядеть программа. ТЗ задает соответствующие требования, а мы, как тестировщики, должны проверить, что все требования из ТЗ не только реализованы, но и работают правильно.
2. Создание уверенности в уровне качества объекта тестирования.
   Напрямую тестирование не влияет на качество продукта. Грубо говоря, качество — это удовлетворение ожиданий пользователей. А удовлетворение зависит от очень многих факторов.
   Тем не менее, поиск и исправление дефектов позволяет продукту работать именно так, как он был задуман. И, как минимум, можно сказать, что если программа работает корректно и соответствует заданным критериям, то достигнут определенный уровень качества объекта тестирования.
3. Предотвращение дефектов.
   Тестирование — не только поиск багов на уже реализованном продукте. Существует также тестирование на более ранних этапах, например, тестирование документации.
   Заранее протестировав тоже ТЗ, тестировщик может указать на потенциальные проблемы, которые могут появиться в результате разработки программы. А зная о таких проблемах заранее, можно избежать вполне реальных багов в будущем.
4. Обнаружение отказов и дефектов.
   Здесь все просто: поиск багов в программном обеспечении (ПО) является неотъемлемой частью тестирования.
5. Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения (особенно в отношении уровня качества объекта тестирования).
   Тестирование — это все-таки услуга. Мы, как тестировщики, не влияем напрямую на исправление дефектов. Но можем показать текущее состояние продукта, выраженное в количестве багов, путем оформления баг-репортов. Заинтересованные лица (например, руководитель проекта) могут оценить текущие проблемы и принять решение о выпуске или не выпуске продукта.
6. Снижение уровня риска ненадлежащего качества программного обеспечения (например, пропущенные сбои в работе).
   Чем лучше тестирование, тем меньший риск пропуска критичных багов. А значит, что риск возникновения ненадлежащего качества ПО уменьшается.

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

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

1. Тестирование демонстрирует наличие дефектов, а не их отсутствие.
   Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, тестирование не доказывает его корректности. Почему? Потому что есть пункт 2.
2. Исчерпывающее тестирование недостижимо.
   Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо попытки исчерпывающего тестирования должны использоваться анализ рисков, методы тестирования и расстановка приоритетов, чтобы сосредоточить усилия по тестированию.
   Элементарно, попробуйте посчитать сколько усилий необходимо приложить, чтобы проверить все комбинации калькулятора. И даже если вы продумаете абсолютно все варианты, то всегда найдется еще один, о котором вы не знаете.
3. Раннее тестирование сохраняет время и деньги.
   Активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения. Это как раз позволяет находить дефекты на ранних стадиях.
   Раннее тестирование иногда называют «сдвигом влево» по ISTQB. Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения. Хотя бы потому что вовремя замеченную ошибку в ТЗ исправить намного проще, чем когда по этому ТЗ уже будет разработана функциональность.
4. Кластеризация дефектов (Скопление дефектов).
   Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском. То есть баги имеют свойство скапливаться где-то в одном месте и, если нашли интересную ошибку в функционале, есть очень большая вероятность найти рядом еще одну.
5. Парадокс (эффект) пестицида.
   Если одни и те же тесты будут выполняться снова и снова, в конечном счете эти тесты больше не будут находить новых дефектов. Для обнаружения новых ошибок может потребоваться изменение существующих тестов и тестовых данных, а также написание новых тестов.
   Тесты больше не эффективны при обнаружении дефектов, так же как пестициды через некоторое время больше не эффективны при борьбе с вредителями.
6. Тестирование зависит от контекста.
   Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение управления производством, в котором критически важна безопасность, тестируется иначе, чем мобильное приложение электронной коммерции.
7. Заблуждение об отсутствии ошибок.
   Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1 говорят нам, что это невозможно.
   Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех продукту. Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.

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

Что такое тестирование и как оно устроено

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

Зачем тестировать программы

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

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

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

Как проходит тестирование ПО

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

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

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

Тестирование — это сложно?

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

Типичные ошибки при тестировании

Список наиболее распространенных ошибок, которые можно обнаружить при тестировании, выглядит так:

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

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

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

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

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

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

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

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

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

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

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

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

Статистическое тестирование требует больше времени (предварительное составление чек-листов, много встреч по доработке кода), но существенно дешевле, поскольку ищет ошибки на раннем этапе. Динамическое занимает меньше времени при разработке, но стоит дороже — на поиск и исправление багов после компиляции кода нужно больше времени и сил.

Другие виды тестирования

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

Что тестируют на разных этапах разработки

Модульное тестирование. Это самая ранняя стадия тестирования, которая проверяет отдельные компонентов и модули программы отдельно друг от друга (или изолированно). Цель модульного тестирования — выявить ошибки на ранних стадиях написания программ и убедиться, что каждый компонент работает должным образом.

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

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

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

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

Как проходит тестирование

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

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

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

Выполнение. Только теперь начинается фактическое выполнение тестирования. Данные о любых ошибках или проблемах записываются и анализируются.

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

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

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

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

Вот несколько принципов, которые помогут сделать тестирование эффективнее:

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

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

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

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

Автоматизация. Автоматизируйте как можно больше тестов: это позволит сэкономить время и повысить эффективность.

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

Заключение

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

Катрин Алимова

Вам может также понравиться.

Мы меняем цены на курсы

24 окт. 2023 г.

Рейтинг языков программирования 2023

24 окт. 2023 г.