Сайт находится в состоянии доработки. Извиняемся за неудобства.

x
© 1995-2019 Компания «Инфосистемы Джет» Разработано в Liqium

Практики тестирования

За последние 40 лет в тестировании не было кардинальных изменений. Фундаментальные идеи появились еще в те времена, когда тест-сет представлял собой напечатанный на бумаге документ. Чтобы получить еще один экземпляр тест-сета, его достаточно было пропустить через копировальный аппарат. Основные принципы проверки кода, разработанные в начале 1980-х годов, можно успешно применять и сейчас. Например, тестирование, управляемое данными.

 

Лучшие практики тестирования возникли в начале нулевых, когда оно вышло на массовый рынок. Однако именно в этот момент специалисты «распустились»: для работы им стало достаточно освоить тестовый интерфейс. Вместо головы начали думать руками, и фундаментальные знания обесценились.

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

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

 

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

Теги

Реклама

 

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

6000 рублей в среднем стоит баг, найденный на позднем этапе тестирования. Такую цифру назвал Федор Зволинский в своем выступлении «Проблемы управления тестами» на Avito Automation Meetup в 2017 г.

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

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

Следите за нашими обновлениями

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Оформить
подписку на журнал
Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Ваш комментарий отправлен.
После прохождения модерации комментарий будет опубликован на сайте.
Оставить
комментарий
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня