Меня зовут Иван Бормотов. Я много лет работал в агентстве Notamedia, потом руководил ведущим в стране аутсорс-продакшном DigitalWand. Но, что такое качественное тестирование я осознал по-настоящему, только когда основал специализированное QA-агентство Qualitica и с головой погрузился в процессы.
Если вы представляете digital-агентство и пришли к мысли, что пора поднять качество работы на новый уровень, то эта статья для вас.
Я выделяю 4 ключевых этапа, которые проходят digital-агентства в процессе развития. Цифры по численности сотрудников и наименования условные, основаны на моем личном опыте. Итак, вот этапы:
Микро агентство. Команда до 10 сотрудников. Тестировщика в штате обычно нет.
Маленькое агентство. До 30 сотрудников. Появляется первый тестировщик или даже два.
Агентство средних размеров. Коллектив до 70 сотрудников. Компания активно развивается, прорабатываются бизнес-процессы, улучшаются стандарты качества.
Большое агентство. 70 сотрудников и более. Значительно усложняется иерархия отдела тестирования, внедряются новые рабочие инструменты.
Ниже мое видение и рекомендации того, что нужно делать на каждом из этапов для повышения качества работ.
Вы делаете первые шаги в бизнесе. Берете на работу знакомых и всех, кто согласится с вами работать. Заказы тоже берете все, до которых можете дотянуться. Важен каждый клиент и каждый заказ, важна каждая копейка. Мотив сэкономить на тестировании предельно понятен. Я сам проходил через это и видел подобное у других.
Есть два основных подхода, которые используют начинающие компании:
тестирует менеджер;
тестирует разработчик.
Дополнительных расходов на тестирование нет. И это хорошо. Но у такого подхода есть вполне ощутимые недостатки.
Если тестирует сам разработчик, то он проверяет только те сценарии, которые реализовал и с теми тестовыми данными, которые использовал в процессе разработки. Все альтернативные сценарии опускаются. В итоге всплывают ошибки у конечных пользователей.
Если тестирует менеджер, то обычно это делается поверхностно, в перерывах между другими делами. В результате многие нюансы упускаются из виду.
Есть соблазн закрыть глаза на какую-либо проблему, посчитать её не существенной.
Разработчику сложно поставить себя на место конечного пользователя. Для него все работает логично и понятно, а вот у реальных пользователей начинаются проблемы: то не так поле заполнил, то не на ту кнопку нажал — и все сломалось.
В особо экстремальных компаниях тестированием занимается конечный клиент — именно от него приходит большая часть багов. Особенно печально, когда проект — продукт массового пользования и ошибки видят сотни и тысячи пользователей.
Не снимайте с себя всю ответственность. Это ваш бизнес. Тестируйте все сами — хотя бы в самом конце перед отправкой клиенту.
Не успеваете сами — организуйте перекрестное тестирование. Пусть одни сотрудники тестируют проекты других. Делайте рассылку по всем сотрудникам с просьбой проверить проект и написать о найденных ошибках.
Используйте экономные решения: обратитесь к фрилансерам или аутсорсинговым компаниям.
Помните — перфекционизм нужен, когда крепко стоите на ногах. Если микро агентство будет править все, даже незначительные ошибки, то очень скоро основатель может остаться без штанов и без бизнеса.
Ваш бизнес развивается. Появилась некая уверенность в завтрашнем дне. Клиентов все еще немного, и вы цените каждого из них. Вы начинаете понимать, что лучше всего на удержание клиентов и эффект сарафанного радио влияет качество оказываемых услуг. А для этого нужно тестировать то, что делаете.
Вы решаете нанять первого тестировщика в штат, но опыта в найме таких людей у вас нет. Как быть?
Вы можете пойти двумя путями:
Разобраться в вопросе самостоятельно и своими силами найти специалиста.
Обратиться к экспертам.
Когда-то давно я сам пошел по второму пути. Нашел тестировщика с большим опытом и заказал у него отбор и собеседование кандидатов. Бонусом получил тестовое задание, которое до сих пор использую при отборе тестировщиков.
С годами пришел опыт, а вместе с ним появилась и разработанная нами таблица компетенций, которую сейчас даем кандидатам еще до тестового задания. Смотрим на компетенции и решаем — звать сразу на собеседование, дать тестовое или не тратить время и отказать.
Итак, у вас появился первый штатный тестировщик. Обычно на этом уровне тестирование проводят в момент сдачи проекта или финализации какого-то этапа работ. У такого подхода к тестированию есть свои минусы. И самый большой из них в том, что ошибки, найденные на стадии завершения проекта, неминуемо сказываются на сроках сдачи конечному клиенту (так как скорее всего сроки на исправление ошибок не закладывались изначально или закладывались в меньшем объеме). Кроме того:
в условиях сжатых сроков у тестировщика нет времени на внимательное изучение требований и взаимосвязей компонентов. В итоге он тестирует менее качественно;
тестировщик, подключаемый в самом конце проекта, не знает, к кому из команды разработки обращаться с возникающими вопросами;
перед сдачей проекта у всех много дел, и нет времени отвечать на вопросы нового человека — тестировщика.
Как с этим быть? Постарайтесь глубже интегрировать тестировщика в процесс работы, заранее знакомьте его с проектом и требованиями к нему. Пусть он проверяет все задачи по мере их готовности. Так вы не решите все проблемы с качеством, но хотя бы снизите риски срыва сроков по проектам. Пусть тестирует не только проекты под ключ, но и проекте на поддержке — там качество не менее важно, несмотря на то, что задачи кажутся мелкими и неинтересными.
На этом этапе в ваших отношениях с клиентом возникает новая дилемма — требовать ли с заказчика оплату за тестирование? Тестировщик теперь получает зарплату, и вам нужно решить, как вы будете компенсировать эти расходы. Вот два варианта.
Прописать тестирование в смете отдельной строкой. Если вы только начинаете, то у вас могут возникать затруднения с обоснованием этой строки для клиентов. Они уверены, что работа должна сразу делаться качественно и не хотят платить за мифическое тестирование.
Заложить расходы на тестирование в стоимость разработки. Большинству агентств так комфортнее. Клиенты понимают и легко принимают тот факт, что агентство заботится о качестве, имеет в штате профессионального тестировщика и его час услуг разработки теперь стоит столько-то.
Компания растет, штат тестировщиков тоже. Проекты становятся более сложными. Вы понимаете, что с ростом числа тестировщиков общее качество работ сильно не меняется и нужно что-то с этим делать.
Назначить руководителя отдела тестирования, если еще не сделали этого. Пусть этот человек отвечает перед вами за работу тестировщиков. Вложите время и деньги в его развитие — отправьте на курсы и поощряйте различного рода эксперименты. Это окупится.
Интегрировать тестировщиков во все этапы жизни проекта, чтобы они подключались еще на стадии проверки ТЗ или дизайна.
Разобраться в тест-дизайне и перестроить процесс тестирования так, чтобы он начинался с аналитики требований.
Проводить ретроспективу. Анализировать причины пропуска ошибок тестировщиками.
На этом этапе вам пригодятся следующие термины:
тест-дизайн — этап процесса тестирования ПО, на котором проектируются и создаются тест-кейсы (чек-листы) в соответствии с определёнными ранее критериями качества и целями тестирования.
тест-кейс — последовательность шагов, которые необходимо пройти для проверки функционала. Описание каждого шага сопровождается указанием на ожидаемое поведение системы.
чек-лист — список проверок, необходимых для тестирования функционала.
В большинстве проектов, особенно на начальной стадии, достаточно составления чек-листов и последующего тестирования по ним. В отличие от тест-кейсов на составление и поддержку чек-листов нужно значительно меньше времени.
У вас большая команда и вы делаете сложные проекты: банковский софт и вообще любые проекты с кучей интеграций, высокими требованиями к нагрузке и так далее.
Внедрить систему управления тестированием.
Внедрить автотесты на проектах с большим жизненным циклом разработки.
Внедрить нагрузочное и другие виды тестирования.
Назначить тест-лидов на проектах, а, возможно, и тест-менеджеров.
Система тестирования бывает в виде облачного сервиса или программы для установки на свой сервер. Мы в Qualitica используем серверную версию TestRail.
Что может такая система:
хранить требования и тест-кейсы\чек-листы, а также их разные версии;
связывать требования с тест-кейсами\чек-листами;
анализировать тестовое покрытие;
создавать тестовые наборы и выполнять тестовые прогоны;
делать анализ тестовых прогонов;
интегрироваться с баг-трекинг системой;
вести историю отчетности по тестированию;
отслеживать рабочую нагрузку команды для корректировки задач и ресурсов.
С их помощью можно быстро получать результаты тестирования. Например, после изменений в ветке разработки автоматически запускаются тесты и результаты доступны всем участникам. Или, если это юнит-тесты, то ещё на этапе сборки версии приложения разработчик получает результаты прогона.
В работе над проектами с высокими требованиями к безопасности и надежности не обойтись без выполнения специализированных видов тестирования. Таких, например, как нагрузочное тестирование и тестирование безопасности.
Не буду вдаваться в детали и рассказывать о проведении подобных тестов (в интернете достаточно информации). Скажу лишь, что такое тестирование способны проводить тестировщики, а не только разработчики или системные администраторы, как некоторые почему-то считают.
Это лидер команды тестирования. Прежде всего тест-лид отвечает за Контроль Качества (QC). Вся полнота информации о качестве тестируемого продукта сосредоточена именно у тест-лида. Он выстраивает процесс тестирования команды и сам занимается тестированием. Тест-лид — связующее звено между менеджментом и командой.
Менеджер организует работу нескольких тест-лидов и получает от них актуальную информацию о качестве продукта. Выстраивает процесс тестирования. Чаще находится вне команды тестирования: не глубоко вникает в детали, а сосредоточен на процессе. Тест-менеджер формулирует задачи для тест-лидов. Тест-менеджер это уже уровень тестирования под кодовым названием QA (Обеспечение качества).
Если до этапа большого агентства тестирование в основном проходило на уровне Testing, то есть реактивно (сделали продукт-протестировали-нашли ошибки-исправили), то в большом агентстве тестировщики уже должны работать на более высоких уровнях QC и QA, действуя проактивно на всех этапах разработки продукта.
QC (Контроль качества) — совокупность мероприятий контроля соответствия разрабатываемого продукта и сформированных к нему требований.
QA (Обеспечение качества) — совокупность мероприятий в процессе разработки продукта направленных на обеспечения необходимого уровня качества.
Контроль качества (QC) ориентируется непосредственно на исполнение, то есть на предоставление информации о качестве уже созданного продукта, опирается на уже созданный процесс тестирования. А Обеспечение качества (QA) занимается предотвращением появления ошибок в процессе разработки продукта и ориентируется больше на процесс.
Думайте о качестве всегда, вне зависимости от размера вашей компании. Будет плохое качество — ваш бизнес долго не продержится.
Развивайте внутренний отдел качества последовательно и соответственно этапу, на котором находится ваше агентство. Не пытайтесь сразу все сделать на высшем уровне, ведь небольшим студиям не нужны продвинутые механики и крутые тестировщики. Достаточно осознанно тестировать то, что вы делаете сейчас.
Не пытайтесь хантить крутых тестировщиков на ранних стадиях развития компании. Им у вас будет скучно, и вы их потеряете еще до того, как компания сможет выйти на следующий уровень.
Не хотите развивать свой отдел? Найдите хороших партнеров по тестированию, например, приходите к нам в QA-агентство Qualitica. Партнер-тестировщик, как правило, имеет узкую экспертизу и опыт тестирования самых разных проектов. Например, у такого партнера может быть опыт тестирования калькуляторов ОСАГО и ему не придется разжевывать все нюансы. Или такой партнер может быстро внедрить авто тестирование на проектах, потому что ему (в отличие от штатных тестировщиков) не придется доучиваться по ходу дела. Не менее важно и то, что у профессионального агентства тестирования большой штат и есть возможность быстро заменить специалиста в случае его болезни, отпуска или увольнения.
Автор: Иван Бормотов, руководитель Qualitica.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.