Мы запускаем раздел Вакансии тестировщиков на пробный период до 1 июля 2023 года.
Подробнее посмотреть где будут размещены ваши вакансии и условия размещения можно по ссылке.
Ответьте на насколько вопросов о том, как вы ищите тестировщиков и разместите одну вакансию на один месяц на нашем сайте бесплатно, а также получите 30% скидку на размещение других вакансий вашей компании. Даже если вы не планируете сейчас размещать вакансию, все равно поучаствуйте в опросе, скидка будет действовать до 1 июля 2024 года (в случае, если данный раздел останется после пробного запуска).
Всем привет, меня зовут Глеб! Я — Head of QA в Mayflower. В последние несколько лет мне стали интересны метрики QA — особенно такие, которые позволяют искать проблемы в процессах, вести переговоры с бизнесом, показывать пользу тестирования для проекта и использовать показатели в качестве KPI.
За время работы в различных компаниях я видел разные подходы для решения этих задач и среди множества метрик я сконцентрировался на defect density. В результате ее изучения, я кастомизировал ее и запилил свою dd “со звездочкой”.
Если вы тоже находитесь в поиске метрики, учитывающей чистоту релизов, их объем и скорость, вам может быть полезна моя статья.
По классике, метрика defect density — это доля дефектов, приходящаяся на отдельный модуль в течение итерации или релиза; считается на тысячу строк кода. Идея метрики заключается в том, чтобы определить отношение дефектов в вашем коде к его объему и постепенно уменьшать его. Идея, надо признать, отличная, но нюансы внедрения метрики могут сделать ее достаточно неудобной для использования.
Если ваш проект написан на нескольких языках, имеет много модулей, отдельных сервисов, механизм подсчета этой метрики будет непросто прикрутить.
Интерпретация значений может быть затруднена: для кого-то соотносить баги и количество строк может показаться неудобным, нелогичным и неприменимым, например, при тестировании “на стороне”, когда к коду вообще может не быть доступа, а данные о его качестве хочется получать.
Хочется взять самое лучшее от этой метрики, модифицировав ее для удобства и большей информативности. Если оттолкнуться от идеи, добавить производительность команды, критичность разных дефектов, то можно посчитать defect density ”со звездочкой” — отношение дефектов различных приоритетов на продакшне к фактической пользе, которую донесла команда за спринт. Так можно учесть сразу и чистоту тестирования внутри спринта, и скорость доставки через доставленный объем задач и багфиксов. Такой показатель можно понятно объяснять бизнесу и на него можно подвязываться как на качество релизного процесса — как на уровне отдельной команды, так и на уровне всего продукта.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Недавно я разговаривал с моим непосредственным руководителем про end-to-end (e2e) тесты и их предназначение. Возможно, дело в моем лингвистическом прошлом, но я лучше думаю, Когда пишу. Я решил перечислить, чем должен быть хороший e2e-тест и что он должен делать, а чего не должен. Так я и пришел к этому списку.
