Как искать и находить баги

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

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

Регистрация в QA Battle

До конца апреля регистрация на QA Battle остается бесплатной. На данный момент зарегистрировано 500+ человек (это мы еще почти не рекламировались) и мы ожидаем, что будет более 3000 участников (хотелось бы набрать 5000).

Если наберем 5000+ участников - то, возможно, расширим набор призов для тех, кто займет первые 20ть мест в чемпионате (сделаем футболки или медальки/статуэтки на память о вашем участии)

Важная информация: если у вас не получается зарегистрироваться на сайте https://qa-battle.com - откройте этот адрес в приватном режиме браузера и повторите попытку регистрации. Иногда ваш браузер может закэшировать старую версию JS скриптов, в результате чего регистрация может не работать (если вы открывали этот сайт раньше). У новых пользователей регистрация должна работать в штатном режиме. Если что-то не работает - пишите на почту timur@qa-battle.com.

Чемпионат по тестированию QA Battle

Всем привет,

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

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

И вот настало время действовать :)

QA Battle - это уникальный чемпионат по тестированию, в котором у тебя будет шанс проверить свои навыки тестирования и знания тест дизайна.

Сколько вы находите дефектов за неделю?

Всем привет,

подниму немного холиварную тему - сколько должен находить багов хороший QA инженер за неделю?

Я думаю что если QA инженер за три недели не нашел и не зарепортил ни одного бага - то это плохой (или уставший) QA инженер. И не надо тут про то что автоматизаторы не должны репортить баги - они тоже работают с продуктом и тесты тоже иногда что-то находят, особенно если вы пишете хорошие тесты.

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

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

Уже позже, когда я работал менеджеров распределенной команды (большая распределенная команда в 30 крутых QA инженеров) - я по-прежнему продолжал находить баги. Я уже почти совсем не занимался ручным тестированием (то есть таких задач не было) и количество лично мной найденных багов совсем не входило в мой KPI (наоборот каждый раз когда я отвлекался от менеджмента на меня укоризненно смотрели :) ) . - все равно я репортил от 1 до 10 багов в неделю.

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

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

За сегодня нашел и зарепортил 25 дефектов. Почти весь день был потрачен на то чтобы писать тексты репортов об ошибках (хотя конечно же есть шаблоны) - пока подготовишь последовательные скриншоты со стрелочками, пока все опишешь на понятном английском, выделишь нужные фрагменты жирненьким :)

25 баг репортов в день, мой новый личный рекорд :).

А сколько обычно багов репортите вы?

Кстати, у меня появился телеграм канал, подписывайтесь: https://t.me/qa_and_testing

Функциональные тесты превращаются... в тестирование на SQL инъекции!

Всем привет,

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

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

В чем преимущества:

1. Для такой сессии тестирования вам потребуется только настроить тестовое окружение и запустить все функциональные тесты, после чего можно приступать к сканированию на SQL-инъекции. Это не потребует особой квалификации и больше чем несколько часов для подготовки. Вы можете сделать это прямо сегодня!
2. Используем только бесплатные компоненты с открытым исходным кодом.

И так, начнем.

1. Скачиваем и распаковываем SQLmap:

https://github.com/sqlmapproject/sqlmap/wiki/Download-and-update

2. Скачиваем и устанавливаем Burb Proxy:

https://portswigger.net/burp/freedownload/

3. Запускаем Burb Suite, он запустит прокси на порту 8080 (по умолчанию, в UI это можно изменить).

В Burb proxy на вкладке Intercept не забываем выключить Intercept, чтобы он не захватывал запросы, а просто логировал их.

4. Настраиваем прокси на Linux хосте, откуда будем запускать тесты, для этого вбиваем в bash консоль такие команды:

12

export HTTP_PROXY=127.0.0.1:8080
export HTTPS_PROXY=127.0.0.1:8080

здесь 127.0.0.1 - адрес Burb Proxy, 8080 - порт, который слушает прокси. Если вы запускаете прокси на одной машинке, а тесты запускате с другой машинки, тогда вам надо изменить эти параметры. В моем примере все компоненты работают на одной и той же машинке.

5. Запускаем наши автоматические тесты (у меня тесты написаны на PyTest, но это могут быть так же любые другие тесты, главное - убедитесь, что ваши тесты отправляют запросы через прокси - в Burb UI на вкладке Proxy > HTTP History должны появиться новые записи):

pytest -n 30 tests/lbs


6. Переключаемся обратно на Burb UI, переходим на вкладку Target > Site Map, щелкаем правой кнопкой мыши на адрес, куда обращались наши автоматизированные тесты (для каждого тестируемого сервиса здесь будет отдельная строка). В выпадающем меню выбираем пункт 'Save Selected Items' и сохраняем все это в файл test001.txt.

7. Переходим в дирректорию с sqlmap и запускаем сканирование:

./sqlmap.py --batch -l test001.txt

Опция --batch заставляем sqlmap сканировать все, что дали, не спрашивая на каждом шаге подтверждение от пользователя, опция -l указывает SQLmap, что надо брать список "целей" из файла с логами от прокси сервера.

Если вы тестируете не production окружение, то лучше запустить так (это увеличит список проверок, которые сделает SQLmap):

./sqlmap.py --batch --level 5 --risk 3 -l test001.txt

8. Анализируем всё, что выдаст нам SQLmap, открываем баг трекер и записываем результаты эксперимента ;)

Небольшой совет №1:
Создайте различные сущности в своем сервисе и сделайте тесты, которые будут их читать / изменять, чтобы в список запросов попали запросы работы с существующими в системе ресурсами. Если ваши тесты полностью очищают после себя все ресурсы SQLmap будет сложно найти уязвимости, ведь на многие запросы он получит 400/404 ошибки, просто потому что этих ресурсов и ссылок уже не существует.

Небольшой совет №2:
Почитайте вывод команды

./sqlmap.py --hh

Для тех, кто предпочитает делать все через UI - есть возможность установить sqlmap плагин прямо в Burb Proxy (хотя для этого потребуется поставить всякие зависимости, за то красиво):

https://support.portswigger.net/customer/en/portal/articles/2163785-using-burp-to-exploit-blind-sql-injection-bugs

Новый блог :)

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

Вот новый блог (вдруг кому будет интересно подписаться и читать :) ):
https://xwizard-mobile-games.blogspot.ru

PyTest: красивые имена тестов в репортиках

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

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

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

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

Как было - список тестовых сценариев (пример запуска pytest --collect-only):

Как стало - список тестовых сценариев (пример запуска pytest --collect-only):