Всем привет!
Меня зовут Саша, я тестировщик.
Работаю в Студии Т — 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-специалист в Студии Т