сделал , вышло все очень круто https://gist.github.com/Benedicttt/3993a7a4e5a4673f0165430e1b64519f

Ассерта не хватает только. ;)

ни разу не видел (а проверял один раз :) ), чтобы на сайте RSTQB в расписании вообще были экзамены на эксперта

ни разу не видел (а проверял один раз :) ), чтобы на сайте RSTQB в расписании вообще были экзамены на эксперта

Ну нам в rstqb сказали, что никто не сдавал. Может и обманули)

потому что RSTQB это способ потратить деньги на сертификат который никому не нужен

зачем сдавать на русском, чтобы работать в РУ-резервации?

RSTQB != сдача на русском

это просто организация в России

зачем оно нужно? чтобы люди в европе задумались на секунду и выбросили в помойку твое резюме? :)

почему если есть возможноть сдать номральный сертификат, не сдать его? :)

У них только foundation и test manager на русском, все остальное на английском

ты и получаешь "нормальный" сертификат. ISTQBшный

(хотя и то и другое - филькина рамота, и не нужен, но это совсем другая история)

тест аналитик еще на русском есть

сделал , вышло все очень круто https://gist.github.com/Benedicttt/3993a7a4e5a4673f0165430e1b64519f

Молодец

https://gist.github.com/Benedicttt/3993a7a4e5a4673f0165430e1b64519f

done

а зачем жабаскрипт?

Радиобатон там интересный

https://gist.github.com/Benedicttt/3993a7a4e5a4673f0165430e1b64519f

бутстрап? :)

angular

просто так можно нажать

по класу уже проблемно

А через ByChained xpath?

*classname

Собираюсь сдавать istqb на русском

На английском сдавать проще

Переводы терминов бывают идиотские очень часто, в итоге сбивают с толку и не выбираешь верный ответ. Плюс времени банально больше на англ экзамене

Сдавали foundation на русском. С терминами в меньшей степени проблема. Прочитать их силабус и словарь и ок. Сложности в более сложных вопросов, выбрать более правильное утверждение. Когда все это к теме разговора относится по минимуму

а оно всегда будет относиться по-минимуму, потому что в тестировании нет общего понимания в утверждениях. Никто до сих пор в них не утвердился. А знаете почему? потому что если б это было по-настоящему нужно, неужели б кто-то об этом не знал?

На всякий случай напоминаю, что за провокации тоже банят. См. Правила. Пишу безотносительно кого либо.

Доброе утро тем, у кого утро. А расскажите мне как вы храните тестовые данные (логины, пароли, тестовые карты итп), особенно в тех случаях, когда их много? У меня сейчас хранятся в yaml вместе с автотестами, думаю перейти на хранение в отдельной БД, пытаюсь понять плюсы и минусы

у нас в yml то же; мне кажется лучший вариант, когда для прогона тестов данные не беруться готовые, а генерируются... типа нужен пользователь с определенными правами: коннектимся к тестовой в БД или к приложению - и выполняем команды создающие эти данные... мне кажется это более хороший вариант, чем хранить подготовленные данные, но он сложнее )

у нас в yml то же; мне кажется лучший вариант, когда для прогона тестов данные не беруться готовые, а генерируются... типа нужен пользователь с определенными правами: коннектимся к тестовой в БД или к приложению - и выполняем команды создающие эти данные... мне кажется это более хороший вариант, чем хранить подготовленные данные, но он сложнее )

а чем такой вариант лучше? аргумент "мне кажется", как-то неубедителен

лучше тем, что: * если нам требуется проверить изменение данных в ходе теста, то нам эти данные "не жалко": не нужно их потом восстанавливать и приводить в исходное состояние * мы генерируем "чистые" и "конкретные" данные для каждого теста и можем не думать о том, что кто-то мог зайти в тестовую базу и изменить какие-нибудь параметры у конкретной сущности: например уровень доступа у пользователя

Пока что нереально настроить генерацию тестовых данных - слишком сложная структура БД проекта, затрагивается очень много таблиц, по сути придется дублировать всю логику продакшна, руководство не готово выделять время на это. Мне тоже больше нравится создание "на лету", позволяет параллелить тесты без боли

на текущем проекте делаю так, как описал Антон. Ни в каких файлах тестовые данные не храню. В коде каждого теста указываю требования к данным, нужным для его прогона. А специальный генератор по требованиям ищет подходящие данные или создает новые, возвращая подробную информацию о подготовленных бизнес-объектах. И к этой информации уже обращаюсь в самом тесте

хуже тем, что: * нужно создать и поддерживать инфраструктуру генерации данных * дополнительное время в прогоне тестов, пока они генерят данные

