Senior Software Developer In Test
0,0
рейтинг
25 марта 2015 в 10:09

Разработка → Как стать автоматизатором тестирования?



Добрый день!

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

Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и 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.
К бизнесу, руководителям, специалистам по подбору персонала:

Профессиональный автоматизатор тестирования в конечном счёте экономит деньги компании, я бы даже сказал, в краткосрочной перспективе. Смотрим сравнение очень близкое к реальности здесь.
Sergei Tovmasian @FranciscoSuarez
карма
16,0
рейтинг 0,0
Senior Software Developer In Test
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (11)

  • +2
    Мне кажется, вы описали то, что сейчас называт «Software Developer In Test». А что нужно (и в какой роли) в проекте сильно зависит от поставленных процессов
    • +1
      Хорошо, спасибо, могу называть это так — не принципиально. Принципиально в данном случае то, что в большинстве случаев, хотят именно такого специалиста, но не могут ни сформулировать это, ни найти его. В большинстве случаев, потому что таких специалистов крайне мало…
  • 0
    Планирование тестов/написание тестов
    180 полноценных функциональных тестов за почти 2 года работы

    Тесты совершают больше 1 действия?
    Проверяют больше 1 условия?
    С идеей согласен, но объем функциональности продукта кажется небольшим. Или нет?

    В первую очередь надо выбрать язык программирования

    И ни слова о том, что лучший выбор — тот язык, на котором написан проект?

    Вы работаете на проектной, не продуктовой разработке?
    • +2
      Да Тесты совершают намного больше одного действия. Они заточены под сценарии поведения пользователей системы — включают в себя ненормальное поведение пользователей и «троллей». Объём функциональности продукта, на самом деле, большой… Не гигантский, но большой.

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

      Над продуктовой разработкой в проекте :)
      • 0
        «Тесты совершают намного больше одного действия»
        На мой взгляд — это антипаттерн. Тесты должны быть простыми — подготовка данных, действие и проверка. Благодаря такому подходу — тесты станет гораздо проще поддерживать, да и поиск ошибок упростится — представьте — если падает тест, то можно сразу предположить в каком именно методе и при каких условиях возникает ошибка, а не разгребать тонну логов и стек трейсов.
        Тесты иммитурующии работу троллей разбивайте на маленькие:)
        И еще очень полезны практики код ревью тестах (как между тестировщиками, так и перекрестные ревью разработчик — тестировщик).
        • +1
          На мой взгляд, это паттерн. Тесты не должны быть простыми… Потому что пользователи ведут себя крайне непросто. Не существует действия «оплатить покупки в интернет-магазине» без действия «добавить товары в корзину»… Этот примитивный пример масштабируется на любую систему. И ограничивается лишь функциональными возможностями пользователя.
          Это примерно то же самое, что говорить «тех-задание» — это паттерн. А user-story — антипаттерн. Сайты, программы, даже API постепенно переходят из набора функциональностей в набор сценариев для пользователя по реализации этих функциональностей. Уже почти нет форм с кучей кнопок на них… Есть call-to-action-ы, есть вероятности тех или иных сценариев… Это можно анализировать, изучать пользователей, выделять приоритетные сценарии, а не приоритетные функции, покрывать эти сценарии тестами. Теория тестирования, BDD идеи и т.д. подтягиваются к реальности, но, к сожалению, и в них пока есть то, что вызывает грусть.

          — По-вашему проще поддерживать 2000 маленьких тестов, а не 100 сценарийных? :) Мой опыт говорит об обратном. Сценарии можно разбивать по тематикам, включать в разные сэты тестов — после падения видеть сразу, что вот в этой «сфере» у нас беда. Это очень удобно. С маленькими проверками такой прозрачности не добиться…
          — По поводу предположений, в каком-методе. В стэк-трейсе всегда видна цепочка вызовов — видно в каком методе началось и где мы упали. Если всё правильно обработано, то ясное сообщение в Exception. Если и этого недостаточно, логи, если и этого — ну можно отдельно этот тест запустить и посмотреть глазами :) Ну или пройти по сценарию, если Software Developer in Test позаботился о том, чтобы тесты были читабельные и понятные. В конце концов Debug )))
          -Тролли априори не троллят маленькими операциями :)
          — Код-ревью — замечательная штука. Тут спорить не о чем

          • +1
            Ой… тут в голову пример пришёл.
            Вот вопрос — сколько надо сделать заборов крови, что провести анализ? :)

            У меня в последний раз делали 3 забора:
            1. Всякие стандартные элитроциты, лейкоциты, тромбоциты и т.д. штук 25
            2. Всякие нехорошие — ВИЧ, гепатит и т.д.
            3. Сахар…

            4*… Ещё делали время свёртываемости крови из пальца…

            Окей… я вижу 4 сценария…
            Ну или как предлагается Вами за 30 даже — если на секунду забыть о том, что человек умрёт от такого большого количества заборов. Кстати — если перевести на язык тестирования, то сценарии экономят время на инициализации. Потому что она проводится реже. 4 против 30 небольшая экономия. Но 100 против 2000 — огого… Особенно, если инициализация тяжёлая…

            Окей. Вернёмся к нашей крови… Давайте поанализируем результаты. Я на терапевта не учился… Но рискну предположить, что часто «картиной» является не отдельный анализ, а некоторая совокупность. То есть терапевт, увидев, повышенные тромбоциты заостряет своё внимание на каких-то определённых показателях из общего списка анализов, отвергая в голове версии, или подтверждая их. Получив некоторую наибольшую вероятность, он/она принимает решение о том, к кому направить…

            Согласитесь, добавив в мои 4 сецнария немного макс-правдоподобия и гипотетическую таблицу направлений в зависимости от того, на что похожа «картина», я получу неплохой движок, отвечающий с точки зрения тестирования(анализа) крови на бОльшее количество вопросов, чем изолированные проверки каждого из показателей.
            • +1
              *эритроциты))) очепятка
              • 0
                Рискну предположить, что Вы и Ins4n3 говорите о разном. Он говорит про модульное тестирование, а Вы про функциональное. Первое — оно про качество кода. И нужно чтобы быть уверенным что хотя бы по отдельности все модули работают так, как ожидает программист. Второе же — про качество продукта. Оно нужно уже чтобы убедиться что все модули правильно друг с другом соединены.

                По идее, модульные тесты можно выкинуть, и оставить только функциональные, однако, как показывает опыт, работать с функциональными тестами значительно проще, если каждый отдельный модуль работает корректно. В таком случае хотя бы видно что «конкретно в этом месте идет запрос аккаунта с плохим id и падает один тест», а не «сама реализация поиска аккаунта по id с ошибкой и падают все тесты».

                Соответственно, функциональные тесты, как Вы правильно сказали, куда полезнее делать именно сценарийными. Но вот модульные действительно должны быть простыми.
                • +1
                  Быть может и о разном. Быть может и нет :)
  • +2
    Полностью согласен с автором. Технологии меняются и пора меняться тестировщикам. Такие тестировщики, т.е. Software Developer In Tests наиболее полезны в продуктовых командах, т.е. работая вместе с разработчиками. В данном случае стоит использовать, тот язык, на котором построен основной код продукта

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