
softwaretesting
software-testing - профессиональная площадка тестеров, с избытком годного материала по теме а также видеокурсов. Рекомендуем к просмотру...
Всё о заведении задач, которые не закрывают как Won`t fix.
Соберем логи, сбросим кеш, поищем границы и дадим полную информацию по воспроизведению. Кодовое название — НЛО (найти, локализовать и оформить ошибку).
На курсе мы будем решать задачи из реальной жизни:
Кому полезен курс
Интеграторы
Интеграторы стыкуют разные проекты: биллинговые системы и CRM, личный кабинет и Дадату... Данные приходят в шину из одной системы и должны попасть в другую. Если что-то куда-то не дошло, нужно четко локализовать баг — где именно информация пропала?
Тестировщикам в интеграторах нужно уметь собрать всю информацию: логи сервера, логи шины, упавший запрос. Курс идеально подходит для данной области. Пройдя его, отпадет много вопросов:
Аутсорсинг
Аутсорс-команда работает на проекте по договору. Время работы самое разное — от пары месяцев до нескольких лет. Хорошо, когда несколько лет в одной команде. Уже знаешь команду, знаешь, что от тебя нужно.
Но если срок работы на проекте — пара месяцев, то кто знает, что ждет тебя дальше? Какие требования предъявит заказчик? Если на тестирование выделен месяц, нет времени начинать учиться. А вдруг там надо читать логи или отправлять soap-запросы, а ты не знаешь, что это такое? А как убедить стороннего разработчика, что надо поправить баг? Мы будем работать над обоснованием.
Баги аутсорс-тестировщика читают люди, которые относятся к новичку с подозрением. Плохо оформленная задача вызывает раздражение: «И зачем их наняли? Ничего же непонятно. А логи где? А подробные шаги? У меня не воспроизводится!». Курс поможет ставить задачи так, чтобы незнакомые люди говорили «Вау, как баг описан! Даже я все понял. Ребята явно крутые». С такой командой захотят работать снова.
Фриланс
К фрилансерам относятся с подозрением. Как работодателю понять, что тестировщик правда крутой? Что он поможет проекту, а не просто потратит деньги?
Тестировщика-фрилансера нанимают для того, чтобы он искал баги. Баг-репорт - главный показатель уровня тестировщика. Если оформлен непонятно (а читать его может и "большой босс"), доверия нет, кажется, что нанял джуниора. А уж если пропустил баг - пиши пропало. Своему тестировщику простительно, фрилансеру нет.
На курсе мы будем:
Тестирование остальных проектов
Если тестировщик не умеет локализовывать ошибку, эта работа падает на программиста. Тестировщик нашел и оформил «как есть». А разработчику самом воспроизводить, собирать логи, искать «корень зла» вместо последствий...
После нашего курса тестировщик сможет разгрузить разработчика. Сам найдет причину, локализует, соберет всю нужную информацию. И сэкономит время коллег. А это всегда ценно.
После курса вы сможете:
Изучим инструменты
Программа курса
1. Логи
Я расскажу, что такое логи в целом. Покажу, куда смотреть в стек-трейсе и как использовать grep. Дам доступ к папке с логами на linux-сервере.
Логи — основной инструмент команды разработки. Тестировщик не может воспроизвести баг и несет лог разработчику. Разработчик смотрит в стек-трейс и понимает, в чем проблема. А когда тестировщик сам может туда посмотреть — это круто)
2. Панель разработчика
Панель разработчика используют разработчики. Но и нам она бывает полезна:
- получить прямую ссылку на всплывающее окно;
- посмотреть JS-лог;
- ограничить быстрый интернет, словно сидите с телефона;
Рассмотрим полезные для тестирования вкладки.
3. Локализация
Если не локализовать баг — его закроют. Он или не воспроизведется, потому что мало нужной информации. Или окажется дублем другой задачи. В локализации помогут:
Принцип лопаты. Как докопаться до истины.
Эффект лентяя. Как вовремя остановиться.
4. Оформление — шаги
Что такое баг-трекер и зачем он нужен. Как офомлять задачи.
Шаблон бага.
Шаблон улучшения.
Эффект мышки. Чем меньше, тем лучше
Фишка прямоты. Чем понятнее, тем лучше
Особенности вложения аттачей, типовые ошибки при описании и примеры из жизни тренера.
5. Оформление — название
Как правильно оформить название бага и что может вызвать проблемы.
Принцип «Что? Где? Когда?».
Эффект упоротого менеджера.
Теория краткости.
6. Классы эквивалентности
Классы эквивалентности и граничные значения — основные техники тест-дизайна. На границах чаще всего встречаются баги. Не зная о классах, не сможем локализовать баг — в какую сторону думать?
Рассмотрим:
7. Поиск и доп инструменты
Расскажу, как вообще искать баги, что делать, когда больше нет идей и какие дополнительные инструменты помогут в работе.
Покажу, как использую любимые исследовательские туры и какие команды из linux-а спасают мне жизнь.
8. Кэш
Напомню, что такое клиент-серверная архитектура, и дам ссылку на более подробный рассказ. Покажу, где в этой цепочке кэш и как он формируется.
В доп инфо покажу, как отправлять запросы через Postman, а вам предстоит найти баг кэширования на сервере.
9. Ретроспективный анализ ошибки
Поделюсь личным опытом — что помогает именно мне. Расскажу про принцип пяти почему и дам шаблон анализа проблемы.
software-testing - профессиональная площадка тестеров, с избытком годного материала по теме а также видеокурсов. Рекомендуем к просмотру...