на мой взгляд в исходном варианте: Работать с YML или работать с БД: нет особой разницы: Тесты либо парсят YML встроенными средствами либо подключаются к базе: другими встроенными методами... тут в итоге: Кому что удобнее ) лично мне легче открыть текстовый редактор и по ctrl+F найти нужное значение, чем коннектить в базу и писать запрос на выборку Какие еще факторы могут быть: Скорость прохождения тестов - не вижу особой разницы между БД и ЯМЛ Поддержка: для бд нужен сервер, хоть бы и локально поднятый - для YML - не нужно об этом думать может еще есть какие-то факторы: не знаю )

Коллеги-автоматизаторы (те, кто занимается исключительно автоматизацией в команде тестирования) как у вас построены процессы? как определяется очередность покрытия функционала тестами? по каким кейсам вы пишите тесты?

Доброе утро тем, у кого утро. А расскажите мне как вы храните тестовые данные (логины, пароли, тестовые карты итп), особенно в тех случаях, когда их много? У меня сейчас хранятся в yaml вместе с автотестами, думаю перейти на хранение в отдельной БД, пытаюсь понять плюсы и минусы

У меня для таких целей использовалась монга.

+ немного логики, отвечающей за поиск нужного юзера, отметку что он уже используется в тестах, создание, удаление и вот это всё

на мой взгляд в исходном варианте: Работать с YML или работать с БД: нет особой разницы: Тесты либо парсят YML встроенными средствами либо подключаются к базе: другими встроенными методами... тут в итоге: Кому что удобнее ) лично мне легче открыть текстовый редактор и по ctrl+F найти нужное значение, чем коннектить в базу и писать запрос на выборку Какие еще факторы могут быть: Скорость прохождения тестов - не вижу особой разницы между БД и ЯМЛ Поддержка: для бд нужен сервер, хоть бы и локально поднятый - для YML - не нужно об этом думать может еще есть какие-то факторы: не знаю )

Я задумалась о БД в первую очередь потому, что есть порядка 15 продуктов, у каждого из которых по 300 строк в Yml файле, и количество будет расти. Мне тоже пока что проще открыть yml и найти там значение, но когда приходится добавлять похожие значения 15 файлах, как-то не очень удобно

я бы в вашем случае то же подумал о БД, при том сделал бы какую-то мастер Таблицу - добавление в которую инициализировало бы триггер и добавляло данных в таблицу для каждого продукта ) технически я такое не делал, но это вроде возможно )

+ немного логики, отвечающей за поиск нужного юзера, отметку что он уже используется в тестах, создание, удаление и вот это всё

создание и удаление в смысле копирование юзера из базы тестовых данных в окружение?

Всмысле генерация юзера с нужными параметрами в базу окружения и закидывание данных о нем в монгу.

Коллеги-автоматизаторы (те, кто занимается исключительно автоматизацией в команде тестирования) как у вас построены процессы? как определяется очередность покрытия функционала тестами? по каким кейсам вы пишите тесты?

Сначала покрывается смоук, потом позитив из регресса, потом все остальное

Сначала покрывается смоук, потом позитив из регресса, потом все остальное

Саша, твою историю я слышал)

Хочется послушать истории других участников, чтобы понять «то ли лыжи не едут, то ли я нутый»

а что? вроде правильно говорит)

ну да, так же все, а у вас как, Дмитрий?

Меня тут больше именно взаимодействие интересуется)

с продактками, ручными тестировщиками, разработкой?

Я так же по классике покрыл весь смоук, развернул инфраструктуру и уже готов крыть дальше, но тут все упирается в проблемы взаимодействия

"готов крыть дальше"... а если не матом?)

"готов крыть дальше"... а если не матом?)

Опять же. И мою ситуацию ты знаешь, не матом тут сложно)

Сначала покрывается смоук, потом позитив из регресса, потом все остальное

+

Короче, я очень обособлен от проекта (не по своей воле, такие процессы). Обо всех изменениях в проекте я узнаю на поздних стадиях. Чтобы как то это победить, был предложен простой порядок взаимодействия. Лид определяет блок кейсов, которые необходимо покрыть первоочередно, ставит на меня тикет, если необходимо доработать кейсы + ставится тикет на ручников, я крою -> ревью и по кругу.

"как определяется очередность покрытия функционала тестами?" - если это выделенная команда автоматизаторов, то совместно с ручными тестировщиками/продактами решается приоритетность функциональностей и кейсов, и далее идем по приоритету. Ну т.е. от них фидбек что нужно в первую очередь, от вас что можно быстрее покрыть, а что невозможно в принципе. Наверное так.

Короче, я очень обособлен от проекта (не по своей воле, такие процессы). Обо всех изменениях в проекте я узнаю на поздних стадиях. Чтобы как то это победить, был предложен простой порядок взаимодействия. Лид определяет блок кейсов, которые необходимо покрыть первоочередно, ставит на меня тикет, если необходимо доработать кейсы + ставится тикет на ручников, я крою -> ревью и по кругу.

