Грешки Автоматизатора. Часть 2. Sucker Punch Effect

Для не шпрехающих по англицки:

Sucker punch - запрещенный удар (удар исподтишка)

Самый тривиальный пример такого удара можно назвать "смотри, птичка!". Работает так же, как и называется:

1. Говорим "смотри, птичка" явно указывая, что птичка где-то в стороне.
2. Когда противник отвлекается - бьем его в лицо.

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

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

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

Увы, у этого костыля есть ряд побочных эффектов.

Первый, и самый главный - если у нас в голове дерьмо, то костыль тут ничем не поможет. Даже если вы начнете делать все это дерьмо в 1000 раз быстрее, золотом оно от этого не станет. Оно просто станет очень быстрым дерьмом. Как это лечить, и что нужно делать - тема долгая и отдельная. Первая часть "грешков" была лишь об одном из тысяч аспектов.

Второй побочный эффект - мы начинаем этому костылю верить. А он нас начинает бить. Причем чем меньше мы о нем знаем, тем больнее он бьет.

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

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

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

Хуже, если там есть проприетарный софт с закрытым кодом. Вам придется отправлять запросы на починку/фичи. Смотреть как их отклоняют/принимают. Ждать новых версий. И все это время писать костыли, так как у вас нет возможности прожить с этой кучей багов годик до нового релиза.

Еще опаснее, если под этот проприетарный тестовый софт вам придется подстраиваться всем продуктом.

Итого. Вернемся к исходной позиции.

Есть мы. Мы пишем тесты.
Есть тесты. Хорошие, автоматические тесты. Будем считать, что тут никаких проблем нет, иначе все станет сильно сложно.
Есть наш любимый костыль. Наш инструмент. Мы в него верим.

И этот наш инструмент, наш друг, бьет нас в лицо. Нагло обманывает, так сказать. А мы об этом догадаемся когда будет уже поздно. Самый натуральный sucker punch.

Как с этим бороться?
Очень просто:

1. Изучайте свои инструменты
2. Тестируйте свои инструменты

Взять selenium и начать писать под него тесты просто. Хорошую инфраструктуру под тесты написать сложно, да. Но сами тесты в большинстве случаев писать не очень сложно.

Взять jenkins, xUnit и приклеить туда тесты написанные на selenium еще проще.

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

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