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

Всем привет!
Меня зовут Саша, я QA-спелиалист в Студии Т.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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