а проблема то какая: Слишком поздно узнаете об изменениях в регрессе ? или какая-то другая ?

Так это проблема коммуникации, может сначала стоит ее решить?

Ну я так и думал, что проблема больше в лыжах. Просто хотел лишний взгляд со стороны)

Тут походу проще место сменить, все 3 месяца здесь я пытаюсь наладить коммуникации)

в итоге «мы там UI перепилили на 80% и да, кейсы править некому»

вот поэтому я не пользуюсь сервисами данной компании ?

ERROR: S client not available

Тут походу проще место сменить, все 3 месяца здесь я пытаюсь наладить коммуникации)

дак если это кроме вас никому не надо - значит идея не была продана второй стороне ) Построение процессов это болезнено и обычно не быстро )

дак если это кроме вас никому не надо - значит идея не была продана второй стороне ) Построение процессов это болезнено и обычно не быстро )

Ну тут попытки построения процессов в QA разбиваются об общепроектные процессы. Лид меня слушает, соглашается, на неделю что то налаживается и все опять разбивается об общие процессы

Бизнес тут не слушает QA вообще

бизнесу обычно вообще не важно как QA работает, если оно делает свое дело за приемлимые для бизнеса ресурсы

+ немного логики, отвечающей за поиск нужного юзера, отметку что он уже используется в тестах, создание, удаление и вот это всё

как боролся с гонкой? :)

бизнесу обычно вообще не важно как QA работает, если оно делает свое дело за приемлимые для бизнеса ресурсы

Ну не всегда, бизнес готов двигаться в общих процессах если QA донесет до него, что это принесет профит

В прошлом месте я был в одном лице и это работало)

ну я про это и говорил, когда говорил про "продать идею" ) бизнес любит циферки и очевидные профиты: "мы будем выпускать меньше багов если начнем автоматизировать регрессионное тестирование" - это для бизнесса не очень очевидно а вот "нам не придется нанимать 3 тестировщика на регресс, если наймем 1 автоматизатора" - это уже деньги ) которые можно посчитать и измерить )

Здесь я вообще больше склоняюсь к тому, что автоматизация на данных этапах и с данными процессами не просто лишняя, а даже убыточная

«Хей, я знаю как сэкономит ваши деньги. Увольте меня» ?

я почти с такой формулировкой ушел с прошлой работы ?

я почти с такой формулировкой ушел с прошлой работы ?

+1

В моем мирке, автоматизация приносит профит только на стабильном функционале. Автоматизировать активно растущий и меняющийся сервис, больно, дорого и бесполезно

В моем мирке, автоматизация приносит профит только на стабильном функционале. Автоматизировать активно растущий и меняющийся сервис, больно, дорого и бесполезно

ну почему же... просто тут автоматизация другая и для другого )

Есть тут ява автоматизаторы? Хочу вопрос задать

ну почему же... просто тут автоматизация другая и для другого )

Тесты ради тестов?)

не совсем так: автоматизировать же имеет смысл то, что не меняется и то, в чем могут возникнуть регрессионные ошибки Вот и тут так же: например UI тесты не нужны - а какую-нибудь апишку - может и есть смысл

В моем мирке, автоматизация приносит профит только на стабильном функционале. Автоматизировать активно растущий и меняющийся сервис, больно, дорого и бесполезно

+1 поддерживаю, на прошлой работе были изменения в дизайне и функционале каждый спринт, в итоге qa только и занимались тем, что правили падающие тесты

Есть тут ява автоматизаторы? Хочу вопрос задать

есть, задавай ) будет вопрос - люди подтянуться )

не совсем так: автоматизировать же имеет смысл то, что не меняется и то, в чем могут возникнуть регрессионные ошибки Вот и тут так же: например UI тесты не нужны - а какую-нибудь апишку - может и есть смысл

Да, забыл уточнить. я мобайл и все у меня через жоп…. UI)

В моем мирке, автоматизация приносит профит только на стабильном функционале. Автоматизировать активно растущий и меняющийся сервис, больно, дорого и бесполезно

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

но там автоматизаторов было пару человек

@ogionfrost а вопрос то какой ? )

Можно ли экстракты для ассертов переделать на что-то более удобное-вменяемое ?

как боролся с гонкой? :)

Особенной необходимости не возникало, на самом деле.

Можно ли экстракты для ассертов переделать на что-то более удобное-вменяемое ?

да, можно. Почитай про Hamcrest, механизм матчеров и как создавать собственные матчеры

или вместо Hamcrest про AssertJ, но суть та же

Спасибо

Особенной необходимости не возникало, на самом деле.

любопытно :) у меня просто совсем другое впечатление осталось от параллелизма

Ну, параллеллизм рождает рейсы, это очевидно. Вопрос в том, что у меня лично кейсов когда двум тестам в одну миллисекунду понадобилось два одинаковых юзера особо не было.