Дякую за фiдбек, але і я з свого досвіду не можу з вами погодитись, але це нормально як на мене. У кожного своя школа та своя правда тут, але я спробую відстояти ці пункти, що ви описали.

Почнемо з того, що Priority дуже часто може та повинен виставляти QA (іноді залежить від процесу на проекті), бо Priority, як я зазначив у статті також показує наскільки це важливий фікс для подальшого тестування, а хто як не QA це може знати?

Що стосується Safari, то про нього в статті навіть немає згадки, а говоримо ми про chrome, який є одним за найпопулярніших браузерів. Але немає сенсу який браузер ми обговорюємо, бо я у статті казав про перевірку та підтвердження що дефект релевантний у любому браузері що ми підримаємо за вимогами, та й дефект цей не є браузерозалежним. Звідси й показники priority та severity

Ну а про базу, то я в цілому не можу прийняти, як QA старої закалки. QA, який буде тільки, як та мавпа зі статті тикати у UI без якогось вміння копнути глибче — поганий тестувальник, та не QA зовсім, на мою думку. Гарний QA буде або мати рацію як і в які таблиці потрібно додати запис для реєстрації юзера (камон, це базовий функціонал для подальшого тестування), або запитає на це девелопера, та зможе продовжити тестування, а не буду чекати на фікс багу, якщо є шанс на workaround

Але я не говорю, що це єдина істина. Може на ваших проектах ви не допускаєте QA до бази, та в них другий спектр задач. Все може бути

Якщо цей дефект потребує срочного фікса, то я би про нього зарепортував в девелопера, а потім спокійнісенько сів би збирати усю інфу до купи. Памʼятаємо, що работа на дефектом на закінчується фіксом девелопера, після цього дефект треба перевірити комусь, а це може бути менш кваліфікований колега.

Дуже шкоди, що у вас така думка, але я розумію звідки вона могла зʼявитися. Але не усюди так, у моїх командах наприклад, девелопери з повагою відносяться до тестувальників, та щиро вдячні за грамотно оформлені та своєчасно знайдені бажини

достойно уважения :) мое почтение QA инженеру

Відчуваю усю боль через текст :) Дякую за розгорнутий команетар

Дякую! Хто знає, може і напишу подалі. Хочу додати статей до нашої спільноти!

Так я же в статті вказував номер релізу :) Даже у прикладах є. Інші пунктики — гарні доповнювання.

Вітання та дякую за питання. З мого досвіду, майже завжди, якщо немає можливості відтворити, то, швидше за все, просто ще не знайшли спосіб. Інакше, то швидше за все якийсь збіг випадковостей, котрий і користувач відтворити не зможе. Але я не вірю в випадковості в IT, то моя порада, якщо ви в глухому куті і не знаєте, як бути далі з відтворенням, а ваше професійне чуття підказує, що проблема є, то найвірнішим способом буде попросити допомоги у розробника цієї частини функціоналу. Описати ситуацію, з якою ви зіткнулися, показати лог та описати що коїлось з продуктом у цей час запису у логах, та запитати куди ще подивитися і покопати, щоб дістатися до істини, та відтворити цей дефект

а я ось посмію не погодиться. Допустимо самарі не вистачило, то тоді, якщо все грамотно описати, вистачить найчастіше AB щоб відтворити, і EB щоб зрозуміти, як потрібно бути. А кроки по відтворенню, це швидше для складних і заплутаних кейсів, або для джуників які ще не так поглунили у проект.

Anyway, порядок цих полів може бути таким яким це зручно усім членам команди, це не є правилом. На мою думку порядок ціх полів не є таким принциповим, щоб за нього сперечатись. Пишить як це зручно для проекту і як це історично склалось :)

Дякую за коментар. Радий, що доповідь сподобалась. Фібек це завжди домога наступним статтям :) За перевірка на дублікат «Шукай перед тим як створити новий» тисну руку, колега. А ось з іншими пунктами не можу не погодатись, а ні оскаржити, бо вони дуже залежні від проекту та процесів на ньому.

