В наше время команды тестировщиков проделывают огромную работу, причем в сложных условиях и в сжатые сроки. Это связано с ограничениями в бюджете и беспокойством о безопасности и удобстве использования программ.
Чтобы тестирование было эффективнее, предлагается изменить подход к нему. Например, не тратить много времени на оформление документов, а вместо этого больше времени уделять исследовательскому тестированию. Это поможет находить больше ошибок и проблем в программе, что сделает её качество лучше.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
В этой статье мы рассмотрим, как можно улучшить эффективность тестирования и сделать его проще.
Проблема сжатых сроков
Одна из самых больших проблем, с которыми сегодня сталкиваются ИТ-компании – сжатые сроки разработки. Программисты должны писать код быстро, а тестировщики – быстро адаптироваться к изменениям в функционале приложения и обнаруживать ошибки.
Решение
Необходимо что-то сделать, чтобы повысить эффективность работы тестировщиков.
Это можно сделать за счет применения современных инструментов разработки и автоматизации тестирования. Но обеспечение высокого качества ПО все равно остается сложной задачей. Это связано с тем, что заказчик хочет побыстрее получить продукт, поэтому сроки для разработки и тестирования значительно сокращаются.
Это означает, что тестирование нужно проводить “умнее”. Перестаньте тратить большую часть времени на создание документации. Вместо этого лучше сосредоточьтесь на исследовательском тестировании.
Сокращение документации не приводит к снижению качества. Совсем нет. Тестовые сценарии по-прежнему создаются и выполняются. Умное тестирование требует от разработчиков и тестировщиков планирования, создания и запуска основных модульных тестов, функциональных тестов, приемочных тестов и тестов безопасности.
Однако умное тестирование означает признание того факта, что некоторые тесты важнее других, и поэтому им следует уделять больше внимания.
Примечание редакции: на эту тему есть отдельная статья – “Принцип Парето в тестировании”.
Рассмотрим ситуацию, когда перед agile-командой стоит задача добавить новую функциональность на сайт или в мобильное приложение. В начале спринта команда составляет план тестирования и создает новые тест-кейсы или меняет существующие. После завершения написания кода команда запускает тесты и документирует результаты их выполнения вместе с обнаруженными дефектами.
Если обнаружены дефекты, код исправляется, а тесты проводятся повторно. В некоторых случаях обнаруженные дефекты могут потребовать от команды пересмотреть написанные тест-кейсы, а также код, и, возможно, обновить их. Далее, в случае необходимости, тесты проводят повторно.
Создание и обновление тест-кейсов также требует определенного времени и ресурсов. Если вы запускаете много тестов, автоматизация тестирования поможет сократить время и избежать ошибок.
Большая часть тестовой документации не приносит никакой пользы. Тестировщики должны составлять отчеты только в случае обнаружения дефектов, а не документировать все тестовые сценарии и их результаты. Если результаты тестов отрицательные (т.е. дефектов нет), то нужно переходить к следующему этапу тестирования.
Если результаты положительные (т.е. найдены дефекты), то тестировщики должны задокументировать тест, включая все необходимое для повторного воспроизведения дефекта.
Пример
Представьте, что у нас есть 100 новых тестовых сценариев для конкретного спринта. Все эти 100 тестовых сценариев должны быть изучены и тщательно задокументированы.
Как тестировать умнее?
Скажем, будет определено, что 10 из этих тест-кейсов необходимо перенести для будущего регрессионного тестирования. Возможно, еще 15 тестов провалились во время выполнения, выдав неожиданные или нежелательные результаты. Тогда команде нужно документировать только эти 25 ключевых и неудачных тест-кейсов, а не все 100. Представьте, сколько времени это сэкономит!
Используйте это время для улучшения качества продукта. Если ваша команда применяет автоматизированные инструменты тестирования, чтобы превращать исследовательские тесты в повторно используемые сценарии, это будет большим преимуществом. Благодаря этому повысится эффективность работы и улучшится качество продукта.
Внимание! Перед тем, как тестировщики начнут проводить умное тестирование и перестанут документировать некоторые тесты, важно убедиться, что они полностью понимают цели текущего проекта или этапа разработки.
В методологии Agile это означает понимание целей каждого спринта. Необходимо понять, что нового или какие изменения содержатся в текущем спринте и в бэклоге задач. Тестировщики должны определить, какие тесты необходимы для текущего спринта (и их не обязательно документировать), а также какие тесты потребуются для будущего регрессионного и приемочного тестирования (эти тесты следует документировать тщательно).
Подумайте о том, что было бы важно для конечного пользователя, когда он будет использовать готовый программный продукт. Проведите тестирование и составьте отчеты о результатах для этих важных мест. Но также задайте себе вопрос: в каких местах кода могут возникнуть проблемы, хотя конечный пользователь, возможно, и не заметит ничего?
Эти вопросы помогут разработчикам, тестировщикам и другим участникам команды обратить внимание на ситуации, которые требуют дополнительного тестирования и проверки.
Руководители команды должны определить, какие сценарии тестирования являются ключевыми для каждого этапа работы и требуют повторного тестирования, так как они важны или понадобятся в дальнейшем. После выявления таких сценариев их можно добавить в план для будущего регрессионного тестирования.
В то же время, области кода с низким риском обнаружения дефектов могут быть протестированы один раз, особенно если код стабилен и не повлияет на расширение функционала приложения в будущем. Для таких случаев не требуется создавать дополнительную документацию.
Заключение
Умное тестирование позволяет ускорить разработку программного обеспечения, не жертвуя качеством. Используйте автоматизацию тестирования, выполнение модульных тестов при изменениях кода и регрессионное тестирование. Не тратьте время на документирование ненужных тестов. Вместо этого сосредоточьтесь на исследовательском тестировании, что улучшит качество и ускорит разработку.
Согласны ли вы с таким подходом? Поделитесь своим мнением в комментариях!
Перевод статьи «How to Test Smarter: Explore More, Document Less».