Документация-документация

при таких вводных можно посоветовать максимально удобные для апдейта документации инструменты, типа github pages и прочего. Здесь кстати могут пригодиться скиллы самих автоматизаторов 🙂

Не слышал про такую туллу, а что она даёт если не секрет? У нас просто вся документация лежит в testrail

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

https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages
Если у вас документация лежит в testrail, пусть лежит. Если бы она у вас лежала в вордах\экселях на шарепойнте, тогда да

Вот как раз таки и думаю над этим вопросом, поэтому и решил послушать мнение со стороны. Бывает очень полезно

Спасибо

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

По моему субъективному опыту, ситуация когда автоматизаторы сильно зависит от актуализации тест-кейсов (и документации в целом) чаще всего возникает тогда, когда у ребят примерно нулевое погружение в проект и они работают в формате "моё дело простое, получил тесткейсы - написал код".
Это, в общем-то, совсем не единственный формат в котором автоматизаторы могут работать.
Где-то он полезен, где-то вреден, где-то "так исторически сложилось, поэтому не трогаем".

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

Есть прекрасная практика "Five why's?", которая помогает не только с инцидент-менеджментом и поиском root-cause`ов, но и хорошо работает когда тебе надо понять "зачем нужно делать эту хрень?".

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

Много раз это говорил, повторю ещё много.
"Плохие" (если этот термин вообще применим) процессы - это не проблема.
Проблемы - это то, к чему они могут приводить (а могут и не приводить):
Низкое качество, неэффективное использование ресурсов, проваленные дедлайны или ещё что-нибудь, что в итоге стоит бизнесу денег.

С выявления этих самых проблем (где болит) и надо начинать.
Дальше уже по цепочке искать зависимости и причины, а для них уже придумывать варианты решения.
Условно: много багов/инцидентов в продакшене или медленная скорость поставки в продакшен -> потому что тестирование - bottleneck и вечно завалено задачами -> потому что мы тратим 40% времени на переписывание тест-кейсов -> и тут будет много причин почему вы это делаете, зачем и почему так много времени тратится и ещё больше вариантов решения.

В общем, сначала проанализировать - потом уже менять. :)

Спасибо большое за информативный диалог!

Привет.скажите, вот авторизация с 2fa и без- это 2 разных ТК? Допустим,да, А что делать если адрес страницы авторизации изменился? Во всех ТК его исправлять? Или shared steps использовать? А ведь не ясно что модет поменяться.. вдрес или доп поле новое будет обязательное.. запутались совсем в архитектуре)) подскажите как у вас это

Можно просто не писать URL в тесткейсах.

Тогда не нужно будет его обновлять.

В кейсах - наименование страницы, в конфлюенсе - адреса конкретные

А как лучше сделать?
1.
Сьют- регистрация
Тк-рега с запрещенным доменом
Тк-рега с реф ссылкой
....

2. Сью -регистрация
Тк-поле логин-позитив
Тк-поле логин-чеклист ошибок
Тк-поле пароль-позитив
Тк-поле пароль-чеклист ошибок
Тк-кнопка Зарегистрироваться
Тк-поле ввода кода из письма-позитив
...
Во втором варианте для смока модно выбирать позитивные тк только.
В первом- не ясно особенно что именно тестируется- проверябтся ли ошибки в полях..

Нету никакого «лучше».
Если у вас стоит задача написать максимально подробно - берите второй вариант.
Если задача стоит просто описать список проверок - берите первый вариант.

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

Спс попробуем)

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

Глупый вопрос?)