Home

Автор: Мэтт Хойссер (Matt Heusser)
Оригинал статьи
Перевод: Ольга Алифанова

"Не можем ли мы в сообществе разделять функциональное/исследовательское/юзабилити-тестирование и регрессионные проверки?"

(твиттер Мэтта Хойссера)

Недавно я побывал на SauceCon, ежегодной конференции Sauce Labs. Sauce предоставляет платформу (и облачные мобильные устройства при необходимости) для запуска скриптов Selenium. Слушая, как докладчик говорил о "тестировании", не проводя черту между регрессом и функциональным тестированием, я написал об этом твит.

Знаю, знаю, есть множество типов тестирования, а не только эти два, как мог я забыть про тестирование производительности, безопасности, и так далее, и тому подобное! Вот он, ужасный я, "всего лишь" упоминающий "функциональное" тестирование. Ладно, хорошо, но я так-то не об этом.

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

Это не просто тестирование

Один из спикеров говорил о тестировании, как будто это статичная штука. Мы распадались как сообщество, потому что ручное тестирование не заменилось автоматическим. Представьте на минутку, что бы означал "успех" этого мероприятия.

На совещании вы рассказываете о новой функциональности для второго имени. Вице-президент по развитию клиентов хмурится, думая об этой функции. Она размышляет вслух, что будет, если у вас два тезки, но у одного есть второе имя, а у другого нет. В каком порядке они появятся в результатах поиска? Она хватает клавиатуру и начинает печатать. "ОСТАНОВИТЕСЬ", говорите вы. "ОТОЙДИТЕ ОТ КЛАВИАТУРЫ!", потому что это "организация с автоматизированным тестированием. Мы положим этот тест в бэклог, напишем его, и расскажем вам о результатах в следующем спринте".

Надеюсь, такого никогда не произойдет, потому что это идиотизм. В этом смысле "ручное" тестирование не исчезнет никогда. Это исследование того, как ПО ведет себя на самом деле, с целью получения новой информации (в чем хороши люди) будет с нами, пока ИИ не сможет делать это лучше. Насколько мне известно о состоянии дел с ИИ – я не сильно взволнован перспективой.

Это исследование возникает во многих областях продукта, но чаще всего – на этапе разработки стори или сразу после (иногда это называют тест-шагом). Это тестирование стори – не регрессионное тестирование. Это не проверка, что изменение в одном месте вызвало регресс или поломку ПО в другом. Это просто исследование этого конкретного изменения.

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

Теперь перейдем к регрессионному тестированию.

Методы регрессионного тестирования

Люди, говорящие о регрессионном тестировании, часто обсуждают его в терминологии "от и до", или пути пользователя. Это цельный путь. Для коммерческого приложения это авторизация, поиск, страница продукта, добавление в корзину – возможно, нескольких товаров. Это также оформление заказа, иногда называемое "путь к покупке". Существует множество способов проведения регрессионного тестирования – от проверки каждой функции до таких вот пользовательских "от и до". Некоторые компании разрабатывают "тест-кейсы" и подразумевают, что "регрессионное тестирование" состоит из прогона всех "кейсов" приоритета 1 и 2. Чтобы получить 100% тест-автоматизацию, они стремятся автоматизировать все тест-кейсы.

Но компьютеры преуспевают не в том, в чем преуспевают люди. Как сказал архитектор Sauce Labs Solutions Титус Фортнер, вы получаете худшее из обоих миров. Вы теряете мощь человеческой способности замечать что-то необычное, и не пользуетесь способностью компьютера выполнять задачи в параллели.

Во время SauceCon я провел некоторое время с Джошем Грантом, другим архитектором Sauce. В своем обучающем семинаре Джош познакомил меня с новым термином:DOM-To-Database, или тесты D-to-D. В терминах программирования это "полностековые" тесты. Они идут от браузера к микросервису и оттуда к базе данных, а затем назад, изучая отрендеренные в браузере результаты. При этом это не тесты "от и до" в классическом смысле. Вместо того, чтобы начинать с авторизации, они могут сгенерировать авторизационный токен. Предполагая, что навигацию проверяет другой тест, они идут напрямую к нужной странице, делают что-то одно, проверяют результаты и уматывают. Каждый тест может использовать отдельного пользователя с уникальным ID. При такой структуре инструмент проверяет одну важную часть функциональности, делает это быстро и логически изолированно от прочих проверок. Это упрощает дебаг, ускоряет исправления и повторные тесты, и позволяет команде прогонять весь набор параллельно за несколько минут.

Оказалось, термин придуман Титусом. Спасибо, Титус.

Подводя итоги

Все это сказано для демонстрации двух вещей:

1. Проводите черту между тем, что могут делать инструменты, и тем, что могут делать люди, и делайте ее явной, иначе вас ждет боль и отчаяние.

И второе правило, дополняющее первое:

1. Если вы собираетесь частично автоматизировать тестирование, не начинайте с предположений, что то, что делает машина, похоже на то, что делает человек, нацеливайтесь на синтез.