Тестировщик отвечает за продукт наравне с разработчиком

Зачем нужны блок-схемы

Пару лет назад тестировщик с навыками программирования был большой редкостью. Если взять всех тестировщиков, с кем я работал (а это порядка 100 человек), то максимум 20% худо-бедно умели программировать. Сейчас тестирование выбирается из этого болота — большие компании стали обучать сотрудников кодингу и растить их до софт-инженеров. Все поняли, что без этого знания специалисты либо вообще не отлавливают часть багов, либо делают это очень поздно, что замедляет скорость вывода продукта на рынок и заставляет компанию терять деньги.

Тестировщики привыкли работать через пользовательский интерфейс, и это не очень хорошо. Простой пример: есть задача — протестировать автоматический расчет ставки по кредиту. Если идти в лоб — заполнять вручную все поля в приложении и смотреть на его поведение, процесс затянется надолго. Но поскольку за расчет ставки отвечает лишь одна функция кода, гораздо проще посмотреть на ее работу изнутри — залезть в сам код. Если тестировщик не умеет программировать, то не может подобраться максимально близко к объекту тестирования и вместо этого фокусируется на интерфейсных проверках. Чтобы залезть в код, тестировщику приходится прибегать к помощи разработчика. Соответственно, нужно менять майндсет тестировщика, учить мыслить алгоритмами.

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

Что дает послойный дизайн тестов

Тестировщики привыкли писать тесты end-to-end. Для этого они сразу создают все возможные положительные и отрицательные сценарии, а затем добавляют corner cases (тупиковые ситуации — Прим. ред.). Этот подход ведет к появлению серьезных ошибок на этапе проектирования, которые выявляются уже на этапе проверки. В итоге приходится переделывать тестовую модель и заново проводить тестирование, то есть делать одну и ту же работу дважды.

Я рекомендую использовать послойный дизайн тестов. Для этого мы вначале делаем общую схему тестирования, разграничивая проверки на основные и расширенные. Затем начинаем их постепенно проходить, передавая результаты в разработку. Мы не ждем, пока напишут всю логику приложения, а сразу создаем тесты того уровня абстракции, который нам сейчас доступен.

Однажды к нам на проверку пришло 100 юзкейсов, в которых нашли 160 ошибок проектирования. То есть ошибок было больше, чем самих сценариев. Мы внедрили послойный дизайн и разбили работу на этапы. Вначале мы описали базовые слои нашей «пирамиды»: взяли ключевую функцию приложения и разложили ее на составляющие — блоки. Провели ревью этих блоков, оставили корректные и заменили ошибочные. Затем каждый блок разбили на «кирпичи», проанализировали и также доработали их. И только после проработки этого этапа мы приступили к написанию самих тест-кейсов.

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

Как внедрить послойный дизайн

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

Главное, что нужно донести, — теперь за выпуск новых версий продукта отвечают все. Менеджмент, разработчики и тестировщики должны работать сообща. К сожалению, нередко от последних можно услышать: «Мы только проверяем, остальное нас не касается». На мой взгляд, это неправильно. Тестировщик должен отвечать за успех продукта наравне с другими. Только это может по-настоящему мотивировать делать свою работу хорошо.

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

Главная задача тимлида — не мешать. Проблемы возникают, когда руководители начинают насаждать тот или иной метод. Не надо давить авторитетом и говорить людям, как им делать свою работу. Вместо этого предлагайте варианты, рассказывайте о преимуществе и недостатке каждого и помогайте советом, если его спросили. Кроме того, потребность в изменениях должна формироваться внутри команды, чтобы тестировщики сами осознавали необходимость перемен. В таком случае они либо самостоятельно решат, как справиться с задачей, либо придут за советом.

Инструменты для тестирования

Хорошие трекеры и системы управления тестами стоят очень дорого. Например, за лицензию Microsoft TFS или HP ALM можно выложить до 10 000 долларов.

Есть более простые и дешевые инструменты, но их необходимо дорабатывать под задачу. Чтобы кастомизировать тот же TestLink, придется потратить немало времени.

Иногда стоит прибегнуть к самописным решениям. Для их разработки нужно создать хранилище тест-кейсов на метаязыке вроде Gherkin, который будет работать на разных уровнях тестов: от сценарных до компонентных. Реализовать такой инструмент могут разработчики или команда автоматизации тестирования.

Использовать ИИ в тестировании дорого и бессмысленно. В игре X Rebirth есть прекрасная цитата: «Искусственный интеллект умеет обрабатывать разные массивы данных. Генерализированный искусственный интеллект умеет обрабатывать данные по-разному». На сегодняшний день инструменты на базе ИИ решают какую-то однотипную задачу. Тестировщик, несмотря на кажущуюся однообразность его работы, решает большое количество разноплановых задач: понимает потребности бизнеса и соотносит их с логикой приложения, разбивает работу на этапы, применяет к каждому из них правильные техники тест-дизайна и оценивает код с инженерной точки зрения. Столь сложная нейросеть обойдется слишком дорого.

Всегда ли нужно внедрять автотесты

Что можно автоматизировать при тестировании мобильных приложений? Практически все. От эмуляции поведения пользователей с помощью фреймворков Appium и Selendroid до создания unit-тестов и использования библиотеки Espresso, если мы говорим об автоматизации Android. Для других платформ существуют свои инструменты. Главный вопрос: есть ли в этом резон? Особенно с точки зрения финансовой целесообразности. Для качественной автоматизации достаточно комбинировать вышеназванные подходы в стандартном треугольнике тестирования: 60% unit-тестов, 30% интеграционных и еще 10% тестов от имени пользователя.

Главное — донести до разработчиков, что мы не пытаемся любой ценой найти недостатки в их коде. Мы просто помогаем делать качественный продукт для пользователя.