Комментарии 42
Какой бонус получает ручной тестировщик от того, что у него добавляется еще и автоматизация? Он занимает позицию автотестера? Или получает как ручной, а работает как автоматизатор? Исходя из текста вы против роста штата автоматизаторов.
Спасибо за вопрос. Чтобы ответить на него, прежде всего я предлагаю разделить автоматизацию, как позицию в отделе QA, и автотесты — инструмент для тестирования.
Любой тестировщик, если он чувствует ответственность за свою работу, хочет, чтобы его задача была протестирована хорошо. Автотесты — это прерасный инструмент, позволяющий легко и быстро проверить регрессию, убедиться, что все работает как раньше. Умение работать с автотестами упрощает тестирование задачи. А чтобы уметь работать с автотестами, нужно этому научиться.
Что касается позиции автоматизатора, то, по моему опыту, далеко не все хотели бы заниматься этим на фултайм. Кому-то интереснее тестировать проект на уязвимости, кому-то заниматься менеджментом, иметь компонент и отвечать за него, кому-то интересно заниматься другими тулзами для тестирования. А кто-то любит разнообразие и вполне непрочь написать один или два теста в неделю. Но чтобы чаще, увольте!
Никто не заставляет насильно сидеть и заниматься тестами сверх определенного минимума — уметь разобраться в упавшем тесте, быть способным его поправить или описать баг, которые этот тест поймал. Вот, пожалуй, и все.
Любой тестировщик, если он чувствует ответственность за свою работу, хочет, чтобы его задача была протестирована хорошо. Автотесты — это прерасный инструмент, позволяющий легко и быстро проверить регрессию, убедиться, что все работает как раньше. Умение работать с автотестами упрощает тестирование задачи. А чтобы уметь работать с автотестами, нужно этому научиться.
Что касается позиции автоматизатора, то, по моему опыту, далеко не все хотели бы заниматься этим на фултайм. Кому-то интереснее тестировать проект на уязвимости, кому-то заниматься менеджментом, иметь компонент и отвечать за него, кому-то интересно заниматься другими тулзами для тестирования. А кто-то любит разнообразие и вполне непрочь написать один или два теста в неделю. Но чтобы чаще, увольте!
Никто не заставляет насильно сидеть и заниматься тестами сверх определенного минимума — уметь разобраться в упавшем тесте, быть способным его поправить или описать баг, которые этот тест поймал. Вот, пожалуй, и все.
Можно было бы в одну строку уместить «Они ничего не получают сверху. По нашим ожиданиям они должны быть рады интересным задачам и возможностям».
Можно было и так написать. Но я боялся, что подобной формулировкой не донесу свою основную мысль. Автотесты — это инструмент, который в умелых руках упрощает и ускоряет работу тестировщика. Умение с ним работать — само по себе профит. Не считая того, что это дополнительный навык работы с кодом в целом, что довольно важно в IT-индустрии.
Они ничего не получают сверху. По нашим ожиданиям они должны быть рады интересным задачам и возможностям
Это не совсем так.
1. Лиды учитывают вклад ручных тестировщиков в автоматизацию при проведении ревью (подробнее можно почитать тут: habrahabr.ru/company/badoo/blog/331570). Т.е. наличие автоматизации влияет на размер премии.
2. Кроме того, суммарный вклад в автоматизацию влияет на внутренний уровень сотрудника департамента QA (чем больше вклад, тем больше вероятность подняться на следующий уровень; чем выше уровень, тем выше з/п).
3. Ну и на самом деле даже в ручное тестирование мы стараемся набирать высококлассных специалистов, что позволяет нам в рамках одного уровня делать з/п одинаковой и ручным тестировщикам, и автоматизаторам (уверяю вас, задачи на ручное тестирование у нас ничуть не менее интересные/сложные/трудоемкие, чем задачи на автоматизацию).
Не знаю, как в Badoo, но крутой ручной тестировщик by design не получает меньше крутого автоматизатора :) Поэтому не понимаю ваш вопрос.
By design работа автотестера предполагает наличие специальных навыков, это должно учитываться. Так что дело здесь, скорее, в различной степени «крутости». Типичные автотестеры получают выше типичных мануальщиков.
Обычно на вакансиях Manual QA, которые я видел, величина зарплаты поменьше.
Но там где мне приходилось работать, разделения на manual и automation QA не было. Все были вовлечены в автоматизацию, соответсвенно от senior qa ожидают больших навыков автоматизации, чем от junior.
Но там где мне приходилось работать, разделения на manual и automation QA не было. Все были вовлечены в автоматизацию, соответсвенно от senior qa ожидают больших навыков автоматизации, чем от junior.
Спасибо за статью. Почерпнул для себя пару идей про нестабильные тесты. Расскажите, пожалуйста, поподробнее про SeleniumManager. Это ваша собственная разработка? Что умеет делать этот менеджер? Отдельная статья про SeleniumManager была бы очень кстати.
Спасибо за отзыв.
SeleniumManager — это самописный интерфейс, который упрощает работу с автотестами. Он умеет запускать тесты параллельно по группам, умеет хранить в себе и красиво показывать результаты прогонов для разных задач, независимо от того, где эти тесты были запущены — на облаке, в CI или локально, фильтруя их и указывая особенно подозрительные падения.
Помимо этого там есть интерфейс для добавления тестов в список “сломанных”, графики стабильности тестов и нагрузки на selenium-ноды, список самых частых ошибок и так далее.
Да, я уже подумал о том, чтобы написать про него статью. Но хочется не просто рассказать, какой инструмент у нас есть, а рассказать так, чтобы кому-то захотелось себе такой же, и чтобы этот кто-то уже знал, как его создать. :)
Как только я структурирую эту информацию и найду время облачить ее в слова, выйдет новая статья.
SeleniumManager — это самописный интерфейс, который упрощает работу с автотестами. Он умеет запускать тесты параллельно по группам, умеет хранить в себе и красиво показывать результаты прогонов для разных задач, независимо от того, где эти тесты были запущены — на облаке, в CI или локально, фильтруя их и указывая особенно подозрительные падения.
Помимо этого там есть интерфейс для добавления тестов в список “сломанных”, графики стабильности тестов и нагрузки на selenium-ноды, список самых частых ошибок и так далее.
Да, я уже подумал о том, чтобы написать про него статью. Но хочется не просто рассказать, какой инструмент у нас есть, а рассказать так, чтобы кому-то захотелось себе такой же, и чтобы этот кто-то уже знал, как его создать. :)
Как только я структурирую эту информацию и найду время облачить ее в слова, выйдет новая статья.
Интересная публикация, спасибо! А в TeamCity нет средств параметризации для создания параметризованных сборок, к примеру для запуска тестов по группам? Для стека JAVA + Testng + Jenkins есть возможность завести параметры groups и для каждого метода-теста указать группу, к которой он принадлежит (вида Test(groups = {«all», ..}), и в дальнейшем запускать необходимую. Ну и Allure — для отображения состояния тестов в графическом виде.
Спасибо, хорошая статья.
Можно немножко подробностей из внутренней Wiki?
Например, как составлять локатор.
Можно немножко подробностей из внутренней Wiki?
Например, как составлять локатор.
Там довольно много рекомендаций, которые работаю для нашего проекта.
По поводу локаторов. Например, новые локаторы мы стараемся писать на css, однако если правится локатор, который уже написан на xpath, переводить его на css не стоит — высока вероятность, что этот локатор складывается с другим.
Еще пример. Бывает, что в xpath-локаторе у одного тега описывается сразу два класса:
То лучше эти два класса разделять вот так:
Дело в том, что классы элементам довольно часто добавляются динамически через JS, а значит асинхронно. И порядок, в котором классы будут добавлены, может меняться. В итоге элемент не будет находиться, а тест будет падать через раз.
Или как правильно работать с SVG, используя xpath-локаторы.
В целом там довольно много примеров, все не перечислить. Мы туда добавляем все знания, которые кажутся нам важными или из-за которых мы сталкивались с какими-то сложностями.
По поводу локаторов. Например, новые локаторы мы стараемся писать на css, однако если правится локатор, который уже написан на xpath, переводить его на css не стоит — высока вероятность, что этот локатор складывается с другим.
Еще пример. Бывает, что в xpath-локаторе у одного тега описывается сразу два класса:
//div/a[contains(@class,"added active")]То лучше эти два класса разделять вот так:
//div/a[contains(@class,"added")][contains(@class,"active")]Дело в том, что классы элементам довольно часто добавляются динамически через JS, а значит асинхронно. И порядок, в котором классы будут добавлены, может меняться. В итоге элемент не будет находиться, а тест будет падать через раз.
Или как правильно работать с SVG, используя xpath-локаторы.
В целом там довольно много примеров, все не перечислить. Мы туда добавляем все знания, которые кажутся нам важными или из-за которых мы сталкивались с какими-то сложностями.
За год работы я добился от нашей автоматизации того, что если тест падает, он указывает на действительную проблему в системе. Я не делаю насильственной популяризации автоматизации в проекте, но добился за год того, что ко мне приходят и спрашивают, можно ли функцию автоматически протестировать, я пишу им для этого тест. (Или говорю, мол, нет, слишком затратно, или что тест не будет стабильным). Или после изменений разработчики прогоняют UI-тесты через локальную сборку (DevBuild) и сравнивают результаты на регрессию. Для меня все это хороший знак.
Инструментт тестирования у нас в принципе простой, но никто не хочет этим заниматься помимо основной работы. Да и я видел какие разработчики пишут юнит-тесты, не надо на них вешать автоматизацию :) У меня даже есть гипотеза, что разработчики подсознательно не видят крайних случаев, потому что мозг знает что если их увидеть, то это выльется в дополнительную работу.
Инструментт тестирования у нас в принципе простой, но никто не хочет этим заниматься помимо основной работы. Да и я видел какие разработчики пишут юнит-тесты, не надо на них вешать автоматизацию :) У меня даже есть гипотеза, что разработчики подсознательно не видят крайних случаев, потому что мозг знает что если их увидеть, то это выльется в дополнительную работу.
Очень точно подмечено про крайние случаи.
А эти крайние случаи в коде обрабатываются явно? Если нет, то и юнит-тесты на них обычно не нужны.
я имею ввиду, что разработчик пишет например тест на контейнер с методами добавления и удаления элементов. Часто можно увидеть такой тест: три раза добавили, три раза удалили, проверили размер ноль. Т.е. проверка только того чем разработчик собирается пользоваться. При этом редко тестируются крайние случаи, как например, что будет если контейнер пустой, и мы попытаемся удалить элемент. Потому что как бы зачем это делать. «Я же не собираюсь удалять что-то из пустого контейнера» — думает себе разработчик. А по ходу программы такое может произойти. И выяснится, что вылетит какое нибудь исключение. А исключение это что? Это обычно указание на то, что какой-то случай не учли. Например то, что объект может быть нулевым. Каждую неделю один-два тикета из-за NPE это норма.
Вот, ради примера, кусок теста из опенсурсного проекта jmonkeyengine:
Я пишу тесты не для того чтобы покрыть код тестами, а потому, что я ни нихрена не знаю как поведет себя этот код в нестандартной ситуации. Я давно избавился от наивной веры в то, что «оно как написано так и работает». Практика показывает, что это не так. Даже у лучших из лучших. Баги возникают именно в той ситуации которая как бы не должна была произойти.
Ну вот, я вам обьяснил, что я имею ввиду, теперь вы мне обьясните, что Вы имеете ввиду. Желательно с примером.
Вот, ради примера, кусок теста из опенсурсного проекта jmonkeyengine:
код
То, что эта струкрура данных делает, то что должна по замыслу разработчика, я не сомневаюсь — этот случай не интересен. Интересно, что будет когда ключом будет строка а значением null. Или еще какой-нибудь странный случай. Мы не знаем для чего будут использовать эту структуру данных и где. ListMap<String, String> listMap = new ListMap<String, String>();
listMap.put("bob", "hello");
assert "hello".equals(listMap.get("bob"));
assert "hello".equals(listMap.remove("bob"));
assert listMap.size() == 0;
assert listMap.isEmpty();
Я пишу тесты не для того чтобы покрыть код тестами, а потому, что я ни нихрена не знаю как поведет себя этот код в нестандартной ситуации. Я давно избавился от наивной веры в то, что «оно как написано так и работает». Практика показывает, что это не так. Даже у лучших из лучших. Баги возникают именно в той ситуации которая как бы не должна была произойти.
Ну вот, я вам обьяснил, что я имею ввиду, теперь вы мне обьясните, что Вы имеете ввиду. Желательно с примером.
Пропустил как-то, но лучше поздно, чем никогда.
Да, я обычно не пишу тесты в процессе разработки на крайние случаи, если этот случай я в своём коде не обрабатываю. Если где-то в рантайме языка или используемой библиотеке (не важно стандартной, сторонней или своей) произойдёт ошибка в каком-то случае и я о возможности такой ошибки не подумал, не обработал её в коде (или хотя бы не написал в аннотации к методу @throws NullPointerException), то тестов я на неё не пишу. Для меня это неопределённое поведение. Если мысль о возможной ошибки возникла, то уточню требования — если будут, то напишу тест на новое требование и код, его реализующий (хотя бы аннотацию об исключении). Если нет, то так и оставлю до лучших времён.
Будет баг-репорт о недопустимости NPE и возвращения какого-то специального значения, либо выбросе другого исключения — напишу тест на этот случай, который упадёт сразу, а потом сделаю так, чтобы поведение было ожидаемым.
Главная опасность при таком подходе — кто-то (даже я сам позднее) может завязаться на недокументированное, не покрытое тестами поведение, отлавливать, например, конкретно NPE и что-то делать, да ещё и без тестов со своей стороны, а когда я всё-таки изменю на, например, возврат null (или при обновлении рантайма/зависимостей поведение изменится), то не моя ошибка неизвестно где и как проявится. Причём ошибкой тут будет завязываться на неопределенное поведение моего метода, а не если не исправление его на другое, то написания теста на мой метод, на проброс NPE.
Не совсем понятен воркфлоу в ситуации, когда правят тесты сами тестировщики.
Правильно ли я понимаю, что разработчик не прогоняет тесты, этим занимается тестер, попутно определяя тест упал, условно, из-за изменений в верстке либо из-за бага? Или разработчик фиксит тесты упавшие по багам, а требующие апдейта тестов падения оставляет тестировщику?
И поскольку Вы пишите, что ранее тесты фиксились от релиза до следующего релиза, то в продакшен код попадал с красными тестами (возможно неработающим функционалом)?
line 1 -> line 2 -> line 3 = 123
line 12 -> line 3 = 123
может разделители? или такое опущено за маловероятностью?)
Правильно ли я понимаю, что разработчик не прогоняет тесты, этим занимается тестер, попутно определяя тест упал, условно, из-за изменений в верстке либо из-за бага? Или разработчик фиксит тесты упавшие по багам, а требующие апдейта тестов падения оставляет тестировщику?
И поскольку Вы пишите, что ранее тесты фиксились от релиза до следующего релиза, то в продакшен код попадал с красными тестами (возможно неработающим функционалом)?
Помимо вышеперечисленных полей, в таблицу было добавлено новое – код ошибки. Этот код формируется на основе трейса упавшего теста. Например, в задаче А тест упал на строке 74, где он вызвал строку 85, где был вызван UI-класс на строке 15. Почему бы нам не склеить и не записать эту информацию: 748515?
line 1 -> line 2 -> line 3 = 123
line 12 -> line 3 = 123
может разделители? или такое опущено за маловероятностью?)
По поводу воркфлоу. Все тесты у нас запускаются автоматически, когда задача готова — код написан и прошел код-ревью. Когда она попадает к тестировщику, он уже видит список сломанных тестов.
Для unit-тестов у нас отдельный флоу. Если для какой-то задачи падает unit-тест, то AIDA (о ней можно почитать тут — https://habrahabr.ru/company/badoo/blog/169417/) оповещает разработчика, и он сам правит тест.
Если же ломается интеграционный тест, то тестировщик занимается им самостоятельно. Он определяет, почему тест сломался. Если это баг, задача возвращается на доработку. Если что-то изменилось и тест надо поправить, тестировщик его правит в той же ветке, где и код задачи, после чего отправляет задачу в релиз.
Бывают сложные кейзы, когда для починки теста не обойтись изменением одного или двух локаторов. Тогда все уже зависит от желания и квалификации тестировщика. Если он может, он переписывает тест. Если не может или задача срочная и на это нет времени, этим занимаются автоматизаторы. Тут все строится на интересе и на взаимовыручки.
Для unit-тестов у нас отдельный флоу. Если для какой-то задачи падает unit-тест, то AIDA (о ней можно почитать тут — https://habrahabr.ru/company/badoo/blog/169417/) оповещает разработчика, и он сам правит тест.
Если же ломается интеграционный тест, то тестировщик занимается им самостоятельно. Он определяет, почему тест сломался. Если это баг, задача возвращается на доработку. Если что-то изменилось и тест надо поправить, тестировщик его правит в той же ветке, где и код задачи, после чего отправляет задачу в релиз.
Бывают сложные кейзы, когда для починки теста не обойтись изменением одного или двух локаторов. Тогда все уже зависит от желания и квалификации тестировщика. Если он может, он переписывает тест. Если не может или задача срочная и на это нет времени, этим занимаются автоматизаторы. Тут все строится на интересе и на взаимовыручки.
Мы договорились, что никаких логических проверок типа assert в таких классах быть не должно – только взаимодействие с UI
Очень интересно… что вы тогда тестируете
1. Ввел креды: logtester/passtester
2. Зашел на страницу — как мне узнать под тем ли я юзером? Нужно найти метод который мне вернет юзера так? А что если таких проверок 10000, если это какая нить форма огромная?
Второй момент, Вы показали только код ваших инпутов, а теперь покажи ваши километровые трайкетчи метода submitForm() и waitForAuthPage(), ведь ошибок может быть масса — как вы их разделяете? Простой пример ошибка валидатора пароля: слишком короткий, и запрещенные символы.
В общем, не хочу Вас обидеть или еще что, но Ваша идея (ту которую я увидел из кода) — это плохой стиль. При такой вариации, сложно делать data-driven тесты, сложно так же управлять потоками данных (представьте лапшу из if, если Ваш фреймворк будет тестировать форум с большим discretionary access control).
На самом деле, немного оффтопа, за время, которое я провел за автотестами, у меня выработался набор небольших правил:
— Композиция, никакого наследования, никаких гетеров/сеттеров, меньше тра/кетчей, все только по тай-маутам (элемент должен появиться рано или поздно, если нет — упали)
— PageObject не всегда хорош, Widget/Elements куда удобнее, особенно когда на проекте 100500 разных Drop-Down листов и не только.
— Все проверки строго по данным, которые берутся из базы/мусора/бумажки. В фреймворке только проверка перехода через страницу (деление страниц до тех пор, пока не будет уникального идентификатора). Страница должна самодостаточно себя определить, как абстрактный элемент теста: страница корзины одинакова — будет она вызвана из личного кабинета, или из айтема покупки, а вот виджеты «Добавленные покупки» уже будет другой, в таком случае в страницу Корзина я могу добавить автопроверку в конструктор при переходе на нее, и если переход состоялся куда я не ожидал (нет на страницы скажем h1 «Корзина») то я «заваливаюсь».
— Приучитесь писать run-конфигурации для тест-энвайромента: есть 100 тестов, они все разрозненны, но есть тест сьюты, которые должны проверять функциональности. Берем пачку тестов, засовываем в конфигурацию, прикрепляем в бранчу/тикету/ — готово. Это облегчает запуск, и всегда из ранее готовых тестов можно «набрать» нужную функциональность, обозвать для нее конфигурацию, и запускать.
Спасибо за Ваш интерес к нашему коду. К сожалению, я не увидел в Вашем комментарии четко сформулированного вопроса, только поток сознания. :)
Что касается оффтопа, то может Вам стоит написать статью о том, как Вы организовываете свой код тестов и какой профит с этого имеете? С удовольствием почитаю. Только соберите мысли в порядок и пишите побольше наглядных примеров. Удачи!
Что касается оффтопа, то может Вам стоит написать статью о том, как Вы организовываете свой код тестов и какой профит с этого имеете? С удовольствием почитаю. Только соберите мысли в порядок и пишите побольше наглядных примеров. Удачи!
а можно подробностей про Widget/Elements?
Основная суть в том, что на момент создания каркаса приложения для тестирования, вы не описываете страницы целиком, а делаете некую структуру модулей внутри страницы. К примеру, есть страница товаров, она включает в себя:
— виджет Товар
— виджет калькулятор (общая цена зачеканных товаров)
— виджет препросмотр (ну например там фотки посмотреть)
Создаем три класса виджетов, и оперируем только входящими для них элементами, и состояниями.
Например для товара это будет, чекбокс выбора, атрибут цены. Для других все точно такое же (для калькулятора результирующая цена, для предпросмотра текущее фото, общее кол. фоток)
Уточнение: Виджетом я называю какую либо активною, порождающую сущность, иными словами, такую, которая может мне вернуть новую страницу, элементом же я называю сущности, которые работают с текущей страницей: Айтем товара, это виджет, так как он мне может вернуть страницу товара, а вот фильтр на странице каталога (по цене например) уже будет элементом, так как он изменяет лишь содержимое страницы, не меняя ее структуры
Далее вы пишите PageItemViewet класс (непосредственно PageObj, которая вам реализует работу с каталогом) и создаете композицию из предопределенных виджетов, при этом не забывая о согласовании интерфейсов между классами:
— pageobj должен сам иметь счетчик ссылок, на множества елементов (вы должны хранить ссылку на каждый товар, и только при использовании товара (выделении, проверки цены ) непосредственно пересоздавать ваш виджет.
— pageobj обязан знать, кто его вызвал, и где он находится, более того для каждого pageobj при создании необходимо проверять текущее положение в веб-приложении, я обычно проверяю в конструкторе уникальных элемент для данной страницы, как пример: при создании при переходе на страницу каталога, я смотрю на заголовок каталога, если он совпадает с тем, куда меня отправил предыдущий шаг — значит я на верной странице. данное действие избавляет от необходимости в тестах, чекать каждый чих переходов (но злоупотреблять им не следует, обычно это основные страницы (каталог, о магазине, контакты, определенный товар)
— все елементы (не активные виджеты) обязательно должны иметь автообновляемые свойства, иначе вы рискуете потерять целостность вашего состояния (вы добавили товар, спрашиваете у калькулятора какова текущая общая стоимость, он вернул 10, вы добавили еще один товар, спрашиваете у калькулятора, а теперь? — он вернул 10, очевидная ошибка, сохраненное предыдущее состояние.)
— реализация getter-ов должна быть сугубо на стороне элементов, и только они должны вам отдавать информацию со страницы. Pageobj являюется только агрегатором виджетов, и хранилищем текущего состояния теста (страницей выполнения).
Как то так. Спасибо за внимание)
— виджет Товар
— виджет калькулятор (общая цена зачеканных товаров)
— виджет препросмотр (ну например там фотки посмотреть)
Создаем три класса виджетов, и оперируем только входящими для них элементами, и состояниями.
Например для товара это будет, чекбокс выбора, атрибут цены. Для других все точно такое же (для калькулятора результирующая цена, для предпросмотра текущее фото, общее кол. фоток)
Уточнение: Виджетом я называю какую либо активною, порождающую сущность, иными словами, такую, которая может мне вернуть новую страницу, элементом же я называю сущности, которые работают с текущей страницей: Айтем товара, это виджет, так как он мне может вернуть страницу товара, а вот фильтр на странице каталога (по цене например) уже будет элементом, так как он изменяет лишь содержимое страницы, не меняя ее структуры
Далее вы пишите PageItemViewet класс (непосредственно PageObj, которая вам реализует работу с каталогом) и создаете композицию из предопределенных виджетов, при этом не забывая о согласовании интерфейсов между классами:
— pageobj должен сам иметь счетчик ссылок, на множества елементов (вы должны хранить ссылку на каждый товар, и только при использовании товара (выделении, проверки цены ) непосредственно пересоздавать ваш виджет.
— pageobj обязан знать, кто его вызвал, и где он находится, более того для каждого pageobj при создании необходимо проверять текущее положение в веб-приложении, я обычно проверяю в конструкторе уникальных элемент для данной страницы, как пример: при создании при переходе на страницу каталога, я смотрю на заголовок каталога, если он совпадает с тем, куда меня отправил предыдущий шаг — значит я на верной странице. данное действие избавляет от необходимости в тестах, чекать каждый чих переходов (но злоупотреблять им не следует, обычно это основные страницы (каталог, о магазине, контакты, определенный товар)
— все елементы (не активные виджеты) обязательно должны иметь автообновляемые свойства, иначе вы рискуете потерять целостность вашего состояния (вы добавили товар, спрашиваете у калькулятора какова текущая общая стоимость, он вернул 10, вы добавили еще один товар, спрашиваете у калькулятора, а теперь? — он вернул 10, очевидная ошибка, сохраненное предыдущее состояние.)
— реализация getter-ов должна быть сугубо на стороне элементов, и только они должны вам отдавать информацию со страницы. Pageobj являюется только агрегатором виджетов, и хранилищем текущего состояния теста (страницей выполнения).
Как то так. Спасибо за внимание)
Интересная статья, большое спасибо!
Интересно, а с какими трудностями сталкивались при обучении Manual QA чтению и модификации тестов? Все таки тесты — это тоже исходный код, техническая часть. Были ли сложности с пониманием тех или иных принципов авто-тестирования, и какие именно?
P.S.: Очень хотелось бы помочь своим мануальщикам начать использовать авто-тесты, вот и интересуюсь о подводных граблях :)
Интересно, а с какими трудностями сталкивались при обучении Manual QA чтению и модификации тестов? Все таки тесты — это тоже исходный код, техническая часть. Были ли сложности с пониманием тех или иных принципов авто-тестирования, и какие именно?
P.S.: Очень хотелось бы помочь своим мануальщикам начать использовать авто-тесты, вот и интересуюсь о подводных граблях :)
Тут, как и с любым инструментом, надо начинать знакомиться с простых вещей. Можно показать, как запускать тесты. Если это сделано неудобно, стоит сначала оптимизировать процесс. Чем проще запустить тест, тем чаще его будут запускать.
Далее важно сделать удобный вывод репорта об ошибке. У нас он пишет, какой user был авторизован, делает скриншот и HTML-слепок, пишет строку для перезапуска теста в консоли и так далее.
Сами тексты ошибок, которые формируются, если элемент не найден или какой-то assert не сработал, стоит писать подробно. Так, чтобы глядя на скриншот было понятно, в чем проблема.
Только когда тесты готовы к тому, чтобы ими можно был легко пользоваться, стоит привлекать тестировщиков или девелоперов к их использованию. Тут важно не спугнуть. :)
Что касается работе с кодом, само собой все приходит с опытом. Волне нормально, если допускаются стилистические или даже логические ошибки. Для этого есть код-ревью, где более опытный коллега может подсказать верное решение.
Главное начать! А опыт придет.
Далее важно сделать удобный вывод репорта об ошибке. У нас он пишет, какой user был авторизован, делает скриншот и HTML-слепок, пишет строку для перезапуска теста в консоли и так далее.
Сами тексты ошибок, которые формируются, если элемент не найден или какой-то assert не сработал, стоит писать подробно. Так, чтобы глядя на скриншот было понятно, в чем проблема.
Только когда тесты готовы к тому, чтобы ими можно был легко пользоваться, стоит привлекать тестировщиков или девелоперов к их использованию. Тут важно не спугнуть. :)
Что касается работе с кодом, само собой все приходит с опытом. Волне нормально, если допускаются стилистические или даже логические ошибки. Для этого есть код-ревью, где более опытный коллега может подсказать верное решение.
Главное начать! А опыт придет.
Есть вопрос — ловите ли как-то «false positive» тесты — вроде assert(1,1) — они всегда будут зелеными, независимо от изменений кода.
Добрый день.
Да, конечно, иногда бывает так, что тест проверяет фичу не в полном объеме и пропускает что-то. Обычно такое отлавливается как раз ручными тестировщиками, которые находят баг руками и видят, что тест его пропустил.
Если это не долго, тестировщик может сам добавить нужную проверку. Если же это займет существенное время, ставит тикет.
Более того, у нас устроено так, что для любого тикета с пометкой баг автоматически ставится QA-тикет на дописание нужного теста. Это очень удобно и положительно влияет на покрытие.
Да, конечно, иногда бывает так, что тест проверяет фичу не в полном объеме и пропускает что-то. Обычно такое отлавливается как раз ручными тестировщиками, которые находят баг руками и видят, что тест его пропустил.
Если это не долго, тестировщик может сам добавить нужную проверку. Если же это займет существенное время, ставит тикет.
Более того, у нас устроено так, что для любого тикета с пометкой баг автоматически ставится QA-тикет на дописание нужного теста. Это очень удобно и положительно влияет на покрытие.
Добрый день, есть два вопроса:
1) Вы определяете покрытие тестами? Если да, то как?
2) Так как система большая, а разработчиков тестов много, как вы определяете, что автотесты взаимонепересекающиеся? Т.е. что нет двух автотестов которые частично или полностью проверяют одно и то же?
1) Вы определяете покрытие тестами? Если да, то как?
2) Так как система большая, а разработчиков тестов много, как вы определяете, что автотесты взаимонепересекающиеся? Т.е. что нет двух автотестов которые частично или полностью проверяют одно и то же?
Добрый день.
1) Да, мы ведем учет тестов. Само собой, речь идет не о покрытий строк кода, как для unit-тестов. Ведь даже простое открытие страницы чаще всего затрагивает много классов и методов, хотя мы еще ничего не проверили. Для функциональных тестов мы считаем, какое количество фич мы покрыли автотестами, из общего их количества. У нас есть внутренний документ, где мы ведём подобную статистику.
Когда появляется новый функционал на сайте, мы дописываем его в этот документ, и покрытие падает. Когда пишем тесты — покрытие снова оказывается на прежнем уровне. Так мы развиваем покрытие «в ширину».
Помимо этого, как я уже писал в одном из комментариев, если тестировщик находит баг, который автотестами был пропущен, мы ставим тикет на автоматизацию. Это помогает «углубиться» в тестирование фичи, покрывая ее особенно уязвимые кейзы.
2) Существует некоторое конечное число направлений, в которых мы развиваем автоматизацию у нас в компании. Биллинг и интерфейсы, Desktop Web, Mobile Web, iOS и Android приложения, тестирование API и так далее. За каждый компонент отвечает один человек. Он знает, какие тесты есть, и через его код-ревью как правило проходит весь-весь-весь новый код, связанный с его зоной ответственности. Таким образом он следит за повторениями.
Помимо этого у нас есть внутренние документы, которые я описал выше. Они тоже помогает в решении такой задачи.
1) Да, мы ведем учет тестов. Само собой, речь идет не о покрытий строк кода, как для unit-тестов. Ведь даже простое открытие страницы чаще всего затрагивает много классов и методов, хотя мы еще ничего не проверили. Для функциональных тестов мы считаем, какое количество фич мы покрыли автотестами, из общего их количества. У нас есть внутренний документ, где мы ведём подобную статистику.
Когда появляется новый функционал на сайте, мы дописываем его в этот документ, и покрытие падает. Когда пишем тесты — покрытие снова оказывается на прежнем уровне. Так мы развиваем покрытие «в ширину».
Помимо этого, как я уже писал в одном из комментариев, если тестировщик находит баг, который автотестами был пропущен, мы ставим тикет на автоматизацию. Это помогает «углубиться» в тестирование фичи, покрывая ее особенно уязвимые кейзы.
2) Существует некоторое конечное число направлений, в которых мы развиваем автоматизацию у нас в компании. Биллинг и интерфейсы, Desktop Web, Mobile Web, iOS и Android приложения, тестирование API и так далее. За каждый компонент отвечает один человек. Он знает, какие тесты есть, и через его код-ревью как правило проходит весь-весь-весь новый код, связанный с его зоной ответственности. Таким образом он следит за повторениями.
Помимо этого у нас есть внутренние документы, которые я описал выше. Они тоже помогает в решении такой задачи.
0.
Вы поднимаете тесты после релиза? Почему не до?
1.
Почему поднятием тестов занимается не программист? Зачем лишнее звено — автотестер?
2.
Функциональность.
3.
Именно это решение вы и реализовали, разве нет? Вы попытались сделать из «ручных тестеров» «автоматизаторов», но почему-то не путем повышения квалификации, а путем снижения порога входа и упрощением системы тестов (что само по себе стоит дорого)
4.
До этого не так? Как вы убивались об версионирование кода приложения и кода тестов?
5. Вы не считаете порочным деление на «автоматизаторов»" и «ручных тестеров»? Автоматизация всего лишь инструмент. Ваши автоматизаторы тестировать умеют?
Спасибо большое, очень интересная статья.
В какой-то момент мы оказались в ситуации, когда правка тестов после релиза занимала почти всё время, которое было у автоматизатора до следующего релиза.
Вы поднимаете тесты после релиза? Почему не до?
1.
В какой-то момент мы оказались в ситуации, когда правка тестов после релиза занимала почти всё время, которое было у автоматизатора до следующего релиза.
Почему поднятием тестов занимается не программист? Зачем лишнее звено — автотестер?
2.
функционал
Функциональность.
3.
Первое решение, которое приходит в голову, — нанять ещё одного автоматизатора.
Именно это решение вы и реализовали, разве нет? Вы попытались сделать из «ручных тестеров» «автоматизаторов», но почему-то не путем повышения квалификации, а путем снижения порога входа и упрощением системы тестов (что само по себе стоит дорого)
4.
Когда ребята начали работать с тестами в своих задачах, мы договорились, что правки будут вноситься в ту же ветку, где лежит код задачи.
До этого не так? Как вы убивались об версионирование кода приложения и кода тестов?
5. Вы не считаете порочным деление на «автоматизаторов»" и «ручных тестеров»? Автоматизация всего лишь инструмент. Ваши автоматизаторы тестировать умеют?
Спасибо большое, очень интересная статья.
Вы поднимаете тесты после релиза? Почему не до?
Я здесь не достаточно корректно написал, согласен. Имеется в виду, что как только релиз оказывается на стейджинге, у нас есть где-то 4 часа на его проверку, прежде чем он окажется на продакшене. В какой-то момент мы оказались в ситуации, когда все эти 4 часа уходили на следующее.
Мы проверяли каждый тест, если он падал из-за бага, искали тикет, который этот функционал сломал, чтобы либо запатчить, либо откатить, в зависимости от серьезности проблемы.
Если же тест падал из-за изменений, мы либо чинили его, если это было быстро и у нас еще оставалось время, любо откладывали его починку и проверяли функционал руками. Само собой, работать в такой суматохе было довольно сложно, к тому же мы рисковали иногда в спешке ошибочно решить, что тест падает, «это не страшно, поправлю потом».
Сейчас тестирование релиза происходит куда спокойнее.
Почему поднятием тестов занимается не программист? Зачем лишнее звено — автотестер?
Именно запуском тестов у нас вообще занимаются скрипты или CI, в зависимости от окружения. Все автоматизированно.
Что касается починкой тестов. У нас в компании написанием функциональных тестов занимается отдел тестирования. Это наш инструмент для более тщательной и быстрой проверки функционала. Следовательно и починкой занимаемся тоже мы. Во-первых, мы уже знаем как эти тесты устроены, так как сами их разработали, во-вторых, когда тест падает, именно нам нужна информация о том, почему он упал. Может быть это не тест надо править, а тикет переоткрывать.
Именно это решение вы и реализовали, разве нет? Вы попытались сделать из «ручных тестеров» «автоматизаторов», но почему-то не путем повышения квалификации, а путем снижения порога входа и упрощением системы тестов (что само по себе стоит дорого)
В чем-то Вы правы, мы действительно научили ребят из ручного тестирования работе с тестами. Но те задачи, которые они решают, это еще не все задачи, которые в целом существуют в автоматизации.
Они, по сути, работают уже с готовым фреймворком и готовым окружением, в рамках которых пишут новые тесты или правят старые. Но поддержание этой архитектуры, создание базового кода, настойка автозапусков, обновление selenium, браузеров и прочего тоже занимает время. Этим у нас уже по большей части занимаются автоматизаторы.
До этого не так? Как вы убивались об версионирование кода приложения и кода тестов?
До этого мы запускали тесты с ветки Master и вносили изменений тоже в Master. В целом такой подход работал. Но иногда были сложности, да. Например, мы вносили правки к задаче, которая еще была в релизе, а потом ее откатывали. Сейчас, когда мы запускаем тесты с ветки релиза, все стало удобнее и лучше.
Вы не считаете порочным деление на «автоматизаторов»" и «ручных тестеров»? Автоматизация всего лишь инструмент. Ваши автоматизаторы тестировать умеют?
Лично я такое деление не считаю порочным. У нас это скорее не вопрос способности, а определение зоны ответственности. Я прихожу каждый день на работу, пью кофе и сажусь работать с автотестами. Кто-то приходит, кушает булочку и садится тестировать задачи. Каждый занимается своим делом. :)
Спасибо за Ваши вопросы и Ваш отзыв.
Вы используете Codeception?
Если да то чем обусловлен выбор кроме того что cам продукт написан на php? Если использовали менйстрим решения на вроде testNG можете сказать почему не его?
ps. Сам начинал с Codeception, и сейчас перейдя на TestNG и Robot, ловлю себя на мысли как же там было удобно и просто писать тесты.
Если да то чем обусловлен выбор кроме того что cам продукт написан на php? Если использовали менйстрим решения на вроде testNG можете сказать почему не его?
ps. Сам начинал с Codeception, и сейчас перейдя на TestNG и Robot, ловлю себя на мысли как же там было удобно и просто писать тесты.
Когда только начинали писать selenium-тесты, скачали себе последнюю на тот момент версию Facebook Webdriver Framework (https://github.com/facebook/php-webdriver). Сами тесты писали, используя Phpunit Framework (https://github.com/sebastianbergmann/phpunit).
Однако у нас появлялись какие-то свои решения и хотелки, которые мы самостоятельно вносили в FB Framework. Сейчас он довольно сильно переписан и имеет мало общего с текущей версией.
У нас есть внутренние проекты, которые мы покрываем новой версией FB Framework и собираем все через Composer, стараясь не влезать в код библиотек. Не могу сказать, что это принесло какие-то плюшки против собственного фреймворка. Просто эти проекты поменьше и тестов там тоже меньше.
Codeception мы не пробовали внедрять. В тесты для боевого проекта это будет сделать неоправданно сложно. Возможно мы опробуем его на каком-то из внутренних проектов и тогда я напишу свое мнение. :)
Однако у нас появлялись какие-то свои решения и хотелки, которые мы самостоятельно вносили в FB Framework. Сейчас он довольно сильно переписан и имеет мало общего с текущей версией.
У нас есть внутренние проекты, которые мы покрываем новой версией FB Framework и собираем все через Composer, стараясь не влезать в код библиотек. Не могу сказать, что это принесло какие-то плюшки против собственного фреймворка. Просто эти проекты поменьше и тестов там тоже меньше.
Codeception мы не пробовали внедрять. В тесты для боевого проекта это будет сделать неоправданно сложно. Возможно мы опробуем его на каком-то из внутренних проектов и тогда я напишу свое мнение. :)
Вообщем, было принято решение не нанимать автоматизаторов с улицы, а делать автоматизаторов внутри. Чем это не увеличение штата. Принципиально другим решением было бы какое-о изменение процесса, которое вело бы к более стабильным тестам или что-то вроде того. Ваше решение — это увеличение manpower так или иначе. А что делать мануальным тестировщикам, которые из-за увеличения загрузки автоматизацией, не будут успевать делать свои задачи? Они кого будут привлекать и обучать своим активити? Или они всё же будут кого-то нанимать?
Принципиально другим решением было бы какое-о изменение процесса, которое вело бы к более стабильным тестам или что-то вроде того.
Одно другому не мешает. Со стороны тестов тоже были сделаны изменения. Я об этом писал в той части, где рассказывал о подготовительных работах, о TeamCity, и о сломанных и нестабильных тестах.
А что делать мануальным тестировщикам, которые из-за увеличения загрузки автоматизацией, не будут успевать делать свои задачи?
Вы же понимаете, что автоматизаторы не бегают среди прикованных цепями ручников, заставляя во что бы то не стало править тесты и наливать себе кофе?
Если у тестировщика задача сверх срочная и большая — хотя я упоминал в статье, что такое бывает не часто и давал ссылку на статью, где мы рассказываем, как планируем сроки — само собой, он может обратиться за помощью ко мне или другому автоматизатору и мы поможем ему поправить тесты. Главное, что мы сделает это до того, к задача окажется в релизе. Это и есть то принципиально новое, о чем Вы спрашиваете, как мне кажется.
Если же в задаче надо поправить один-два локатора, согласитесь, это не сильно замедлит тестирование задачи и не отнимет много времени у тестировщика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Selenium для всех: как мы учим QA-инженеров работать с автотестами