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

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

Определение слова “тестирование” имеет много значений. Рассмотрим основные:

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

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

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

Тестирование программ является важной практикой по нескольким причинам:

1. Выявление ошибок. Позволяет обнаружить ошибки и недочеты в программном обеспечении. Раннее обнаружение и исправление ошибок способствует улучшению качества программы и уменьшению возможных проблем и рисков в дальнейшем.
2. Гарантия качества. Помогает проверить, насколько программа соответствует своим требованиям и спецификациям. Это позволяет удостовериться, что программа работает правильно, выполняет задачи и доставляет ожидаемые результаты.
3. Улучшение надежности. Способствует повышению надежности программного обеспечения. Через тестирование можно выявить уязвимости, ошибки в обработке данных и другие проблемы, которые могут привести к сбоям или неправильной работе программы.
4. Оптимизация производительности. Позволяет оценить производительность программы, выявить узкие места и бутылочные горлышки, которые могут замедлять работу программы.
5. Повышение удовлетворенности пользователей. Позволяет выявить и исправить проблемы, которые могут негативно влиять на пользовательский опыт. Корректная и надежная работа программы улучшает удовлетворенность пользователей и способствует их лояльности.
6. Уменьшение рисков и затрат. Помогает снизить риски, связанные с неправильной работой программы. Обнаружение и устранение ошибок на ранних стадиях разработки экономит время, усилия и ресурсы, которые могут быть затрачены на исправление проблем в более поздних этапах.

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

Жизненный цикл разработки проекта

Стадии разработки ПО — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с анализа требований к проекту и первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»).

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

• Анализ требований к проекту
• Проектирование
• Реализация
• Тестирование продукта
• Внедрение и поддержка.

Каждой стадии разработки ПО присваивается определенный порядковый номер. Также каждый этап имеет свое собственное название (Пре-альфа, Альфа, Бета, Релиз-кандидат, Релиз, Пост-релиз), которое характеризует готовность продукта на этой стадии.

Жизненный цикл разработки ПО (Software Development Life Cycle — SDLC):

1. Идея (Idea)
2. Сбор и аналитика (Planning and Requirement Analysis)
3. Документирование требований (Defining Requirements)
4. Дизайн (Design Architecture)
5. Разработка (Developing)
6. Тестирование (Testing)
7. Внедрение/развертывание (Deployment)
8. Поддержка (Maintenance)
9. Смерть (Death)

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

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

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

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

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

Для проведения качественного теста важно знать основы и принципы работы.

Есть 7 устоявшихся аксиом качественного тестирования:

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

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

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

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

1. Планирование тестирования. В этом этапе определяются цели и объем тестирования, разрабатывается тестовый план, определяются ресурсы, расписывается расписание и составляется список требований для тестирования.
2. Анализ требований и создание тестовых случаев. На этом этапе производится анализ требований к программному обеспечению и разрабатываются тестовые случаи. Тестовые случаи описывают шаги, которые необходимо выполнить для проверки функционального и нефункционального соответствия требованиям.
3. Подготовка тестового окружения. Здесь создаются необходимые условия для проведения тестирования, включая установку программного обеспечения, настройку тестовых данных, настройку тестовых средств и инструментов.
4. Выполнение тестов. На этом этапе проводятся тесты в соответствии с разработанными тестовыми случаями. Тестировщики выполняют шаги тестирования, вводят тестовые данные и проверяют результаты, сравнивая их с ожидаемыми значениями.
5. Регистрация и отслеживание поломок. Если в процессе тестирования обнаруживаются ошибка, она регистрируется в виде дефектных отчетов. В отчетах указывается описание проблемы, шаги для воспроизведения, приоритет и серьезность. Дефекты отслеживаются и передаются разработчикам для исправления.
6. Анализ результатов тестирования. После завершения тестирования производится анализ результатов. Оцениваются выполнение требований, обнаруженные дефекты, покрытие тестами и эффективность тестирования.
7. Завершение и отчетность. На последнем этапе составляется отчет о выполненном тестировании, включающий информацию о проведенных тестах, обнаруженных дефектах, выполнении требований и других важных аспектах. Отчет передается заинтересованным сторонам, таким как руководство проекта или заказчику.

Также есть тестовые среды:

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

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

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

Тестирование классифицируется по разным критериям. Основные виды тестирования:

1. Функциональное тестирование (functional testing). Данный вид подразумевает проверку того, что ПО правильно решает пользовательские задачи, проверка функциональных задач. Функциональный вид тестирования сосредотачивается на функциях и возможностях приложения, а также его соответствии требованиям и ожиданиям пользователей. Основная цель функционального тестирования — убедиться, что все функции и операции приложения работают корректно и взаимодействуют друг с другом так, как ожидается.
2. Тестирование производительности. Вид тестирует оценку быстродействия ПО при заданной нагрузке. Тестирование производительности проводится до и после оптимизации. Его целью является проверка и выявление факторов, которые влияют на производительность ПО.
3. Тестирование API — это тип функционального и нефункционального тестирования ПО, при котором анализируется интерфейс прикладной программы (API).
4. Интерфейсное тестирование. Это тестирование и проверка взаимодействия системы с пользовательским интерфейсом (GUI).
5. Тестирование безопасности. Этот вид тестирования подразумевает проверка системы на наличие уязвимостей и защищенность от внешних угроз.
6. Нагрузочное тестирование (load testing). Оценка ПО при плановой, повышенной и пиковой нагрузке. Ресурсы системы конечны и такое тестирование позволяет избежать связанных с нагрузкой инцидентов после ее внедрения.
7. Стресс-тест (stress testing, стрессовое тестирование) – проверка работы ПО в критических условиях, процесс тестирования на стресс: миграция данных из другой системы в больших объемах, загрузка большого количества данных, нехватка памяти или дискового пространства. Как пример, также проверяется, как будет работать ПО, когда им одновременно начнет пользоваться много новых пользователей.
8. Тестирование стабильности. Проводится для проверки реакции программного обеспечения на взлом и другие угрозы безопасности. В этом случае проверяется, насколько стабильно и надежно приложение работает в связи с возможными атаками и нарушениями безопасности.
9. Нефункциональное тестирование. Нефункциональный тип относится к проверке нефункциональных нюансов программного приложения. Это может включать тестирование, например, производительности, совместимости с различными окружениями и другими системами.
10. Юзабилити (usability testing) - это метод тестирования удобства. Согласно ему проводится со стороны пользовательского интерфейса тестирование удобства пользования операционными системами.
11. Тестирование совместимости. Направлено на проверку реакции ПО на различные окружения, другие системы и компоненты. Тестировать совместимость нужно, чтобы убедиться, что приложение может без проблем работать в разных условиях и взаимодействовать с другими системами.
12. Тестирование Черного ящика. Осуществляется путем тестирования приложения через интерфейсы, доступные пользователю. В этом случае тестируется функциональное и нефункциональное оснащение приложения, не затрагивая его внутренний код или структуру.
13. Тестирование Белого ящика. Предполагает доступ к исходному коду программы и тестирование его внутренних компонентов и логики. Этот подход позволяет более точно выявлять ошибки и неоднозначности в реализации логических цепочек программы.
14. Альфа-тестирование. Проводится для имитации работы программного приложения в реальных условиях использования. Целью этого тестирования является оценка работы приложения и его функциональности в контексте реальных сценариев использования.
15. Бета-тестирование. Выполняется с целью проверки приложения на наличие минимального количества ошибок перед его окончательным выпуском или публикацией.
16. Тестирование Регресс (формат регрессионного тестирования). Проверяет ранее найденные ошибки после внесения изменений или доработки кода. Целью этого тестирования является убедиться, что исправления ошибок не повлекли появление новых проблем.
17. Дымовое тестирование (smoke testing). Проводится для проверки работоспособности приложения в момент его запуска. Это своеобразный первичный тест, чтобы убедиться, что приложение может успешно запуститься и функционировать в основных сценариях использования.
18. Acceptance testing, или тестирование приемки, направлено на убеждение, что продукт готов к использованию и соответствует ожиданиям заказчика.
19. Ручное тестирование: проводится без использования дополнительных инструментов, где тестировщики имитируют действия пользователей вручную.
20. Автоматизированное или электронное тестирование. Осуществляется с использованием специальных программных средств и инструментов для автоматизации тестовых сценариев. Для автоматизации тестирования могут применять также сервисы.
21. Динамический анализ кода. Включает анализ исходного кода программы в процессе ее выполнения. Это позволяет выявить проблемы в коде, возникающие во время работы приложения, и обеспечить его стабильность и надежность.
22. Статический анализ кода. Проводится без реального выполнения программы и позволяет обнаружить дефекты и проблемы в коде до его запуска. Этот подход позволяет выявить потенциальные ошибки и недочеты еще на этапе разработки приложения.