Все так! Хороший комментарий

Чого тільку не буває, хтось міг дістатись у спадок, когось перевели до команди та погано співбесідували на вході. Наше завдання виправити помилки та виховати грамотних інженерів

Отлично! спасибо!

Абсолютно верно. Я об этом указала в статье и причины такого решения :)

Спасибо большое, рад что статья нашла отклик.
По вопросам:
1) Первое — attrition и tenure два разных показателя:
Overall это выглядит примерно так:
Attrition = dismissed / average headcount
Tenure = average working period before dismissing

Не смотря на то, что оба показателя касаются увольнений, говорят они совершенно о разном. Attrition дает понять насколько компания способна к росту с текущим уровнем увольнений. Можно много нанимать, когда в компании много увольнений, при этом Attrition держать на относительно низком уровне. Но большой найм никак не отменяет увольнения.

Tenure в свою очередь говорит о среднем стаже работы в компании тех людей, кто уже уволился. Если все компании его считают одним способом, то большой Tenure может говорить как о низком количестве увольнений в компании, так и о том что из компании уходят преимущественно «старички».

Из тех чисел, которыми я могу поделиться касательно DataArt, то у нас например больше трети коллег с нами 3 и больше лет (при том, что компания выросла за год практически в два раза), и больше половины из этих ребят сеньеры или выше.

2) По моим личным наблюдениям, чем выше у человека квалификация, тем реже причина ухода именно ЗП.

3) Стоимость найма и привлечения нового сотрудника я раскрыть не могу, это внутренняя информация.

Сори за долгий срок ответа, но война в стране не способствовала возможности посещать DOU чаще

Чуть другой вариант анкетирования даем и в таком случае, я себе добавляю цель объяснить коллеге причины почему именно было принято такое решение. Поднятый вами поинт крайне важен на самом деле, потому что, если коллега не понимает причин окончания сотрудничества с ним это может привести к странным трактовкам в дальнейшем. У DataArt в этом плане хорошая позиция, так как мы всегда даем второй, а иногда и третий шанс коллегам и всегда доносим фидбек по такой ситуации, чтобы потом не получился «сюрприз» для коллеги.

Мне очень жаль, что в нашей сфере тоже такие истории летают. Хочется верить, что хоть тут все как-то человечней, но видимо не всегда

Мне кажется вы потеряли нить разговора, я попробую помочь, поправьте пожалуйста, если я ошибаюсь. Проблем для ухода потенциального может быть миллион, компенсация лишь один из возможных вариантов. Сидеть о них помалкивать последнее дело, как по мне. Если вы считаете, что это правильно — ваш выбор. Если вам безразличны коллеги, с которыми вы работали в проекте, офисе и компании — ваш выбор. Если вы считаете, что высказать свое мнение по неустраивающим вас проблемам — это «прощальны подарок», который вы делать не хотите — ваш выбор :) Я же только благодарен, что со мною работают коллеги, которые рады поделиться своими мыслями, которые рады указать на узкие места и которые даже после ухода с компании со мной и другими коллегами в отличных отношениях. Каждый дает миру и получает обратно по вложенным усилиям. Кто-то «ушат правды» на спецресурах, кто-то взаимопомощь и взаимовыручку.

Спасибо за мнение. Мне кажется это инструмент, который в любом случае при правильном использовании и подходе принесет пользу и не будет «лишь формальностью». Вопрос обработки результатов — подходов к обработке полученных данных в ходе любого сбора информации существует масса, тут советов не даю, так как это уже совсем другая история. Но, кстати, про необходимость обрабатывать эти результаты я в любом случае упомянул :)

Ни в жизнь. Встречи с коллегами, постоянные HR-синки с моим личным присутствием и 1-2-1 c коллегами вне моего офиса, но с моего проекта — моя прямя обязанность. Эти встречи и Exit review это не замена друг другу и разные вещи