x
© 1995-2021 Компания «Инфосистемы Джет»
Почему тестировщик отвечает за продукт наравне с разработчиком ?
Программное обеспечение

Почему послойный дизайн тестов — это новый стандарт проверки ПО и как его внедрить

23.01.2020

Посетителей: 280

Просмотров: 656

Время просмотра: 1.7 мин.

Какие подводные камни существуют в тестировании через пользовательский интерфейс?

 

Почему послойный дизайн тестов — это новый стандарт проверки ПО и как его внедрить?

 

Как работа тестировщика влияет на Time-to-Market приложения?

 

 

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

 

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

 

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

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

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

 

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

 

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

 

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

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

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

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

Для качественной автоматизации достаточно комбинировать подходы в стандартном треугольнике тестирования: 60% unit-тестов, 30% интеграционных и еще 10% тестов от имени пользователя.

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

 

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

 

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

Уведомления об обновлении рубрик – в вашей почте

Беспилотные машины в центре Москвы мы увидим еще не скоро…

По мнению аналитиков из PwC, к 2040 г. в крупнейших городах появится беспилотная транспортная инфраструктура, в которой не будет места водителю-человеку. Наши собеседники — эксперты Центра Сколтеха по научным и инженерным вычислительным технологиям для задач с большими массивами данных Евгений Бурнаев (доцент) и Алексей Артемов (научный сотрудник) — более сдержанны в своих оценках. Сначала необходимо решить инженерные проблемы, разработать законодательную базу и, главное, изменить отношение людей к беспилотным автомобилям.

Мы как саперы — не имеем права на ошибку

Как Сбербанк проверяет на производительность платежную систему для физических лиц

Мифы автоматизированного и нагрузочного тестирования

Каковы основные заблуждения, связанные с автоматизированным и нагрузочным тестированием

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

Каким компаниям нужен проактивный мониторинг сети? Чем проприетарные системы мониторинга отличаются от решений open source? Как выбрать решение?

Система компьютерного зрения окупается за 1–2 месяца

Какой рост продаж может обеспечить ритейлеру внедрение системы машинного зрения

Time-to-Market и технологии тестирования: вопросы влияния

Как Банк «Союз» ускорил Time-to-Market при разработке интеграционной шины для своего кредитного конвейера

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на рубрику






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







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








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

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

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

            Спасибо!

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

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