Также следует учесть классификацию тестирования по фазе жизненного цикла:

• Тестирование в процессе разработки (Development Testing): проверка на ранних стадиях разработки для обнаружения поломок.
• Тестирование перед выпуском (Release Testing): финальное тестирование перед выпуском продукта.
• Тестирование после выпуска (Post-Release Testing): тестирование после выпуска для обнаружения дефектов и улучшения продукта.

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

Тестирование включает различные процессы на разных уровнях, которыми управляют тестировщики.

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

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

Вот некоторые из основных уровней тестирования:

1. Модульное тестирование (unit testing). Проверяет отдельные модули или компонентное наполнение ПО на корректность их функционирования. Тесты проводятся над отдельными функциями, процедурами или классами.
2. Интеграционное тестирование. Проверяется взаимодействие и взаимосвязь между различными модулями или компонентами программного обеспечения. Цель — убедиться, что они работают вместе и взаимодействуют без ошибок.
3. Системное тестирование. Проводится на уже интегрированной системе в целом. Здесь проверяется функциональность, производительность и поведение системы в соответствии с требованиями и ожиданиями.
4. Приемочное тестирование. Выполняется для проверки соответствия программного обеспечения конечным требованиям заказчика или пользователя. Оно проводится с целью получить подтверждение от заказчика о готовности продукта к использованию.
5. Регрессионное тестирование. Выполняется после внесения изменений в готовое ПО для обнаружения новых дефектов или нежелательных побочных эффектов, возникших в результате внесенных изменений.
6. Альфа- и бета-тестирование. Проводятся перед релизом продукта и выполняются соответственно в контролируемой среде разработчика (альфа-тестирование) и в реальной среде пользователей (бета-тестирование). Они помогают выявить проблемы, связанные с использованием продукта в различных сценариях и средах.

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

Требования к тестированию

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

Сюда можно отнести следующие критерии:

• Корректность тестирования. Каждое требование обязательно точно описывает желаемые инструменты и функции.
• Проверяемость тестирования. Требование формулируется так, чтобы существовали способы однозадачной проверки на факт выполнения.
• Полнота тестирования. Каждое описание содержит информацию, которой достаточно разработчику для грамотной реализации того или иного функционала.
• Недвусмысленность тестирования. Сформулированные описания являются понятными. Они трактуются только одним способом. Неоднозначные аббревиатуры и выражения в них отсутствуют.
• Непротиворечивость тестирования. Описание не должно содержать внутренних противоречий. То же самое касается «несоответствий» техническому заданию и иным документам.
• Приоритетность тестирования. Приоритет требования представлен количественной оценкой степени важности.
• Атомарность. Описание нельзя разделить на более мелкие без потери завершенности. Каждое требование описывает всего одну ситуацию.
• Модифицируемость тестирования. Указывает на простоту внесения изменений в отдельные описания или их наборы.
• Возможность отслеживания. Каждое описание имеет уникальный идентификатор. Он помогает обнаружить требование при необходимости.
• Описание не может быть необязательным. Это – явное противоречие самому замыслу требований к тестированию.

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

Дефекты и репорты

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

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

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) отражает степень воздействия дефекта на проект. Тестировщик устанавливает уровень серьезности в зависимости от его влияния на функциональность и работоспособность приложения.

Градация серьезности дефектов включает следующие уровни:

