Давно не дает покоя такой вот вопрос, какие достижения есть

у мидл/синьор QA? Я имею ввиду суровые квесты и строчки в резюме. Тестировал задачи, находил баги и был крутым во всех отношениях чуваком - это не то. А что-то вроде "Организовал процесс релизного тестирования" это уже из жизни лидов. Чем же мидл/синьоры могут похвастать?

Наиболее адекватное, имхо, разделение -- по уровню ответственности. Джуна без надзора оставлять нельзя, миддла можно, синиор может этот самый надзор уже сам осуществлять. Процессы так-то и миддл может организовывать. (А корректировать процессы, по необходимости, должен любой адекватный инженер, джун в т.ч.) у синиора могут быть достижения, связанные с непрямым управлением другими юнитами: планирование, менторинг, адаптация, подбор, обучение etc. Upd: и связанные со стратегическими, а не тактическими шагами: тест-план со стратегией внятный написать, выбрать и обосновать стек будущей автоматизации, фреймворк с нуля запилить под проект...

Похоже вы не поняли вопрос. Достижение в моем понимании это о том, как работа QA отразилась на бизнесе или стратегически изменила проект. Можно менторить до посинения и составить горы документации, но вы этим не убедите абстрактного менеджера, что именно ваши скиллы повлияли на результат.

Можно менторить до посинения, а можно рассказать про результат в цифрах, и попробовать перевести в деньги. Например, был бюджет на одного синиора, а взяли трёх джунов -- вот так-то и так-то отбирали, нашли за столько-то времени (цена хайринга), за столько-то человекочасов я их отменторил по таким-то и таким-то показателям, что в результате привело к тому-то и к тому-то. (Два проекта вместо одного застаффлено за три месяца вместо условных 9, которые прогнозировали ичары, сэкономлено столько-то денег, относительно изначального прогноза) Точно так же и с процессами: была ситуация А, внедрили Б, в результате добились ускорения В, сокращения Г и перешли на релизы раз в месяц, вместо раза в год. Точно так же и со всем остальным. Такие-то метрики обуздали, вот так это считали, столько-то бабла, в итоге, сэкономили. Только это уже, скорее, условно-синиорские достижения. Хотя, грейды условны и задачи/ответственность по ним может немного размываться. Не видел, однако, ни одного ещё миддла, оперирующего экономическими показателями. Но "процессы были такие-то, проблемы были вот такие, я предложил и защитил такие-то изменения -- и это сократило reopen rate с 10% до 2%, а баги с прода стали приходить в пять раз реже" -- это и миддл может. Похоже, вы неверно сформулировали изначальный вопрос и не поняли ответ ;)

А в реальной жизни результат в цифрах кто-нибудь считал? Даже в продуктовых компаниях у синьоров почти никогда нет инфы о бюджетах, а менеджмент не предоставляет сотрудникам отчёт о влиянии, выраженном в деньгах. На галерах это вообще фантастика, ну и финансовая эффективность там стоит на последнем месте

Обычно, и правда, доступа к финансовой информации у миддлов/синиоров нет. Человек сказал про бизнес, бизнес говорит и слушает на языке денег. Без доступа к финансовым показателям, считать можно в попугаях человекочасов и принятых метрик.

Так в том то и дело, что метрики это больше инструменты менеджеров. Организация тестирования, то есть управление процессом это работа лида. Я не могу представить ситуацию, когда в компании сидят идиоты, тут приходит мидл, предлагает гениальную идею, ее все радостно принимают и баги вообще исчезают как класс. В лучшем случае ему дадут пару месяцев попробовать по ренироваться на кошках для того, чтобы чсв не распухало и человек не ломал устоявшиеся роцессы. На то и мидл. А синиоры тоже могут между собой сраться. То есть я к тому, что именно мидлы и синоры ничем не управляют сами. Откуда в таких условиях будут достижения?

Синьоры вполне управляют. Синьор по скиллам - это тот же лид, но не обременённый управленческими обязанностями. Основное отличие синьора от миддла заключается в хардскиллах и более богатом опыте в целом (больше доменов, технологий, инструментов). Ну и синьор должен понимать место тестирования в SDLC лучше миддла, но на уровне лида

Тогда зайду с другой стороны. Чтобы оценить свой вклад в тестировании, нужно знать вклад тестирования в целом на продукт наравне с другими этапами жизненного цикла. А это уже синьоров не касается. Опять же, не придет же бизнес-аналитик и не вручит орден за конкретные заслуги.

Метрики, связанные непосредственно с производимой работой, инженеры обычно как бы и без менеджеров могут знать. Количество багов, пришедших с прода после релиза; тестовое покрытие; рассчётные человекочасы на регрессию etc. "Гениальные" идеи и правда трудно представить, однако небольшие изменения процессов, определение entry/exit критериев, уточнение definition of done -- всё это могут делать (и иногда делают) линейные инженеры. Отсутствие багов, понятное дело, комментировать не буду. А "в лучшем случае, иди в песочницу на полгода" -- ну, в моей практике были, по всей видимости, худшие случаи. Откуда достижения -- я, кажется, привёл несколько примеров. А вот передёргивать не надо.

