Задачи тестирования в работе системного аналитика. Основы и ключевые аспекты

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

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

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

Какие типы тестов могут проводиться

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

Функциональное тестирование

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

Основные подтипы функционального тестирования:

• Юнит-тестирование (Unit Testing). Этот подтип функционального тестирования сфокусирован на проверке работы отдельных, минимально возможных частей системы, таких как функции, методы или модули. Цель юнит-тестирования – изолированно убедиться, что конкретный компонент выполняет свою задачу корректно.
  Юнит-тесты полезны для раннего выявления дефектов и часто автоматизируются. Например, при разработке интернет-магазина можно протестировать отдельно функцию, которая рассчитывает стоимость товаров с учетом скидки, без необходимости проверять остальные функции.

• Интеграционное тестирование (Integration Testing). Данный вид тестирования проверяет взаимодействие между модулями или компонентами системы, которые ранее были протестированы отдельно. Его цель – убедиться, что компоненты правильно интегрируются друг с другом, обмениваются данными и выполняют свои задачи в связке.
  Например, в интернет-магазине тестирование может включать проверку процесса оформления заказа, где взаимодействуют модуль корзины, платежный модуль и модуль уведомлений.

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

Нефункциональное тестирование

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

Основные подтипы нефункционального тестирования:

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

• Тестирование безопасности (Security Testing). Проверяет систему на наличие уязвимостей, защищенность данных и возможность предотвращения несанкционированного доступа.

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

Smoke-тестирование и регрессионное тестирование

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

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

FAT и UAT тестирование

• Factory Acceptance Testing (FAT). Это тестирование, которое проводится на стороне разработчика до передачи продукта заказчику. Цель FAT – проверить, соответствует ли продукт всем техническим спецификациям, согласованным с заказчиком.
  Например, в рамках FAT разработчики интернет-магазина тестируют его полную функциональность, чтобы убедиться, что он готов к установке в рабочей среде заказчика.

• User Acceptance Testing (UAT). Тестирование, проводимое конечными пользователями или представителями заказчика. Цель UAT – убедиться, что система полностью соответствует ожиданиям пользователей и может быть введена в эксплуатацию.
  Например, для интернет-магазина представители заказчика могут проверить, насколько удобно пользователям искать товары, оформлять заказы и получать поддержку через сайт.

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

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

1. Анализ требований.

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

2. Планирование тестирования.

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

3. Подготовка тестовой документации.

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

4. Проведение тестирования. На этом этапе выполняются различные виды тестов в следующем порядке:

   1. Smoke-тестирование – первичная проверка основной функциональности.

   2. Функциональное тестирование – проверка выполнения требований.

   3. Регрессионное тестирование – проверка стабильности после изменений.

   4. FAT-тестирование – тесты на стороне разработчика перед передачей системы.

   5. UAT-тестирование – проверки с участием целевых пользователей.

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

5. Анализ результатов тестирования.

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

Роль системного аналитика в тестировании

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

Подготовка требований к тестированию

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

• Формулировку требований. Аналитик пишет требования в четкой, понятной и однозначной форме, чтобы минимизировать возможность их неправильного трактования. Например, использование стандартов вроде SMART или шаблонов (Gherkin, BDD) делает требования более структурированными.

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

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

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

Взаимодействие с тестировщиками

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

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

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

• Участие в тест-планировании. Аналитик может помочь определить приоритеты тестирования, подсказать, какие сценарии критически важны для бизнеса и требуют проверки в первую очередь.

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

Оценка исправлений

При внесении изменений в систему аналитик берет на себя ответственность за:

• Проверку соответствия требованиям. Аналитик оценивает, насколько внесенные изменения отвечают первоначальным требованиям. Например, если разработчики изменили алгоритм расчета, аналитик проверяет, сохраняется ли его корректность в различных сценариях.

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

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

Такая работа снижает риск возникновения новых проблем и помогает поддерживать стабильность системы.

Тестирование функционала

Системный аналитик может принимать непосредственное участие в тестировании, что включает:

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

• Совместное тестирование. Аналитик может участвовать в тестировании вместе с бизнес-заказчиком, разработчиками или тестировщиками. Это особенно полезно при проведении User Acceptance Testing (UAT), где важно получить обратную связь от всех участников процесса.

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

Тестирование на примере реальной задачи

Рассмотрим процесс тестирования на примере простой формы регистрации, содержащей поля для ввода имени, электронной почты, пароля и кнопку «Зарегистрироваться». Тестирование проходит в несколько этапов:

1. Smoke-тестирование. На первом этапе проводится быстрая проверка основной функциональности формы. Убедились, что форма открывается корректно, элементы (поля и кнопка) видны, и при вводе корректных данных (например, имя: «Иван», email: « ivan@mail.com», пароль: «Test1234») запрос успешно отправляется, а пользователь видит сообщение об успешной регистрации.

2. Функциональное тестирование. Затем проверяется соответствие формы заявленным требованиям. Например, все поля проходят валидацию: имя не принимает цифры, email проверяется на корректность, а пароль требует минимум 8 символов, включая заглавные буквы и цифры. Также тестируется, что в случае ошибок отображаются понятные сообщения, а при корректных данных запись создаётся в базе.

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

4. FAT-тестирование. Перед передачей формы заказчику разработчик проверяет её готовность. Убедились, что все требования выполнены, сообщения об ошибках отображаются правильно, а форма работает во всех популярных браузерах (Chrome, Firefox, Safari).

5. UAT-тестирование. Завершающий этап – проверка формы конечными пользователями. Например, тестовая группа вводит данные, проверяет понятность сообщений и оценивает удобство использования. После этого собирается обратная связь, например: «Шрифт слишком мелкий» или «Хорошо бы добавить подсказку для пароля».

Подведем итоги

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

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

1. Искусство Agile-тестирования. Чернов Ю. Г.

2. Основы тестирования программного обеспечения. Старолетов С. М.

3. Что такое тестирование. Курс молодого бойца. Назина Ольга

4. Сам себе тестировщик. Пошаговое руководство по тестированию ПО. Досадж Чхави