Если вам от руководства поступила команда полностью сфокусироваться на тест-кейсах и инструментах тестирования, следует помнить, что одними тест-кейсами баги не находятся.
Дефекты находятся тестировщиками, а вот тест-кейс призван помочь человеку в выполнении данного процесса.
Далее рассмотрим практические советы того, как можно реально оценивать эффективность от использования тест-кейсов при выполнении рутинной работы в сфере обеспечения контроля качества.
Оценивание тест-кейсов
Итак, как только вы зафиксировали дефект, сделайте пометку о том, где именно в ПО вы его нашли. Рядом необходимо указать оценку найденному артефакту и прописать пометку о том, почему вы оценили данный артефакт именно так, а не иначе.
Касательно оценок, следует придерживаться такой логики:
- Оценка 3 — если артефакт был незаменим при поиске ошибки, у вас бы не получилось найти дефект без него;
- Оценка 2 — если данный артефакт был существенной помощью при поиске бага; может быть ошибка и была бы найдена, но артефакт был полезен;
- Оценка 1 — если от артефакта была польза, но несущественная;
- Оценка 0 — артефакт вообще ни на что не влияет;
- Оценка -1 — такая оценка ставится тогда, когда артефакт отвлек вас от насущной проблемы поиска багов;
- Оценка -2 — если поиск артефакта занял много времени, либо же он, банально, оторвал пользователя от процесса поиска фундаментальных задач;
- Оценка -3 — пользователь обратил внимание на артефакт и больше не смог оторваться от него и весь процесс поиска багов застопорился.
К слову, для того чтобы проставлять оценки, не нужно находить дефекты.
Рекомендуется делать небольшие паузы для процесса оценки статуса поиска багов.
Если баг не удалось найти, необходимо зафиксировать потраченное время.
Как бы не выполнялся процесс тестирования, отмечайте время, которое уходит на исследование тест-кейсов, работу с инструментами и процессами автоматизации.Вам нужно фиксировать взаимодействие с артефактами.
Если есть немного свободного времени, вы можете просматривать подобные оценки вместе с проект-менеджерами и даже разработчиками.
Общая оценка действий иногда показывает реально удивительные результаты: если она выше средней, значит с уверенностью можно говорить о то, что используемые вами методологии и технологии являются передовыми и идеально вам подходят. И не стоит слишком сильно зацикливаться на общей оценке тестируемого проекта.
Гораздо эффективнее будет бегло «пройтись» по всему перечню критериев выбора тест-кейсов. Вы можете «идти» по хронологии либо же просмотреть самые низкие или высокие оценки.
Заключение
Последовательный процесс выстраивания и анализа оценок позволяет вам систематизировать полученный опыт при общении с разными командами разработки: от отдела программистов до звена проект-менеджеров, которые на основе вашего заключения могут прогнозировать стратегии тестирования ПО на все последующие проекты.
Учитесь брать все самое полезное из любого маломальского бага, так как дефекты учат команду по тестированию прогнозировать появление будущих дефектов.
Любое познание дефекта и связанного с ним артефакта — это неоспоримый пользовательский опыт при взаимодействии с ПО, который так необходим рядовому QA-специалисту.
Оставить комментарий