Касательно "знать вклад тестирования" -- это как бы и джуну полезно. Понимать, так сказать, чем я тут вообще занимаюсь (в противовес общепринятому "мне тасочки дают, я их делаю и часы в жиру трекаю") -- нужно, имхо, любому инженеру, начиная от джуна. Но это, разумеется, не точно ;) (так не везде и не со всеми)

Вы привели примеры достижений за гранью компетенции большей части мидлов/синьоров. Ладно, допустим мне не понравились сами примеры. Вопрос пока в другом. Лид вполне может записать достижение команды по любым метрикам на свой счет, потому что он лид и это его работа. Может ли мидл/синьор себе позволить то же самое? Или у вас есть рецепт как отделить личное достижение от достижения команды?

Допустим, мне не нравится выбранный тон дискуссии -- изначально он чересчур агрессивный с переходом на личности ("похоже, вы не поняли вопрос", да-да). Ну тут вы поделились, я поделился, ок. Upd: на всякий, это я легонько намекаю, что все мы не без греха, а приведённые примеры не имели цели кому-то нравиться. Метрики, относящиеся непосредственно к работе команды/юнита обычно известны и доступны членам команды (писал выше, время на регрессию, покрытие, пасс рейт -- много их может быть). Более того, часто сами линейные сотрудники могут эти метрики считать. Что до "позволить" -- то тут либо я и правда не понимаю вопроса, либо фиг знает. В моей голове, инженер понимает, что он делает, зачем, и к какому результату это, по итогам приводит. Например, "я предложил идею перевести 30% юайных тестов на апи, заэстимейтил таску, обосновал плюсы и согласовал таску с лидами и пм, за 32 человекочаса я это сделал, ключевые метрики не пострадали, а время ночного прогона сократилось с M часов до N, что позволило нам, в итоге..." -- можно расписывать как персональное достижение, почему нет? Рецепт так-то довольно прост: чьё решение и кто его реализовывал.

Не понимаю где вы видите переходы на личности, я пытаюсь вопрос объяснить. Инженер может на 146% понимать что делает и лично он и команда. А как это влияет на итоговый результат? Он может не понимать, потому что не управляет процессами на более высоком уровне. Он может не работать с бизнесом (как продакты или аналитики). Он может банально не иметь доступ ко всем метрикам. Да и какие метрики то в его позиции очевидны? Покрытие тестами это чаще про юниты, этим разработчики занимаются. Время прогона тестов от инфраструктуры зависит. Количество багов с прода это вообще на уровне гороскопов.

Если ты лично предложил то, что стало достижением - значит личное. Если ты лично реализовал то, что предложил другой - командное. Если просто рядом с пацанами стоял, которые предлагали и реализовывали - ну, тоже принимал участие

Кажется, мы в тупике. Может понимать -- в разрезе своей работы (а как не понимать, зачем мы вообще делаем то, или иное); может не понимать -- в разрезе всей компании (доступ к финансовой информации ограничен). В позиции инженера очевидны почти все метрики из примеров выше. Далеко не все из них применимы к конкретной ситуации, конечно. Да, коэффициент оборачиваемости основных средств компании тестировщик, конечно же, не посчитает. Почти всё из моих примеров (и даже больше того) -- посчитает, т.к. доступ ко всей необходимой информации у инженера есть. Покрытие -- это не только про юниты. Имея тесты и тестовый объект, можно считать покрытие, относительно уровня тестов. Покрытие требований, а не строк кода, например. Время прогона зависит не только от инфраструктуры, но и от уровня тестов, от качества тестового кода, от инструментов, от подходов, от количества тестов в прогоне... Количество багов с прода -- это не предсказание, а ретроспектива. В десяти предыдущих релизах мы пропускали в прод, в среднем, по 10 багов высокого приоритета, после изменений мы пропускаем, в среднем, один такой баг на два релиза.

Во первых, Вот вы сами перечислили, что там может не понимать инженер. Соотвественно то, что он взял и начал в этом всем разбираться - одно из тех достижений, про которые вы хотели знать. Во вторых, покрытие есть не только юнитами. А ещё ничего не мешает инженеру работать с юнитами или следить за тем, что бы их качество и количество росло. В третьих, очевидность метрик не зависит от позиции. Она зависит от человека и того, какие метрики он хочет получать. В четвёртых, Время прогона тестов зависит не только от инфраструктуры. Более того, ничего не мешает в эту самую инфраструктуру лезть.

Ну, продакшен баг рейт в абсолютных числах, конечно, мерить нельзя. А вот в процентном соотношении от общего числа найденных - вполне себе.

Согласен. Мне показалось, в абсолютных числах нагляднее объяснить, в противовес идее вангования. @azshoo отдельное мерси за коммент, кстати: я увлёкся и переступил-таки грань допустимого упрощения.

