У нас системой управления тестирования был плагин zephyr scale для jira server. Функционала в данной тмс немного и в основном она подходила для ручного тестирования. Нам же хотелось обьединить ручные и авто тесты в одном интерфейсе и собирать метрики по работе с ними. Allure TestOps отлично для этого подошёл. У нас в проекте около 10-ти тестировщиков, из них несколько автоматизаторов.
Здравствуйте, e2e в нашем случае, это не только проверка интеграции со сторонними сервисами, но и тестирование функционала от начала до конца (пользовательские сценарии). К примеру, пользователь авторизовался, оформил подписку, проверил, что она активирована. Такие автоматизированные сценарии (будь то api или ui) удобно запускать при регрессе, когда нам надо проверить, что новый код не поломал существующий, возможно затронутый функционал.
Наверно я не правильно выразился, но я имел ввиду, что существующие процессы в стратегии тестирования могут быть изменены, если мы смотрим на качество продукта, к примеру, основываясь на собранных метриках, и если оно нас не устраивает - мы меняем процессы в стратегии(уровни, виды тестирования, практики и др.) смотрим опять на метрики - стало лучше/хуже, еще раз меняем процессы и так, пока не придем к оптимальным, удовлетворяющим нас значениям. Таким образом мы можем понять, что было у нас не так в стратегии = понимание как лучше тестировать.
Формально в Scrum не может быть роли QA инженера, но это не мешает вам использовать тестирование, всегда можно подстроить процессы под ваш проект. В данной статье нет пересказа каких либо курсов, я моделировал стратегию, опираясь на известные мне шаблоны и личный опыт.
Используемый набор практик и целей тестирования поможет понять как лучше тестировать продукт, к примеру, если опираться на метрики качества разрабатываемого ПО, на основе собранных данных можно скорректировать стратегию.
Ну, статья то не про это, а как организовать мониторинг системы, используя указанные в статье инструменты. Выбору того, что важно мониторить, можно посвятить отдельную статью...
Возьмем на заметку. Спасибо!
Модульный монолит?)
Спасибо вам за отзыв!
Нет, говорит она не медленно, с обычной скоростью. По поводу лаконичных фраз, зафиксировал, спасибо, что подметили!
Видел данный навык, спасибо за уточнение!
Спасибо, взял на заметку!
У нас системой управления тестирования был плагин zephyr scale для jira server. Функционала в данной тмс немного и в основном она подходила для ручного тестирования. Нам же хотелось обьединить ручные и авто тесты в одном интерфейсе и собирать метрики по работе с ними. Allure TestOps отлично для этого подошёл. У нас в проекте около 10-ти тестировщиков, из них несколько автоматизаторов.
Спасибо, обязательно!
Мы работаем над этим)
Здравствуйте, e2e в нашем случае, это не только проверка интеграции со сторонними сервисами, но и тестирование функционала от начала до конца (пользовательские сценарии). К примеру, пользователь авторизовался, оформил подписку, проверил, что она активирована. Такие автоматизированные сценарии (будь то api или ui) удобно запускать при регрессе, когда нам надо проверить, что новый код не поломал существующий, возможно затронутый функционал.
Наверно я не правильно выразился, но я имел ввиду, что существующие процессы в стратегии тестирования могут быть изменены, если мы смотрим на качество продукта, к примеру, основываясь на собранных метриках, и если оно нас не устраивает - мы меняем процессы в стратегии(уровни, виды тестирования, практики и др.) смотрим опять на метрики - стало лучше/хуже, еще раз меняем процессы и так, пока не придем к оптимальным, удовлетворяющим нас значениям. Таким образом мы можем понять, что было у нас не так в стратегии = понимание как лучше тестировать.
Формально в Scrum не может быть роли QA инженера, но это не мешает вам использовать тестирование, всегда можно подстроить процессы под ваш проект. В данной статье нет пересказа каких либо курсов, я моделировал стратегию, опираясь на известные мне шаблоны и личный опыт.
Используемый набор практик и целей тестирования поможет понять как лучше тестировать продукт, к примеру, если опираться на метрики качества разрабатываемого ПО, на основе собранных данных можно скорректировать стратегию.
Эх..жаль. Всем приятных сюрпризов.
Хаброжители, подкините кармы - с удовольствием поучаствую!))
Согласен, все это есть. Задумка о создании такого бота показалась мне интересной, реализовал и поделился этим, не более того.
Взял на заметку..
Согласен, если выполняем pip install PyTelegramBotAPI, то нет необходимости… учёл
Это проще автоматизировать и использовать в регрессе
Ну, статья то не про это, а как организовать мониторинг системы, используя указанные в статье инструменты. Выбору того, что важно мониторить, можно посвятить отдельную статью...