Nice lecture! This lecture not long before the war in Ukraine started, you'd almost forget how good the computer scientists/devs from Ukraine are with all the focus on that war... Some of my former colleagues (in the Netherlands) are from the Ukraine, so I worked with them for years... Hope it ends soon, and preferably Ukraine gets its whole country back.
Если переносить метрику продуктивности для программиста "количество написанных строк" на тестировщика, то правильнее будет "сколько стори/фич ты можешь проверить за день" или "за сколько будет пройден регрессионный набор вручную"
И то, один пройдет тест-свит за 2 дня ответственно, второй за 2 часа левой ногой пропасает, третий будет мурыжить 2 недели, а потом скажет что у него лапки. Как и метрика девов по строкам кода - откровенное говно, посмотрим правде в глаза.
@@milana6452 можно сделать выводы в совокупности с другими метриками, как пропуск ошибок у пропасавшего. Если есть система управления тестами, то видно время. По времени будет видно какие у кого лапки. Какими вы хорошими метриками можете поделиться?
@@orangemad1 пождите, возьму разбег и начну делиться подходами и метриками с русскими на 11й месяц войны. Охота вам своих несчастных мерять как рабов - ваше дело.
Метрика производительности тестировщика как "количество багов в день" выглядит необъективной, ибо зависит не только и не столько от качества работы тестировщика, сколько от качества тестируемого кода. Хорошей метрикой может быть "количество НЕнайденных багов", измеряемое по фидбеку от конечных пользователей. Аналогично кажется логичной метрика для разработчиков "количество ошибок, найденных в его коде".
Да, не объективно, но использовать стоит. У нас была сотрудница и на неё жаловались, что она не выкладывается, и подобное случалось уже несколько раз. Посмотрели сколько она завела багов и оказалось, что она топ1 среди большого штата. И в данной ситуации надо понять почему у неё бывают моменты непродуктивности, возможно из-за усталости, а не вешать на неё ярлык "ленивой"
@@orangemad1 Я работал с такими сотрудниками. Человек не может настроить окружение - заводит баг. Человек не знает как работает фича - заводит баг. Удачи вам с такой метрикой решать, что это хороший спец.
Обов'язки РМ це обов'язки QA, таких собі "ефективних менеджерів". Його стратегія не принесе покращення для продукту, а робота буде тільки задля процесу. Така фігня зараз в нас в державних структурах
At the end I got who devops are))) and what is the difference between them and programmers… QA and QC are known as different aspects by default. QA knows figures, make metrics from figures understanding the dependencies. QC produces some figures related to the product, not to the customers and market.
Мне кажется было бы лучше чтобы Java гуру рассказал об автоматизации и как не надо делать... Для меня было удивлением что рассказывали про QA :) я приготовился изначально к хардкору)
як цікаво, що відкритий сексист і фашист, який підтримав війну росії проти України, виступав на конфі в Києві. І ці погляди в нього завжди були. Сподіваюся, ми не будемо тягнути це сміття до себе в країну тепер, незважаючи на їх досвід у розробці.
Вообще кстати чел не учитывает несколько моментов из реальной жизни 1. Порог качества часто ниже, чем обеспечивает даже рядовой тестер с опытом 2-3 месяца. И таких спецов в тестировании и разработке очень много и работают, ходят на собеседования и т.п. 2. Вам достаточно одного сеньора на одном из 3 уровней (аналитика, разработка, тестер) и у вас уже критов будет по минимуму. Модель швейцарского сыра. Если у тебя на 2 уровнях нормальные спецы - то вероятней всего бизнес уже не будет готов платить за отдельного QA. Если говорить про слова - слова правильные. Если говорить про суть - QA никому не нужны. Это просто общепринятое название тестеров.
![[DOKKAN BATTLE] Worldwide Campaign Announcement Video Part 2!](http://i.ytimg.com/vi/JpT5Voak6WA/mqdefault.jpg)
Nice lecture! This lecture not long before the war in Ukraine started, you'd almost forget how good the computer scientists/devs from Ukraine are with all the focus on that war... Some of my former colleagues (in the Netherlands) are from the Ukraine, so I worked with them for years... Hope it ends soon, and preferably Ukraine gets its whole country back.
Если переносить метрику продуктивности для программиста "количество написанных строк" на тестировщика, то правильнее будет "сколько стори/фич ты можешь проверить за день" или "за сколько будет пройден регрессионный набор вручную"
И то, один пройдет тест-свит за 2 дня ответственно, второй за 2 часа левой ногой пропасает, третий будет мурыжить 2 недели, а потом скажет что у него лапки.
Как и метрика девов по строкам кода - откровенное говно, посмотрим правде в глаза.
@@milana6452 можно сделать выводы в совокупности с другими метриками, как пропуск ошибок у пропасавшего. Если есть система управления тестами, то видно время. По времени будет видно какие у кого лапки. Какими вы хорошими метриками можете поделиться?
@@orangemad1 пождите, возьму разбег и начну делиться подходами и метриками с русскими на 11й месяц войны. Охота вам своих несчастных мерять как рабов - ваше дело.
Метрика производительности тестировщика как "количество багов в день" выглядит необъективной,
ибо зависит не только и не столько от качества работы тестировщика, сколько от качества тестируемого кода. Хорошей метрикой может быть "количество НЕнайденных багов", измеряемое по фидбеку от конечных пользователей.
Аналогично кажется логичной метрика для разработчиков "количество ошибок, найденных в его коде".
Да, не объективно, но использовать стоит. У нас была сотрудница и на неё жаловались, что она не выкладывается, и подобное случалось уже несколько раз. Посмотрели сколько она завела багов и оказалось, что она топ1 среди большого штата. И в данной ситуации надо понять почему у неё бывают моменты непродуктивности, возможно из-за усталости, а не вешать на неё ярлык "ленивой"
@@orangemad1 Я работал с такими сотрудниками. Человек не может настроить окружение - заводит баг. Человек не знает как работает фича - заводит баг. Удачи вам с такой метрикой решать, что это хороший спец.
@@СергейКушнир-э3м у нас такие не заводят, такое помечается в отказ, процент отказов крайне мал
Егор, спасибо за доклад!
Очень круто!
✌👍
The best video I like how you explains the difference thank you very much ❤️
Обов'язки РМ це обов'язки QA, таких собі "ефективних менеджерів". Його стратегія не принесе покращення для продукту, а робота буде тільки задля процесу. Така фігня зараз в нас в державних структурах
At the end I got who devops are))) and what is the difference between them and programmers… QA and QC are known as different aspects by default. QA knows figures, make metrics from figures understanding the dependencies. QC produces some figures related to the product, not to the customers and market.
Мне кажется было бы лучше чтобы Java гуру рассказал об автоматизации и как не надо делать... Для меня было удивлением что рассказывали про QA :) я приготовился изначально к хардкору)
это и был хардкор.
Было познавательно, спасибо. Хоть и не со всем согласен.
Спасибо за доклад!
як цікаво, що відкритий сексист і фашист, який підтримав війну росії проти України, виступав на конфі в Києві. І ці погляди в нього завжди були. Сподіваюся, ми не будемо тягнути це сміття до себе в країну тепер, незважаючи на їх досвід у розробці.
Вообще кстати чел не учитывает несколько моментов из реальной жизни
1. Порог качества часто ниже, чем обеспечивает даже рядовой тестер с опытом 2-3 месяца. И таких спецов в тестировании и разработке очень много и работают, ходят на собеседования и т.п.
2. Вам достаточно одного сеньора на одном из 3 уровней (аналитика, разработка, тестер) и у вас уже критов будет по минимуму. Модель швейцарского сыра. Если у тебя на 2 уровнях нормальные спецы - то вероятней всего бизнес уже не будет готов платить за отдельного QA.
Если говорить про слова - слова правильные. Если говорить про суть - QA никому не нужны. Это просто общепринятое название тестеров.