Техники и инструменты поиска и оформления дефектов

Всё о заведении задач, которые не закрывают как Won`t fix.
Соберем логи, сбросим кеш, поищем границы и дадим полную информацию по воспроизведению. Кодовое название — НЛО (найти, локализовать и оформить ошибку).

На курсе мы будем решать задачи из реальной жизни:

• Залезть на сервер linux, найти нужный лог, изучить стек-трейс. 
• Перехватить сообщение в консоли разработчика. 
• Прочитать ответ, пришедший с сервера. 
• Найти баг кеширования на сервере. 
• Проверить классы эквивалентности и найти баги граничных значений. 
• Локализовать проблему. 
• Выкинуть все лишнее из шагов.

Кому полезен курс 

• 1. Интеграторам 
• 2. Аутсорсу, которых вечно кидают на разные проекты, включая те, где нужны логи, post-запросы и.т.д.
• 3. Фрилансерам по той же причине
• 4. Обычным тестировщикам для развития, чтобы разгрузить разработчиков

Интеграторы 

Интеграторы стыкуют разные проекты: биллинговые системы и CRM, личный кабинет и Дадату... Данные приходят в шину из одной системы и должны попасть в другую. Если что-то куда-то не дошло, нужно четко локализовать баг — где именно информация пропала?

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

• Что такое логи? Где их искать? Куда именно смотреть? Как дорабатывать, если ничего не понятно?
• Как отправить SOAP-запрос? А REST?
•  Как понять, кто именно сломался, если системы интегрированы?
• Как доказать подрядчику, что проблема именно на его стороне?
• Что делать, если ошибку уже пропустил?

Аутсорсинг 

Аутсорс-команда работает на проекте по договору. Время работы самое разное — от пары месяцев до нескольких лет. Хорошо, когда несколько лет в одной команде. Уже знаешь команду, знаешь, что от тебя нужно.

Но если срок работы на проекте — пара месяцев, то кто знает, что ждет тебя дальше? Какие требования предъявит заказчик? Если на тестирование выделен месяц, нет времени начинать учиться. А вдруг там надо читать логи или отправлять soap-запросы, а ты не знаешь, что это такое? А как убедить стороннего разработчика, что надо поправить баг? Мы будем работать над обоснованием.

Баги аутсорс-тестировщика читают люди, которые относятся к новичку с подозрением. Плохо оформленная задача вызывает раздражение: «И зачем их наняли? Ничего же непонятно. А логи где? А подробные шаги? У меня не воспроизводится!». Курс поможет ставить задачи так, чтобы незнакомые люди говорили «Вау, как баг описан! Даже я все понял. Ребята явно крутые». С такой командой захотят работать снова. 

Фриланс

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

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

На курсе мы будем: 

• оформлять баги так, чтобы к ним не подкопались;
• воспроизводить ошибки по невнятным жалобам от пользователей;
• искать баги там, где разработчик посмотреть не догадался;
• «продавать» свои баги. Если заказчик не понимает, почему это баг, он не будет за него платить.

Тестирование остальных проектов 

Если тестировщик не умеет локализовывать ошибку, эта работа падает на программиста. Тестировщик нашел и оформил «как есть». А разработчику самом воспроизводить, собирать логи, искать «корень зла» вместо последствий...

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

После курса вы сможете: 

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

Изучим инструменты 

• Putty - снять статистику, последить за логом 
• WinSCP - забрать лог с сервера  
• Grep -найти нужный стек в логе (linux)
• Cygwin - найти нужный стек в логе (windows)
• Postman - послать POST-запрос на сервер
• Perlclip - сгенерить большую строку текста

Программа курса 

1. Логи 

Я расскажу, что такое логи в целом. Покажу, куда смотреть в стек-трейсе и как использовать grep. Дам доступ к папке с логами на linux-сервере.

Логи — основной инструмент команды разработки. Тестировщик не может воспроизвести баг и несет лог разработчику. Разработчик смотрит в стек-трейс и понимает, в чем проблема. А когда тестировщик сам может туда посмотреть — это круто) 

2. Панель разработчика 

Панель разработчика используют разработчики. Но и нам она бывает полезна:

- получить прямую ссылку на всплывающее окно;
- посмотреть JS-лог;
- ограничить быстрый интернет, словно сидите с телефона;

Рассмотрим полезные для тестирования вкладки. 

3. Локализация 

Если не локализовать баг — его закроют. Он или не воспроизведется, потому что мало нужной информации. Или окажется дублем другой задачи. В локализации помогут:

Принцип лопаты. Как докопаться до истины.
Эффект лентяя. Как вовремя остановиться. 

4. Оформление — шаги 

Что такое баг-трекер и зачем он нужен. Как офомлять задачи.

Шаблон бага.
Шаблон улучшения.

Эффект мышки. Чем меньше, тем лучше
Фишка прямоты. Чем понятнее, тем лучше

Особенности вложения аттачей, типовые ошибки при описании и примеры из жизни тренера. 

5. Оформление — название 

Как правильно оформить название бага и что может вызвать проблемы.

Принцип «Что? Где? Когда?».
Эффект упоротого менеджера.
Теория краткости. 

6. Классы эквивалентности 

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

Рассмотрим: 

• как писать чек-листы;
• как расширять их с помощью классов эквивалентности;
• какие бывают границы.

7. Поиск и доп инструменты  

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

Покажу, как использую любимые исследовательские туры и какие команды из linux-а спасают мне жизнь. 

8. Кэш 

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

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

9. Ретроспективный анализ ошибки 

Поделюсь личным опытом — что помогает именно мне. Расскажу про принцип пяти почему и дам шаблон анализа проблемы.