Метрики в тестировании. Матрица трассировки

[@rusau]

Таймкоды ниже: 00:00 - Матрица трассировки 10:56 - Метрики в тестировании 25:35 - Подводим итоги

[@antheanika865]

Готовлюсь к собеседованию к стажировке на тестировщика (до этого с IT не была связана). Ваши лекции очень помогают освоить материал! Спасибо! Очень хорошо объясняете, никакой "воды", все четко и по делу!

[@rusau]

Большое спасибо! Удачи!

[@thecomrad1677]

И как ?

[@starkinc.2809]

Хорошие уроки, Артём! Буду пересматривать и перечитывать. Спасибо за материал!

[@rusau]

Пожалуйста!

[@ПолинаГру-к5ь]

Уже больше полугода работаю, но поучить новый материал у тебя всё ещё очень люблю 🥰

[@rusau]

Мне приятно 🐈

[@irynachechyna1015]

:))) я уже 5 лет куда и смотрю Артема с удовольствием. Особенно перед собесами

[@ALEXCAPITAL666]

Артем благодаря твоему каналу за год моя ЗП возраста с 100к до 250к. Спасибо большое тебе!

[@rusau]

Привет, если это действительно так, то очень рад!! Всегда пожалуйста!!

[@marikovalyova9357]

Артем, спасибо Вам огромное за доступное и структурированное объяснение таких сложных (по моему мнению) вещей. Однозначно полезный и познавательный канал для тестировщиков. Успехов Вам.

[@rusau]

Большое спасибо!

[@ЮлияСтепанова-г5ж]

Большое вам спасибо! На ваших курсах все четко, ясно и понятно)

[@rusau]

Спасибо!

[@annafrankenstein85]

Спасибо большое за урок, Артём!

[@elenaterlyga2497]

Прекрасно структурировано и детально! Огромное спасибо!

[@Luana-nc4pl]

Супер! Спасибо ☺️

[@dariakhomenko6727]

Спасибо! Очень полезно 😋

[@resident77777]

Дякую за пізнавальний контент :)

[@АлексейДоценко-э3к]

Спасибо за топовый контент

[@СергейИванов-й5х2х]

Класс! Спасибо.

[@allascherbakova3178]

Артём, доброго вам проживания в Стамбуле! Спасибо за все, что вы делаете, под вашим последним видео у меня отключены комментарии (((

[@rusau]

Я специально их отключил, дабы не разжигать ненависть. Сейчас нет большого временного ресурса, чтобы следить за комментариями. Спасибо!

[@allascherbakova3178]

@@rusau И вам спасибо! Удачи на новом месте и всем нам мирного неба над головой!

[@МаМася-у1р]

Артём, добрый вечер. Что посоветуете для редуцирования избыточности тест-плана? Думала прлтзоваться матрицой трассировки, и оставить в тест-плане регресса только по одному кейсу на каждое требование. Очень разросся тестплан за счет кейсов, сшставленных по ошибкам, найденным в очередной итерации регресса. Но по сути получается одно требование покрыто несколько раз. Этот разросшийся план отдельная боль. И делать дальше такой объем уже нереально, и выбросить что-то страшно. Автоматизатора нет. Так что регресс - это боль

[@asmr_codster]

Спасибо за шаблон с матрицей

[@rusau]

Пожалуйста!

[@ALEXCAPITAL666]

Супер!!!!

[@murtazina_raisa]

Здравствуйте, у вас телеграм канал есть на всякий случай? Или где вас можно ещё смотреть?

[@alekst1908]

Отличное разъяснение))

[@KseniyaLavnich]

Спасибо

[@Fundamentum2012]

Здравствуйте, благодарю за видео! Я работаю единственным тестировщиком в компании (так получилось), и не использую матрицу и метрики. Вот думаю, что хорошо бы подучить эти и другие темы, на всякий случай, если надо будет менять работу) И вот возник вопрос, хочу задать. Сначала опишу свой рабочий день, чтобы было более понятно. Прошу прощения, если отнимаю время🙏🏻 Девелоперы ведут работу в гитлабе, у каждого эпика есть таски, к каждой из которых есть merge request. Я пишу чеклисты для конкретного MR'a в связанной с ним гитлаб таске и апруваю его (MR) только, если все чеклисты passed. Покрываю проверками требования, обычно, на ±80% с edge cases, но без жести) Баги пишу ниже под чеклистами (ну и в личку дублирую разработчику). Все девелоперы довольны, вопросов ни у них, ни у руководства не возникало по моей работе. Каждый день созваниваюсь с тимлидом американским (cross functional team) и говорю, что сегодня можно мержить, а что нет. По итогу менеджеру видно, что скажем в эпике 1 есть 10 тасок, из них 5 вмержены, 2 в процессе qa, 3 ещё не начаты. До релиза 2 недели, всё ок, типо) Те минорные баги, что уже есть на проде, с ними все ок, потому что на их исправление нет времени. А те блокеры, что пролазят, к сожалению, иногда после тестирования, они быстро фиксятся в авральном режиме, но такое бывает раз в 2 месяца, может, тьфу-тьфу. Ну и часто бывает, что после релиза бизнес внезапно передумал и сделал новые требования. Тогда всё по новой) Отсюда главный вопрос: что я упускаю? зачем в принципе нужно бюрократизировать такую довольно простую и наглядную работу тестировщика, где весь отчёт уже есть в таске, привязанной к mr'у?

[@cherepashkaRafael]

