Как тестировать умнее?

Как тестировать умнее?

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

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

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

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

Проблема сжатых сроков

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

Решение

Необходимо что-то сделать, чтобы повысить эффективность работы тестировщиков.

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

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

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

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

Примечание редакции: на эту тему есть отдельная статья – “Принцип Парето в тестировании”.

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

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

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

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

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

Пример

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

Как тестировать умнее?

Скажем, будет определено, что 10 из этих тест-кейсов необходимо перенести для будущего регрессионного тестирования. Возможно, еще 15 тестов провалились во время выполнения, выдав неожиданные или нежелательные результаты. Тогда команде нужно документировать только эти 25 ключевых и неудачных тест-кейсов, а не все 100. Представьте, сколько времени это сэкономит!

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

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

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

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

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

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

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

Заключение

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

Согласны ли вы с таким подходом? Поделитесь своим мнением в комментариях!

Перевод статьи «How to Test Smarter: Explore More, Document Less».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *