Всем привет!
Меня зовут Саша, я тестировщик.

Работаю в Студии Т — IT-компания, которая занимается заказной разработкой сайтов, сложных сервисов, мобильных приложений, ведением соцсетей и performance-маркетингом. С фокусом на результат.

У нас в компании одновременно в работе бывает по десять новых проектов и еще множество на технической поддержке. Роль тестировщиков в этих процессах огромная и важная, но часто неоднозначная для заказчиков, особенно при обосновании стоимости работ. Нередко сталкиваемся с возражениями в типе:

делайте нормально и не надо будет тестировать
мы сами пройдёмся, когда будет готово, убирайте тесты из сметы
почему столько часов на тестирование? нельзя было написать автотесты?

И еще больше достаётся менеджерам, если в ходе тестирования всё было окей, сделали новый спринт и после него протестировали не все сценарии.

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

Будет полезно, как с клиентской стороны, для общего понимания процессов, так и небольшим агентствам/командам, чтобы улучшить тестирование проектов.

Процесс тестирования в общем процессе разработки

Возьмём за основу самые популярные этапы проекта при работе по водопаду или итерациями.

Этап «Аналитика и прототипирование»

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

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

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

Этап «Аналитика и дизайн»

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

QA на данном этапе составляет тест-план, тестирует ТЗ и дизайн n-ой страницы, по мере их готовности, а также разрабатывает тестовые сценарии и чек-листы к разделам.

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

Далее, дизайн-макеты и ТЗ к разработке согласовываются с заказчиком и начинается этап разработки.

Этап «Frontend и адаптивы»

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

Если было принято утвердительное решение, то QA тестирует верстку постранично на данном этапе. Здесь также проводится тестирование ТЗ и макетов к адаптивной/мобильной версии сайта, документирование найденных дефектов и контроль их ликвидации.

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

Этап «Backend и адаптив системы»

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

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

Этап «Сдача проекта»

На этапе сдачи проекта проводятся регрессионное, кроссбраузерное, нагрузочное (если необходимо) , **smoke и приемочное тестирование. После того, как все запланированные тесты выполнены и все исправления перепроверены, составляется отчет о результатах тестирования.

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

Постановка задач на тестирование (да и не только)

Перед тем как перевести задачу на исполнителя необходимо убедиться, что задача содержит:

Ёмкое и исчерпывающее название, понять которое можно даже не заходя в задачу
Приоритет
Дедлайн
Описание Если задача простая и все понятно из названия, лучше продублировать/переформулировать в описании еще разЕсли задача большая (по объему) — необходимо ее декомпозировать на подпункты
Ссылки на все ресурсы, необходимые для выполнения задачи (“ссылка на <...> в обзоре” — плохая практика, “проверяем в деве/проде/ветке NNNNN” — норм, но лучше тоже сразу ссылкой)
Скриншоты (если необходимо)
Если задача — баг от заказчика, то необходимо сразу уточнять окружение.

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

Оценка времени на тестирование

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

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

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

локализацию дефекта,
составление баг-репорта,
ретест.

Оценку по тестированию можно и нужно формировать по различным видам тестирования:

позадачная оценка,
оценка на smoke-тестирование,
оценка на регрессионное тестирование и т. д.

Примеры оценок по видам тестирования:

Позадачная оценка состоит из:
— 2–4 часа на написание тестовой документации
— 1–4 часа на тестирование «простой» задачи
— 4–8 часов на тестирование «сложной» задачи
— 1–2 раб.дня на тестирование «сверхсложной» задачи
— более 2 раб. дней может занимать сложное тестирование объемной задачи.
Smoke-оценка: не более 2–4 часов на test/dev стенде, не более 1 часа на prod стенде.
Регрессионное тестирование: 1–5 раб. дней на полное покрытие тестами всей системы.

Тестовая документация

Как это у нас — для каждого проекта создается папка в GoogleДиске, содержащая Тест-план, Тестовые сценарии, Чек-листы, Баг-листы, Сводную таблицу и Отчет по тестированию.

Это полный перечень существующей документации, набор для конкретного проекта может варьироваться в зависимости от сложности проекта. Финальный список используемой документации для конкретного проекта составляется ведущим тестировщиком.

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

Сводная таблица состоит из двух листов:

На первом выводится статистика по количеству успешно пройденных тестов

На втором выводится статистика по статусам найденных багов (исправлено, не исправлено, не воспроизводится и т.д.)

Отчет о тестировании содержит информацию о выполненных действиях и результатах проведённой работы в письменном виде. Отчет составляется на финальном этапе работы над проектом, а Сводная таблица по мере выполнения задач/разделов.

Для получения актуальной информации по какому-либо конкретному разделу/задаче до этапа написания отчета по тестирования, следует обратиться к тестировщику, ведущему интересующий проект.

Про митинг

Один из принципов тестирования гласит: «Тестирование должно начинаться как можно раньше в жизненном цикле разработки»

Этот принцип во многом связан с понятием «цена дефекта», которая существенно растет на протяжении жизненного цикла разработки. Чем раньше дефект будет обнаружен, тем быстрее, проще и дешевле его исправить.

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

Лучший способ разобраться в проекте — наблюдать за ним с момента его «зарождения». А лучший способ поучаствовать в обсуждениях — это получить приглашение на собрание :)

Команду тестирования нужно звать на:

Знакомство команды с проектом,
Митинги по спринту/срезы,
Любые митинги по крупным изменениям.

Послесловие

Тестирование — важный и трудоемкий процесс. Его нужно учитывать заранее и грамотно распределять нагрузку. Если тестирование применяется на протяжении всего жизненного цикла разработки ПО, конечный продукт более стабилен и надежен.

Как и обещал — полезные ссылки:

Тестировщик и его роль в разработке
Почему тестирование занимает так много времени? (вообще обязательно к прочтению, я считаю)
Основные понятия
Виды тестирования

Александр

QA-специалист в Студии Т

Тестирование проектов в заказной разработке или «я не буду за это платить»