Нет, я не собираюсь ниспровергать Selenium или предлагать вам абсолютно новый удобнейший инструмент, которым можно Selenium заменить, речь пойдет о трагичной привычке очень многих сводить всю автоматизацию к умению работать с WebDriver.
Я надеюсь для всех моих читателей выступать в этой статье, как Капитан Очевидность, рассказывая о тех вещах, которые известны и понятны всем вам. Но к сожалению мой горький опыт показывает, что очень много людей не понимают очевидных вещей и сами же страдают от этого.
Не буду сильно углубляться в описание, мы знаем, что Selenium – это инструмент взаимодействия с современными браузерами, который может использоваться в целях автоматизации тестирования web-приложений (но не обязательно). С его помощью мы можем эмулировать все те действия, что пользователь может предпринять в браузере, таким образом проверяя все необходимые сценарии использования нашего продукта.
Selenium — продукт с богатой историей, многократно и повсеместно используемый, переживший несколько обновлений, имеющий большое сообщество пользователей, огромное количество статей, блогов и даже книг. Естественно, что сложилась неверная ситуация когда мы говорим Selenium, подразумеваем автоматизацию тестирования, говорим автоматизация – подразумеваем Selenium (или его клоны в том числе и для других языков программирования).
Казалось бы, в чем проблема? Молодые (и не очень) ребята проходят некие курсы по Selenium или занимаются самостоятельно по книгам, блогам, видео и выкладывают свои резюме с гордыми записями в стиле Автоматизатор, QA Automation или даже Software Developer in Test (в этом месте слышен шлепок facepalm’а разработчиков). Но потом не могут найти работу, не проходят собеседования или, что хуже, приходят на работу, но не могут с ней справиться.
Давайте разбираться, что же тут не так, ребята же 2 недельные курсы прошли, книжку прочитали…
- web-приложение — это не только и не столько графический интерфейс (далее ГУИ). По сути ГУИ — это только фасад с которым взаимодействует ваш пользователь, самое важное как всегда — это информация, ее трансформация, обработка и так далее. Крайне сложно представить приложение, где самое важное – это графика в браузере, а не стоящая за ней информация, которая этой графикой визуализируется. Даже в браузерных играх, которые я имел удовольствие тестировать, графика конечно важна, но гораздо важнее правильность обработки всего того, что происходит за кадром. Проще говоря пользователь еще может смириться с тем, что выстрел его рельсы был не того цвета, но даже не думайте начислить ему на 1 кристалл меньше или при этом выстреле нанести дамаг ниже ожидаемого. Согласитесь, что и пользователи ваших приложений скорее могут смириться с поехавшей версткой или неплавными переходами меню, чем с некорректными данными или с их отсутствием. Можно конечно сверять данные и с помощью Selenium, но для этого есть более простые и надежные способы.
- Про критичную важность и маст-хев юнит-тестов я даже не буду говорить, это должно быть всем ясно, но в чем их особая сила? Они тестируют максимально малый участок кода, максимально близко к нему и максимально быстро, тем и хороши. В чем проблема Selenium-тестов? Между нашим кодом и приложением есть посредники, а именно API самого Selenium и собственно используемый браузер, то есть к проблемам (возможным) нашего кода и/или приложения добавляются проблемы как программные так и с временем выполнения от Selenium и браузера. В эту цепочку кроме того часто встраивают еще и обертку над Selenium или прокси. О надежности и скорости выполнения таких тестов думаю все в курсе.
- ГУИ –самая простая и логичная вещь в плане проверки простыми тестировщиками (я не люблю терминов «ручные» тестировщики, так как мы их не приручили, не люблю и «ручники», так как ногами тоже никто не тестирует, в данном случае под «простыми тестировщиками» я имею в виду тех, кто не использует автоматизацию на языках программирования). Среди простых тестировщиков есть те, кто умеют работать с БД или скажем SOAP UI(Postman), но проверять ГУИ, согласитесь можно научить кого угодно, да и это уже все умеют, достаточно дать теорию. То есть многие вещи из наших тестов могут и должны проверять простые тестировщики, в том числе те, кто знаком с исследовательским тестированием. А с помощью кода проще и логичнее проверять те стороны продукта, которые простым тестировщикам недоступны в силу отсутствия знаний и соответствующих инструментов. То есть простые тестировщики тестируют черный ящик, а уж автоматизатор должен лезть внутрь этого ящика и проверять серый или прозрачный ящик.
- Современный ГУИ уже редко пишется руками и на чистом javascript, все чаще его строят на основе имеющихся фреймворков. А элементы и блоки этих фреймворков уже многократно протестированы как их разработчиками, так и многими пользователями этих фреймворков по всему миру. Дополнительно проверять скроллы, календари и кнопки в них нет смысла, важны только данные, которые придут и как они будут обработаны.
В итоге мы приходим к тому, о чем много раз говорилось:
а) Selenium тесты должны быть на вершине пирамиды тестирования и проверять совсем немного сценариев;
б) больший упор в ГУИ должен быть отдан на проверку простым тестировщикам, исследовательское тестирование rules!
в) должны быть тесты API приложения и/или его частей, которые можно проверить изолированно
г) приложение должно быть максимально покрыто юнит-тестами (да, я знаю, что их не пишут)
в итоге наш автоматизатор должен появляться в пункте «в» по максимуму и совсем немного и в последнюю очередь в пункте «а»
Что же должен уметь и знать автоматизатор по факту, а не после просмотра видео на ютубчике:
1) Главное правило автоматизации тестирования «Изучай язык программирования, а не автоматизацию на нем!» (с)
Автоматизация тестирования, в том числе с помощью Selenium – это лишь малая часть всего того, что есть в данном языке программирования. Заранее делая узкой свою область знаний (только Selenium) автоматизатор отказывается от большого числа технологий и инструментов, которые в языке есть. Кроме того, при появлении проблем и задач, не связанных с Selenium, автоматизатор впадает в ступор, так как не знает как это решать, более того начинает придумывать костыли в силу этого незнания. Владея только одним инструментом, а не всеми инструментами языка, автоматизатор и все проблемы пытается решать им, что не всегда нужно и логично.
Для языка Java автоматизатор должен знать:
— основы (да-да!) примитивы, объекты, как работает сборщик мусора, модификаторы доступа
— ООП, не просто прочитать и выучить определения, а понимать что это, как реализуется в коде, почему ругают наследование, в чем сила полиморфизма, для чего нужна композиция
— коллекции! Без этого просто невозможно, как минимум List, Set, Map и их основные реализации
— многопоточность, особенно понимание блокировок, взаимодействия потоков, общих данных
— работа с http запросами, на чистой Java или используя библиотеки.
— работа с БД с помощью jdbc
— паттерны (шаблоны), нужно знать хоть что-то еще кроме ПейджОбджект и Синглтон, рекомендую Команда, Стратегия, Декоратор, Строитель
— логирование
— нужно знать еще один тестовый фреймворк. Если чаще работаете с TestNG то знать и Junit и т.п.
— умение писать юнит-тесты (для своего кода)
— парсинг данных и все что с этим связано
— умение работать со сборщиками maven/gradle
— Java 8 фичи – это обязательно! Стримы, лямбды, функциональные интерфейсы, методы по умолчанию
— вы будете смеяться, но нужно знать и уметь работать с Selenium: локаторы, логи, ожидания, actions, вот это вот все
Для других языков программирования нужны аналогичные знания
2) Не помню у кого прочел (или Болтон или Виноградов) но все мы тестировщики изначально, а все остальное, в том числе автоматизация – это уже не так важно. Болтон вообще считает разделение на автоматизаторов и простых тестировщиков вредной. Это я к тому, что знание всего из пункта 1 не освобождает автоматизатора от знаний теории тестирования, цикла разработки, умения писать баги, проводить исследовательское тестирование.
3) Есть довольно обширная, но не очень глубокая зона сопутствующих знаний, которые должны быть у автоматизатора:
— понимание как работает браузер, понимание самого протокола http, кодов ответа, rest.
— знание основ SQL
— умение работать с системой контроля версий
— понимание что такое json, xml
Проблема, которую я хотел описать не только в низком уровне «автоматизаторов». Что важно, сами компании (наши работодатели) ассоциируют автоматизацию с Selenium и не ищут автоматизатора там, где он бы пригодился, потому что не знают что он ДОЛЖЕН решать и такие проблемы, а не только кликать в браузере. То есть с одной стороны мы имеем не самых хороших кандидатов, а с другой стороны формирование мнения (частично справедливого) о невысоком уровне автоматизаторов и их ненужности на серьезных проектах, где важнее данные, а не картинка. И эту ситуацию нужно менять, в первую очередь начиная с себя и своих умений.
Надеюсь, эта статья толкнет некоторых на пересмотр своего резюме, а главное на изучение дополнительных технологий. Но мне будет достаточно и «Спасибо, Кэп!»
Все вышеописанное является лишь моим личным мнением основанным на опыте, в том числе не опыте проведения ряда собеседований с теми, кто считает себя автоматизатором тестирования, а также опыте общения с менеджерами, HR и разработчиками, имеющими смутное или невысокое мнение об автоматизации тестирования.
testers little helper 