При рассмотрении термина «осмысленное тестирование» он выглядит как довольно странная абстракция, распространяющаяся на всю цепочку работы с программным обеспечением – от постановки задачи на разработку до деплоя. Что же значит слово «осмысленный» в данном контексте?
Если кратко, то создатель софта должен сосредоточиться на тестировании, приносящем пользу конечному продукту и его пользователям. Есть несколько подходов к осмысленному тестированию. Далее я расскажу о них, методиках, которые включены в эти подходы, и том, как реализовать новые знания в своей работе.
Пирамида тестирования
Я думаю, что все вы знакомы с пирамидой тестирования. В блоге Мартина Фаулера есть хорошее объяснение для данного понятия от Хэма Вока. Если вы согласны с тем, что там сказано, то позволю себе обратить внимание на одном из предложений публикации.
«Несмотря на то, что концепция тестовой пирамиды существует довольно давно, команды все еще пытаются воплотить ее на практике».
Так почему же у команд возникают проблемы с практической реализацией стратегии QA? Ответ кажется простым: нельзя протестировать все, что имеет смысл. Не так ли?
При обработке запроса «пирамида тестирования» в Google вы можете увидеть что-то вроде этого.
Очевидно, что можно рассматривать данное понятие на разных уровнях детализации. Однако со временем вы будете превращать любые абстрактные стратегии QA в собственную реализацию. С моей точки зрения, стратегия QA может быть разделена на три основных блока, описанных в следующем изображении.
Я же хочу объяснить, как, по моему мнению, вы должны реализовывать «осмысленное тестирование», руководствуясь представленными выше категориями. При этом мною будут упоминаться практики, которые в совокупности могут привести к прозрачной и осмысленной реализации стратегии QA (снизу вверх).
Стилистическое и программное тестирование кода
Данная категория является фундаментальной для пирамиды тестирования и, как следствие, бескомпромиссной. Это общеизвестная составляющая тестирования, включенная в стандарты программирования и признаваемая с точки зрения терминологии. Именно на ней и строится наша пирамида.
Всегда следует пытаться охватить проверки наименования и стиля кода, а также бороться с дефектами кода на самом раннем этапе тестирования (насколько это возможно). После этого наступает очередь unit-тестирования и прочих изолированных подходов к проверке продукта, которые могут быть реализованы разработчиком. В идеале данный процесс должен осуществляться перед добавлением исходного кода в GIT-репозиторий.
Причем данный подход должен быть разумным и осмысленным. Нет причин пытаться достичь стопроцентного охвата или строгого соответствия правилам, если это не имеет очевидного смысла для автора кода. Мне нередко попадались проекты, в которых тест блокировал работу, а не оказывал какую-то значимую пользу. Подобные тесты я рассматриваю как фундаментальное условие для перехода к следующим этапам тестирования.
Другой рассматриваемый мною процесс, как часть того самого фундамента пирамиды, – ревью кода. Проверка кода должна стать частью ежедневной рутины, связанной с тестированием софта. Можно отдохнуть от собственных задач и помочь другим членам команды решить их проблемы.
Если выполнять эту работу, как рутинную, ежедневно, то можно получать более чистый и понятный код. Без серьезной базовой проверки вы скорее всего потратите время на исправления, которые будут касаться устоявшихся правил. Потому вновь можно вернуться к теме того, зачем нужна осмысленность во время проведения тестов.
Интеграционное тестирование
Двигаясь вверх по пирамиде, мы переходим от изолированных тестов к более сложным. Интеграционное тестирование для меня всегда основывалось на правильной архитектуре и четко спланированной разработке. Если такие предварительные условия как чистые интерфейсы, контракты, базовые модели данных и API выполняются правильным образом, то ничто не помешает определить высокий уровень интеграционного тестирования с большим количеством моков и симуляций.
Сейчас существует большое количество инструментов, используемых для создания своего стека интеграционного тестирования. Отмечу, эволюцию Swagger, Postman или такой многообещающий облачный продукт как Azure API Management. Последними, но не менее важными, я хотел бы упомянуть известные библиотеки и инструменты типа Faker и прочих.
На этом этапе также должны выполняться проверки зависимости на безопасность, даже если это будет служба от поставщика VSC, управляемая внешняя служба SaaS или инструмент с открытым исходным кодом DependencyTracker.
e2e тестирование
Самая сложная из дисциплин всегда зависит от различных «но». Правильная реализация может позволить работать всей цепочке гораздо быстрее, заранее реагируя на потенциальные инциденты.
Нагрузочное и перфоманс-тестирование (проверка производительности) идеально подходят для этой категории. С их помощью можно ответить на вопросы, которые следует задавать до релиза продукта.
Простота внедрения e2e-тестов в рамках вашего проекта/компании строго зависит от того, как реализованы предыдущие уровни тестирования. По сути, верхушка пирамиды зависима от основания и не может без него существовать.
Однако на этом этапе про изолированные тесты можно забыть. Реализовывать нужно самое необходимое для конечного пользователя. Это позволяет избежать бесконечного тестирования на уровне поддержки продукта.
Expect true to be “truthy”
В заключении я хотел бы начать с пояснения смысла названия этого раздела: «Expect true to be “truthy”. Я думаю, что каждый причастный к разработке делает все необходимое, чтобы иметь высокий уровень QA (насколько это возможно). При этом мы по-прежнему сфокусированы на лучших практиках, а не на осмыслении того, как они реализуются. Именно поэтому тратится время на устранение преград, которые в итоге вынуждают нас делать то, что не приносит никакой пользы.
Мы по-прежнему считаем, что, следуя общим шаблонам, можно сделать продукт лучше. Однако это не так. Нужно перестать считать, что система, работающая в рамках одной реализации, подойдет и для другой. Нужно доказать жизнеспособность этой реализации и потенциальную пользу от расширения текущего решения на остальные случаи, пользу для продукта и конечного потребителя.
Первоначально опубликовано в ТГ канале QA team
