Что такое тестирующая программа и как ее написать

Содержание

Введение

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

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

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

Отношение к тестированию требований на проектах

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

Писать Тесты в Python – проще чем Ты думаешь!

1. Группа А: лучшие практики в деле

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

Вопросы сводятся к минимуму.

2. Группа Б: успеть все

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

3. Группа В: все усилия на разработку

Если указаны требования трехлетней давности – ты счастливчик, даже если этот функционал менялся уже 3 раза; у команды есть хоть какое-то понимание, как должна работать система. Большую же часть требований, раскиданных по чатам, приходится долго и упорно их искать (при этом со временем и сообщения из чата теряются, особенно при использовании бесплатной версии Slack).

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

Выпуск 1. Модульные тесты — что такое модульные тесты и для чего.

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

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

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

1. Четкость и ясность

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

Вы начали читать требования, и уже с первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это плохо. После прочтения документации не должно быть вопросов. Совсем. Требования – это как свод законов для продукта, а законы не допускают двусмысленность, «воду» и неточности.

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

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

Тестировщик не понимал, по каким критериям проверять данное поле, и тоже начал расспрашивать аналитика.

Последствия:

затраченное время нескольких членов команды;

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

Как тестировать:

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

Дальнейшее («более глубокое») исследование требует гораздо больших временных затрат.

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

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

Другой разработчик вернул кнопки на прежние позиции согласно документации.

Последствия:

время нескольких членов команды потрачено впустую;

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

Как тестировать:

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

Основные принципы тестирования требований

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

Итог

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

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

Источник: quality-lab.ru

Тест-кейс: что это и как его написать

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

Какая тестовая документация бывает

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

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

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

Оформление подписки.
Просмотр витрины фильмов.
Запуск продолженного просмотра.

А тест-кейс — детализированный план того, как проверить определённое требование к программе. Например, когда проверяем оформление подписки, шаги тест-кейса могут выглядеть так:

Авторизоваться в приложении Кинопоиска как пользователь без подписки.
Нажать на кнопку «Оформить подписку».
Ввести данные карты и код из смс.
Подтвердить оформление подписки.

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

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

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

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

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

Из чего состоит тест-кейс

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

Когда тестовая документация не нужна

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

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

Даниил Скляров, инженер по тестированию в Яндексе

Источник: academy.yandex.com

8 best practices по автоматическому тестированию

Зачем нужна Automated Test Strategy

Представьте, что вы разрабатываете систему, которая берет заказы из ERP-системы компании и размещает эти заказы у поставщика. В ERP у вас есть цены на ранее заказанные товары, но текущие цены могут отличаться. Вы хотите контролировать, размещать ли заказ по более низкой или более высокой цене. У вас сохранены предпочтения пользователей, и вы пишете код для обработки колебаний цен. Как бы вы проверили, что код работает так, как ожидалось? Скорее всего:

Создадите dummy заказ в экземпляре ERP менеджера (предполагается, что вы настроили его заранее).
Запустите свое приложение.
Выберите этот заказ и запустите процесс размещения заказа.
Соберите данные из базы данных ERP.
Запросите текущие цены из API поставщика.
Переопределите цены в коде для создания определенных условий.

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

тест сценарии

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

Перейдем к лучшим практикам:

1. Сохраняйте правильное отношение

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

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

2. Выберите правильный тип теста

Разработчики часто не любят автотесты, тк им нужно «мокать» кучу зависимостей только для того, чтобы проверить, что они вызываются в коде. В качестве альтернативы разработчики сталкиваются с high-level тестом и пытаются воспроизвести каждое состояние приложения, чтобы проверить все варианты в небольшом модуле. Эти шаблоны непродуктивны и тратят ваше время зря, но мы можем избежать их, используя различные типы тестов, для различных задач.

Какие типы тестов бывают?

типы автоматических тестов

На картинке выше описаны 5 распространенных типов тестов. Ниже опишем в чем суть каждого из них:

Unit тесты

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

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

Интеграционные тесты

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

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

Функциональные тесты или E2E

Функциональные тесты — это тесты всего приложения, также известные как End-to-End(E2E) тесты. Вы не используете прямые вызовы. Вместо этого все взаимодействие происходит через API или пользовательский интерфейс — это тесты с точки зрения конечного пользователя. Тем не менее инфраструктура все еще мокается в этом случае.

