10 принципов написания хороших тестов

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

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

Что это значит

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

Зачем это нужно

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

Практические советы

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

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

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

Если не следовать

Если тесты не обнаруживают потенциальные проблемы, они теряют свою ценность.

Что это значит

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

Зачем это нужно

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

Практические советы

• Проектируйте тесты соблюдая принцип атомарности “один тест = одна проверка” или “один тестовый случай — один сценарий”.
• Избегайте длинных цепочек действий, ведущих к одной проверке.

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

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

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

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

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

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

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

• Тестируйте на разных устройствах и в различных средах.
• Используйте техники тест-дизайна: исследовательское тестирование, ad-hoc подходы.
• Развивайте эмпатию к пользователю: “Как бы я себя почувствовал в этой ситуации?”

Если не следовать

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

Что это значит

Сначала необходимо провести тестирование, чтобы убедиться в корректности работы системы и только потом можно попытаться “сломать” систему, чтобы выявить уязвимости и слабые места.

Зачем это нужно

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

Практические советы

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

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

• Используйте креативные техники, например, задавайтесь вопросами вроде “Что если пользователь случайно нажмёт несколько кнопок одновременно?” или “Как система ведёт себя, если запросы идут из разных мест одновременно?”.
• Регулярное обсуждение с коллегами и обмен опытом часто помогает взглянуть на продукт с новых сторон, выявляя дополнительные сценарии для тестирования.

Если не следовать

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

Что это значит

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

Зачем это нужно

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

Практические советы

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

Если не следовать

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

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

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

• DevOps;
• Java разработка;
• Тестирование.

За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, при которых вам может пригодится наша экспертиза, просто напишите нам,

• hello@swcats.kz,
• https://t.me/swcats_kz,
• или через любую форму на сайте.

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