Home

Автор: Каллум Эйкхерст-Райан (Callum Akehurst-Ryan)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Ниже – инструменты, которые я использовал, и считаю очень простыми в освоении.

Производительность – K6

Сайт: https://k6.io/

Используется для легкого в освоении тестирования производительности API и нагрузочного тестирования.

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

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

K6 – это отдельное приложение, которое можно установить и запускать локально или через контейнер Docker. Оно управляется простыми командами из командной строки. Можно также выгрузить свои ручные запросы API из Postman, и вам не придется писать скрипты с нуля. Как и запросы Postman, запросы K6 можно направить к любому API через http-адрес – вы можете тестировать локальное, тестовое и продакшен-окружения.

Если вы способны создать запрос в Postman, вы легко начнете тестировать производительность с K6.

Безопасность – OWASP ZAP

Сайт: https://owasp.org/www-project-zap/

Используется для сканирования сайтов, поиска уязвимостей безопасности и проведения атак.

OWASP ZAP (Zed Attack Proxy) – это сканер уязвимостей, использующий известные уязвимости и заранее подготовленные атаки для выявления потенциальных уязвимых точек продукта.

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

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

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

Доступность – Axe

Сайт: https://www.deque.com/axe/

Используется для анализа UI на уровне кода с целью поиска проблем доступности.

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

Удобство использования – Flesch-Kincaid Calculator

Сайт: https://goodcalculators.com/flesch-kincaid-calculator/

Используется для оценки, насколько абзац читабелен и понятен.

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

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

Делимся лежащим на поверхности

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

• Расскажите о вашем методе. Поговорите о том, что вы сделали, чтобы найти эту информацию, каким инструментом вы пользовались, сколько времени это заняло, что вы хотели найти. Также можно в общих чертах рассказать об этой области нефункционального тестирования и ее важности для пользователей.
• Расскажите о проблемах. Это похоже на дебрифинг исследовательского тестирования. Расскажите, что вы нашли, в чем могут быть проблемы, и какими техническими деталями вы владеете.
• Упомяните, что это не целевой ориентир и не трагедия. Упирайте на то, что мы прагматичны и рассказываем об этом для общего развития; это информация, на основании которой можно принимать решения. Упомяните, что мы не стремимся, чтобы продукт соответствовал каким-то определенным индикаторам, и что любые улучшения (если они будут) помогут улучшить продукт.
• Свяжите проблему с конечным пользователем. Поговорите о том, как это связано с вашим проектом, и что это означает для конечного пользователя. Может ли проблема производительности вызвать провал демо? Может ли проблема доступности снизить продажи продукта? Поможет ли информация о безопасности повысить уровень уверенности вашей компании?
• Скажите, что это только то, что лежало на поверхности. Сделайте упор на то, что используемый инструмент находит только простые проблемы, и что при дальнейшем тестировании мы можем найти больше. Используйте эти тесты, чтобы начать разговор о проблемах и предположить, что эти области требуют более глубокого тестирования для поиска остальных багов.
• Будьте готовы к игнорированию. Иногда эти проблемы просто не входят в рамки наших задач, или никого не интересуют прямо сейчас. Не отчаивайтесь, попробуете еще в другой раз. Помните, что мы передали информацию, и решение было принято на основании явной информации, а не ее отсутствия, поэтому это тоже хорошо!

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

Обсудить в форуме