4) Тут работает негласное правило - если баг появился в результате выкатки новой фичи (неважно, в существующем ранее коде или в новом), то считаем, что это "Баг после релиза"
Понимаю, что этот показатель адаптирован под вас и вы по нему принимаете какие-то решения. Однако я думаю, что если все-таки учитывать в каком именно коде - в новом коде/новых фичах или в старом - появился баг, то можно прийти к полезным предположениям, может быть и выводам:
Ситуация 1: после релиза обнаружился баг в новом: - предположение 1: что-то пошло не по плану в процессе релиза; - предположение 2: что-то в тестировании фичей пошло не так;
Ситуация 2: после релиза обнаружился баг в старом: - предположение 1: некорректный/неполный регрессионный набор был запущен именно для этого релиза; - предположение 2: в целом регрессионный набор не соответствовал (не успели прогнать, не успели/забыли/не планировали покрывать кейсами старый код)
Думаю что понимание в каком коде появился баг - в старом или новом - важно и поможет выявить разные проблемы: поле для анализа здесь открывается не маленькое.
Метрики тестирования — это определенные показатели, которые дают нам возможность оценить качество программного обеспечения
Здесь нет ошибки? Может быть вы имеете ввиду "возможность определить качество тестирования", а не качество продукта?
Баги в старом коде. Эта метрика нужна для измерения общего качества и понимания, сколько багов мы обнаружили в старом коде.
Подскажите, что значит общее качество и каким образом можно понять степень качественности опираясь на количество багов.
Баги до релиза. Их находит тестировщик. Благодаря этой метрике мы понимаем, сколько дефектов обнаружено в новой фиче до того, как мы ее зарелизили
Баги до релиза могут быть не только в новых фичах, но и там, где новые фичи случайно что-то сломали. Вы такое не учитываете в этой метрике или вообще не учитываете?
Баги после релиза — это баги, найденные тестировщиками, менеджерами, другими сотрудниками или пользователями после выпуска фичи. Собираются автоматически из Jira. Учитываются задачи с типом “Баг” и меткой “баг_в_новом_коде”.
Аналогично - баги могут оказаться и в старом коде, вы их учитываете здесь?
Пожалуйста. Еще интересовался получением MS в Computer Science - https://institute.constructor.org/programs/quantum-software-engineering-and-computer-science - но пока отложил. Из интересного там:
можно обучаться очно в Швейцарии, хотя это не жесткое требование - можно договориться и большую часть времени проходить в онлайне, приезжая несколько раз на сдачу сессий.
обучение платное - 20k CHF в год за обучение + 2к CHF административный платеж за все время обучения; в случае интересного для профессора предложения по магистерской, можно заплатить только 2к, остальное покроют стипендией. Заинтересовать можно попробовать темами, связанными с QA, т.к. профессор сильно связан с этой областью.
консультируют по процессу получения визы и содействуют; говорят - дают пока еще визу для обучения гражданам РФ.
Здесь уже будет нужно и документы о текущем образовании и мотивационное письмо для поступления.
Написание эффективных концепций тестирования очень важно, поскольку это может повлиять на качество самого тестирования
Может повлиять - интересная формулировка. А может и не повлиять. Из этого следует, что утверждение о важности - сомнительно, потому что опирается на «может повлияет, в может не повлияет»
лучше всего приобретать железо с процессорами одного производителя. Тогда откроется возможность переезда работающих виртуальных машин с одной ноды кластера без остановки самой виртуальной машины
Инженер-робототехник, в 2009 устроился в техподдержку IT конторы за 9к. Благодаря тому, что у самого всегда был интерес и дела делал в соответствии с ним :) До сих пор в IT
Рост ЗП - 20к в конце 2010, 60к в середине 11г, 100к в середине 2012, 130 в середине 15, 150 в середине 17, 200 в 19, 250 в 20, 300 в 22, дальше умолчу ;)
Мне кажется, у вас сложилось неправильное впечатление, что своим комментарием я принижаю чью-то значимость. Совершенно не принижаю, однако продолжу говорить, что тестировщик не может «руководить качеством». Это просто факт.
Тестировщик (как специалист) начинает руководить качеством
Ощущение, будто тестировщик (который, как я писал выше, руководит качеством)
Тестировщик не может руководить качеством. Тестировщик может находить несоответствие требованиям.
Даже если представить, что есть примитивный критерий качественности/некаяественности - «несоответствие в больше чем 5% бизнес требований признак некачественности » - всё, что может тестировщик - выявить эти несоответствия/завести баги. Дальше нужно влияние на соседние процессы - аналитики, поставки, разработки. У обычного тестировщика этого влияния нет. Без влияния на соседние процессы руководить/управлять качеством не получится. Не каждому тимлиду тестирования позволят на эти процессы влиять.
Не передергивай. Я сказал о том, что с планом будет шанс, а не гарантия. Шанс выпадает не всем. Можешь сказать той тысяче, о которой ты даже не знаешь, что кто-то тысяча десятый шанс использовал.
Статью надо было назвать - "как я нашел первую работу в IT в 2011 году". Польза от такой статьи была бы понятна сразу по заголовку.
На мой взгляд, очень удачное сочетание статьи и рекламы. Было интересно и приятно читать
Повышенная концентрация «Я». Первые два мобильных экрана - 8 раз
Не удивительно
Давайте заверифаим баг :)
Необычное ощущение - пролистал статью про дашборды, ни одного дашборда не увидел - монотонный текст
А может лучше новых статей?
Не поздно ли верстать сайты в 9 лет
Как программировать в 10 лет если не хочется
Как программировать в 11 лет если немного начал хотеть но не знаю на чем
Как программировать в 12 лет, если выгорел
Мне было бы интересно
Понимаю, что этот показатель адаптирован под вас и вы по нему принимаете какие-то решения. Однако я думаю, что если все-таки учитывать в каком именно коде - в новом коде/новых фичах или в старом - появился баг, то можно прийти к полезным предположениям, может быть и выводам:
Ситуация 1: после релиза обнаружился баг в новом:
- предположение 1: что-то пошло не по плану в процессе релиза;
- предположение 2: что-то в тестировании фичей пошло не так;
Ситуация 2: после релиза обнаружился баг в старом:
- предположение 1: некорректный/неполный регрессионный набор был запущен именно для этого релиза;
- предположение 2: в целом регрессионный набор не соответствовал (не успели прогнать, не успели/забыли/не планировали покрывать кейсами старый код)
Думаю что понимание в каком коде появился баг - в старом или новом - важно и поможет выявить разные проблемы: поле для анализа здесь открывается не маленькое.
Здесь нет ошибки? Может быть вы имеете ввиду "возможность определить качество тестирования", а не качество продукта?
Подскажите, что значит общее качество и каким образом можно понять степень качественности опираясь на количество багов.
Баги до релиза могут быть не только в новых фичах, но и там, где новые фичи случайно что-то сломали. Вы такое не учитываете в этой метрике или вообще не учитываете?
Аналогично - баги могут оказаться и в старом коде, вы их учитываете здесь?
Именно дашборд качества не был необходимостью, а вот приоритизация требований и контроль за тем, какие задачи берутся в работу, были нужны.
Пожалуйста. Еще интересовался получением MS в Computer Science - https://institute.constructor.org/programs/quantum-software-engineering-and-computer-science - но пока отложил. Из интересного там:
можно обучаться очно в Швейцарии, хотя это не жесткое требование - можно договориться и большую часть времени проходить в онлайне, приезжая несколько раз на сдачу сессий.
обучение платное - 20k CHF в год за обучение + 2к CHF административный платеж за все время обучения; в случае интересного для профессора предложения по магистерской, можно заплатить только 2к, остальное покроют стипендией. Заинтересовать можно попробовать темами, связанными с QA, т.к. профессор сильно связан с этой областью.
консультируют по процессу получения визы и содействуют; говорят - дают пока еще визу для обучения гражданам РФ.
Здесь уже будет нужно и документы о текущем образовании и мотивационное письмо для поступления.
Минус в карму за правду? Это мощно.
Вообще этим надо заниматься с самого начала, а не когда приходит выгорание.
Может повлиять - интересная формулировка. А может и не повлиять. Из этого следует, что утверждение о важности - сомнительно, потому что опирается на «может повлияет, в может не повлияет»
В некоторых случаях также будет работать между AMD и Intel, описано тут https://forum.proxmox.com/threads/live-migration-between-intel-xeon-and-amd-epyc2-linux-guests.68663/
https://forum.proxmox.com/threads/live-migration-cpu-types-and-performance.137946/
Инженер-робототехник, в 2009 устроился в техподдержку IT конторы за 9к. Благодаря тому, что у самого всегда был интерес и дела делал в соответствии с ним :) До сих пор в IT
Рост ЗП - 20к в конце 2010, 60к в середине 11г, 100к в середине 2012, 130 в середине 15, 150 в середине 17, 200 в 19, 250 в 20, 300 в 22, дальше умолчу ;)
Пришлось даже скрипт писать, чтобы успеть купить 4 места в одном купе. По другому не получилось в этом году.
Очередная инновация - «дать возможность» купить то, что даже продать нельзя. Их сметают в первые секунды открытия продаж.
Мне кажется, у вас сложилось неправильное впечатление, что своим комментарием я принижаю чью-то значимость. Совершенно не принижаю, однако продолжу говорить, что тестировщик не может «руководить качеством». Это просто факт.
Тестировщик не может руководить качеством. Тестировщик может находить несоответствие требованиям.
Даже если представить, что есть примитивный критерий качественности/некаяественности - «несоответствие в больше чем 5% бизнес требований признак некачественности » - всё, что может тестировщик - выявить эти несоответствия/завести баги. Дальше нужно влияние на соседние процессы - аналитики, поставки, разработки. У обычного тестировщика этого влияния нет. Без влияния на соседние процессы руководить/управлять качеством не получится. Не каждому тимлиду тестирования позволят на эти процессы влиять.
Не передергивай. Я сказал о том, что с планом будет шанс, а не гарантия. Шанс выпадает не всем. Можешь сказать той тысяче, о которой ты даже не знаешь, что кто-то тысяча десятый шанс использовал.