Тестирование с нуля, или Один в поле — тестировщик
Никто:
Абсолютно никто:
Вы — единственный тестировщик в проекте:
Начать наверняка стоит с представления: меня зовут Валерия, я тестировщик в одном из проектов в Ситимобил, и хотела бы поделиться своим опытом.
Приходя в проект, в котором ранее не было тестирования, каждый тестировщик первым делом наверняка задумывается о том, с чего же начать выстраивать грамотный и последовательный процесс проверки качества продукта. В сети есть множество материалов о различных подходах к организации тестирования в проектах, однако ни один из них не претендует на универсальность. Я расскажу о том, как это сделали мы в одном из своих проектов.
Сначала пара слов о том, что мы тестировали. Это платформа, которая готовит и выгружает платежи в бухгалтерские системы, переводит и выплачивает денежные средства партнерам, генерирует закрывающие документы для организаций и индивидуальных предпринимателей, а также обеспечивает электронный документооборот для вышеперечисленных участников.
Иными словами, чистый B2B с упором на функциональность, а не на косметику.
А теперь к стратегии.
*В статье нет описания конкретных инструментов, используемых технологий и прочих технических подробностей проекта.
Планирование
Самый сложный и значимый процесс в любой работе — планирование. На первый взгляд может показаться, что основным субъектом соответствующих активностей следует считать менеджеров проектов, однако это далеко от правды. Грамотное планирование, выполняемое любой из ролей внутри проекта, не только ускорит работу команды, но и поможет предотвратить потенциальные ошибки и трудности. Что входит в планирование:
Сбор информации об объекте тестирования: основная функциональность, архитектура, используемые инструменты и технологии, документация.
Сбор информации о субъекте тестирования: степень вовлеченности в процессы тестирования остальных участников команды.
Сбор информации о методике работы внутри проекта: цикл разработки, методология управления проектом, принципы оценки результатов.
На основании полученной информации мы решили двигаться от большего к меньшему.
Согласно выбранной методологии управления проектом — повсеместно популярной Agile — задачи по тестированию следовало сделать максимально краткими и понятными. Что же касается цикла разработки, то тестировщик участвовал как в формировании требований к задачам (тестирование документации), так и в их реализации (планирование, проектирование и исполнение тестирования).
Мы пришли к тому, что нам нужны короткие задачи на тестирование, идею которых можно сформулировать еще на этапе обращения от заказчика и развить при разработке соответствующей функциональности.
Субъекты тестирования
В проекте обязанности тестировщика не были возложены ни на одного из членов команды: разработчики принимали небольшую часть собранной ими же функциональности быстро и, по большей части, по позитивным сценариям.
Разумеется, согласно небезызвестной пирамиде тестирования, разработчики так или иначе являются субъектами тестирования, однако покрываемый ими уровень проверок едва ли отвечает требованиям к качеству продукта. В противном случае у разработчиков не было бы времени на основную работу, что привело бы к смещению ролей и понижению эффективности. С появлением отдельного тестировщика достичь баланс гораздо легче.
Документация
И самое важное: изучать объект тестирования нужно начинать с ознакомления с документацией. Её ведением зачастую пренебрегают, однако отсутствие документации обычно приводит если не к многочисленным ошибкам, то уж точно к потере времени. Поэтому мы решили для всех последующих задач на разработку составлять соответствующие code-design документы, которые максимально отражали бы требования заказчика. Таким образом мы уменьшили затраты времени на обсуждения внутри команды и сформировали логичный технический документ, доступный и понятный каждому новичку без дополнительных объяснений.
Разумеется, фундаментальное понимание проекта помогает получить информацию об архитектуре продукта. На этом этапе важно составить план для основных и вложенных объектов тестирования, а также необходимых для реализации инструментов. Замечательно, если есть подробная схема с ее описанием, а если нет — это и есть одна из первых задач.
Основная функциональность
Как правило, большинство проектов можно представить в виде структуры из основных и зависимых элементов. Не стала исключением и наша платформа. На этом этапе часто используют ментальные карты древовидной структуры: двигаемся от самых крупных к самым мелким элементам системы, предусматривая возможные связи между последними. Это поможет планировать тестирование с минимальным количеством обсуждений, а также обходиться без подробного описания тестируемых сценариев при их легковесной поддержке.
Итог
Двигаясь от большего к меньшему, анализируя имеющиеся данные и устраняя сложности, мы пришли к вполне простому и понятному плану первичного внедрения тестирования в проекте.
