Комментарии
От читателя: «Судя по вашему блогу, я заметил, что у вас хорошо отточен процесс тестирования ваших проектов. Может быть вы могли бы поделиться технологией работы тестировщика? Вы всегда очень щедро делитесь своим опытом с коллегами».
Проводим аудит QA-процессов, по просьбе коллег
От читателя: «Судя по вашему блогу, я заметил, что у вас хорошо отточен процесс тестирования ваших проектов. Может быть вы могли бы поделиться технологией работы тестировщика? Вы всегда очень щедро делитесь своим опытом с коллегами».
Сибирикс
Сибирикс

Соглашаемся, просим написать поподробнее о том, что интересно. Чуть погодя приходит еще письмо:

Спасибо за готовность проконсультировать. Давайте я опишу наш текущий процесс, а вы укажите на слабые стороны такого подхода, если нужно.

Итак, комментируем, по пунктам из письма.

1. «Менеджер описывает и согласовывает с программистом каждую функцию в бэклоге и в графе „Как проверить“ — описывает действия для достижения для теста».

avatar
Владимир Завертайлов CEO&Founder

Да, пока что всё в точности так. Графа «как проверить» — это и есть тест-кейсы, по которым потом программист будет проверять за собой.

2. «Во время разработки после готовности каких-то элементов — программист сдает тестировщику функцию на тестирование. В Basecamp переносится задача из списка „Программирование“ в список „Тестирование“».

avatar
Владимир Завертайлов CEO&Founder

Если сравнивать с нашими процессами, то у нас тест-кейсы пишутся именно для разработчиков. Почему тестируют сами разработчики перед тем, как отдать фичи тестеру? Во-первых, они больше погружены в проект, а значит, могут выловить такие баги, о которых тестер даже не будет подозревать. А во-вторых, это просто дисциплинирует и подтягивает качество кода (программист старается сделать максимально качественно с первого раза). В Basecamp’e мы задачи не ведем, он для нас «маловат». Задачи фиксируем в JIRA.

3. «Тестировщик в комментариях к задаче описывает ошибки текстом (что? где? когда?) + скриншоты. Уведомляет программиста и менеджера».

avatar
Алексей «Федорович» Ашихмин QA

Приблизительно так. Учет всех багов мы сначала вели в багтеркере, отдельными задачами. Но по большим проектам оказалось удобнее работать с таблицами с общим доступом в гуглдоксах. Для прикладывания скриншотов, кстати, хорошо подходит SSmaker. У нас есть два типовых шаблона для багрепортов: по верстке и по коду. Для верстки колонки называются: «Браузер», «Описание», «Снимок экрана», «Оценка», «Комментарий». Для программной части немного другие колонки: «Приоритет», «Место сайта», «Описание», «Снимок экрана», «Оценка», «Комментарий».

Еще у каждого бага есть свой приоритет, выраженный цифрой от 0 до 5 (например, 0 — критические баги (блокеры), не позволяющие пользователю работать с сайтом, 4 — косяки в текстах). Глядя в такой «пронумерованный» багрепорт, можно понять, насколько готов проект: например, если закрыты все баги до «3», значит, пользователь сможет работать, но время от времени будет натыкаться на некритичные ошибки.

4. «Программист вносит правки и уведомляет, пока менеджер не закроет задачу».

avatar
Владимир Завертайлов CEO&Founder

Всё ок, но тут важно заморозить разработку на время, пока проект тестируется и заморозить тест, пока программисты вносят изменения. Иначе у вас будет эффект постоянного «докидывания» задач в багрепорт, внезапно пропущенные критические баги и нервные разработчики. Или — использовать параллельные вкладки для теста и разработки.

5. «После полной готовности основного функционала (или каких-то крупных модулей) тестировщик проходится по всему сайту и выписывает в список „Правки“ все найденные недочеты по юзабилити, верстке и функционалу».

avatar
Владимир Завертайлов CEO&Founder

Финальный тест у нас обычно проводится тестировщиком и «внешним» руководителем проектов, человеком, у которого, что называется, «глаз не замылен». До этого — не одна итерация тестирования QA, программистами, проверка юзабилити. Чтобы верстка и функционал были адекватны первоначальной задумке, к тестированию подключается дизайнер. Не в качестве еще одного QA, а как «рецензент» реализованного проекта. Вот здесь мы писали об этом подробно.

6. «Cкажите, вы пользуетесь какими-то средствами автоматизации, вроде selenium?»

avatar
Алексей «Федорович» Ашихмин QA

Да, пользуемся. Помогает на больших и сложных проектах, вроде нашего Scrumban.

7. «Мне очень нравится ваш юзабилити чек-лист. У вас есть еще что-то вроде этого? Может быть ссылки на какие-то ресурcы?»

avatar
Эмма Мецкер юзабилити-специалист, архитектор UX-интерфейсов

У нас есть большая таблица с тест-кейсами, прародителя которой мы как-то публиковали на Хабрахабре. Насчет литературы — могу посоветовать сходить по этим ссылкам: [1], [2], [3]. Ну и «Ководство» сюда же.

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

Спасибо автору!