К слову, особенно "люблю" такие success-stories, где отказ тестировщиков что-то улучшил 😂 . Ни разу не была их участницей. Зато, наоборот, провалов на эту тему видела немало.
Вспомнился недавний пост, где в комментариях тоже достаточно "прошлись" по этой теме. И, как верно, подметил один из комментаторов "Это все уже было) Много много много много раз. И результат всегда один и тот же". 🙂
https://www.linkedin.com/posts/alexandr-pankratiew-771b6b160_%D0%BA%D0%B0%D0%BA-%D0%BC%D1%8B-%D1%83%D1%88%D0%BB%D0%B8-%D0%BE%D1%82-manual-qa-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5-%D0%BE%D1%87%D0%B5%D0%BD%D1%8C-activity-7211033848598384640-H1hc/
Так что тем более интересно будет послушать автораочередной новой методологии. 🤓
Вспомнился недавний пост, где в комментариях тоже достаточно "прошлись" по этой теме. И, как верно, подметил один из комментаторов "Это все уже было) Много много много много раз. И результат всегда один и тот же". 🙂
https://www.linkedin.com/posts/alexandr-pankratiew-771b6b160_%D0%BA%D0%B0%D0%BA-%D0%BC%D1%8B-%D1%83%D1%88%D0%BB%D0%B8-%D0%BE%D1%82-manual-qa-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5-%D0%BE%D1%87%D0%B5%D0%BD%D1%8C-activity-7211033848598384640-H1hc/
Так что тем более интересно будет послушать автора
Linkedin
Alexander Pankratiev on LinkedIn: Как мы ушли от Manual QA на проекте
Очень долгое время мы работали по… | 95 comments
Очень долгое время мы работали по… | 95 comments
Как мы ушли от Manual QA на проекте
Очень долгое время мы работали по знакомому для многих процессу: две недели спринт, затем смоук/регрессия, стабилизация… | 95 comments on LinkedIn
Очень долгое время мы работали по знакомому для многих процессу: две недели спринт, затем смоук/регрессия, стабилизация… | 95 comments on LinkedIn
А мы уже начали: https://pruffme.com/landing/u3180278/testify7
Всем привет!
Делюсь записью митапа Testify, в котором я приняла участие на прошлой неделе:
✅ Выпуск на YouTube : https://clck.ru/3D53Bm
✅ Выпуск в VK: https://clck.ru/3D53QB
Мой доклад идет вторым. Те, кто не был на митиапе, посмотрите обязательно, доклад реально полезный. 🙂
После доклада были еще вопросы. Не все из них попали на видео. Так что на этой неделе постараюсь опубликовать их здесь вместе с моими ответами.
Делюсь записью митапа Testify, в котором я приняла участие на прошлой неделе:
✅ Выпуск на YouTube : https://clck.ru/3D53Bm
✅ Выпуск в VK: https://clck.ru/3D53QB
Мой доклад идет вторым. Те, кто не был на митиапе, посмотрите обязательно, доклад реально полезный. 🙂
После доклада были еще вопросы. Не все из них попали на видео. Так что на этой неделе постараюсь опубликовать их здесь вместе с моими ответами.
Так заработалась сегодня, что и не поздравила нас с нашим профессиональным праздником - днем тестировщика. 😂
Так что исправляюсь и желаю всем нам, дорогие нынешние и будущие коллеги, побольше интересных проектов, классных команд, спокойных релизов и гармоничного баланса между работой и личной жизнью! 🤗
Ну и какой же праздник без подарка?!
Пролистала свой онлайн-ежедневник и обратила внимание, что давно не проводила вебинар по моей любимой технике тест-дизайна.
Так что мой подарок будет, как говорится, "в тему".
Приглашаю вас 12 сентября в 19.00 по МСК на вебинар по ТТД “Таблицы принятия решений”.
Как всегда на моих вебинарах, вас ждут:
👍 лайфхаки по применению ТТД;
👍 разбор примеров;
👍 практические задания;
👍 ответы на ваши вопросы;
👍 ну и, конечно же, тестирование требований - куда ж тестировщикам без этого 😀
Приблизительная длительность вебинара - 1,5-2 часа.
А поскольку 12 сентября еще и день программиста, то всех участников вебинара ждет дополнительный подарок еще и по этому поводу. 😉
Как стать участником вебинара:
1️⃣ быть подписанным на мой блог;
2️⃣ заполнить анкету - https://forms.gle/bHESfWNW7YP6dZR27;
3️⃣ проверить свою почту 11-12 сентября;
4️⃣ пройти по ссылке в присланном вам письме-приглашении.
Буду рада вашим лайкам ❤️ и репостам 🚀!
#вебинар #техникитестдизайна
Так что исправляюсь и желаю всем нам, дорогие нынешние и будущие коллеги, побольше интересных проектов, классных команд, спокойных релизов и гармоничного баланса между работой и личной жизнью! 🤗
Ну и какой же праздник без подарка?!
Пролистала свой онлайн-ежедневник и обратила внимание, что давно не проводила вебинар по моей любимой технике тест-дизайна.
Так что мой подарок будет, как говорится, "в тему".
Приглашаю вас 12 сентября в 19.00 по МСК на вебинар по ТТД “Таблицы принятия решений”.
Как всегда на моих вебинарах, вас ждут:
👍 лайфхаки по применению ТТД;
👍 разбор примеров;
👍 практические задания;
👍 ответы на ваши вопросы;
👍 ну и, конечно же, тестирование требований - куда ж тестировщикам без этого 😀
Приблизительная длительность вебинара - 1,5-2 часа.
А поскольку 12 сентября еще и день программиста, то всех участников вебинара ждет дополнительный подарок еще и по этому поводу. 😉
Как стать участником вебинара:
1️⃣ быть подписанным на мой блог;
2️⃣ заполнить анкету - https://forms.gle/bHESfWNW7YP6dZR27;
3️⃣ проверить свою почту 11-12 сентября;
4️⃣ пройти по ссылке в присланном вам письме-приглашении.
Буду рада вашим лайкам ❤️ и репостам 🚀!
#вебинар #техникитестдизайна
Google Docs
Анкета для регистрации на вебинар-практикум по техникам тест-дизайна от EREMINA.PROQA
Хочу поделиться постом моего коллеги Михаила Писарика, который сейчас специализируется на тестировании мобильных приложений и его автоматизации. На днях он опубликовал статью об использовании Remote Test Lab от Samsung: https://www.linkedin.com/pulse/remote-test-devices-mikhail-pisaryk-39nge/
Очень рекомендую и эту, и другие статьи Михаила на LinkedIn.
К слову, почему-то немногие знают о том, что Samsung предоставляет бесплатный доступ к своей ферме девайсов. Конечно, бесплатное время ограничено, но его ежедневно дается столько, что этого вполне хватает для тестирования.
О Remote Test Lab еще рекомендую почитать вот эту статью: https://t.me/qaglossary/432.
Так совпало, что главного героя там тоже зовут Михаил. Наверное, у Михаилов особая предрасположенность к разработке и тестированию мобильных приложений. 😁
Очень рекомендую и эту, и другие статьи Михаила на LinkedIn.
К слову, почему-то немногие знают о том, что Samsung предоставляет бесплатный доступ к своей ферме девайсов. Конечно, бесплатное время ограничено, но его ежедневно дается столько, что этого вполне хватает для тестирования.
О Remote Test Lab еще рекомендую почитать вот эту статью: https://t.me/qaglossary/432.
Так совпало, что главного героя там тоже зовут Михаил. Наверное, у Михаилов особая предрасположенность к разработке и тестированию мобильных приложений. 😁
Linkedin
Remote test devices
When we test mobile applications, it's very important to conduct testing on real devices. Sometimes, however, there’s a need to test on a device that we don’t have available at the moment.
📚 EREMINA.PROQA: всё о тестировании и QA
Так заработалась сегодня, что и не поздравила нас с нашим профессиональным праздником - днем тестировщика. 😂 Так что исправляюсь и желаю всем нам, дорогие нынешние и будущие коллеги, побольше интересных проектов, классных команд, спокойных релизов и гармоничного…
Тем, кто уже зарегистрировался на вебинар, отправила письма-приглашения. Если письма нет во входящих, обязательно проверьте спам.
Люблю сентябрь: что ни день, то праздник. С днем программиста, коллеги!
А мы уже через 3 часа встречаемся на вебинаре по техникам тест-дизайна.
Все приглашения отправила. 📧
Все приглашения отправила. 📧
Как же приятно читать такие отзывы от своих выпускников! 🥰
Еще учась у меня на курсе, Татьяна очень хотела работать именно в компании Сенла.
И в итоге из 5 предложений выбрала именно эту компанию.
Я очень рада и за Татьяну (ведь мечты должны сбываться), и за компанию (потому что теперь там работает +1 очень добросовестный, способный и перспективный QA-специалист).
#моивыпускники
Еще учась у меня на курсе, Татьяна очень хотела работать именно в компании Сенла.
И в итоге из 5 предложений выбрала именно эту компанию.
Я очень рада и за Татьяну (ведь мечты должны сбываться), и за компанию (потому что теперь там работает +1 очень добросовестный, способный и перспективный QA-специалист).
#моивыпускники
А уже 23 сентября стартует моя новая группа по "Тестированию ПО с нуля".
Как всегда, у меня на курсе будущих тестировщиков ждет:
✅ полное погружение в тестирование без "воды" и ненужной информации;
✅ много практики;
✅ лайфхаки и профессиональные секреты;
✅ живое общение с преподавателем и группой;
✅ сертификат об успешном прохождении курса;
✅ стажировка (по результатам собеседования);
✅ реальная помощь в трудоустройстве.
Подробности здесь: https://sites.google.com/view/ereminaproqa/from0tohero
Там же можно ознакомиться с результатами моей программы трудоустройства за 2024 год: https://sites.google.com/view/ereminaproqa/job_offers и с профилями моих выпускников: https://sites.google.com/view/ereminaproqa/graduates
Как всегда, у меня на курсе будущих тестировщиков ждет:
✅ полное погружение в тестирование без "воды" и ненужной информации;
✅ много практики;
✅ лайфхаки и профессиональные секреты;
✅ живое общение с преподавателем и группой;
✅ сертификат об успешном прохождении курса;
✅ стажировка (по результатам собеседования);
✅ реальная помощь в трудоустройстве.
Подробности здесь: https://sites.google.com/view/ereminaproqa/from0tohero
Там же можно ознакомиться с результатами моей программы трудоустройства за 2024 год: https://sites.google.com/view/ereminaproqa/job_offers и с профилями моих выпускников: https://sites.google.com/view/ereminaproqa/graduates
Всем привет!
Немного полезной информации для тех, кто хочет разобраться в техниках тест-дизайна и правильно применять их на собеседованиях и на реальных проектных задачах.
На следующей неделе стартуют мои новые группы по курсу “Техники тест-дизайна” для базового и продвинутого уровня: https://sites.google.com/view/ereminaproqa/ttd
Кому подойдет этот курс?
1️⃣ Базовый уровень я рекомендую пройти тем, кто уже закончил курсы по тестированию ПО, но еще не трудоустроился. А также тем, кто уже трудоустроился на позицию trainee/junior QA, но чувствует себя неуверенно и не понимает, с чего и как начинать тестирование задачи.
На базовом курсе мы:
✅ разбираем такие ТТД, как доменное тестирование, ТПР, КЭиГУ, pairwise, диаграммы состояний и переходов;
✅ знакомимся с нюансами и лайфхаками их применения на практике;
✅ применяем эти ТТД на реальных 20+ проектных задачах.
Почему это важно для новичков?
Умение выполнять тест-дизайн и использовать при этом ТТД - это базовый навык в работе любого тестировщика. Ведь как иначе подготовиться к тестированию фичи и понять, какие проверки нужно провести для полного и качественного тестирования?
Поэтому практически на каждом собеседовании предлагают выполнить задание на техники тест-дизайна:
* применить ТТД;
* составить чек-лист или тест-кейсы с использованием ТТД.
2️⃣ Продвинутый уровень я рекомендую для middle/senior/lead QA.
Здесь мы будем дополнительно разбирать:
* применение различных ТТД для более сложных задач из таких доменов, как Fintech, Banking, Insurance, HoReCa, Health, Retail и др. (40+ задач);
* применение ТТД в тестировании API;
* использование ТТД на проектах с BDD.
Подробности о курсе и отзывы выпускников можно посмотреть здесь: https://sites.google.com/view/ereminaproqa/ttd
Здесь же можно оставить заявку на курс.
Присоединяйтесь! Будет очень полезно и интересно 🙌
#техникитестдизайна #тестдизайн #testdesign #обучение
Немного полезной информации для тех, кто хочет разобраться в техниках тест-дизайна и правильно применять их на собеседованиях и на реальных проектных задачах.
На следующей неделе стартуют мои новые группы по курсу “Техники тест-дизайна” для базового и продвинутого уровня: https://sites.google.com/view/ereminaproqa/ttd
Кому подойдет этот курс?
1️⃣ Базовый уровень я рекомендую пройти тем, кто уже закончил курсы по тестированию ПО, но еще не трудоустроился. А также тем, кто уже трудоустроился на позицию trainee/junior QA, но чувствует себя неуверенно и не понимает, с чего и как начинать тестирование задачи.
На базовом курсе мы:
✅ разбираем такие ТТД, как доменное тестирование, ТПР, КЭиГУ, pairwise, диаграммы состояний и переходов;
✅ знакомимся с нюансами и лайфхаками их применения на практике;
✅ применяем эти ТТД на реальных 20+ проектных задачах.
Почему это важно для новичков?
Умение выполнять тест-дизайн и использовать при этом ТТД - это базовый навык в работе любого тестировщика. Ведь как иначе подготовиться к тестированию фичи и понять, какие проверки нужно провести для полного и качественного тестирования?
Поэтому практически на каждом собеседовании предлагают выполнить задание на техники тест-дизайна:
* применить ТТД;
* составить чек-лист или тест-кейсы с использованием ТТД.
2️⃣ Продвинутый уровень я рекомендую для middle/senior/lead QA.
Здесь мы будем дополнительно разбирать:
* применение различных ТТД для более сложных задач из таких доменов, как Fintech, Banking, Insurance, HoReCa, Health, Retail и др. (40+ задач);
* применение ТТД в тестировании API;
* использование ТТД на проектах с BDD.
Подробности о курсе и отзывы выпускников можно посмотреть здесь: https://sites.google.com/view/ereminaproqa/ttd
Здесь же можно оставить заявку на курс.
Присоединяйтесь! Будет очень полезно и интересно 🙌
#техникитестдизайна #тестдизайн #testdesign #обучение
А для проверки и закрепления знаний в ТТД попробуйте выполнить первое задание отсюда: https://forms.gle/1Q5s9aBGUeghYmRD9
Google Docs
Пробный тест от eremina.proqa
Подборка вопросов тестового тренажера уровня "Базовый".
Подробнее о тестовом тренажёре для подготовки к собеседованиям и закрепления знаний можно узнать здесь: https://sites.google.com/view/ereminaproqa/tests
Подробнее о тестовом тренажёре для подготовки к собеседованиям и закрепления знаний можно узнать здесь: https://sites.google.com/view/ereminaproqa/tests
Всем привет!
23 сентября (уже сегодня) начинаются занятия в моей новой группе по курсу "Тестирование ПО с нуля".
О чём мой курс и в чём его сильные стороны?
✅ Здесь мы не только изучаем всю необходимую теорию тестирования, но и разбираемся, ПОЧЕМУ она так важна и КАК связана с реальной практикой.
✅ Мы не только решаем много реальных практических задач, но и анализируем РАЗНЫЕ способы их решения.
✅ Мы не только учимся правильно вести разнообразную тестовую документацию, но и разбираемся, КАК АДАПТИРОВАТЬ её под разные проектные ситуации.
✅ Мы не только изучаем все необходимые техники и инструменты, которые нужны тестировщику, но и учимся ПОНИМАТЬ, как именно и в каких именно ситуациях их нужно применять.
А еще у меня на курсе:
✅ формат обучения приближен к менторству, а не к "потоку";
✅ "живые" занятия с ответами на вопросы и индивидуальными разборами всех домашек;
✅ занятия в English speaking club, где мы на английском языке разбираем вопросы с собеседований;
✅ как следствие, каждому слушателю я могу уделить достаточно своего времени и личного общения.
❗️ Но главная цель и ценность курса в том, что здесь мы учимся ДУМАТЬ как настоящие QA-специалисты и применять именно те знания и навыки, которые требуются для решения конкретной практической задачи.
Поэтому у выпускников, успешно закончивших мой курс, не возникает проблем с трудоустройством. Более того - они получают офферы не от одной, а сразу от нескольких ИТ-компаний. В том числе от тех, где уже работают и хорошо себя зарекомендовали мои предыдущие выпускники.
Так что если вы:
* еще присматриваетесь к профессии тестировщика
* или уже начали осваивать её, но поняли, что ваших текущих знаний и навыков недостаточно для успешного прохождения собесов и трудоустройства,
то у вас есть возможность всё изменить в лучшую сторону.
Приходите на первое бесплатное занятие сегодня в 19.00 по Минску, знакомьтесь, задавайте вопросы 🙂🙌: https://forms.gle/yysGo2SuuXs9YLYE8
Подробнее о курсе, моей программе трудоустройства и результатах выпускников можно почитать здесь: https://sites.google.com/view/ereminaproqa/job_offers
23 сентября (уже сегодня) начинаются занятия в моей новой группе по курсу "Тестирование ПО с нуля".
О чём мой курс и в чём его сильные стороны?
✅ Здесь мы не только изучаем всю необходимую теорию тестирования, но и разбираемся, ПОЧЕМУ она так важна и КАК связана с реальной практикой.
✅ Мы не только решаем много реальных практических задач, но и анализируем РАЗНЫЕ способы их решения.
✅ Мы не только учимся правильно вести разнообразную тестовую документацию, но и разбираемся, КАК АДАПТИРОВАТЬ её под разные проектные ситуации.
✅ Мы не только изучаем все необходимые техники и инструменты, которые нужны тестировщику, но и учимся ПОНИМАТЬ, как именно и в каких именно ситуациях их нужно применять.
А еще у меня на курсе:
✅ формат обучения приближен к менторству, а не к "потоку";
✅ "живые" занятия с ответами на вопросы и индивидуальными разборами всех домашек;
✅ занятия в English speaking club, где мы на английском языке разбираем вопросы с собеседований;
✅ как следствие, каждому слушателю я могу уделить достаточно своего времени и личного общения.
❗️ Но главная цель и ценность курса в том, что здесь мы учимся ДУМАТЬ как настоящие QA-специалисты и применять именно те знания и навыки, которые требуются для решения конкретной практической задачи.
Поэтому у выпускников, успешно закончивших мой курс, не возникает проблем с трудоустройством. Более того - они получают офферы не от одной, а сразу от нескольких ИТ-компаний. В том числе от тех, где уже работают и хорошо себя зарекомендовали мои предыдущие выпускники.
Так что если вы:
* еще присматриваетесь к профессии тестировщика
* или уже начали осваивать её, но поняли, что ваших текущих знаний и навыков недостаточно для успешного прохождения собесов и трудоустройства,
то у вас есть возможность всё изменить в лучшую сторону.
Приходите на первое бесплатное занятие сегодня в 19.00 по Минску, знакомьтесь, задавайте вопросы 🙂🙌: https://forms.gle/yysGo2SuuXs9YLYE8
Подробнее о курсе, моей программе трудоустройства и результатах выпускников можно почитать здесь: https://sites.google.com/view/ereminaproqa/job_offers
Для тех, кто хочет потренироваться в тестировании API, рекомендую несколько песочниц.
✅ Для тестирования REST и SOAP API:
https://t.me/qaglossary/992
✅ Для тестирования GraphQL API: https://t.me/qaglossary/991
✅ А еще - список открытых API, на которых также можно потренироваться: https://t.me/qaglossary/762
Для обучения основам тестирования API на моём курсе по тестированию ПО я использую https://petstore.swagger.io/. Заодно знакомимся со Swagger и ловим баги (там они как раз есть). Так что лично от себя рекомендую эту песочницу.
✅ Для тестирования REST и SOAP API:
https://t.me/qaglossary/992
✅ Для тестирования GraphQL API: https://t.me/qaglossary/991
✅ А еще - список открытых API, на которых также можно потренироваться: https://t.me/qaglossary/762
Для обучения основам тестирования API на моём курсе по тестированию ПО я использую https://petstore.swagger.io/. Заодно знакомимся со Swagger и ловим баги (там они как раз есть). Так что лично от себя рекомендую эту песочницу.
Telegram
📚 QA GLOSSARY: полезные материалы по тестированию и QA
⭐ Users — на чем потестить SOAP и REST
https://okiseleva.blogspot.com/2017/04/users-soap-rest.html?m=1
#testing #api #rest #soap #practice #recommended
https://okiseleva.blogspot.com/2017/04/users-soap-rest.html?m=1
#testing #api #rest #soap #practice #recommended
This media is not supported in your browser
VIEW IN TELEGRAM
Еще делюсь хорошей новостью: вчера стартовала моя новая группа по курсу "Тестирование ПО с нуля". 🎉
Конечно, знакомство с тестированием я начинаю не с API (о нем, а также о Swagger, Postman и т.д. мы будем говорить ближе к середине курса).
А вот начинаю я курс с рассказа о SDLC и его моделях, в том числе об Agile. Ну и, конечно же, о роли тестирования в жизненном цикле разработки ПО.
И хочу поделиться с вами вопросом, который мне задала одна из слушательниц на тему Agile и его методологий.
Конечно, знакомство с тестированием я начинаю не с API (о нем, а также о Swagger, Postman и т.д. мы будем говорить ближе к середине курса).
А вот начинаю я курс с рассказа о SDLC и его моделях, в том числе об Agile. Ну и, конечно же, о роли тестирования в жизненном цикле разработки ПО.
И хочу поделиться с вами вопросом, который мне задала одна из слушательниц на тему Agile и его методологий.
Всем привет!
Хорошая возможность для тех, кто хотел изучить Java и автоматизацию на Java:
https://www.linkedin.com/posts/vital-skryl-10214827b_augauxauyauuaut-aston-qa-activity-7246473843270193153-N4i7
В моей библиотеке полезных материалов https://t.me/qaglossary также можно найти хорошие, на мой взгляд, курсы по Java для новичков. Их можно найти там по хэштегу #java.
#курсы #стажировка
Хорошая возможность для тех, кто хотел изучить Java и автоматизацию на Java:
https://www.linkedin.com/posts/vital-skryl-10214827b_augauxauyauuaut-aston-qa-activity-7246473843270193153-N4i7
В моей библиотеке полезных материалов https://t.me/qaglossary также можно найти хорошие, на мой взгляд, курсы по Java для новичков. Их можно найти там по хэштегу #java.
#курсы #стажировка
Linkedin
Vital Skryl on LinkedIn: #астон #aston #qa #qa_engineer_java #курсы #стажировка #бесплатный_курс…
Всем привет! 😉
Начинаем неделю с отличных новостей!
Компания Aston приглашает на бесплатный онлайн-курс
"QA Engineer Java".
Лучшим - приглашение на…
Начинаем неделю с отличных новостей!
Компания Aston приглашает на бесплатный онлайн-курс
"QA Engineer Java".
Лучшим - приглашение на…
Всем привет!
Хочу поделиться публикацией из другого ТГ-канала.
Метрики - это очень важная и актуальная тема в тестировании.
Благодаря им мы можем:
✅ измерять качество не только тестирования, то и разработки, ВА, РМ, ...;
✅ обнаруживать проблемы;
✅ корректировать как стратегию тестирования, так и проектные процессы в целом.
Больше полезных публикаций о метриках в тестировании можно найти в моей библиотеке полезных материалов по хэштегу #metrics: https://t.me/qaglossary
Хочу поделиться публикацией из другого ТГ-канала.
Метрики - это очень важная и актуальная тема в тестировании.
Благодаря им мы можем:
✅ измерять качество не только тестирования, то и разработки, ВА, РМ, ...;
✅ обнаруживать проблемы;
✅ корректировать как стратегию тестирования, так и проектные процессы в целом.
Больше полезных публикаций о метриках в тестировании можно найти в моей библиотеке полезных материалов по хэштегу #metrics: https://t.me/qaglossary
Forwarded from Andrey Ivanov - Quality First (QA)
Тут недавно просили поделиться инфой по метрикам.
Описываю только те метрики, которые собирал сам на практике.
Текста будет много, да и метрик тоже. Поэтому...
Часть 1.
Метрики с участием багов:
1) Открытые/закрытые баги (Open/Closed Bugs).
Считается просто, лучше считать большими диапазонами, от спринта и выше(месяц, квартал) , в зависимости от процесса работы на проекте.
С одной стороны показывает темп работы команды. Ну как команды?! Типа тестировщики открыли, а девелоперы реально пофиксили(хотя мы, конечно, перепроверили). Ну и куча других людей может быть вовлечено в зависимости от содержимого. С другой стороны является хорошим маркером для определения растущего технического долга (Technical Debt), когда мы делаем кучу нового, но и ничего не фиксим в противовес. Для некоторых этапов разработки - это нормально, но все равно полезно.
Также, хочу отметить, что я использую именно статус Closed для этой метрики, потому как плохо настроенный трекер задач, где нет других статусов может очень сильно вводить погрешность в эту метрику, когда баги по итогу оказываются отмененными (Cancelled), или настолько не существенными, что фиксить их никто и не собирается (Rejected, Won't fix, etc.).
2) Количество отмененных дефектов (Canceled bugs).
Иногда собирают рейт (Cancellation rate) по отношению к открытым или собирают обе метрики.
По сути это цифра отображает количество багов признанных избыточными или несущественными, а высокий уровень этой метрики покажет нам то, что есть проблемы в процессе работы, например слабая техническая документация или бизнес требования, проблемы коммуникации, недостаток знаний у тестировщиков или техподдержки.
3) Рейт дефектов на продакшене (Defect Containment Rate).
Одна из самых крутых метрик при регулярных релизах в рамках Скрамов (Scrum), хотя подходит и для других вариантов Agile процессов. Считаем ее, как отношение багов на проде ко всем найденным багам вообще. Чем ниже, тем, соответственно, лучше! Кстати можно считать его не только к продакшену, но и например к UAT, если у вас построен полноценный процесс для этой фазы, а не "просто так называется энвайромент" для тестировщиков или препродакшена.
По факту показывает насколько мы "лоханулись", что может говорить о проблемах с регрессией или покрытием тестами. Хотя тоже бывают и "лишние волнения", когда например продакшен имеет очень специфическую конфигурацию, тогда может быть открыто много дефектов в разных местах на проде, а по сути все может свестись к неверной настройке в одном единственном месте, так что будте осторожны и не вводите себя в заблуждение.
4) Количество дубликатов (Duplicated Bugs).
Вынес эту метрику отдельно от Сancelled потому, что дубликаты показывают рассинхрон именно в QA команде(если кроме вас баги никто не открывает), особенно, актуально для распределенных больших команд, которые могут работать над одним "монолитом" (это не про архитектуру). Можно также считать рейт, тут уже кому как удобнее. Лично я предпочитаю количество.
5) Соотношение багов к задачам (Bug/Task rate).
Считается в основном в разрезе спринтов или релизов. По сути мы оцениваем насколько много или мало багов мы пофиксили за определенный промежуток времени, по сравнению с основной задачей проекта - разработкой приложения.
Метрика "капризная", ей нужно соблюдать баланс. Почему спросите вы?!
Да потому, что если багов мало - значит мы их не исправляем и накапливаем долг, что при накоплении, только еще больше ухудшит качество продукта. А если много, то скорее всего мы только фиксим и ничего нового не производим, а значит, придет "злой" заказчик/менеджер/продукт/хозяин/хаосит-сланешит(нужное подчеркнуть) и накажет нас.
К слову, это тоже может быть не всегда верным, потому что действительно сильная команда разработки может делать хорошо с минимальным количеством проблем, а в "стабилизационные" спринты в составе могут быть только баги. Так что нужно не терять голову, оценивать исторические данные и разумно подходить к любым сигналам от метрик.
На сегодня все 😘.
До встречи в Части 2.
Всем добра!
Описываю только те метрики, которые собирал сам на практике.
Текста будет много, да и метрик тоже. Поэтому...
Часть 1.
Метрики с участием багов:
1) Открытые/закрытые баги (Open/Closed Bugs).
Считается просто, лучше считать большими диапазонами, от спринта и выше(месяц, квартал) , в зависимости от процесса работы на проекте.
С одной стороны показывает темп работы команды. Ну как команды?! Типа тестировщики открыли, а девелоперы реально пофиксили(хотя мы, конечно, перепроверили). Ну и куча других людей может быть вовлечено в зависимости от содержимого. С другой стороны является хорошим маркером для определения растущего технического долга (Technical Debt), когда мы делаем кучу нового, но и ничего не фиксим в противовес. Для некоторых этапов разработки - это нормально, но все равно полезно.
Также, хочу отметить, что я использую именно статус Closed для этой метрики, потому как плохо настроенный трекер задач, где нет других статусов может очень сильно вводить погрешность в эту метрику, когда баги по итогу оказываются отмененными (Cancelled), или настолько не существенными, что фиксить их никто и не собирается (Rejected, Won't fix, etc.).
2) Количество отмененных дефектов (Canceled bugs).
Иногда собирают рейт (Cancellation rate) по отношению к открытым или собирают обе метрики.
По сути это цифра отображает количество багов признанных избыточными или несущественными, а высокий уровень этой метрики покажет нам то, что есть проблемы в процессе работы, например слабая техническая документация или бизнес требования, проблемы коммуникации, недостаток знаний у тестировщиков или техподдержки.
3) Рейт дефектов на продакшене (Defect Containment Rate).
Одна из самых крутых метрик при регулярных релизах в рамках Скрамов (Scrum), хотя подходит и для других вариантов Agile процессов. Считаем ее, как отношение багов на проде ко всем найденным багам вообще. Чем ниже, тем, соответственно, лучше! Кстати можно считать его не только к продакшену, но и например к UAT, если у вас построен полноценный процесс для этой фазы, а не "просто так называется энвайромент" для тестировщиков или препродакшена.
По факту показывает насколько мы "лоханулись", что может говорить о проблемах с регрессией или покрытием тестами. Хотя тоже бывают и "лишние волнения", когда например продакшен имеет очень специфическую конфигурацию, тогда может быть открыто много дефектов в разных местах на проде, а по сути все может свестись к неверной настройке в одном единственном месте, так что будте осторожны и не вводите себя в заблуждение.
4) Количество дубликатов (Duplicated Bugs).
Вынес эту метрику отдельно от Сancelled потому, что дубликаты показывают рассинхрон именно в QA команде(если кроме вас баги никто не открывает), особенно, актуально для распределенных больших команд, которые могут работать над одним "монолитом" (это не про архитектуру). Можно также считать рейт, тут уже кому как удобнее. Лично я предпочитаю количество.
5) Соотношение багов к задачам (Bug/Task rate).
Считается в основном в разрезе спринтов или релизов. По сути мы оцениваем насколько много или мало багов мы пофиксили за определенный промежуток времени, по сравнению с основной задачей проекта - разработкой приложения.
Метрика "капризная", ей нужно соблюдать баланс. Почему спросите вы?!
Да потому, что если багов мало - значит мы их не исправляем и накапливаем долг, что при накоплении, только еще больше ухудшит качество продукта. А если много, то скорее всего мы только фиксим и ничего нового не производим, а значит, придет "злой" заказчик/менеджер/продукт/хозяин/хаосит-сланешит(нужное подчеркнуть) и накажет нас.
К слову, это тоже может быть не всегда верным, потому что действительно сильная команда разработки может делать хорошо с минимальным количеством проблем, а в "стабилизационные" спринты в составе могут быть только баги. Так что нужно не терять голову, оценивать исторические данные и разумно подходить к любым сигналам от метрик.
На сегодня все 😘.
До встречи в Части 2.
Всем добра!