Грешки Автоматизатора. Часть 4. Выбор языка

Я как-то давно обещал написать по этому поводу пару строк - исполняю.

Еще ни один стартап не умирал из-за того, что выбрал неправильный дистрибутив Linux - Пол Хаммонд

Да-да. Все именно так. Не имеет абсолютно никакого значения какой язык вы выберете для написания автоматических тестов, если вы вообще взялись этот самый язык выбирать.

Да, иногда мы привязаны к инструментам, которые не дают нам писать на некоторых языках. Но это, как правило, проприетарные инструменты для тестирования веб-морды. Да даже у них, как правило (не смотрим на MS), выбор языков на которых ожно писать довольно широкий.
Да, под разные инструменты/области автоматизации на разных языках разное количество готовых ништяков. Только все равно всеми вы никогда пользоваться не будете, хотя бы потому, что знать их все в наше время практически невозможно, а возникают они быстрее, чем грибы после дождя.
Да, у вас могут быть разработчики, которые знают хорошо какие-то весьма конкретные языки. Но тут тоже куча ньюансов. Во-первых, тесты писать вам, а не им. Во-вторых, если вы очень надеетесь, что они будут вас активно всему этому обучать - вы несколько переоцениваете количество свободного времени у них, и недооцениваете количество времени, которое вам придется потратить на написание. Большую часть изучения деталей вам придется сделать самим.

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

Собственно главный критерий один - как хорошо лично вы знаете тот или иной язык. Все.

В случаях, когда у вас какие-то корпоративные стандарты - вопрос вообще не должен возникать. Если вы планируете тотальное переиспользование кода приложения - тоже.

Наличие API или хелперов в количестве на том или ином языке - странный аргумент. REST API? Нет вопросов вообще. Хелперы и хуки автоматизации? Если они написаны нормально, то проблем с вызовом быть не должно.

Вы не знаете никаких языков? Учите то, что проще учить - Ruby, Python (это просто пара примеров). Учить Java или еще какие C++ - это путь самурая, но не тот случай когда вам нужно как можно быстрее выучить необходимый минимум (а автоматизация - довольно узкая область, там нужен довольно ограниченный набор) для написания автоматических тестов и тестовой инфраструктуры. Да, какие-то языки было бы неплохо подучить, чтобы набить себе резюме, но это вообще не имеет отношения к выполнению задачи.

Какая бывает автоматизация? Часть вторая.

Какие бывают инструменты?

Занимаясь автоматизацией большинство регулярно изобретает велосипеды - логгеры, фреймворки, драйверочки, тестовые клиенты. Для особо дорогих и очень типовых велосипедов вроде драйверов (selenium) или раннеров (любой xUnit фреймворк) как правило есть готовые решения. Какие-то бесплатны, как selenium, какие-то так или иначе стоят денег, как практически любой набор тестовых драйверов от Microsoft. Все это фактически и является инструментами автоматизации, которые редко кто пишет сам, так как времени на написание хорошего драйвера для того же браузера уходит порядочно.

Коммерческие инструменты

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

Остальные проблемы обычны для практически всех коммерческих инструментов (не только для тестирования):

• Практически невозможно допилить под свои нужды, особенно если ваш поставщщик считает что он точно знает что вам нужно, а чего нет. А в случаях когда это можно вас в лучшем случае ждут боль и страдания.
• Поставщик инструмента может перестать существовать. Особенно это печально, когда у вас перестает существовать поставщик драйверов к какой-нибудь бурно развивающейся вещи вроде мобильных платформ или браузеров - в этом случае меньше чем через год вы удостоитесь чести унести все ваши труды на помойку без возможности восстановления.
• Ну и классический vendor lock-in. Как правило поставщики коммерческих инструментов предлагают вам полный комплекс решений в котором, по мнению поставщика, замены ряда кусков (как то continuous integration) быть не может и не должно. Раньше это принимало такие чудовищные формы, как, например, изобретение собственных языков программирования для своих инструментов тестирования. Так же много боли вас может ожидать от попыток интеграции с другими инструментами автоматизации, даже если их аналогов в продуктовой линейке поставщика нет.

