Comments 43
Как мне видится это все во многом справедливо не только для qa senior-ов, но и для других ветвей IT
Замечу, что на уровне Senior QA вперёд именно и выступает умение вырастить специалистов, чтобы работать не только своими руками. Держать их фокус, интеллект и интерес на должном уровне, взаимодействовать с другими командами... Словом, больше менеджмента и меньше личных усилий.
Второе, это умение документировать и переиспользовать тест-кейсы - прямой путь как к личной так и к командной эффективности. Намного легче посоветовать условный набор тесткейсов номер 42, чем компоновать их каждый раз заново. Выкинуть что-то ненужное проще, чем добавлять и не забывать нужное.
Должен *ню, обязан мешать разрабам, должен до всех доколупаться, всегда за, нет слов «это так не работает» — ванильные сопли эффективного менеджмента. Из статьи четко ясно одно — с вами кашу не сварить — Head of QA же не может ошибаться, профессионал сменит свой привычный инструмент на точно такой же, в менюшках которого он не разобрался, просто по слову какого-то осла.
>>На мой взгляд, опытный сеньор не станет перекидывать ответственность на специалистов, у которых этих знаний достаточно — «пусть дальше разбираются разработчики/девопсы/продакты». А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости. — Вообще пушка! Зачем передавать обратную связь — надо самому нафигачить как поймешь, лишь бы бедный разраб не прикладывал мозги и не знал, что он делает не так. Спускайся с луны!
fun.co/vacancies#jobs — давайте поговорим еще и о том, что чтобы растить каких-то специалистов — надо нанимать не only senior (учитывая вышеизложенное — адекватного технаря вы не увидите)
Обязан мешать разрабам, должен до всех доколупаться
QA-специалист должен помогать определять риски в выпускаемом продукте уже на начальных этапах. Здесь нет цели мешать разработчикам.
Head of QA же не может ошибаться
Может, и об этом есть отдельный пункт. Главное — уметь признавать свои ошибки и сообщать о них команде.
Профессионал сменит свой привычный инструмент на точно такой же, в менюшках которого он не разобрался
Сеньор сам понимает, когда эффективнее использовать привычный ему инструмент, а когда нужно использовать какой-то другой. И он способен это аргументировать.
А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости.
Это не про то, чтобы самому без помощи копать и никому ничего не говорить. Это про то, чтобы копать в меру своих возможностей, привлекая к проблеме знающих разработчиков и других специалистов. При этом ответственность по задаче не передавать.
Задача QA — она на другом конце конвеера — после разрабов. Начальные риски при выборе технологий ложатся на плечи разработчика, а не QA.
Если сеньор говорит мне, что будет использовать определенный инструмент и только его — я не буду с кислой рожей заявлять ему, что он тогда не сеньор. Возможно ему этого инструмента хватает, а при нехватке проторенных дорог он уверен, что выкрутится, потому что знает инструмент как свои пять пальцев. В статье же я вижу явное противоречие, когда наиболее эффективный инструмент в своих требованиях имеет низкий порог входа — это облака и луна, повторюсь. Говорить при этом о каких-то серебряных пулях не приходится — логика всего абзаца выглядит жутко вывернутой: «не буду писать на Java — сроки вальнем наглухо», «только Appium — он стабилен и я с ним знаком, будет качество».
Задача QA — найти проблему и сообщить, не надо лезть дальше и копать, какая у него может быть ответственность в домейне разработчика? Всмысле копать??? Это хлеб разработчика. Достаточно описания и способа воспроизведения — дальше ждать следующей итерации и не рвать волосы, если она ушла к коллеге. Тут же культивируется какое-то непонятное собственничество над тикетом — job security практикуем?
>> перекидывать ответственность на специалистов, у которых этих знаний достаточно
япооооонамать, серьезно? То есть если мне надо построить дом, мне не вызывать строителя, который будет отвечать за качество своей работы, а самому колхозить? Или вызывать, но отвечать самому? Класс.
Задача QA — она на другом конце конвеера — после разрабов.
Я извиняюсь, но вы точно понимаете разницу между специалистом по функциональному тестированию и специалистом по обеспечению качества? И что вообще такое - "обеспечение качества ПО"?
DMAIC, может хоть как с черным ящиком работать. Или тестирование уже не мероприятие по обеспечению качества?
Тестирование требований QA все равно не сделает, по факту этим занимается разработка — потому что, внимание — у них достаточно знаний и имеется возможность оценить полноту, однозначность, выполнимость.
Это все, что вызвало внутренние противоречия конкретно у Вас?
Задача QA — она на другом конце конвеера — после разрабов.
Вообще-то нет. Задачи QA разбросаны по всему конвейеру — и начинаются сразу после постановки задачи — с тестирования требований к продукту.
Я тут, давеча, с аналитиком вычленял методы из бизнес процесса и приоретезировал задачи на разработку, чтобы протестировать и задеплоить бц целиком, а не кусками.
И это было глубоко "До" разработки.
бц?
ПриорИтИзировал — то бишь высказывал свое классное мнение? Сроки вырабатывал?
Ну я вобщем-то понял, какая тут выборка.
А ты токсичный :) Наверняка тебя ценят как сотрудника.
По существу твоего ответа мне скажу, что " жестко разграничивать обязанности" - первый шаг к состоянию "перегорел на работе". Встречал много людей, которые знают как лучше и правильнее делать. Обычно они сидели в одной компании очень долго и им уже всё и все не нравились. И на командную работу они плевать хотели.
Распознавать и перемещать на другие позиции таких людей - тоже задача тимлида.
Тимлид команды в данном конкретном случае обязан присутствовать, так как именно он знает команду, ее возможности, слабости, а еще ему отвечать за результат. Размазать ответственность по тонне людей — хорошая конечно практика, прямо на полвека назад отправляет. Пока что не понял, каким боком QA мне здесь помощник, а не сбоку подсел. Очень долго — это сколько? Больше одного проекта? Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки. Я если честно так и не понял — бц? Точно ли хороший подход тестировать что-то сразу целиком, без кусков (нагрузочка)? За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоретезировал задачи»? Как я, к примеру, смогу оценить качество работы такого специалиста по качеству?
Мне кажется, или командная рабоота — это сложение лучших компетенций каждого из команды? Разделение труда и зон ответственности работает лучше, чем одноранговая сеть. То есть сегодня мы вдвоем работаем над проблемой, над которой я собаку сьел — я веду, ты помогаешь, я отвечаю за; завтра ты более компетентен в стоящей перед нами задаче, и все наоборот, но главный принцип — всегда есть точка входа для контроля команды — ответственный за задачу. Таким образом мы не «жестко разграничиваем обязанности», но всегда есть ответственный — при этом по орг. вопросам, срокам и приоритетам — это тимлид, увы. Может я ограничен, может я #ok_boomer, но QA без наличия хотя бы MVP, которое можно assure — не вписывается в такую схему. Где он, поясни, раз уж начали?
Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов".
И вот это:
" Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?
По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.
Проясним.
За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»? Как дается обратная связь при такой задаче?
QA пишет тесты при TDD?
Как QA влияет на именно процесс при TDD?
Какие метрики есть? Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований, и QA отвечает именно за процесс такого понижения? Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста.
Пока что не продано в моей голове
"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?"
Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6.
Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
Поехали дальше.
Процесса чего? Разработки? Проверки качества?
По последней фразе я могу только вывести, что QA — это тестер, который еще и думает как этим пользоваться — то есть просто хороший тестер.
SDET — это симбиоз разраба и тестера, причем тут QA?
По последним двум не надо ничего доказывать, я спросил пример, а не отписку — it depends немного не катит, тебе так не кажется?
Все еще очень расплывчато, ни одной метрики не названо, оценивать нечего — «сразу видно» — да японамать… Ну го хоть с одной?
Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов
или
Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет.
Для пм - сроки тасок и бюджет в человеко\часах
Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
Неразговорчивый разраб вполне норм история, неразговорчивый тестировщик- это проблема. Где-то про баг не сказал, риск не обозначил или просто хреново отписался в задаче и сразу косяки всплывают
Когда открывал статью, то думал, что очередная копирайтерская компиляция, но нет, действительно, каждый пункт по делу.
Но есть как минимум ещё один пункт, необходимый для Senior QA (да и Dev тоже), который стоит добавить в "Быть про продукт/бизнес" - это отучение от мышления "зонами ответственности". Если для джунов и мидлов полезно ставить такие рамки, чтобы человек держал фокус на своих задачах, то Senior всегда должен думать "за себя и за того парня".
Неоднократно наблюдал случаи, когда в результате ченжей, ломалась интеграция с другой командой на из стороне. А QA разводил руками и говорил "Мы им в начале спринта письмо отправили, и перед релизом ещё одно. Со своей стороны мы все сделали, и этот баг - вне моей зоны ответственности, у них свои QA есть". Формально да, а в итоге в проде половина приложения лежит в руинах, и бизнес несёт убытки. Поэтому, Senior с "зонами ответственности" в голове - не Senior.
А вообще, самая большая проблема - с поиском таких людей. Сами пол года не можем позицию закрыть.
Senior всегда должен думать "за себя и за того парня"
Да, очень важный момент. Возможно я не настолько часто с таким сталкиваюсь, но когда QA смотрит за рамки своей команды и внутренних процессов, это очень хорошо помогает ему расти. Думаю, и мой собственный рост был в какой-то степени связан с улучшениями вне своей «зоны ответственности».
А можете пояснить момент с "этот баг - вне зоны моей ответственности"?
Со своей стороны мы все сделали, и этот баг - вне моей зоны ответственности, у них свои QA есть". Формально да, а в итоге в проде половина приложения лежит в руинах, и бизнес несёт убытки.
Какой набор действий в этом случае предполагался?
Чем занималась та команда "на той стороне"? После того, как этот Senior QA допинал бы команду "на той стороне" - он пойдет к начальству объяснять, что "команда на той стороне" делает свою работу неэффективно, и ставит по угрозу релиз, или так и будет делать за них свою работу потому, что у него нет зон ответственности?
У команд будет какой-нибудь retrospective meeting, где будет обсуждаться этот момент, или Senior QA без зон ответственности будет набирать себе чужой работы, пока не упрется в лимит времени, своих сил, или не выгорит?
Могу усложнить задачу - что если команда Senior QA и команда "на той стороне" буквально находятся в противофазе часовых поясов?
Никто не спорит с необходимостью коммуникативных навыков, желанием разобраться и довести дело до разрешения т.к. это в интересах развития проекта, но упарываться и загребать чужой жар, да еще и бесплатно с мотивацией "нет зон ответственности" - такое себе занятие.
Разве управление ченжами и рисками - не зона ответственности ПМа?
Если QA выявил проблему на определенном этапе, правильно оценил риски и соответственно известил всех об этом свою и другую команды, а в другой команде, которую QA известил, ничего не предприняли по этому поводу(нет ресурсов), то какие в принципе могут быть вопросы к QA? С другой стороны QA может подойти к своим обязанностям формально, написав письма в которых проблема описана общими фразами и в которых мало полезной информации. Но все же, как я полагаю Ваша проблема чисто организационная. Если QA должен делать то, что Вы хотите - "за себя и за того парня", то он должен выполнять функции ПМа.
Основа для хорошей работы – старание двигать продукт в интересах компании. Из этого вытекает всё остальное, от понимания почему минорные баги меньше чем релиз, и заканчивая выкручиванием рук участникам команды, если их действия явно вредят компании и проекту.
Поэтому просто старайтесь сделать работу хорошо, развить проект, помочь компании.
У меня были случаи, когда люди хотели сделать хорошо, и наотрез отказывались сделать костыль, потому что "так не хорошо делать", и могли сорвать этим релиз и годовые планы нескольких компаний, не говоря про отделы маркетинга, штрафы, и прочее.
В итоге продавливали, сделали не очень красиво (технически), но релиз ушел и все довольны.
Посыл – даже хороший код может вредить если он не вовремя. Всё делается ради бизнеса.
Очень классно работать с людьми, которые принимают решения на основе того, как будет лучше бизнесу, и при этом учитывают специфику своей роли в процессе. Когда цели совпадают — работать интереснее.
Посыл – даже хороший код может вредить если он не вовремя. Всё делается ради бизнеса.А должно делаться ради потребителя. И спешка тут чаще всего лишь вредит.
Не согласен со вторым пунктом.
Был у меня в команде как-то один парень. Он мог, найдя ошибку, потратить часа три, докопаться до конкретного места в коде и завести задачу на разработку, где нужно просто поправить это самое место. Т.е. сделать 95% все работы разработчика в данном кейсе.
В то время я не обладал такими навыками в чтении кода, поэтому просто делал примерно 80% всех остальных задач в команде. И когда натыкался на похожую ошибку, просто прикладывал шаги, скриншоты, логи, стектрейсы и т.д.
Технически он был сильнее, но выхлоп от его работы был намного ниже.
Так что у настоящего сеньора не должно быть "разбираться до конца". Он должен оценить какой выхлоп он получит от того, что будет разбираться, какие есть риски по пути, а так же не забыть оценить скорость процесса.
И он должен понимать, что практически всегда "разбираться до конца", проигрывает по эффективности "распараллелить работу, чтобы успеть проверить N задач, пока разработчик занимается выяснением корня проблемы и его фиксом, чтобы успеть сдать релиз вовремя".
Тоже были очень похожие мысли. Мне сложно говорить конкретно за QA, так как в этой области никогда работать не приходилось, но кажется что это хорошо проецируется на IT в целом.
Как мне кажется, в этом пункте очень важно понимать границы его применимости. С одной стороны, я согласен с автором статьи, что умение человека самостоятельно довести задачу до конца является очень полезным и важном для Senior специалистов.
С другой стороны, ты должен понимать когда нужно остановиться и попросить помощи у коллег, которые более компетентны в данном конкретном кейсе/технологии.
Он должен оценить какой выхлоп он получит от того, что будет разбираться, какие есть риски по пути, а так же не забыть оценить скорость процесса.
Поддерживаю. Уточню: я имел в виду, что «разбираться до конца» != «разбираться до конца в одиночку». Сеньор всегда найдёт тех, кто ему поможет разобраться с проблемой.
Я бы скорректировал. Разбираться до конца за разумное время. Копай, но не дальше обеда. Чем больше информации получит разработчик, тем быстрее он поймёт и починит проблему. Мои коллеги порой даже не запариваются, шлепают тикеты а-ля тут был, там нажал, вот скриншот и иногда лог, хотя нужно было выяснить это сервер или клиент, это данные пришли кривые или их обработали неправильно, может есть какие то неявные обстоятельства проблемы, а может просто на стенде что-то с базой не так. Но нет, разработчик же разберется в корне проблемы
Тут есть довольно много зависимостей на разные обстоятельства. Например, два месяца назад я работал в компании, где узким местом всего процесса были разработчики - их было меньше, чем нужно. Поэтому тестирование там было весьма прокачанным и тратило довольно много времени на подробную локализацию дефектов. А сейчас я перешел работать в компанию, где тестирование - узкое место, разработчиков хорошего уровня существенно больше, чем тестировщиков. Поэтому тут время на заведение дефекта минимальное, иначе страдает общий тайм-ту-маркет.
Поэтому я бы не стал однозначно в таком вопросе высказываться - слишком много вводных, и сеньор их должен адекватно учитывать
Я к тому что "Он мог, найдя ошибку, потратить часа три, докопаться до конкретного места" +
"Технически он был сильнее, но выхлоп от его работы был намного ниже." => ваш коллега копал дальше обеда и в этом была его проблема, а не в том что он разбирался в глубь. Технически подкованный QA с нормальным тайм-менджментом экономит кучу времени всем и себе тоже) Мой же мессадж был про то, что есть обратная сторона, когда так чутка дали инфы про баг и побежали дальше. И вы абсолютно правы, все зависит от обстоятельств, но мы так уйдем в ИТ-философию )
Во многом - соглашусь, хорошая статья, спс. Особенно п. 8 резонирует)
Хорошая статья однозначно. Когда её читаешь и все пункты подходят тебе, понимаешь, что скорее всего идёшь правильной дорогой :) Много вопросов бывает, вот а как вас делить на джнуов мидлов и сеньоров. Эту статью я бы рекомендовал всем для прочтения кто хочет знать, кто такой Senior QA.
Спасибо за статью и отдельно за комментарии ))
В целом почти со всем согласен, однако смутил общий посыл который идет через всю статью — QA должен на любом этапе стараться затыкать собой прорехи и недоработки других членов команды\компании и доводить дело до конца таким образом.
В моменте такой подход действительно уместен и оправдан. Однако хороший QA видя такое систематически должен копать глубже и "не затыкать собой дыры и брать ответственность за других", а искать изначальные причины и устранять.
Если постоянные проблемы со стороны девопсов, или продакта, или процессов надо что-то менять. На мой взгляд иметь специалиста за которым не надо переделывать априори лучше чем постоянно кузьмить какие-то лайфхаки.
Иначе говоря систематические решения, лучше чем конкретные.
Крутая подборка рекомендаций, благодарю. Тоже заметил, что люди, которые приходя в компанию, воспринимают ее как "свою" и выстраивают работу соответственно - хорошо продвигаются и по росту скиллов и по карьере :)
11 признаков Senior QA, к которым я пришёл за годы работы в тестировании