в свои достижения можно смело записывать любую активность на благо проекта, которая выходит за рамки твоих прямых должностных обязанностей/твоего грейда. ну типа, замутил базу знаний проекта - достижение; навел порядок в бэклоге и ПМ тебя не отматерил - достижение; придумал как сократить время регресса - достижение.

Классик Канер написал не одну работу о том что метрики по большей части отстоищное отстоище отстойного отстоя. Время на регрессию зависит от качества того что сделали. Практически линейно (чем больше багов, тем больше баг-репортов, фиксов и пр.) Пасс рейт вообще ни о чём. Потому что "test cases are like briefcases" -- от того как написано пасс рейт может быть очень разным, и всего один кейз критичным до "нельзя релизить, влетим на большие деньги". Покрытие чего? Как? Ответы на этот вопрос вовсе не тривиальны -- если вы покрываете сценарий ABC , это не значит что вы покрывает BCA или СBA, и тем более ABBCBABC. И с совершенно всей проходящей автоматизацией и 100% пасс рейтом продукт может оказаться или заказчикам или пользователям в итоге не нужен, как Windows Phone или Windows store

я почти стриггерился, но потом перечитал ник. отличная попытка

я бы послушал, но прихватил бы пару тухлых помидор на всякий

у QA специфика такая. ПМ, разраб и QA - каждый должны тянуть одеяло на себя. Где-то посередине рождается хороший продукт. если QA сам говорит "и так сойдет" - значит это не QA

Вы ещё скажите, что задача QA делать продукт качественнее.

это зависит исключительно от того что вы подразумеваете под словом "качество"

1) Возможны большие проблемы. ) от вашего софта что-то большое разобьётся (спутник, самолёт и пр.) ) от вашего софта кто-то помрёт или тяжело пострадает иным образом, и иск выкатят на миллионы ) аналогично могут выкатить на миллионы если ваш софт нарушит какое-то законодательство вроде GDPR. 2) Зависит от того есть ли у вашего клиента альтернативы. ) Крупные компании могут "продавать баги" в рамках комплексных решений (как Skype for business в рамках общего пакета Майкрософта ) Но у того же Майкрософта "продавать" Windows Phone и Windows RT не получилось, и вместо того чтобы они похоронили конкурентов в мобайле (как хвалились в апреле 2010), конкуренты похоронили их. ) Оба этих случая происходят с Windows Store. Сам по себе он глючен и ненужен. Бизнес на нём не настаивает. Но он покупается как часть Винды. Но у пользователей есть возможность ставить нормальный софт и игнорировать Windows Store. ===== Однако эти два подхода ("качество переоценено") легко совместить если принять тезис Вайнберга-Баха-Болтона (и Канера в какой-то мере) что качество это не что-то однозначно определяемое, а некоторое отношение между несколькими сторонами. Да, и крэшащийся продукт может быть достаточно качественным для какой-то стороны. И убивающий в каких-то случаях продукт тоже может быть достаточно качественный для кого-то (коронавирусная вакцина или упоминаемый в литературе пример с Форд Моторз, которые посчитали что выплата по искам будет дешевле чем отзыв и исправление определённой модели).

Только вот амазон и майкрософост с эпл могут себе позволить кидать пользователей через колено, а небольшой стартап выпустивший приложение с багами, может навсегда потерять клиентов и вылететь в трубу

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

потому что стартап на ранних стадиях - не про качество, а про time to market. Там если тестирование вообще есть - уже хорошо.

"Не у нас, а у вас". Бах с Болтоном не секта, а школа, как "школа кунг-фу" из фильмов нашей молодости. Секта это когда "правильно только одно". У Баха с Болтоном в зависимости от контекста может работать одно или другое. Обязательного нет. Не нравится, считаешь что достигаешь нужных результатов своим путём — да пожалуйста. Бах с Болтоном говорят что всё надо принимать критически (в том числе и что говорят они сами), каждый сам в ответе за своё тестирование и каждый изобретает тестирование для себя, идёт своим путём тестирования. > да, риски - это важно, но риск менеджмент - это вот реальный QA (а не часть, под названием тестирование) и контроль нефакапа в области рисков можно делать > а) без тестирования > б) в рамках программирования (то есть автоматизации проверок) А я считаю что ты тут неправ. Мы можем заавтоматизировать код, но не можем заавтоматизировать реакцию человека на реальное оповещение. Ты видимо не вчитывался в историю вопроса с Боингами, потому что там бизнес так хотел впарить новый самолёт и эту систему, что пилотам просто говорили что ничего нового. А если бы проверили систему на живых пилотах и хотя бы симуляторных ситуациях — это тоже тестирование.

У майкрософта есть "крепостные" и "на оброке" пользователи, у которых мало других вариантов. Но когда у пользователя появляется свобода выбора — что майкрософту что эпплу нагнуть пользователя становится непросто, что подтверждено печальною судьбой винфона, винстора, сильверлайта, Нокии, и, конечно же, интернет эксплорера (с нетерпением жду прекращения официальной поддержки оного чтобы бурно отпраздновать). Майкрософт скайп довёл до мерзости и запустения, а когда-то ж переговорка №1 была.