testomat.io управление авто тестами@Ayia А мы бы хотели увидеть более детальный репорт 
и сразу в базу знаний этот репорт.
Вовсе необязательно (не для всех видов тестирования пока что есть вменяемые средства автоматизации), хотя предоставляет ряд дополнительных бонусов
Для этого необязательно использовать тот же технологический стек. Преимущество только в том, что не придется разводить “зоопарк” технологий + для некоторых задач есть типовые решения в средствах самого языка программирования.
О, нет. Пока что средства автоматизации не настолько унифицированы, чтобы так просто можно было туда разработчиков подпускать. Для разного рода back-end построенного на всяких вызовах утилит или сервисов это еще применимо, но для GUI, особенно за пределами веб - пока что нет. Только разводить мусорную свалку в коде тестов или забивать голову ненужными деталями. К тому же это работает в основном только для компонентных и интеграционных тестов. Если речь идет о какой-то более разветвленной бизнес-логике, то такого самостоятельного исправления надо избегать.
В команде могут быть еще бизнес-аналитики, менеджеры и прочие люди, которые может и знают/помнят тот или иной язык, но у них хватает своей возни, чтобы колупаться еще в коде. Унификация технологий, используемых при разработке и тестировании имеет другие преимущества:
-
Оптимизация затрат на поддержку/содержание/интеграцию инфраструктуры (так как все делается одним на всех, а не по отдельности + те или иные подходы можно перенять)
-
Возможность переиспользовать компоненты тестируемой системы, что увеличивает покрытие + позволяет делать проверки, которые другими средствами просто недоступны, особенно, если тестируемый компонент используется другим программным компонентом.
-
Наличие более развитого сообщества + наличие материалов + наличие специалистов, которые знают, как этим пользоваться. Для примера, сравните количество специализированных ресурсов\книг\библиотек\прочих материалов по тому же WebDriver-у или QTP, скажем, и по любому языку из списка Java/C#/Python/Ruby.
Но если использовать эти преимущества не удается, то синхронизация используемых технологий особой роли не играет
2 лайка
Можете обьяснить немного подробней, может на более детальных примерах?
Пока что средства автоматизации не настолько унифицированы, чтобы так
просто можно было туда разработчиков подпускать.
По какой причине лучше не подпускать разработчикав?
но для GUI, особенно за пределами веб - пока что нет. Только разводить
мусорную свалку в коде тестов или забивать голову ненужными деталями.
Какими такими ненужными деталями? Тесты ведь ориентированы на приложение со стороны внешнего мира, разве не для него девы пишут код, разве они не должны думать об этом и разбираться? Я понимаю что всегда есть исключения, и могут быть специалисты очень узкого профиля, и они реально на прямую не влияют на “внешний интерфейс” а пишут больше внутренние сервисы…
И в чем будет проявляться мусорная свалка?
Если речь идет о какой-то более разветвленной бизнес-логике, то такого самостоятельного исправления надо избегать.
Тут я конечно же согласен, но не будет необходимости в этом… Бизнес логика обычно меняятся не как “побочный эфект” который мы и хотим устранять или предупреждать с помощью СI, но в контексте какой то “стори”, и понятно, что автоматизировать тест кейсы, или изменять существующие будет тестер.
Моя идея была в том, кроме всех Вами хорошо подмеченых бонусов, мне кажется наиболее полезным будет тот, что “побочные ефекты” выявленные вовремя СI могут быть быстро устранены самими девелоперами… Ведь они и должны быть за это ответственны, и тем более должны приучаться думать о последствиях. Сильная сторона тестеров не в том что они как обезьяны терпят рутинную работу, а в том что они сопособны определить и внедрить правильное/нужное в соответсвии со всеми требованиями покрытие тестами. А не в том чтобы каждый день они приходили на работу и до обеда изменяли тесты которые теперь не проходят, потому что там кто то “локатор” поменял, а там кто то забыл после фикса баги проапдейтить или включить соответсвующий тест…
Конечно все это будет возможно, если кроме того что язык для автотестов будет тем который знает команда (имею ввиду “прикладная ее часть” - девы и автоматизаторы как минимум), но и тесты будут написаны “с умом”, будут краткими/простыми и понятными. Мне не кажеться что в таком случае будет иметь место “мусорная свалка”.
ЗЫ
Впрочем я уверен в том что мир безграничен, и более чем вероятно, что есть такие сферы где мой “категорический” и особенно “идеологический” подход не будет применим. Я буду безмерно рад если вы поделитесь своим опытом или просто мыслями о примерах (может просто более детальных, ибо те что были я понял недостаточно…) где такой подход не принесет большей выгоды.
Я не на достаточном количестве “разных” проектов побывал конечно чтобы судить так категорично. На прошлом у нас были интеграционные автотесты (о юнит и упоминать не хочеться как стандарте) и некоторые функциональные на “языке команды” а также на том же языке был написан фреймворк с DSL, которая предоставляла все возможности для покрытия тестами основного функционала. И в целом жизнь была замечательная. За эту часть приложения отвечали 3 девелопера и 1 тестер (который успевал еще и другую часть приложения тестировать). И все было действительно еджайл, никто никого не ждал, в любое время любой мог просто и понятно поменять любые тесты. Тестер же отвечал в первую очередь за их генерацию. И поскольку количество “рутинной работы” в плане автоматизации была сведена к минимуму - одного тестировщика хватало (девелоперы тоже писали тест фреймворк) на функционал написаный (3 + 1,5) девелоперами, причем учитывая более менее полное покрытие тестами. Хоя и трудно было временами:) Конечно стоит упомянуть что проект был о сервисах. И гуи как такового не было… Поэтому тут примеров со своей стороны привести не могу… Но как минимум знаю проекты где девелоперы отвечают за имплементацию тестирования веба через вебдрайвер, и ничего там такого куда их не следует подпускать нет… С десктоп гуи конечно может быть еще та морока… Там может действительно живут звери к которым требуется особенный подход.
Также хочу заметить… Что я согласен с тем, что есть очень много фактов против которых ну никак не попрешь. Например нет квалифицированых автоматизаторов, которые смогут и на языке девелоперов что то написать, да еще и так что бы им все было понятно).
Также где то в душе я еще надеюсь что при достаточном уровне (к которому стремлюсь), можно используя соответсвующие инструменты, быстро создавать для автоматизации ту DSL которая будет проста и понятна не только девелоперам но и простым меньюел тестировщикам. И тогда не нужно привязывать всех к какому то далекому от предметной области языку. 
1 лайк
Такое не сработает, если используются вендорские тулы типа TestComplete, QTP и прочее, где с 95% вероятностью используется не тот язык, что при разработке. Плюс у этих тулов слишком много своих внутренних заморочек, так что разработчикам придется ознакомиться и с тулом как таковым, и со структурой фреймворка, и с особенностями реализации конкретного набора тестов. В такие детали никто не захочет вникать. А если и начнет, то с большой долей вероятности запутается во всем этом. Уж точно, быстрого фикса не получится.
Тесты-то может и ориентированы на внешнего пользователя, но разработчик таковым не является и то, что он пишет для чего-то код, еще не значит, что он разбирается в самой системе, особенно в системе в целом. Более того, у него свое виденье системы, которое может быть не верным или как минимум не совпадать с вашим. Более того, роль автоматизатора отличается от разработчика тем, что он как бы должен отвечать за качество своих тестов и следить за тем, чтобы они были в состоянии отлавливать потенциальные проблемы. А если код тестов может править кто угодно, то может так оказаться, что вам придется отдуваться за те ошибки и недочеты, которые вы не делали.
Это полезно, если речь идет о юнит и white-box интеграционных тестах, которые пишут сами разработчики. Если каждый билд будет проходить через такой набор тестов, то потом эти же компоненты можно устанавливать на тестовое окружение и запускать более высокоуровневые тесты там, и уже там пусть тестировщики смотрят, что работает, а что нет. В теории, может, и хорошо, если обязанности размыты внутри проекта, но на практике это либо коллизии, либо нежелание лезть в чужую область.
А еще это может выявляться в целенаправленном устранении проверок или подгонки тестовых данных таким образом, чтобы тест проходился, а не чтоб приложение работало корректно.
А вся беда в том, что разработчикам надо выкатить продукт и они заинтересованы в том, чтобы это сделать быстрее. Тестировщики же в этом плане выступают как сдерживающий фактор, который предотвратит поспешность и позволит избежать серьезных ошибок. У тестировщиков должны быть рычаги контроля, которые нельзя обойти. Иначе все эти тесты можно с таким же успехом проигнорировать.
3 лайка
Проблема даже не столько в квалификации. Проблемы в том, что:
-
Понятность - понятие растяжимое и относительное. И само по себе оно не означает ровным счетом ничего. Нету четкого критерия, по которому можно сказать, что то или иное решение понятно.
-
Да и сами инструменты еще далеки от совершенства. Они сами в себе таят кучу ошибок + очень многих вещей нехватает. А чего можно ожидать от решения, если сам инструментарий далек от совершенства.
Ох как мне повезло что я со все этим не работал) Надеюсь и не прийдется)))
Эх… В целом, если ставить себя в ситуации которые Вы описываете - я полностью с Вами согласен.
Я не работал с такими людьми и в таких проектах… Наверное мне повезло… А может я специально выбирал себе проекты и команды) Может и несознательно)
С чем то я конечно тоже сталкивался. Команда у нас была расспределенная… И другая ее часть была с фокусами) Но мы все дружно сделали очень многое, и покрайней мере у нас никогда не было авралов (хотя и были файловые спринты, но мы всегда об этом предупреждали и заказчик знал что это его ошибка а не наша) и свою часть мы делали качественно, да еще умудрялись и забугорную команду строить.
Может я и идеалист… Но мне нравиться всегда стремиться к идеалу (не забывая и про здравый смысл конечно)… Ведь если не стремиться, зачем просто ходить на работу и терпеть все это… Жизнь то одна… Почему бы не попробовать сорвать с неба звезду:)
Думаю меня нужно запхнуть в какой то проект пострашней и увидим как я тогда запою…))) В какой то мере я сейчас как раз на таком проекте… И тесты я пишу не на том языке на котором пишет команда (пришлось продолжать то что уже было начато до меня) и даже не на том что сердцу близок:) и девелоперы вряд ли будут в эти тесты смотреть)
Нус… Поживем увидим) Спасибо большое за Ваш новледж шеринг)
UPDATE:
Я не работал с такими людьми и в таких проектах… Наверное мне
повезло… А может я специально выбирал себе проекты и команды) Может
и несознательно)
оХ, тут я упускаю что еще кроме людей и проектов есть продукты) И да, конечно есть продукты где даже при правильных процессах автоматизация уже не будет играть ту роль которую она играет в тестировании API и веба… Взять те же десктоп епликейшены с их ГУИ…
Сейчас на С++ с использованием gtest фреймворка. Редко балуюсь чтением дампов памяти в АСМе.
До этого были Питон, Руби + Javascript, Java + Селениум, C#, Bash скрипты, Autoit, и какой-то инхаус нонейм, который, б**ть, вообще не поддерживал операторов перехода (тоесть, никаких циклов). В итоге код проверки значения i от 1 до 30 превращался в рулон туалетной бумаги. Но потом научился решать проще, писал на Java функции, которые генерировали мне простыню вот такого кода для нонейм языка, получалось значительно быстрее.
Больше всего нравится конечно С++ и Autoit, ближе всего к нижним уровням, но это у меня просто характер такой.
А вообще - наиболее правильным для тестировщика считаю Питон. Быстро, легко, много примеров, популярно.
Как у вас все серьёзно (С++ – это всегда серьёзно 
). Я так понимаю, что вы не UI-автоматизацией занимаетесь в данный момент.
Если не секрет, то, как конкретно тестируете и что? API приложения?
А кстати, чем вам так нравится именно C++? Ведь у вас опыт работы и с C# и Java и другими языками, так почему именно C++?
Т.к. нахожусь в Cиликонке скажу что здесь язык программирования для автоматизации диктует рынок, а это где-то 80% Java, 10% Python и 10% Ruby, слышал еще некоторые развлекаются c Scala и C# , но это большая редкость здесь; про использовании остальных языков в автоматизировании ничего тут не слышал (сорри кому обидно).
Именно поэтому переключился почти 5 лет назад с Python на Java, ломая себя и свой мозг, но сейчас уже привык k Java.
А каков «портрет» тестировщика-автоматизатора на Силиконщине?
- Автоматизацией занимается вся команда, т.е. автоматизатор – это и разработчик приложения и тестов?
- Или это заморский SDET, как в Google и Microsoft?
- Или все таки есть разделение: кто-то тесты придумывает, а кто-то – имплементит?
Ситуация не ахти.
Из приведенных 3х вариантов присутствуют все.
В больших конторах обычно имеются automation team, очень часто часть автоматизаторов на оутсорсинге, там aвтоматизатор больше разработчик.
В конторах среднего и малого размера по разному , но в основном автоматизатор имплементит, но также очень часто попадаются хитро выкрученные работодатели, в понимании которых автоматизатор – это и разработчик приложения и тестов.
П.С. основная работа в конторах среднего и малого размера.
По поводу параллельного запуска тестов в роботе: я написал прототип python-скрипта, который удачно запускает тесты параллельно + склеиватель логов робота. Выглядит неплохо. Могу оформить на форуме.
Это, наверное, больше зависит о того, как договорится. Если мне, например, на вопрос «А что я буду деть?» – Ответят: «Всё!» – То для меня будет вполне нормально сегодня подевелопить – а завтра потестировать.
Занимаемся тестированием ядра приложения, проверяем API. Поскольку продукт для нас - это собранная статическая библиотека, написанная на С++, то и тестировать её API удобнее всего на родном языке. Можно было бы использовать врапперы и писать тесты на питоне, но тогда гораздо сложнее понять, где возникла ошибка - внутри враппера или приложения. По-этому, берем библиотеку, берем заголовочный файл, и используя их строим приммер приложения, которое усиленно будет использовать весь API продукта.
Просто характер такой. Люблю усложнять себе жизнь. Если вы разберетесь (полностью, включая где и сколько памяти было выделено на хранение переменной) в том как работает программа на С++, то гарантированно ваш мозг сможет быстро определить не только то, выполняет ли функция то что должна, но и то, за сколько она выполняется, можно ли её ускорить, стоит ли её ускорять, сколько памяти необходимо функции, есть ли возможность переполнения буффера и т.д. Ниже только асм код, а потом маш. код, но это уже надо жить в матрице и быть избранным, чтобы быстро разбираться в нем (видел людей читающих маш коды). Скриптовые языки, которые, в основном, делают всё за вас (проверки переполнения буффера например), делают мозг более ленивым и, как бы, отбивают желание более глубоко разбираться в том что вы пишете. Вы знаете какая максимальная длинна строки в Питоне, какая максимальная длинна имени переменной и функции, какой предел вложенности функций? Вот и я не знаю, программируя на питоне об этом не задумываешься. Программируя на С, о памяти приходится беспокоиться самому, что улучшает понимание.
Вот такой вот гемор мозга. Но, С (и наверное именно С, а не С++) нравится мне, но другим все-равно советовал бы использовать Питон. Зачем вам лишние заботы?
Конечно же, большинство людей, которые работают со скриптовыми языками, не волнует как там выделяется память и все такое. Это хорошо, потому что на скриптовых языках можно быстро сделать прототипы чего-либо или собственный инструмент для решения проблемы.
Но, те люди, которые копают глубже – обязательно выходят за рамки скиптовости. Например, для языка Perl есть возможность дописать модуль на Си (и С++), что в разы увеличивает производительность. Кроме того, сам парсер и компилятор языка можно хачить, по средством таких плагинов, добавляя новые синтаксические конструкции.
Я поддерживаю, и считаю что это очень правильно писать API-тесты на том языке, на котором написано приложение. Если бы это были UI тесты или тесты для Rest API, то тут, конечно, можно было бы отдать предпочтение более простым инструментам, скриптовым языкам
1 лайк
Ну, в общем-то да. Тупо писать тесты на Паскале к библиотеке на C. 
Я начал учить Java, потому что хотел научится автоматизировать на Selenium. На данный момент я учу Java 4 месяца, а для автоматизации использую в основном Thucydides из-за крутых подробных отчетов.
Так же немного использовал Selenium+TestNG+ReportNG, а еще писал пару простых тестов на Selenide.
Из языков - хотел бы поучить еще Ruby или Python но нужно сначала хоть джаву немного апнуть до уверенного уровня.
@heartwilltell А поделитесь учебниками и книгами, которые помогали вам Джаву изучить
А WebDriver и Thucydides как изучали?
Ну пока я читаю 2 книги:
http://www.ozon.ru/context/detail/id/8237920/ - Java. Полное руководство, Герберт Шилдт
http://www.ozon.ru/context/detail/id/19729271/ - Философия Java, Брюс Эккель
WebDriver начал изучать после видео Андрея Дзыни - Строим Web Testing Framework за 20 минут - YouTube
По форумам, блогам, официальной доке, видеоурокам.
Фукудит мне показал друг, дал ссылку вот сюда - http://internetka.in.ua/thucydides-intro/
Собственно из мавен архитипа можно сгенирировать проект в котором будет пара базовых тестов.
Просто смотрел код, локейтил элементы и применял к ним методы вебдрайвера, паралельно читаю книги по джаве и сразу же пишу тесты, гуглю, и создаю темы на форуме.
1 лайк