Бесплатные инструменты

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

• БОЛЬ И СТРАДАНИЯ ЧЕРЕЗ ОПЕНСОРС. Бывают откровенно чудовищные решения с плохим кодом внутри. И на них, как правило, не написано какое хорошее, а какое нет, особенно если вам приходится браться за не очень популярные инструменты.

Чему учиться?

1. Учитесь программировать. Желательно на скриптовых языках вроде Python, Ruby, Perl, JavaScript (продолжать можно бесконечно). Вам все равно придется писать скрипты рано или поздно, так что если у вас есть выбор - лучше выбирайте их.
2. Регулярные выражения. Вам часто приется заниматься разбором больших текстовых выводов в том или ином виде и просто работать с текстом. Увы лучше регулярных выражений для подобных задач пока ничего не придумали. К тому же регулярные выражения +/- универсальные для всех языков.
3. Если вы занимаетесь автоматизацией веба, то учите xpath и css. У веба большое преимущество перед другими видами автоматизации - доступ до всех элементов иинтерфейса, даже если там внутри мрак и фарш. Пользуйтесь пока есть такое счастье.
4. SQL (или NoSQL, но это пока сильно реже). Даже если тестируемые вами приложения не используют базы данных (что сейчас редкость), то оно вам пригодится когда вы возьметесь за тестовую инфраструктуру.
5. Системы контроля версий.

Кто и как обычно разрабатывает автоматические тесты?

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

Автоматизация после разработки

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

Вообще такой подход типичен для водопадных или пост-водопадных проектов, когда фаза тестирования все еще существует как таковая. Такие проекты как правило несут ряд артефактов прошлого вроде code freeze'а или обильной околотестовой бюрократии. Но даже без таких артефактов обратная связь у автоматизации тестов будет очень медленной.

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

Автоматизация вместе с разработкой

Как и тестирование параллельно/вместе с разработкой - довольно диковинный зверь в наших краях, увы.

Обычно такой подход характерен для agile проектов, когда всякие ATDD начинаются еще до того как хоть что-то написано. Программисты могут довольно оперативно включать "ручки" для улучшения testability, во время планирований и принятия тезхнологических решений сильно проще договариваться о получении различных testability-фич и инструментария. Фактически автоматизация становится неотъемлимой частью разработки, поскольку разработчики и тестировщики довольно плотно сотрудничают.

Какая бывает автоматизация? Часть первая.

Принесли как-то русским мужикам
на лесозаготовках японскую бензопилу.
Мужики положили под пилу здоровую сосну:
- Вжик - сказала пила
- Ого - сказали мужики и положили под пилу лом:
- Др-рр-рр- сказала пила и заглохла
- Ага!!- сказали мужики и пошли валить
лес двуручными пилами.

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

В данном tl:dr речь пойдет об автоматизации тестирования в классическом понимании, когда мы так или иначе делаем дамп наших ручных тестов в автоматические скрипты. Про другую автоматизацию когда-нибудь потом, все равно всем хочется "чтобы как пользователь так по экранчику жмакать", а остальное начинает будоражить умы только когда данный подход перестает работать.

Есть много способов это сделать и все они хороши в той или иной степени. О том как можно делать и какие приблемы приходится решать и пойдет речь.

Как мы пишем тесты?

Способов много и ни один из них сам по себе не лучше и не хуже других. Они просто есть и в ряде случаев нам лучше подходят одни, а в ряде случаев лучше подходят другие.

Record + Playback

Древняя как автоматизация тестирования идея - записать шаги пользователя и потом проигрывать их. До сих пор эти "зайчатки разума" тлеют в разного рода коммерческих приложениях, а так же в некоторых не очень коммерческих (Selenium IDE умеет так делать).

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

• Вообще не надо уметь программировать - тупо записал и тупо проиграл обратно
• Очень легко создавать тесты, бессмысленные и беспощадные

На этом бонусы заканчиваются и начинаются проблемы:

