Home

Автор: Виктор Славчев (Viktor Slavchev)

Оригинал статьи: http://mrslavchev.com/2017/11/23/the-missing-link-between-testing-and-automation/

Перевод: Ольга Алифанова

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

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

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

Два разных склада ума

Я взял это под наблюдение примерно тогда, когда готовился к TestBash в Мюнхене, и эта мысль начала расти и развиваться – мне требовалось время, чтобы окончательно ее оформить.

Когда вы, как тестировщик, присутствуете на конференции по «тест-автоматизации», или вы эксперт по автоматизации, и попали на конференцию по тестированию – не кажется ли вам, что люди говорят на чужом языке?

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

Готов спорить, что автоматизаторов тоже озадачивают разговоры и доклады, развивающие идеи командной работы, критического мышления, предубеждений, эвристик. И они, возможно, думают «О чем, черт побери, эти люди говорят? Они что, не в курсе, сколько кругом инструментов и технологий? Это же просто код, что за драма?»

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

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

Склад ума тестировщика

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

Проблемы, которые пытаются решить тестировщики:

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

Почему складу ума тестировщика не удается помочь автоматизации?

Как правило, склад ума тестировщика не справляется с помощью автоматизации по нескольким причинам:

«Сопротивление тестирования»

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

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

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

Неспособность извлечь пользу из автоматизации

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

Мы норовим поставить перед автоматизаторами практически нереальные задачи – или из-за предубежденности «ручных идиотов заменят скриптами», или потому, что мы знаем реальную ценность и сложность тестирования, и стремимся ее продемонстрировать.

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

Склад ума автоматизатора

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

Какие проблемы решает автоматизация?

Если она правильно применяется, то:

• Функциональная корректность.
• Проверки точности.
• Низкоуровневые проверки.
• Стабильность.
• Быстрая и регулярная обратная связь.
• Утверждение окончательных условий.
• Изолирование переменных условий от тестов.
• Регулярный запуск снова и снова.
• Решение всех типов проблем программирования – чистоты кода, багов в тестовом коде, сложности, возможности повторного использования, рефакторинга, и так далее.

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

Почему складу ума автоматизатора не удается помочь тестированию?

Культ инструментов

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

Но давайте не будем обманывать себя – значимость и цель автоматизации (и, к моей радости, Бас Дийкстра пришел к тому же выводу в своей блестящей статье) – в поддержке тестирования.

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

Почему это происходит? Переходим к проблеме номер 2.

Вера в то, что того, «что мы делаем как тестировщики, достаточно»

Из-за культа инструментов желание заменить тестирование вместо того, чтобы поддерживать его, и фокусе на том, как писать автотесты, большинство автоматизированных решений – это просто демонстрация, а не эксперимент. Сходите на конференцию автоматизаторов, почитайте статьи в их блогах – видали ли вы хоть раз, чтобы кто-нибудь из них задался вопросом «Тестирую ли я сейчас то, что нужно?», или «Это наилучший эксперимент, который я могу провести, используя этот инструмент?», или «Каково качество моих тестов?». Готов спорить, ответом будет «нет». Зачастую автоматизаторы так заняты подражанием поведению человека – открыванием выпадающих меню, взаимодействием с элементами, переходами между страницами, - что они забывают главную цель своего кода – быть высококачественным тестом определенного условия, которое имеет смысл тестировать.

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

Решение в создании недостающего звена

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

Тестирование и автоматизация не смешиваются.

Давайте отбросим бред про «замену» и «если», и «когда», и «ручное», и попробуем поговорить о чем-нибудь продуктивном.

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

«Универсальных солдат» не существует

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

Старайтесь делать ваши проблемы и цели видимыми для окружающих

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

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

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

Как я планирую решать этот вопрос для себя?

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

Вправе ли я писать об этом? Да кого это волнует! У меня есть блог, и я буду писать о чем хочу. Если людям это понравится – они это продемонстрируют, если не понравится – я остановлюсь.

Я с радостью прочитаю и обсужу ваши решения для создания отсутствующего звена.

Шаринг и ретвиты приветствуются. Спасибо, что прочитали.

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