Доброго времени суток, господа. Вопрос у меня про роли, взаимодействие и разграничение обязанностей между QA и разработчиком. Есть разработчики которые пишут модульные тесты, есть те которые пишут/хотят писать интеграционные тесты. И казалось бы идея с написанием интеграционных тестов достаточно хорошая. Однако тут встаёт куча вопросов - как всё это взаимоувязать с QA/автоматизацией. И проблема не только в том, что возможны конфликты интересов, а ещё и проблема в выборе программных стеков. Изначально кажется что хорошей идеей было бы написание разработчиком базовых интеграционных тестов на позитивные сценарии (дабы быть более уверенным, что адекватно закрыта таска и она реализует определённый флоу в цепочке микросервисов) с последующей доработкой этого набора интеграционных тестов специалистом по qa. QA бы добавил каких-то более изощрённых тестов с более тонкой проверкой негативных сценариев и т д. Но в такой модели один из  ключевых моментов, это то, что стек должен быть общий. Зачастую предпочтения QA сводятся к python. А что при этом, если сам проект на jvm платформе? Да, java выглядит как хороший вариант для написания тестов, но она сложнее, да и сам проект может быть на scala допустим и использовать java не все разработчики захотят. Таким образом получается, что эта модель утопична. Да, каждый может остаться при своём (будет писать свои наборы тестов), но мы получаем тогда наборы тестов, которые могут дублироваться в определённых частях. На текущий момент видится более жизненной такая схема, что разработчик может писать простейшие интеграционные тесты (с использованием test containers) на своём любимом языке и они по сути должны задействовать контейнеры с реальными бд и возможно какие-то моки, тоже в контейнерах запущенные. QA же пишут на своём любимом языке и вещи, приближенные к e2e. Тогда выходит, что они особо не пересекаются и каждый счастлив и взаимодополняет друг друга. Подскажите какой у кого опыт в разграничении и решении подобного?

https://a-yevtukhov.medium.com/%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-requirements-%D1%87%D0%B0%D1%81%D1%82%D1%8C-3-36800e1cfa7c
Качественные требования к ПО.
Как можно определить (и улучшить) качество требований?
Что же такое качественное требование, и какими свойствами оно должно обладать, чтоб всем было максимально удобно с ним работать.

🌟15 февраля, уже на следующей неделе стартует Podlodka QA Crew!🌟

В этот раз две недели конференции будут посвящен релизам без стрессов. Темы недель – “Автоматизация тестирования бэкенда” и “SRE и жизнь после релиза”.

Задача первой недели – разобрать автотесты бэкенда, причем с разных сторон так, чтобы полезно было и тем, кто уже давно ими занимается, и тем, кто только начинает. Вместе со спикерами участники:
• Разберутся, как завести автотесты бэкенда с нуля. Утром теория, вечером – практика!
• Узнают, как устроено автотестирование бэкенда в Альфа-Банке и Moovit
• Посмотрят, как собеседует сеньоров-автоматизаторов бэкенда Никита Макаров (Тинькофф). Причем собеседовать он будет кого-то из желающих, так что можно попробовать свои силы
• Конечно же, не обойдется и без традиционной рулетки кейсов. Кодовой название – “Протестируй это!”

Вторая неделя “SRE и жизнь после релиза” – про спокойный сон после выкатки. Слушатели:
• Научатся писать постмортемы, когда неизбежное уже случилось
• Разберут все активности, которые помогут в любой непонятной ситуации снизить время реагирования, будь то мониторинги и не только
• Обсудят кейсы инцидентов, и посмотрят на реальных примерах, что пошло не так, и что можно было сделать лучше
• Изучат практики выстраивания отношений с теми, кто принимает на себя первый удар – с техподдержкой.
• Сыграют в “Где был баг” – это как “что было дальше”, только про баги🤯

Как это выглядит:
🏃‍♂️Каждый день ходите на воркшопы
💬Общаетесь с топовыми экспертами в QA
💰Забираете лучшие практики себе на работу

Добавляем нескучные форматы, мемы и бодрое комьюнити в Slack, и получаем отличные впечатления!
И это только часть программы. Старт 15 февраля, подробности и билеты доступны по ссылке на сайте!

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

Спасибо. посмотрю, что за зверь этот кукумбер

лучше не надо...

)

Про это тоже посмотрю

Выйду в нуль так скажем

печальный опыт его использования был? :)

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

Доброго дня, коллеги.
Запускаю тесты на селениде, в частности на ЯБ в данный момент. И постоянно вылезают всякие штуки а-ля подсказка по коллекциям, предложение сохранить пароль и т.д. Предполагаю, что это можно разрулить через Configuration.browserCapabilities, но не что-то не нашёл какие вообще туда capability можно всунуть. Есть у кого-нибудь подсказки, может знает где можно такое найти?

"--no-sandbox"

Не сработало. Делаю через setCapability("—no-sandbox", true). Оно же так предполагается работать?

Ну так это Селениумовский подход, у меня Селенида. Я и не хотел мешать их

ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.addArguments("window-size=1366,768", "--no-sandbox");
Configuration.browserCapabilities.setCapability(ChromeOptions.CAPABILITY, chromeOptions);

Не сработало