• Это не тесты, от слова "совсем". Это просто запись, которую мы можем проиграть и она может сможет проиграться, а может не сможет. Если нам понадобятся какие-то проверки (verification point'ы) или особо умное поведение, то придется допиливать
• Они как правило записывают не все. Да, возможно у вас будет тот самый случай, когда во всем вашем проекте не будет ни единого контрола/события, которое данный конкретный инструмент не может обработать, но зачастую это не так, поскольку технологии шагают семимильными шагами вперед, а производители софта ддля record'n'replay в большинстве своем за ними не очень поспевают
• Они отлично ломаются. Изменения в пользовательском интерфейсе как правило позволят вам часто и по-многу пользоваться возможностью легко и непринужденно создавать тесты
• Их сложно поддерживать. У вас не будет практически ничего что вы могли бы переиспользовать в разных тестах. И если тестов будет очень много, то это + предыдущий пункт принесут вам очень много головной боли
• Нельзя начать тестировать пока нет готового приложения. Вообще. Никак. Тупо потому что нечего записывать

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

Тупо скрипты

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

Отсюда появляются новые плюсы и минусы. Собственно плюсы:

• Бесплатно. Мы можем взять любой скриптовый язык и начать фигачить тесты
• Гибко. Нас не ограничивают возможности записывающего софта и создаваемые им структуры
• Быстро. Не так быстро как просто record'n'replay, но все еще быстро, т.к. просто берем и пишем какой нам вздумается тестовый говнокод в меру наших способностей

И есть набор суровых, непреодолимых для ряда людей/контор препятствий:

• Надо писать код. Хотя бы как-нибудь. Хотя бы фиговый код. Но надо
• Они все еще хрупкие. Мы же ничего принципиально нового не придумали, так что проблема с хрупкостью никуда не делась
• Сложно поддерживать. См. предыдущий пункт

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

Модульные скрипты

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

От такого подхода у нас появляется волшебная шляпа и +10000 к ловкости еще одна куча бонусов:

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

Из этих бонусов вытекают логичные минусы:

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

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

Data-/Keyword-Driven скрипты

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

• Не умеющие программировать пользователи смогут писать тесты
• Мы можем поопилить поддержку автоматических тестов. Не умеющие программировать правят сами тесты, умеющие программировать правят и развивают все что под ними
• Легко поддерживать и есть куча кода для переиспользования. Т.к. у нас там все же какая-то модульная структура внутри есть

Правда все становится сложнее, из-за чего возникают следующие проблемы:

• Очень много работы. Для keyword-driven варианта, конечно, есть куча опенсорсных BDD фреймворков, но не для всех
• Придется допиливать. Время от времени будут возникать хотелки не предусмотренные текущей реализацией и всю эту машинерию придется перепиливать. А для этого нужны будут люди способные в ней разобраться и время

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

Testability
Одной из самых сложных частей автоматизации тестирования является взаимодействие с тестируемым приложением. Где-то это будет упираться в используемые инструменты и прочие внешние факторы, а где-то мы сможем с этим что-то сделать (сделать легко разбираемый текстовый вывод, проставить ID везде где надо, предоставить прочие полезные интерфейсы для автоматизации). Но в целом идея простая - чем проще нам будет тестировать приложение тем проще пойдет вся автоматизация.

Часто приходится иметь дело с графическими интерфейсами, т.к. начальство/заказчик/мы хотим "чтобы как пользователь так по экранчику жмакать". Собственно с ними и возникает больше всего проблем, потому что:

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

Вариант сам по себе неплох, если у автоматизатора нет возможности или желания вникать в то, что происходит под графическим интерфейсом и работа с этим интерфейсом в принципе реализуема без глобальных проблем (привет автоматизации на symbian!).

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

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

Если последним пунктом вас никто не пытает, то оптимальным вариантом было бы покрытие основной функциональности под графческим интерфейсом и сравнительно небольшой (не обязательно автоматизированный) набор end-to-end тестов для морды.

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

Продолжение следует...

Агония качества. Серия #2

Мир мобильных приложений можно считать спонсором "Агонии" в этом месяце.

Любите оплачивать счета через приложение Citybank под iPad? Проверьте счета, возможно с вас списали деньги дважды. Как и с неизвестного числа пользователей начиная с Июля месяца (а может и раньше).

Вас очень злят приложение на мобильных телефонах? Успокойтесь, The Street утверждает, что 75% приложений в мобильных маркетах не тестировалось в принципе (это касается всех маркетов).

Верите в безопасность своих мобильных приложений? Зря, тот же Google Wallet отдает свой PIN на ура, а хранение паролей открытым текстом на устройстве это практически норма. Безопасность при разработке мобильных приложений? Никого не волнует.
Не нравится? Подключайтесь к OWASP Mobile Security Project.

Чтобы не нагнетать обстановку, дальше парочка увеселительных ссылок.

Нейтрино быстрее света? А может просто кабель стоило проверить?

Ваш HAL пристрастился к порнушке? Ничего, бывает.

Грешки Автоматизатора. Часть 3. Xpath головного мозга

На этот раз пишу с привязкой к инструменту. И инструмент этот (СЮРПРИЗ!!!) - Selenium-WebDriver (дальше просто Selenium или Se).

Так вот, в selenium есть одна большая и неутихающая головная боль - локаторы элементов. Головная боль, если задуматься, довольно древняя и растет из того, что текущие (да и прошлые, чего греха таить) биндинги никак не располагают к тому, чтобы:

• Задать много идентификаторов для одного элемента
• Использовать все возможные идентификаторы тегов (title, например)
• Обращаться напрямую к индексу элемента
• Различать элементы по типам (привет findElement!)

Одной невозможности обращаться к элементу по его имени (title) и по индексу уже достаточно чтобы плакать кровавыми слезами.

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

Я долго думал почему же css-локаторы лучше чем xpath, но в итоге не придумал ни одного железобетонного аргумента.

Я мог бы сказать, что CSS лучше уже тем, что он быстрее чем xpath. Но многим автоматизаторам (особенно начинающим) в принципе плевать насколько быстро выполняется скрипт. Им вообще до оптимизации автоматических тестов дела нет - лишь бы работал хоть как-нибудь.

Я мог бы сказать, что CSS читабельней чем xpath. Но это вкусовщина. Если человек привык писать //div[@id='eid'], то div#eid для него может показаться ущербным.

Я мог бы сказать, что CSS это практически jQuerry, но автоматизатору со средней полосы до jQuerry как правило нет никакого дела.

Но больше всего раздражает в xpath-локаторах то, что люди пытаются делать вот такие вещи:

html/body/div[2]/div[2]/div/div/ul/li[2]/div/img
//div[@id='ui-datepicker-div']/div/div/select[2]

Только xpath тут совсем ни при чем. Огромная, зловонная куча таких вырвиглазных примеров локаторов на xpath скорее всего существует только потому, что CSS-локаторы штука относительно новая и применяя их не успели еще создать столько мусора. Это просто гипотеза, но справедливости ради стоит заметить, что вырвиглазные примеры css-локаторов я тоже вижу, но в разы реже.

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

Например можно подойти к разработчикам и сделать вот такое лицо (мне подсказывают, что бить палкой людей плохо, так что лучше так):

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

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

Или проставьте их сами.

Только не рисуйте бессмысленных и беспощадных локаторов. Это зло, которое вам потом придется переписывать. И если у вас нет никакой возможности это зло побороть - переписывать, скорее всего, придется много и часто. И если смену имени/id элемента еще можно быстренько поправить (хотя в частой их смене тоже нет ничего хорошего), то переписывать развесистые локаторы, где упоминается добрая половина элементов DOM-дерева, сильно дольше. А уж читать эти развесистые локаторы после вас...

Агония качества. Серия #1

Вместо предисловия.

Тут tldr, кто не хочет - мотает до линок, там самое вкусное.

Здравствуйте, меня зовут Сергей, я тестировщик (мне же можно так себя называть?).
Поскольку я занимаюсь тестированием, то я живу и работаю в постоянной драме по поводу того, что хочется идеального качества, а оно не возможно. Как писал Джерри Вейнберг:

"Попытка выполнить невозможное убьет вас"

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

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

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

Если хорошо пойдет - постараюсь выкладывать такие наборы ссылок каждый месяц.

Пища для ума:


Why Facebook doesn’t have or need testers. Заметка, которая и сподвигла меня начать фиксировать все подобные вещи публично. Facebook не нуждается в тестировщиках, и не ставит себе целью производить высококачественное програмное обеспечение.

Magazines and Newspapers Need to Build Better Apps. Около трети всех приложений от журналов и газет для iPad работают из рук вон плохо.

$45 Million Hospital Bill: It's Enough To Really Make You Sick. 45 миллионов долларов за лечение. Такой чек по ошибке получил один безработный в штатах. С ошибкой успешно разобрались, но осадочек остался.

Passengers panic over false crash alarm. Еще один повод скончаться от инфаркта получили пассажиры трансатлантического рейса, когда посреди полета случайно сработало автоматическое оповещение о крушении.

[rhelv6-list] A kernel bug that causes a system crash when the uptime is longer than 208.5 days. Или даже так. Баг, приводящий к падению системы через 200 с хвостом дней работы. Уже починили. Спешите обновить.

И немного не то чтобы проблем, а просто не нравится:

Твиттер купил твитдек, и постепенно доводит его до того же состояния нестояния, что и свой веб-интерфейс:
Dear Twitter: Tweetdeck wasn’t broken
Ну или просто безуспешные попытки связаться с саппортом.

Новая файловая система для Windows 8. Будет доступна в серверной версии до того как полностью протестируют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Грешки Автоматизатора. Часть 1 и, думаю, не последняя

Не автоматизируйте thirdparty компоненты.

Каждый раз, когда вы пишите автоматический тест на проверку thirdparty компонент, умирает пушистый котенок.

Нет, ну серьезно, зачем писать автоматические тесты проверку получения почты через GMail-морду? Или виджеты типа кнопочки like? Зачем писать автоматические тесты на проверку thirparty процессора кредитных карт? Зачем писать автоматические тесты на авторизацию вашего приложения через твиттер?

Даже не так.

Что вы хотите узнать?

Если GMail перестанет работать, то вы с этим ничего не поделаете. А ваш тест свалится.
Если банк не проведет платеж через кредитную карту, то что вам это даст? Вы узнаете много нового о своем приложении?
А если платеж где-нибудь зависнет? Вы сможете из теста автоматически узнать, где там в банке завис ваш платеж? А сколько ваш тест готов будет ждать? Час? День? Неделю? Или нужно ставить тест в зависимость от состояния счета?
Вы действительно хотите, чтобы ваши тесты зависели, скажем, от того, упадет ли сеть в Берлине? Или получить кучу ложных срабатываний из-за того, что заглючило корпоративную прокси и у вас не открылось окошко твиттера на авторизацию приложения?

Нет.

Конечно, вам может быть и правда нужно проверить почту. Например, когда туда отправили линку на авторизацию. Только не нужно делать работу ребят из Google, занимающихся тестированием вебморды GMail. То же про виджеты facebook. То же про twitter. То же про системы процессинга кредитных карточек.

Делая это вы убиваете котят.

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

• Можно проверить почту через POP/IMAP напрямую, используя библиотеки доступные в вашем языке (а они есть почти наверняка)
• Можно вставить свич и фактически замокировать thirdparty компоненту. Если это сделать аккуратно, то с точки зрения вашего приложения ничего не изменится. Правда тут есть риск выкатить не с тем свичом на продакшен, если деплой у вас идет ручками (в простанородье - "handjob")
• Можно забраться в базу скриптом и там сделать нужные переключения

У всех этих решений будет пара общих свойств:

1. Ни одно решение не ставит вас в зависимость от погоды в Ирландии.
2. Все решения могут сильно ускорить выполнение автоматических проверок.

И это даже не все возможные решения. Можно придумать еще.

На этом с первым грешком автоматизатора все.

Не убивайте котят - пишите хорошие тесты.