Упорядочиваем виды тестирования — Agile Testing Quadrants
Пока готовлю следующий пост из серии про автоматизацию, захотелось поделиться интересным, на мой взгляд, материалом из книги Agile Testing: A Practical Guide for Testers and Agile Teams.
Так вот, видов тестирования очень и очень многое: нагрузочное, ad hoc, sanity, black box, white box и так далее. И долгое время я не встречал хорошей и понятной, по моему мнению, системы, которая бы содержала нормальную группировку всех этих видов, а так же давала объяснение, когда и зачем какие нужно их использовать. И буквально на днях прочитал про Agile Testing Quadrants (ATQ), про которые и хочу рассказать.
Идея данной систематизации изначально принадлежит Brian Marick, а затем была доработана Lisa Crispin, которая является одним из авторов упомянутой книги. По ссылкам можно найти их записи про ATQ.
Собственно сама система выглядит вот так:
Как видно, классическая диаграмма 2*2. Итак, по одной из осей тесты делятся на бизнес-ориентированные и технологически-ориентированные, по другой оси — на тесты для поддержки команды и для «критики продукта». Сразу хочу отметить, что нумерация ничего не говорит о том, когда нужно проводить эти тесты.
Пройдем по каждому из секторов.
Сектор Q1 представляет собой такую известную практику, как TDD. Все просто: сначала тесты, потом код. И эти тесты в первую очередь ответственность команды разработки. Все эти тесты обязательно должны запускаться через CI, для постоянной проверки качества кода. Все это расписано во многих источниках, для тех, кто еще не практиковал TDD, хочу посоветовать вот эту ссылку.
Сектор Q2 содержит в себе более высокоуровневые тесты, которые уже имеют отношение к бизнесу. Успешное прохождение этих тестов является обязательным, чтобы говорить о завершенности какого-либо функционала. Потому что мы можем говорить, что тот или иной функционал сделан, когда он решает одну из поставленных бизнес-пользователями задач. На этом уровне в основном тестируется внешняя оболочка приложения: интерфейс, API, веб-сервисы и так далее. С другой стороны, этот сектор включает в себя тестирование прототипов, мокапов, дизайна и так далее. Часто для обозначения тестов, входящих используют термин приемочное тестирование, хотя это не совсем верно, так как тесты из секторов Q3 и Q4 так же стоит отнести к приемочному тестированию.
Тесты из сектора Q3 подразумевают обязательное участие экспертов в доменной области, экспертов по usability, пользователей и так далее. Так уж часто бывает, что реализованный функционал на самом деле не решает проблемы заказчика, или же что-то было понято неправильно командой разработкой. Опять же, могли возникнуть новые аспекты работы с доменными объектами или выяснилось, что спроектированный интерфейс не удобен пользователям. Как раз тут и вступают в дело тесты, предназначенные для «критики» продукта. Сразу оговорюсь, что слово «критика» здесь имеет положительный оттенок. Само собой, что данное тестирование может быть только ручным, потому что ни один скрипт не может выявить обозначенных проблем, хотя мы, конечно, можем использовать вспомогательные средства, например, для загрузки данных.
И, наконец, последний сектор Q4, который говорит о тех тестах, которые не проверяют решение задач бизнеса, а говорят о том, насколько же хорошо написано наше приложение, используя такие термины как безопасность, производительность, устойчивость, масштабируемость и так далее. Данные тесты помогут, как проверить соблюдение нефункциональных требований, если они есть, так и понять, насколько успешно спроектировано приложение уже на ранних этапах. Эти тесты сильно помогают избежать проблем в будущем. Понятно, что для проведения подобных проверок, нужно использовать специальные инструменты, которых представлено на данный момент очень много.
Таким образом, Agile Testing Quadrants являются неким чек-листом, показывающим, что мы идем в верном направлении, что наши процессы в достаточной степени автоматизированы и можем заниматься ручными исследовательскими тестами. И самое главное, Agile Testing Quadrants покажут, насколько успешен наш продукт, с точки зрения бизнеса.
Thanks for referencing my blog post!
This looks so interesting, wish I could read it, do you have it anywhere translated to English? (What language IS this?)
Hi Lisa!
First of all thanks a lot for the great book you wrote and your blog too.
In this blog post I
ve introduced your and Brian Marick system of Agile Testing Quadrants and translated them into Russian.Currently, there are not so much information about agile testing (and QA in Agile as well), so Im trying to collect information and create some point of view how to test in Agile. My position is first of all developer position, but I`m also have scrum master role in our team, so QA processes are very important for me.
So I plan to write post about Agile testing concepts and practices that work in my project and my colleagues projects.
Will be it OK to make some translations of your materials in fututre?
Hi Andre, it would be great if you can translate more of my work, it’d be nice to share my experiences with more people! I looked at the Google translation of your post and it’s really good! I’m told our book is available in Russian, though I myself don’t have a copy. I’m so glad concepts like the Quadrants are being used in more places, I’ve found them really helpful.
Thank you very much!
Yeah, your book «Agile Testing» is available on russian, but I prefer to read IT-related book in the original.
I`m currently working on several posts about QA Automatization, especially how to use Selenium 2 with TestNG to create UI autotests framework. If it is interesting for Agile QA Community I can make a translation in English and post it somewhere.