Как писать предикаты можно глянуть в интернете. Нет ничего сложного

Понял, спасибо

https://www.youtube.com/watch?v=EnooA2kEhY0

А вы пытаетесь какую-то конкретную проблему решить, или просто про паттерны почитать хочется?

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

PageElements/PageWidgets - это микро-PageObjects

Тоже самое, только один объект не страница - а маленький логический кусочек

И вообще PageObjects сейчас не надо делать, только PageElements/Widgets

И вообще PageObjects сейчас не надо делать, только PageElements/Widgets

Почему？:(

Почему？:(

Приложений со "страницами" практически не осталось. Даже те, которые сейчас еще похожи на страничные - в любой момент могут перестать на них похожи.

Почему？:(

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

Используйте новые паттерны PageObject 10 и PageObject X

Да, это разные имена для одного и того же. Не запрещено так же называть это PageObject.

Да, идея та же.

Используйте новые паттерны PageObject 10 и PageObject X

а пейджобьекты 9 версии тоже перескочили, как и Винда с Ойфоном?

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

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

ссылочку плз =)

@alexejv помоги человеку )

ссылочку плз =)

+1

ссылочку плз =)

Я не вижу, расшарена ли ссылка. @alexejv открыли уже твой доклад?

а пейджобьекты 9 версии тоже перескочили, как и Винда с Ойфоном?

Мало кто знает, но на последней конференции Гейзенбаг был продемонстрирован абсолютно новый, принципиально отличающийся от PageObject и PageElement, паттерн проектирования.

Это доклад про этот патерн, о котором говорится выше?

Мало кто знает, но на последней конференции Гейзенбаг был продемонстрирован абсолютно новый, принципиально отличающийся от PageObject и PageElement, паттерн проектирования.

Вы про какой доклад/паттерн говорите?

это я так троллю ? обычно так про новый айфон говорят, что он принципиально новый, а я про паттерн проектирования

А вы имеете право расшаривать сюда закрытые доклады?

А вы имеете право расшаривать сюда закрытые доклады?

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

А, Сорри.

я уже понял что его еще не расшарили, будем ждать, спасибо за инфу

былинные древние знания за семью печатями, чтобы русские тостеры страдали без знаний паттернов

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

Сейчас задаю себе вопрос "а действительно ли мне нужно прилепить этот паттерн"

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

а я так наоборот не думал, потому что чтобы ударять "абсурдом" паттернов, нужно было умело и учень уверено их втирать. Чего в докладе не было.

Успешным применением такого формата доклада я считаю этот: https://www.youtube.com/watch?v=f4uXBpP_xxY&t=105s

Успешным применением такого формата доклада я считаю этот: https://www.youtube.com/watch?v=f4uXBpP_xxY&t=105s

Спасибо за ссылку

Спасибо за ссылку

+

Коллеги, а подскажите бест практис по ведению конфлюенс для раздела "тестирование" На проекте будет авто тестирование, ручное тестирование. будут приходить новые участники и хотелось бы организовать раздел так, чтобы пришедший мог прочитав сразу вкатиться в проект. Я примерно такие разделы вижу: 1. Введение: как работать в jira, настройка тестового окружения, стенды, пользователи,.. 2. Регресс: информация по регрессионному тестированию

3. Автомтаизирвоанное тестировние 4. Временная шкала.

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

по девайсам и всякому такому полезно еще инфу иметь

Девайсы не актуальны, гос проект, стенды жестко прописаны.

иерархия тестирования это тоже хорошо

Пул тестов будет в регрессе.

Можно чуть подробнее про иерархию ?

Можно чуть подробнее про иерархию ?

Это вы нам как раз рассказывали :)

Так я и хотел услышать решения на ваших проектах.

Частично

Так я и хотел услышать решения на ваших проектах.

У меня на проекте нет решения, с места в карьер :))))

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

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

Это тоже полезно

А процессы в команде стоит описывать. к примеру если челвоек нашел баг, то что нужно сделать перед тем, как его завести и с кем поговорить?

Так я и хотел услышать решения на ваших проектах.

Очень хорошо иметь traceability matrix

А процессы в команде стоит описывать. к примеру если челвоек нашел баг, то что нужно сделать перед тем, как его завести и с кем поговорить?

Ох :))))

А процессы в команде стоит описывать. к примеру если челвоек нашел баг, то что нужно сделать перед тем, как его завести и с кем поговорить?

чтобы заводить такие штуки, скажите, какая текучка кадров на вашем проекте?

Или это уже слишком подробное описание ?

А процессы в команде стоит описывать. к примеру если челвоек нашел баг, то что нужно сделать перед тем, как его завести и с кем поговорить?

поговорить?

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

если у вас текучка кадров и входить в проект нужно быстро, это будет круто

Да текучка есть, и будут стажеры, которых, хотелось бы быстро вкатить в проект, а не объяснять каждому куда смотреть, как и что делать.

тогда сам доктор прописал