К чему вопрос? Одно из главных постулатов тестирования: "Тестирование зависит от контекста". В контексте твоей работы может не требоваться писать документацию, представленную в этом ролике. Это связано и с другим постулатом: "Тестовая документация при разработке - побочный продукт, в то время как основной - работоспособное качественное ПО. Что касается 2-х методов, представленных в этом ролике, то они на 80% мусорные. Первый вообще некорректен в том виде, в котором его представляет автор видео, потому что фраза "Все требования должны быть равномерно покрыты проверками, и поэтому на каждое требование должно быть одинаковое количество проверок " - логически ошибочное. Я не буду перечислять несколько пунктов, почему оно ошибочное, потому что считаю для качественного инженера по тестированию это очевидным. По поводу второй метрики (процент покрытия автотестами или регресса) - пока работник будет составлять табличку на 1000 тестов, его уже уволят за то, что не показывает результат. Таблицу эту пилить навскидку неделю, устно посчитать - условно пару часов. Любая работа имеет КПД. В любом деле надо стремиться к тому, что показывать максимально возможный кпд

[@nikolaypobedy7148]

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

[@rusau]

В матрице на в первую очередь интересует покрытие самих требований. Как вы это организуете особой разницы не имеет. Главное, чтобы можно было визуально оценить покрытие.

[@kseniiahavrylenko1641]

Артем, спасибо за видео! Вопрос: может ли один тест кейс попасть одновременно в регрессию, и в смоук? Почему в таблице можно выбрать только что-то одно?

[@rusau]

Пожалуйста) А какой смысл из запускать два раза? И смоук, и регрессия относят к тестированию, связанному с изменениями. Мы же за оптимизацию ☺️

[@AGRe55ive]

спасибо за объяснение про матрицу. Что гугл, что яндекс выдаёт какую-то дичь на первых двух страницах. В ютубе тоже мало, что нашёл.

[@rusau]

Пожалуйста

[@ole8940]

Привет, а можна сноску на Mindmup, которой ти ползуешся.

[@rusau]

Mindmanager как программа. А ссылки на все карты есть в описании к видео

[@yurijryagin8988]

Спасибо за видео! А что делать если менеджеры не требуют никаких метрик ? =)

[@rusau]

Пожалуйста! Можно ввести их для себя. Без метрика и их анализа не так просто судить о качестве приложения и оценивать эффективность изменений в процессе обеспечения качества.

[@andriichumak7716]

Извиняюсь за вопрос. А можно расшифровать слово 'метрика'

[@rusau]

ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F

[@andriichumak7716]

Спасибо

[@monday--]

Возможно такие метрики больше актуальны для аутсорса или очень больших компаний. Если в компании скажем около 100 человек и ты один тестировщик на проекте (а то и не на одном), то по своей инициативе тратить время на подобные метрики мне кажется не очень разумно. Будет полезнее потратить это время на разработку автотестов, после которых уже можно генерить отчет на основе результатов этих самых автотестов (при условии что у самих автотестов достаточное покрытие от какого-то общего числа кейсов, которые проверяются мануально всегда). Конечно если начальство скажет что нужны метрики - то хочешь не хочешь нужно будет это сделать, но в остальных случаях это кажется лишним. Когда ты один тестировщик на проекте, то как правило времени на подобные метрики у тебя просто нет

[@rusau]

Само собой. Это просто набор наиболее часто встречающихся. И скорее для зрелых компаний и команд.

[@cherepashkaRafael]

Работал в двух банках. за такую низкоэффективную трату времени работника бы линчевали. В ещё двух компаниях, в которых работал - аналогично

[@pfcompany885]

Так!

[@Petrengo1]

👍

[@hannabezvershenko5524]

Кто нашёл работу после этих лекций?

[@rusau]

В инстаграме в актуальных историях сохранены отзывы реальных ребят. Кто-то выучился самостоятельно, кто-то использовал материалы этого канала как дополнительные.

[@Oleg_Bu]

я нашел работу. Учился сам, но данный курс только треть того врмени, потраченого на обучение. Остальное - книга Святослава Куликова и его же видео курс на сайте EPAM, а так же гуглил по темам, которые было сложно понять с первого раза.

[@TatianaLebedeva-u4o]

Не согласна с пунктом касательно оценки качества кода разработчиков. Кто такой QA, чтобы брать на себя ответственность анализировать качество работы разраба? Разве что если только он не бывший разраб или не разработчик в тестировании. Иначе очень сомнительно, что он может обладать знаниями и навыками, достаточными для того, чтобы давать оценку профессиональности чужого кода. Ревью кода разраба должен делать лид разрабов, и для этого у них есть свои метрики. А не тестировщик. Каждый должен отвечать за свой участок работы и не лезть, тем более с оценками, в проф обязанности другого члена команды, выполняющего иные функции. Уже не говорю о том, что подобная "инициатива" может крайне негативно повлиять на взаимоотношения в команде.

[@rusau]

Видимо. вы не работали в Scrum-командах, в которых нет четкого разделения на разработчиков, тестировщиков и других членов. Вас не просят оценивать код на уровне лида разработки, а участвовать в ретроспективах, оценивать общую эффективность команды. работать над обеспечением и контролем качества. Эта зона ответственности всей команды. И нормальные QA не боятся инициативы и обсуждают улучшения с командой.

[@mss2967]

Всё желание дальше изучать тестирование по, после ваших уроков пропадает, слишком умными фразами говорите и быстро(

[@rusau]

А здесь не будет просто) На рабочем месте вас засыпят умными фразами с первого дня. Я еще не самое сложно здесь рассказываю. Плюс к этому видео надо переходить после просмотра базовых уроков. Каждое непонятное слово гуглите. Говорят, что помогает. Без гугла не один айти-специалист работать не сможет)

[@lili2659]

Из песни слов не выкинешь. Учите термины

[@Fundamentum2012]

Смотрю на 2x, всё понятно🙂

[@ilyas5424]

Спасибо

[@olmikify]

спасибо