Canary тесты

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

Load тесты

Load тесты юзаются для проверки пропускной способности вашей инфраструктуры. Обычно они выполняются на отдельной инфраструктуре.

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

3. Разделяйте типы тестирования

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

Эти тесты отличаются в следующем:

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

4. Запускайте тесты автоматически

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

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

5. Пишите только необходимые тесты

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

Если вы знакомы с пирамидой тестирования:

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

Считается, что минимально допустимым в современном программировании есть 80% покрытие юнит тестами, 10% интеграционными тестами и 5 процентов E2E тестами.

Стоит помнить, что для большинства приложений стремление к 100% покрытию кода добавляет много утомительной работы и лишает удовольствия от работы с тестами и программирования в целом, как пишет Мартин Фаулер:

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

6. Играйте в Лего

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

лего в программировании

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

Функциональное программирование

Стоит изучить принципы и идеи функционального программирования. Большинство популярных языков, таких как C, C++, C#, Java, Assembly, JavaScript и Python, заставляют вас писать программы для машин. Функциональное программирование лучше подходит для человеческого мозга.

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

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

Разработка через тестирование

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

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

7. Держите тесты простыми и сфокусированными на главном

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

Иногда я слышу комментарии вроде: «Я ненавижу работать с тщательно покрытым кодом тестами, потому что каждое изменение требует исправления десятков тестов». Это сложная проблема, вызванная тестами, которые не сфокусированы и пытаются тестировать слишком много. Принцип «Делайте одно дело хорошо» применим и к тестам: «Хорошо тестируйте одно дело»; каждый тест должен быть относительно коротким и проверять только одну концепцию. «Хорошо протестируйте одну вещь».

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

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

Структурирования содержимого тестов (обычно структура Arrange-Act-Assert) и именование тестов; затем, самое главное, последовательно следуя этим правилам.
Перенос больших блоков кода в такие методы, как «prepare request», и создание хелперов для повторяющихся действий.
Применение билдера для конфигурации тестовых данных.
Использование (в интеграционных тестах) того же контейнера DI, который вы используете в основном приложении, поэтому каждое создание экземпляра будет таким же тривиальным, как и TestServices.Get() без создания зависимостей вручную. Таким образом будет легко читать, поддерживать и писать новые тесты, потому что у вас уже есть полезные хэлперы.

8. Используйте инструменты, чтобы сделать вашу жизнь проще

Используйте инструменты, чтобы сделать вашу жизнь проще

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

Test runners. Из моего опыта, для .NET я рекомендую xUnit (хотя NUnit тоже хороший выбор). Для JavaScript или TypeScript я выбираю Jest.
Библиотеки для моков. Могут быть моки низкого уровня для зависимостей кода, таких как интерфейсы, но также есть моки более высокого уровня для веб-API или баз данных. Для JavaScript и TypeScript низкоуровневые моки, включенные в Jest. Для .NET. Я использую Moq, хотя NSubstitute тоже хорош. Что касается моков веб-API, мне нравится использовать WireMock.NET. Его можно использовать вместо API для отладки и обработки ответов. Он также очень надежен и быстр в автотестах. Базы данных можно имитировать, используя их копии в памяти. EfCore в .NET предоставляет такую возможность.
Библиотеки генерации данных . Эти утилиты заполняют ваши объекты данных случайными данными. Они полезны, когда, например, вас интересует только пара полей из большого объекта передачи данных, например ID. Вы можете использовать их для тестов, а также в качестве случайных данных для отображения в форме или для заполнения базы данных. В целях тестирования я использую AutoFixture в .NET.
UI automation libraries. Это автоматизированные пользователи для автоматических тестов: они могут запускать ваше приложение, заполнять формы, нажимать кнопки, читать лейблы и т. д. Как вариант можно использовать FlaUI или Selenium для .NET и Cypress для JavaScript и TypeScript.
Assertion библиотеки. Большинство средств выполнения тестов включают в себя инструменты утверждений, но бывают случаи, когда независимый инструмент может помочь вам написать сложные утверждения, используя более чистый и читаемый синтаксис, например Fluent Assertions для .NET.

Источник: bool.dev