Коллеги, а подскажите бест практис по ведению конфлюенс для раздела "тестирование" На проекте будет авто тестирование, ручное тестирование. будут приходить новые участники и хотелось бы организовать раздел так, чтобы пришедший мог прочитав сразу вкатиться в проект. Я примерно такие разделы вижу: 1. Введение: как работать в jira, настройка тестового окружения, стенды, пользователи,.. 2. Регресс: информация по регрессионному тестированию

выделите в спейсе отдельные разделы: 1) регламенты (сюда закидывать все регламенты для всех) 2) тестирование внутри тестирования создайте разделы типа: а) тестирование релизов/версия б) инструкции в) тестовые данные г) АТ

Да текучка есть, и будут стажеры, которых, хотелось бы быстро вкатить в проект, а не объяснять каждому куда смотреть, как и что делать.

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

полезно иметь что-то вроде Хотелок. Вещи, которые выпадают из общего беклога, но которые хочется сделать или с чем-то разобраться. Зачастую такие штуки - это теневая сторона проекта, т.к. это не является бизнес задачей. Если автоматизация с 0 - вполне себе бизнес задача, под которую будет выделяться время, то постепенное улучшение для самого себя и товарища - это вещи мало интересующие продакт оунера. Под такое таски выделятся не будут :) вот поэтому стоит иметь их записанными, и как только будет подыматься вопрос эффективности и скорости - можно начинать доставать эти хотелки из рукава и доказывать их важность.

полезно иметь что-то вроде Хотелок. Вещи, которые выпадают из общего беклога, но которые хочется сделать или с чем-то разобраться. Зачастую такие штуки - это теневая сторона проекта, т.к. это не является бизнес задачей. Если автоматизация с 0 - вполне себе бизнес задача, под которую будет выделяться время, то постепенное улучшение для самого себя и товарища - это вещи мало интересующие продакт оунера. Под такое таски выделятся не будут :) вот поэтому стоит иметь их записанными, и как только будет подыматься вопрос эффективности и скорости - можно начинать доставать эти хотелки из рукава и доказывать их важность.

я вот думаю, в джире к задаче на тестирование делать подзадачки на правку кейсов + доработку АТ. для большей видимости процесса.

полезно иметь что-то вроде Хотелок. Вещи, которые выпадают из общего беклога, но которые хочется сделать или с чем-то разобраться. Зачастую такие штуки - это теневая сторона проекта, т.к. это не является бизнес задачей. Если автоматизация с 0 - вполне себе бизнес задача, под которую будет выделяться время, то постепенное улучшение для самого себя и товарища - это вещи мало интересующие продакт оунера. Под такое таски выделятся не будут :) вот поэтому стоит иметь их записанными, и как только будет подыматься вопрос эффективности и скорости - можно начинать доставать эти хотелки из рукава и доказывать их важность.

чтобы доказывать их важность - хорошо еще от версии к версии собирать статистику. а то может и получиться так, что собрав статистику поймёшь, что какая к чёрту автоматизация... ;)

Всем привет! А подскажите кто какие инструменты применяет для нагрузочного тестирования? В чем плюсы/минусы?

Всем привет! А подскажите кто какие инструменты применяет для нагрузочного тестирования? В чем плюсы/минусы?

jmetr, он лучше всех, он ужасен, но лучше всех ?

jmetr, он лучше всех, он ужасен, но лучше всех ?

почему лучше всех?

потому что бесплатный и работает как часы, а так же всё умеет

какие-то слабые аргументы

какие-то слабые аргументы

какой инструмент лучше ?

к примеру яндекс.танк умеет jmeter юзать + у него сверху функциональность

https://gatling.io/ https://tech.yandex.ru/tank/ что лучше хз

какой инструмент лучше ?

я не знаю, но аргументы у тебя явно не очень а почему не использовать платный сервис, например?

к примеру яндекс.танк умеет jmeter юзать + у него сверху функциональность

оболочка будет всё равно jmetr?

я не знаю, но аргументы у тебя явно не очень а почему не использовать платный сервис, например?

зачем платный, если jmetr всё умеет делать и со всем справляется, и я не видел такого-же по функциональности платного сервиса.

я бы попросил больше вводных. Основной язык и на сколько большой проект для теста. У Jmetr большйо порог вхождения например, но также большое community. Например есть простейшая тула https://www.linode.com/docs/tools-reference/tools/load-testing-with-siege Может ее достаточно.

Тимлид в своё время использовал siege и рекомендовал этот инструмент для организации нагрузочного тестирования. Я так понимаю, что он более лайтовый, чем jmetr?

Ну ребят, ну вкусовщина же, ну.

Если и спрашивать какой лучше, то спрашивать сразу под какой скоуп задач.

page objects: вы объект следующей страницы возвращаете в методе данной страницы? или делаете классы независимыми от других страниц и вся логика в тесте?

кто-то делает это через инициализацию объекта явно в тесте, кто-то делает через возвращение объекта через какой-то "переходный" метод страницы. и то и другое в принципе одинаково читаемо, дело вкуса.

иногда бывает полезно возвращать self (this) с ссылкой на объект, чтобы можно было делать так называемый Builder pattern a.k.a fluent api

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