Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Я размышлял над статьей о тестировании, разработке ПО и их взаимоотношениях с автоматизацией. Я все еще думаю ее написать, но в ходе размышлений у меня родилась другая идея.

Меня спровоцировала одна из статей на LinkedIn с броским заголовком, но сомнительным содержанием и спорными утверждениями. В этой конкретной статье автор высказывал одно из "вечнозеленых" заблуждений об автоматизации и тестировании (не буду давать ссылку – не потому, что я не уважаю автора, а просто потому, что считаю множество допущений там ложными, и не хочу делиться ими со своей аудиторией). Оно звучало так:

"Инженер-автоматизатор просто старается автоматизировать повторяющиеся нудные задачи ручного тестировщика, чтобы они выполнялись программно без посторонней помощи".

Нравится вам это или нет – это определение вы будете часто слышать, спрашивая людей о цели автоматизации, или о том, почему им нравится ей заниматься. И это утверждение… ЛОЖЬ!

Если интересно, почему я так думаю – посмотрите эти статьи:

https://mrslavchev.com/2016/06/14/test-automation-the-bitter-truth/

https://software-testing.ru/library/testing/general-testing/2446-the-non-manual-unautomated-tester

https://www.software-testing.ru/library/testing/testing-automation/2896-about-automation-why-automation-2

https://software-testing.ru/library/testing/testing-automation/2818-the-missing-link-between-testing-and-automation

и небольшая заметка про "ручное тестирование": https://mrslavchev.com/2017/12/11/manual-testing-never-existed/

Как можно видеть, я достаточно разорялся по поводу вопроса, почему мы не должны складывать все яйца в корзину с наклейкой "тест-автоматизация".

Нет, я твердо убежден, что автоматизация приносит пользу – она может расширить наши возможности, но только если мы знаем, как этим инструментом пользоваться. Заявления вроде вышеприведенного демонстрируют серьезную проблему с основным положением – в чем польза от автоматизации.

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

Нудные задания, говорили они

Давайте разберемся с этим раз и навсегда. Если вы когда-либо почувствуете, что ваша работа нудна и скучна, уходите с нее. Вы просто для нее не подходите. Если вам скучно, потому что вам нужно повторять одно и то же снова и снова, не делайте этого – найдите новый подход, подумайте над новым сценарием, и таким образом докажите, что повторение неэффективно.

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

Правда, ее можно таковой сделать, создавая тест-кейсы и слепо им следуя, оставляя свое критическое мышление за порогом, или, что еще хуже, некритично следуя чужим кейсам, не приходя в сознание. Это не тестирование ПО, это посредственное тестирование, и попытка автоматизации посредственного тестирования не создает превосходное тестирование – в результате получится автоматизированная идеократия.

В чем настоящая цель автоматизации?

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

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

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

Но какой информации?

Известные известные

Недавно я делал презентацию "Ретроспективные уроки автоматизации UI" и показал эту схему:

(с) Viktor Slavchev

Вкратце: тестирование – это в целом поиск знаний о продукте.

Знание поступает в различных формах?

• Мы знаем, о чем мы знаем – что-то из этого непременно окажется ложным, вне зависимости от того, знаем мы об этом или нет. Если мы достаточно умны, мы это как минимум подозреваем.
• Мы не знаем, что мы знаем – это можно сформулировать как "неявное" знание, то, что мы делаем интуитивно, или как минимум не давая явных определений – например, езда на велосипеде или печать на клавиатуре.
• Мы знаем, о чем мы не знаем – и мы пытаемся атаковать эту область, чтобы переместить ее в раздел "известного известного".
• Мы не знаем о вещах, о которых мы не знаем – и это огромный океан невежества, недостатка знаний или опыта, который мы можем рассмотреть, или же оставить его там навсегда.

Забавно тут то, что автоматизированные проверки живут в области того известного, о чем мы знаем. По различным причинам мы не можем автоматизировать неявное знание, а также то, о чем мы не знаем. Поэтому автоматизированные проверки помогают нам проверять валидность уже известных фактов. И это уже неплохо!

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

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

Мы называем "сюрпризами" только приятные вещи

Если сюрприз неприятен, мы называем его проблемой. А мы не хотим, чтобы в нашем продукте были проблемы. Следовательно, мы готовы использовать любую возможность для отслеживания и удаления непреднамеренных изменений. И тут автоматизированные проверки тоже могут сильно пригодиться, проактивно отслеживая перемены.

Отслеживать изменения можно по ряду причин:

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

Предсказуемость

Когда я запускаю робот-пылесос в гостиной, я делаю это не только потому, что хочу заменить обычный пылесос. Я часто это делаю, потому что робот предсказуем – он снова и снова использует одинаковый алгоритм, он чистит комнаты в одном и том же порядке, стартуя в одной и той же точке. Я точно знаю, что он чистит полы в квартире в течение примерно 38 минут. Заметьте, я сказал "полы" – не окна, не диван, не пыль на шкафу, не паутину над кроватью, только полы. Он также ничего не знает о рисках и неожиданностях вроде залетевшего в комнату голубя, нагадившего на пол, или домашнего животного, которое начинает гоняться за ним или сидеть на нем. Бросьте носок перед роботом – и он навсегда погиб, пока вы не вытащите носок.

Этот пример я привожу вот для чего – я запускаю робота, потому что он прост и предсказуем, но он также очень примитивен. Нельзя ждать, что он справится с чем угодно, но это нормально – не ожидать, что он взлетит к потолку и уберет паутину.

Этого просто недостаточно

Как можно видеть, автоматизированные проверки – все же хорошая штука. Они полезны, когда используются правильно, но их никогда не бывает достаточно. Они живут в маленьком загончике "известных известных", и это само по себе проблематично:

• Это очень небольшой кусочек информации по сравнению с прочими.
• Если то, что вы знаете, ложно, то вы ничего не знаете.
• Без обновлений эта информация быстро станет нерелевантной.

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

Обсудить в форуме