• Блокирующий (S1 – Blocker) - достиг граничных значений
• Критический (S2 – Critical)
• Значительный (S3 – Major)
• Незначительный (S4 – Minor)
• Тривиальный (S5 – Trivial)

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

Градация приоритета дефектов включает следующие уровни:

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

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

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

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

Существует несколько методов тестирования, актуальных для разных тестировочных задач. Основные методы тестирования:

• Тестирование «черного ящика» (Black Box Testing) — вариант, в котором тестировщик ничего не знает о коде или структуре продукта. QA работает с программой как конечный пользователь. Этим методом проверяют функциональное ли приложение и делает ли то, что должно?
• Тестирование «белого ящика» (White Box Testing), также известное как glass box или прозрачное тестирование, — это, по сути, проверка исходного кода. Чтобы протестировать его, нужен опыт, например, в программировании. Тестировщик анализирует блоки системы по отдельности и ищет проблемы.
• Тестирование «серого ящика» (Grey Box Testing) объединяет методы тестирования «белого» и чёрного ящика. Цель этого подхода — найти любые ошибки в пользовательском интерфейсе или в разработке. У тестировщика нет доступа к коду приложения, но он знает общую структуру сервиса и его ограничения.
• Статическое и динамическое тестирование. Описанные выше техники предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который рассчитывается вручную, либо анализируется специальными инструментами.
• Регрессионное тестирование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на ошибки в уже протестированных участках исходного кода. Может быть использовано не только для проверки корректности программы, часто оно также используется для оценки качества полученного результата. Так, при разработке компилятора, при прогоне регрессионных тестов рассматривается размер получаемого кода, скорость его выполнения и время компиляции каждого из тестовых примеров.
• Позитивное тестирование и негативное. Позитивный тест – использование данных или тестовых сценариев, которые предусмотрены для нормального функционирования приложения. Служит для подтверждения того, что программный продукт может выполнять то, для чего его разработали. Негативное тестирование – противоположность позитивного. Его суть заключается в выполнении программой функций или использование данных, которые не предусмотрены ни разработчиками, ни идейным создателем приложения. Например, как отреагирует программа, если в числовое поле ввести буквы.

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

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

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

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

Рассмотрим важнейшие разделы тестовой документации:

• Идентификатортестплана (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).

Среди тестовой документации в обязательном порядке фигурирует Тестовый сценарий (Test case) и чек-лист (Check list).

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

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

ISTQB, международная организация по сертификации тестировщиков. Тестировщиком, работающим в области quality assurance (QA), необходимо обладать глубоким пониманием различных методик и подходов к тестированию. Он выполняет множество задач, включая конфигурационное тестирование. Чтобы стать тестировщиком, нужно не просто выучить все понятия и особенности каждого компонента, важно иметь навыки отслеживать изменения, которые внес разработчик. Для этого используется QC (Quality Center).

Профессия тестировщик

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

Задача тестировщика — обеспечить высокое качество и надежность программного продукта перед его выпуском. Обязанности тестировщика:

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

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

1. Языки разметки и программирования:
   • HTML/CSS
   • Python
   • SQL
   • Java/JavaScript
2. Фреймворки:
   • Selenium
   • Allure
3. Системы автоматизации:
   • Jenkins
4. ПО для управления проектами:
   • Jira
   • Redmine
5. Библиотеки модульного тестирования:
   • Nose
   • SimpleTest
   • Jest
   • Jasmine
   • Chai
   • JUnit
   • Nunit
   • Boost Test
   • Watir
6. Серверы, для запуска легковесных оболочек:
   • Selenoid
   • Docker
7. Инструменты и сервисы:
   • Testmo
   • QA Wolf
   • Testsigma
   • BugBug (bug bug)
   • ClickUp
   • Online Test Pad
   • Lets Test
   • Anketolog
   • Тестов.ру
   • ClassMarker
   • Testix
   • Qzzr
   • Testograf

Важно понимать, что в каждом проекте будет уникальная комбинация стека технологий, отвечающая индивидуальным требованиям. Какой-нибудь веб-проект может работать, например, с таким стеком. Java + Html elements + Selenoid + Allure + Jenkins + Readmine.

Часто задаваемые вопросы

Заключение

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