Добрый день!
Вчера, отвечая, кажется, в шестой раз на этот вопрос, твёрдо решил, что пришло время для написания статьи. Сразу отмечу – это исключительно моё видение, с которым, уверен, добрая половина мира автоматизаторов не согласится, – мой рецепт несколько сложнее, чем «почитать про тулзу», «поставить тулзу», «использовать тулзу», «написать в резюме, что умеешь пользоваться тулзой».
Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».
Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».
0. Начнём с ошибок, которые не надо допускать:
- Дайте мне книгу умную, которая всё за меня сделает
- Дайте мне курсы платные, которые всему меня научат
- Дайте мне форумы специализированные, которые ответят мне на все интересующие вопросы
- Дайте мне сертификацию полезную, с которой меня везде примут
Это всё хорошо, но лишь в дополнение к рецепту, который описан ниже. Ни в коем случае нельзя с этого начинать.
1. В первую очередь надо выбрать язык программирования
Не тулзу, не TestComplete, не тыкалки по экрану макросоподобные. А объектно-ориентированный язык программирования. Я в своё время поработал немного с C#, затем выбрал Java – и до сих пор не пожалел о сделанном выборе. Но настаивать не стану. Скажу только, что ещё не сталкивался ни с одной нерешаемой на Java проблемой – даже Delphi приложение через WinAPI тестируется (но лучше для таких задач использовать дэльфийские DUnit и прочее).
Итак, мы узнаём, что такое примитивы, классы, объекты, полиморфизм, инкапсуляция, интерфейсы, абстрактные классы, статические поля, циклы, массивы, листы, мапы, потоки и так далее… Это изучение будет продолжаться в целом всё время, даже когда вы уже автоматизируете тестирование. Но на базовом уровне – Junior Java Developer – вы должны (если выбрали Java) быть знакомы с языком и иметь соответствующие навыки, потому как первичная локализация возникшей проблемы лежит на ваших плечах. Забудьте про «а вот у меня сценарий, ошибка наигрывается непонятно как и непонятно почему» — ваша задача, чтобы разработчик знал, что тут вот рядом человек может найти баги даже не запуская приложение. Не поверите, как вдруг качество продукта возрастает, когда есть человек, который не просто слышит запах плохо пахнущего кода, но и может предложить решения по улучшению.
Мы плавно перешли к
2. Использование шаблонов проектирования для разработки тестового фреймворка.
ДА-ДА. Вы открыли, например, Selenium, — всякие примеры, скопировали бездумно, написали на получившемся «фрэймворке» 1000 тестов. Приходит заказчик к бизнесу, говорит «мне тут нужно кое-что переделать», бизнес приходит к разработчику — «нам тут нужно немного подстроиться под рынок», разработчик всё прекрасным образом запиливает, — 90% тестов падают. Приходят к автоматизатору «мы тут немного поменяли, надо привести тесты в порядок», а автоматизатор в ответ «тут работы на месяц»… Упс…
Архитектура фрэймворка, который вы пишите, должна не просто быть гибкой, а должна постоянно стремиться минимизировать время рефакторинга имеющихся тестов и написания новых. В идеале, если разработчик и автоматизатор одновременно садятся исправлять что-либо, то автоматизатор должен сделать всё быстрее и предоставить разработчику некую форму TDD.
В создании такой чудо-архитектуры нам помогают паттерны проектирования и их грамотное использование… Builder, Facade, Factory, Null Object, Singleton, Adapter и многие другие паттерны активно помогают в решении подобных задач. Грамотная архитектура тестового фреймворка – это счастье для вас, для разработчиков, для бизнеса…и в конечном счёте для пользователя. Помните, что экспоненциальный рост ресурсов поддержки тестов при линейном росте/изменении функционала свидетельствует о том, что вам пора дорабатывать архитектуру движка. С наиболее полным списком паттернов с примерами на Java можете ознакомиться здесь. Отдельно отмечу Page Object Pattern, но лучше, сначала познакомиться с классическими.
3. Использование библиотек
То, что плавно вливается в любые задачи, — внешние API, библиотеки, драйверы и прочие прелести. Selenium — тестируем Web, Robotium/Espresso — тестируем Android, Fest/Jemmy — тестируем Java Swing, JemmyFX — тестируем JavaFX, замечательные Apache HttpComponents — делаем запросы и тестируем множество API, GSON — помогает приводить json к объектной модели и обратно и так до бесконечности… Библиотек прекрасных много написано почти под любую задачу — про некоторые из них можно почитать здесь. Не стоит бояться того, что их много — вы уже достаточно знаете, чтобы выбрать то, что вам подходит/нравится/вписывается в архитектуру. Например, под тестирование Java Swing приложений я использую JUnit, Fest, Mockito и широкие возможности java.lang.reflect — этого набора мне более чем хватает.
Будьте готовы к частому посещению stackoverflow и подобных ресурсов на ранних этапах. Будьте готовы к тому, что иногда надо будет заглянуть в исходники. И самое главное — не бойтесь не разобраться.
4. Планирование тестов/написание тестов
В рамках этой статьи я не рассказываю про то, что губительна для любого проекта идея о 100% покрытии, о расписывании сценариев и т.д. Вообще классические подходы к тестированию губительны в автоматизированном тестировании — , например, изолированные входные данные для тестов. В общем тут уже играют роль ваши навыки, умение аналитически мыслить, умение сомневаться в том, в чём стоит сомневаться и не искать проблему там, где её не может быть. Хорошие сценарии тестов — это как хороший интерфейс… идеальными быть не могут. Мой опыт даёт такую статистику: 5% всех сценариев обеспечивает 95% покрытие функционала. На текущем проекте у нас 180 полноценных функциональных тестов за почти 2 года работы, которые обеспечивают нам эти 95% — 99%, шесть успешных внедрений — на выходе немного low замечаний, которые совершенно не отразились на основном функционале и на лояльности клиентов, и были быстро поправлены. Но ради них городить ещё 2000 тестов невыгодно чисто по деньгам — это я обращаюсь в сторону руководителей и бизнеса, которые мечтают о 100% покрытии. Поверьте мне, оно вам не нужно. Тут оговорюсь, если речь идёт не об автоматическом тестировании безопасности или биллинга — тут риски должны быть не минимизированы, а, по возможности, сведены к нулю. Но это отдельная история…
5***. Написание утилит и собственных библиотек
Тут звёздочки… У вас уже всё замечательно на проекте, регресс покрыт, тесты гоняются, разработчики спокойны и могут спокойно рефакторить архитектуру, не боясь сломать имеющийся функционал. Но, например, для того, чтобы что-то сэмулировать руками, разработчику приходится проделывать из месяца в месяц одно и то же действие руками. Напишите для него утилиту, оптимизирующую эти процессы, включите туда всякие невалидные сценарии, разрекламируйте на уровне компании, — пусть все начнут пользоваться… Это ускорит работу и, как ни странно, уменьшит количество багов, так как у разработчика появится больше времени на то, чтобы проверить побольше сценариев, прежде чем коммитить измненения в ветку. Оглядитесь по сторонам и вы увидите так много процессов, которые можно автоматизировать, что не будете знать, за что взяться.
Пишите достаточно абстрактные библиотеки, могущие быть использованными на разных проектах в вашей компании, да и просто в вашей работе в будущем.
Заключение
Вы, конечно, можете про себя подумать «жеееесть», но…
- да, это не самый короткий, это тот путь, пройдя по которому можно стать по-настоящему классным специалистом
- это очень интересный путь — тернистый, но интересный
- вы абсолютно уверены в себе, как специалист
- если вам надоест автоматизировать тестирование, можете спокойно уйти в разработчики
- вы не зависите от какой-то платной тулзы, в которой тоже могут быть баги.
- если вы грамотно всё организуете (это как у профессиональных админов), то у вас появится много свободного времени для саморазвития
- ну и больше материальных благ :)
P.S.
К бизнесу, руководителям, специалистам по подбору персонала:
Профессиональный автоматизатор тестирования в конечном счёте экономит деньги компании, я бы даже сказал, в краткосрочной перспективе. Смотрим сравнение очень близкое к реальности здесь.
Автор: FranciscoSuarez
