Недостающее звено между тестированием и автоматизацией
Серьезный тестировщикЕсли бы на модные словечки века проводился конкурс (хоть я и не думаю, что тестированию уже стукнуло сто лет), я почти на 100% уверен, что выиграла бы автоматизация тестирования. Если вы читаете про тестирование или слушаете подкасты, это обычно «автоматизация то», «автоматизация се», «автоматизируйте все».
Оно безусловно чрезмерно употребляется и чрезмерно злоупотребляется, и я готов спорить, что куча людей, дающих советы по автоматизации, не имеют ни малейшего представления, о чем они, черт возьми, говорят. Или, как минимум, их заявления демонстрируют полнейшее непонимание цели автоматизации.
То, что термины «тест-автоматизация» и «автоматизированное тестирование» во многом ошибочны, то, что «автоматизировать» тестирование, в сущности, нельзя, то, что мы можем автоматизировать только его часть, обсуждалось множество раз, бла, бла, бла, я не буду это повторять, и мне скучно говорить об этом снова и снова. Мысль, которая ударила меня как молния, состоит в том, что автоматизации тестирования не существует – есть «тестирование» и есть «автоматизация». Мне кажется, что наше мышление еще недостаточно развилось для того, чтобы мы эффективно их комбинировали. Сейчас покажу.
Два разных склада ума
Я взял это под наблюдение примерно тогда, когда готовился к TestBash в Мюнхене, и эта мысль начала расти и развиваться – мне требовалось время, чтобы окончательно ее оформить.
Когда вы, как тестировщик, присутствуете на конференции по «тест-автоматизации», или вы эксперт по автоматизации, и попали на конференцию по тестированию – не кажется ли вам, что люди говорят на чужом языке?
Именно так себя чувствую я. Каждый раз, когда автоматизатор начинает петь про «ненадежные тесты», я думаю «ну привет, приехали, не существует ненадежных тестов, существует плохой тест-дизайн! Когда уже ты его выучишь? На эту тему было множество дискуссий, где ты был, пока они велись?»
Готов спорить, что автоматизаторов тоже озадачивают разговоры и доклады, развивающие идеи командной работы, критического мышления, предубеждений, эвристик. И они, возможно, думают «О чем, черт побери, эти люди говорят? Они что, не в курсе, сколько кругом инструментов и технологий? Это же просто код, что за драма?»
Мысль, которую я хочу тут донести, также отвечает на вопрос, почему мы не можем создать автоматизацию, действительно помогающую тестированию – потому что мы изначально неправильно понимаем цели тестирования и автоматизации, и у нас нет прозрачности в плане того, какие проблемы решает чужой «лагерь».
С моей точки зрения, тестирование и автоматизация просто говорят на разных языках и стремятся к разным целям, оттого и растет изначальное непонимание в коммуникациях между ними.
Склад ума тестировщика
Для того, чтобы выяснить, где у нас провал в коммуникации, давайте сначала разберемся, каковы наши цели. Это просто мои наблюдения, возможно, с некоторыми предубеждениями, не относитесь к ним как к высеченным в камне.
Проблемы, которые пытаются решить тестировщики:
- В краткосрочной перспективе – предоставить информацию о существующих проблемах и помочь с их разрешением.
- В долгосрочной перспективе – предоставить информацию об оценке качества и поддержать принятие информированного решения.
- Провести исследования, дабы понять продукт или систему, которая тестируется.
- Провести эксперименты (это, на самом деле, и есть «тесты») над продуктом, чтобы достичь глубокого понимания и получить информацию о нем, его состоянии, поведении, существующих проблемах, и т. д.
- Попытаться провести эксперименты инкрементально, чтобы каждая следующая сессия давала информацию лучше предыдущей, новую информацию, или открывала другой аспект – функциональный, парафункциональный, производительность, безопасность, и т. д.
- Оценить риски и их влияние на качество.
- Выстроить понимание о том, как продукты должны работать, и каковы критерии качества, и использовать их как оракулы.
- Попытаться поставить под сомнение стабильность продукта любым возможным образом.
Почему складу ума тестировщика не удается помочь автоматизации?
Как правило, склад ума тестировщика не справляется с помощью автоматизации по нескольким причинам:
«Сопротивление тестирования»
В какой-то степени наши усилия как тестировщиков превращаются в «сопротивление тестировщиков», потому что мы практически всегда способны покритиковать автоматизацию и указать на то, что она неспособна сделать. При этом мы нечасто демонстрируем выгоды автоматизации для тестирования. Я и сам тут признаю свою вину – я сделал это в статье «Горькая правда об автоматизации», не сказав ничего о ее полезности, но я постараюсь это исправить.
Я убежден, что глупость про «ручное тестирование против автоматизированного» внесла в это немалый вклад, как и чушь про «нас заменят машинами» и прочие эпизоды, когда люди пытаются выглядеть умными, говоря при этом о полной фантастике.
Возможно, настало время реально посмотреть на вещи и попытаться найти решение вместо того, чтобы указывать на проблемы.
Неспособность извлечь пользу из автоматизации
Другая причина, по которой тестирование не может помочь автоматизации – это попытка ужать всю сложность тестирования и впихнуть ее в байты.
Мы норовим поставить перед автоматизаторами практически нереальные задачи – или из-за предубежденности «ручных идиотов заменят скриптами», или потому, что мы знаем реальную ценность и сложность тестирования, и стремимся ее продемонстрировать.
Чтобы стать лучше, нам нужно осознать следующее – тестирование и автоматизация хороши для специфических задач, которые зачастую не пересекаются. Тут не стоит вопрос выбора чего-то одного – скорее это «как им сосуществовать в симбиозе».
Склад ума автоматизатора
Он сильно отличается от склада ума тестировщика. Люди, работающие с автоматизацией, скорее мыслят, как разработчики, а не тестировщики. Нет, я не говорю, что это плохо, просто это совсем другое дело. И это надо ценить, потому что ряд инженеров-автоматизаторов – прекрасные разработчики.
Какие проблемы решает автоматизация?
Если она правильно применяется, то:
- Функциональная корректность.
- Проверки точности.
- Низкоуровневые проверки.
- Стабильность.
- Быстрая и регулярная обратная связь.
- Утверждение окончательных условий.
- Изолирование переменных условий от тестов.
- Регулярный запуск снова и снова.
- Решение всех типов проблем программирования – чистоты кода, багов в тестовом коде, сложности, возможности повторного использования, рефакторинга, и так далее.
Определив оба склада ума, можно отметить, что склад ума автоматизатора куда более технически и алгоритмически ориентирован, а склад ума тестировщика в основном ориентирован на непредсказуемость и критический подход. Пока тестировщики стараются экспериментировать постепенно, упорно давить на систему, чтобы получить новую информацию, автоматизаторы делают ровно наоборот – убеждаются, что тесты выполняются в том же окружении, в тех же условиях, каждый раз. Тут-то многие из нас и поскальзываются на реализации того, что тестирование и автоматизация работают по-разному и не взаимозаменяемы.
Почему складу ума автоматизатора не удается помочь тестированию?
Культ инструментов
Мы уже отметили, что автоматизация очень технична и крайне ориентирована на инструменты, однако это становится проблемой, если инженеры-автоматизаторы начинают смотреть на инструменты как на решения или винить их за ошибки в собственном тест-дизайне. На самом деле множество докладов, посвященных автотестам, глубоко уходят в вопрос, «как» что-то сделать, абсолютно забывая про «зачем». В результате автоматизация ощущает себя полностью оторванной от тестирования и, скажу об этом вновь, возможно, в этом стоит винить битву «автоматизаторы против ручных тестировщиков» и сказку про «замену» одних другими.
Но давайте не будем обманывать себя – значимость и цель автоматизации (и, к моей радости, Бас Дийкстра пришел к тому же выводу в своей блестящей статье) – в поддержке тестирования.
Неважно, насколько устойчив ваш фреймворк, следовали ли вы принципам ООП, легко ли его расширить, слабо ли он связан и сильно ли он прочен, запускаются ли ваши тесты за наносекунду и управляют ли данными на «пять» - все это совершенно бессмысленно, если ваши автотесты не находят багов. Если они не нападают на систему, пробуя ее на прочность достаточно агрессивно, чтобы найти баги. Возможно, это гениальный код – но он не достигает своей цели, если не дает значимую, доступную для инспекции информацию об имеющихся в продукте проблемах.
Почему это происходит? Переходим к проблеме номер 2.
Вера в то, что того, «что мы делаем как тестировщики, достаточно»
Из-за культа инструментов желание заменить тестирование вместо того, чтобы поддерживать его, и фокусе на том, как писать автотесты, большинство автоматизированных решений – это просто демонстрация, а не эксперимент. Сходите на конференцию автоматизаторов, почитайте статьи в их блогах – видали ли вы хоть раз, чтобы кто-нибудь из них задался вопросом «Тестирую ли я сейчас то, что нужно?», или «Это наилучший эксперимент, который я могу провести, используя этот инструмент?», или «Каково качество моих тестов?». Готов спорить, ответом будет «нет». Зачастую автоматизаторы так заняты подражанием поведению человека – открыванием выпадающих меню, взаимодействием с элементами, переходами между страницами, - что они забывают главную цель своего кода – быть высококачественным тестом определенного условия, которое имеет смысл тестировать.
Вместо этого я вижу, как автоматизаторы обращаются с тест-дизайном, как с неким ископаемым из прошлого, с которым мы давно разделались. Это не так! Проводить значимые эксперименты – это основная цель как для тестирования, так и для автоматизации.
Решение в создании недостающего звена
Ну, вряд ли это можно назвать решением, в конце концов, я тут сам с собой разговариваю, но я считаю, что решением будет реализация ряда важных вещей.
Тестирование и автоматизация не смешиваются.
Давайте отбросим бред про «замену» и «если», и «когда», и «ручное», и попробуем поговорить о чем-нибудь продуктивном.
Как мы уже отметили, цели тестирования и автоматизации – в решении совершенно разных проблем, и если обращаться с ними, как с взаимозаменяемыми вещами, мы никуда не придем.
«Универсальных солдат» не существует
Я считаю, что людей, которые одновременно глубоко разбираются и в тестировании, и в автоматизации, не существует, и в этом нет ничего плохого. Нет необходимости просить тестировщиков учиться программировать и писать автотесты, или просить автоматизаторов научиться мыслить критически и чересчур усложнять свой код. Просто продолжайте усердно работать над тем, что делает вас счастливыми, и оставайтесь открытыми для дискуссии, как принести пользу, тестируя продукт или систему.
Старайтесь делать ваши проблемы и цели видимыми для окружающих
Тестировщикам было бы полезно приложить усилия к тому, чтобы объяснить, где нужна автоматизация, приводя примеры, где автоматизация имеет смысл и очень полезна. Безусловно, отдавая себе полный отчет, что она не начнет и не будет «отбирать у нас наше дело».
Автоматизаторам, я думаю, было бы полезно приложить усилия, чтобы объяснить технологические ограничения своих инструментов и подходов, возможные ловушки тех или других, а также занимаемое время и сложность своей работы.
Немного здорового скептицизма тоже не повредит при создании автотестов. Один из ключевых компонентов менталитета тестировщика – это сомнение в собственной способности хорошо тестировать. Следовательно, когда мы пишем автотесты, мы должны в первую очередь сомневаться в их качестве, не удовлетворяясь простым подтверждающим тестированием.
Оригинал статьи: http://mrslavchev.com/2017/11/23/the-missing-link-between-testing-and-automation/
Перевод статьи: http://software-testing.ru/library/testing/testing-automation/2818-the-missing-link-between-testing-and-automation