Home

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

В ходе карьеры мне задавали массу вопросов о тест-архитектуре: как начать тестировать, если ничего не делалось годами? Сколько тест-проектов должно быть? Сколько различных типов тестирования нам нужно? Кто должен отвечать за тестирование в процентном соотношении? Как масштабировать тестирование? Как разобраться с большими приложениями? Как разобраться с существующими тестами, если в них черт ногу сломит? Какими инструментами пользоваться? В каком количестве браузеров надо тестировать (их что, больше двух?!)

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

Начиная работу

Первое, о чем я спрашиваю, начиная говорить о старте тестирования для компании:

1. Как у вас организованы процессы? (Agile, водопад…)
2. Какой технологией вы пользуетесь? (Для разработки, существующие тесты, репозиторий кода, контроль кода, таск-менеджмент…)
3. Каковы взаимоотношения между разработчиками и тестировщиками? Они сидят вместе? Делятся кодом? Проводят совместные код-ревью?
4. Каков размер компании?
5. Пишут ли разработчики юнит-тесты?
6. Сколько людей занимается (или планирует заниматься) исключительно тестированием?

Знакомые вопросы? Часть из них я рекомендовала задавать на собеседовании, если вы – соискатель. Конечно, в зависимости от ответов на эти вопросы я предложу различные наборы инструментов и практик (а если я ищу работу, то смогу определить, дадут ли мне профессионально расти и помогать компании в этих обстоятельствах, и чего ожидать от позиции).

Еще ценные вопросы:

1. Что делает ваше приложение или компания?
2. Сколько у вас клиентов сейчас/в планах?
3. Каков текущий потенциальный рост?

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

1. Убеждение руководства в необходимости тестирования. Иногда вам нужно быть в состоянии объяснить высшему менеджменту необходимость в тестировании, чтобы начать его. Они в основном боятся за время и расходы. Учет этих страхов не всегда прост и зависит от конкретной ситуации, но самый важный вопрос тут – это почему мы тестируем. Подумайте над ним – если вы можете на него ответить, с этим будет легко разобраться.
2. Убеждение других сторон. Иногда они знают, что тестирование необходимо, но не знают, с чего начать (подсказываю – юнит-тесты и TDD). Когда у вас еще нет тест-команды, я обычно предлагаю подключить к тестированию разработчиков. Затем было бы неплохо нанять кого-то с опытом тестирования, чтобы он организовывал эти тесты, рассказывал команде о тестировании и начал создавать систему для end-to-end и прочих типов тестирования, или проводить ручные проверки. Однако с момента, когда такой человек появляется, до момента "завелось и поехало" может пройти много времени, и поэтому хорошо, если разработчики начинают заниматься юнит-тестами – в идеале они будут продолжать это делать в любом случае.
3. Поднять и запустить полный фреймворк. В этом случае у компании есть юнит-тесты и/или ручное тестирование, но им нужна помощь в создании фреймворка автоматизации и идентификации других нужд тестирования. Возможно, они чувствуют уязвимости в нынешних тестах и хотят убедиться, что ничего не упустили – или хотят улучшить свою систему (см. следующие два раздела).

Поддержка

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

1. Можно ли снизить какие-либо повторения? (сколько сейчас у вас тестов и каких именно? Если они прогоняются более 15 минут, это можно улучшить)
2. То, что мы тестируем, на самом деле важно? Иногда мы тестируем то, что на самом деле не несет никакой ценности, но отнимает время и средства на внедрение и поддержку.
3. Есть ли не зависящие от нас тесты? К примеру, скачивание чего-то через браузер (если ваше приложение НЕ браузер – это вряд ли нужно тестировать).
4. Не запускаем ли мы устаревшие тесты? Крайне рекомендую поддерживать систему в чистоте, но если функция вернется, у вас должна быть возможность вернуть и тесты для нее.
5. Можем ли мы использовать инструменты для отслеживания проблем, чтобы понять, где нам нужны или не нужны тесты?
6. Подходят ли наши тесты для текущей ситуации? Интеграция тестов с CI/CD в различных ветках означает, что вам надо решить, что прогонять и проверять, и когда именно.

Масштабирование

Горизонтальное масштабирование означает, что вы добавляете машины для тестирования. К примеру, используете облако для тестов в других системах (больше браузеров, мобильные и десктоп-версии, разные операционные системы…)

Вертикальное масштабирование означает, что вы добавляете больше типов тестов (безопасность, доступность, производительность…)

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

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

Двигаясь дальше

Вы настроили один (или больше) тест-фреймворк. Ваша команда (разработчики/тестировщики) управляется с новыми тестами, которые тщательно спланированы и запускаются в структуре CI/CD. Аналитики на стреме и сообщают о любых проблемах и возможностях для улучшения… Можно ли когда-то остановиться с налаживанием тестирования?

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

Что делать, если вы закончили разработку проекта? Вы двигаетесь к следующему. Конечно, кто-то должен остаться для исправления потенциальных проблем и поддержки, но вам не понадобится такая большая команда и такой набор навыков для этой задачи. Я утверждаю, что то же верно и для тестирования. Разработка и тестирование существуют рука об руку – если в разработке меньше перемен, их меньше и в тестировании.

Значит ли это, что больше никто не должен смотреть в сторону этого проекта? Нет, это значит, что вам нужен человек с другим набором навыков. Не лучше и не хуже – другим. Иногда людям нравится присутствовать на старте проекта (я обожаю исследовать и создавать новое), но другие предпочитают поддержку. Это необязательно происходит после масштабирования всего и вся – возможно, вы уже там, где вы должны быть, и дальнейшие инвестиции в тестирование вам не нужны, несмотря на то, что вы располагаете бюджетом. Проблема в том, чтобы определить, так ли это в вашем случае – посоветуйтесь с профессионалами.

Найм правильного тест-менеджера/архитектора

Как я говорила выше, участие тест-эксперта помогает определить зрелость компании и меры, необходимые для улучшения качества продукта, и это очень важно. Как назвать этого эксперта? Тест-менеджер и тест-архитектор должны быть различными позициями, хотя иногда компании используют эти термины с большой долей свободы.

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

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

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

Следовательно, в поиске правильных навыков вы должны четко понимать, что вам нужно. Меня много раз просили определить тестовые роли, провести интервью и даже обозначить уровень зарплаты. Как-то раз мне пришлось рассказывать собеседующим, как меня собеседовать (смешно, но я получила работу). Но об этом в другой раз.

Обсудить в форуме