Если открыть вакансии QA, можно увидеть огромный разброс открытых позиций — от младшего тестировщика до ведущего, а иной раз и до главного. Часто слышу вопрос, чем должен обладать тестировщик уровня сеньор по сравнению с джуном или мидлом. Сейчас попробую на него ответить.
За 7 лет работы в роли Head of QA, я для себя сформулировал набор качеств и модель поведения, которым должен соответствовать настоящий сеньор QA. Своими наблюдениями поделился под катом.
1. Нести ответственность
Есть цель, к которой надо прийти. Например, выпуск нового микросервиса или перемещение UI-кнопки с одного места на другое. Сеньор QA возьмёт ответственность за результат, пообщается со специалистами, найдёт тех, кто поможет, по пути решит возникшие проблемы и многое другое. Словом, сделает всё для выполнения задачи. И ему не надо ничего разжёвывать.
2. Разбираться до конца
Иногда в разборе проблемы доходишь до момента, когда не хватает собственных знаний — например, непонятно, почему новый сервис не создает очередь в Kafka, или почему крашится приложение при переходе с главного экрана.
На мой взгляд, опытный сеньор не станет перекидывать ответственность на специалистов, у которых этих знаний достаточно — «пусть дальше разбираются разработчики/девопсы/продакты». А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости.
3. Выбирать подходящие инструменты
Часто звучат такие высказывания: «не буду писать на Java», «мне больше Python нравится», «я только Cypress буду использовать», «только Appium» и так далее. Сеньор изучит и применит самый эффективный инструмент для решения конкретной задачи.
У него нет универсальных «серебряных пуль», он выбирает инструменты по входным требованиям. К примеру, если нужно организовать автоматизацию тестирования, то выберет технологии и языки, которые:
подойдут для автоматизации конкретного продукта;
легко поддерживаются;
имеют рынок кандидатов;
уже используются в компании, чтобы было с кем посоветоваться;
имеют невысокий порог входа.
4. Не бояться рассказать о своей ошибке
Виноваты разработчики, окружение, звёзды или что-то ещё. Сеньор не обвинит внешние факторы и не станет скрывать, если допустил ошибку. Он расскажет о ней коллегам и вместе с ними попытается найти решение. Все ошибаются рано или поздно, но растёт тот, кто анализирует неудачи и учится.
5. Уметь находить время на самообразование
Если тестировщик говорит, что у него нет времени на развитие собственных скиллов, то проблема с объёмами тестирования, тайм-менеджментом человека или организацией рабочих процессов. В любом из случаев будет не лишним научиться переключать контекст, правильно декомпозировать задачи и процесс обучения.
6. Быть про продукт/бизнес
Мало смысла строить стену, которая не пропустит и мельчайшего бага в релиз. Куда важнее — доставлять продукт с хорошим качеством.
Сеньор понимает, что бизнесу нужно выпускать новые фичи, поэтому всегда будет искать баланс между качеством продукта и скоростью релизов. Стоит хорошо подумать, прежде чем задерживать апдейт только из-за того, что не все минорные баги исправили.
7. Понимать риски
Не стоит пытаться протестировать всё. Важно понимать, где есть риски. И оценивать задачу перед работой не только с точки зрения «как» тестировать, но и «зачем». Нужно узнавать у заказчика, что именно важно, и на основе этого планировать тестирование. А следом доносить риски и оптимизировать время.
8. Не ставить себе рамки
Только автоматизация, только ручное, только бэкенд… Бывает, что специалист по тестированию хочет заниматься только автоматизацией и не хочет проверять что-либо вручную (даже если это требуется для лучшего понимания продукта). Или не хочет даже пытаться разобраться в результатах и коде автотестов. Хороший же сеньор сделает все необходимые действия, чтобы сделать задачу лучше, качественнее и быстрее.
9. Уметь провести анализ проблемы
Два момента.
Первый — грамотно локализовать проблему, выяснить истинную причину, разобраться, предоставить всю информацию в максимально подробном виде. При этом не отходить от сути, не терять фокус и понимать, до какого уровня нужно закопаться при анализе.
Второй момент — как не допустить проблему в будущем. Если она решена, сеньор предложит варианты, чтобы её избежать в будущем, или обсудит этот вопрос с коллегами.
10. Следить за качеством на всех этапах
Сеньор не ограничивается одним лишь тестированием задачи, когда она приходит к нему от разработки. Он спрашивает в начале процесса, что именно сделал разработчик, наблюдает за проведением релиза, смотрит за связанным мониторингом и анализирует отзывы пользователей. То есть следит за качеством на всех этапах производства продукта.
Например, если на проде обнаружили критический баг, то сеньор не остановится только на том, чтобы помочь быстрее выпустить хотфикс. Он проанализирует причины произошедшего, добавит дополнительные тест-кейсы или автотесты, попросит, чтобы доделали алерты в мониторинге, или добавит шаг проверки деплоя сервиса в тестировании.
11. Знать технологии
Самый скромный вариант: сеньор в курсе технологий, которые используются в разработке, тестировании и деплое в той компании, где работает.
Лучший вариант: сеньор знает, что используется в других компаниях (какие технологии, инструменты и процессы). И активно занимается саморазвитием, интересуется новыми трендами в области IT. К слову, для QA есть множество полезных ресурсов — из старого, но до сих пор актуального, могу посоветовать блог Майкла Болтона.
Как работает настоящий Senior QA
Никто не говорит, что это должен быть человек-оркестр. Но хороший сеньор сумеет довести проект/задачу до конца, чтобы она не споткнулась (хотя бы на своем этапе работы).
Уровень сеньор означает, что ты дал специалисту цель или верхнеуровневую задачу, а он:
нашёл способ к ней приступить;
проработал риски;
пообщался со всеми, с кем нужно;
декомпозировал;
понял, где сэкономить время, согласовал это;
если есть возможность, то привлёк помощников;
озвучил сроки;
начал делать;
если возникли проблемы и блокеры, то озвучил их заинтересованным людям;
если задача большая, сообщил о промежуточных результатах;
доделал;
рассказал, что получилось;
проверил, что все работает так, как должно.
замониторил, при необходимости задокументировал;
спустя время вернулся и посмотрел, как оно работает;
если нужно, собрал метрики.
В его работе нет «расскажите, как делать», «так не получится», «это не будет работать», «надо всё рефакторить» и тому подобного. На мой взгляд, именно так и действует настоящий сеньор. Причём это не привязано к количеству нулей в з/п — уровни вознаграждения везде разные, как и названия должностей.
Вместо заключения
Развивать ответственность и быть предпринимателем в своём проекте — это взрослое мышление сильного и опытного специалиста. Опытный сеньор QA понимает и обосновывает, что нужно и не нужно тестировать в каждом конкретном случае, принимает решения, понимает риски и не боится ответственности. Как вырастить таких специалистов у себя в команде — отдельный разговор.
Комментарии (38)
vgogolin
07.12.2021 13:42+8Замечу, что на уровне Senior QA вперёд именно и выступает умение вырастить специалистов, чтобы работать не только своими руками. Держать их фокус, интеллект и интерес на должном уровне, взаимодействовать с другими командами... Словом, больше менеджмента и меньше личных усилий.
Второе, это умение документировать и переиспользовать тест-кейсы - прямой путь как к личной так и к командной эффективности. Намного легче посоветовать условный набор тесткейсов номер 42, чем компоновать их каждый раз заново. Выкинуть что-то ненужное проще, чем добавлять и не забывать нужное.
irreality Автор
07.12.2021 13:58+5Думаю, что умение вырастить специалистов и делегировать им свои обязанности — это уже про рост из сеньора в лида. Переиспользовать тест-кейсы — здорово, но лучше, если есть возможность их автоматизировать ;)
LuggerMan
07.12.2021 13:54-5Простите, конечно, но это какая-то вялая жвачка из инфоцыганства.
Должен *ню, обязан мешать разрабам, должен до всех доколупаться, всегда за, нет слов «это так не работает» — ванильные сопли эффективного менеджмента. Из статьи четко ясно одно — с вами кашу не сварить — Head of QA же не может ошибаться, профессионал сменит свой привычный инструмент на точно такой же, в менюшках которого он не разобрался, просто по слову какого-то осла.
>>На мой взгляд, опытный сеньор не станет перекидывать ответственность на специалистов, у которых этих знаний достаточно — «пусть дальше разбираются разработчики/девопсы/продакты». А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости. — Вообще пушка! Зачем передавать обратную связь — надо самому нафигачить как поймешь, лишь бы бедный разраб не прикладывал мозги и не знал, что он делает не так. Спускайся с луны!
fun.co/vacancies#jobs — давайте поговорим еще и о том, что чтобы растить каких-то специалистов — надо нанимать не only senior (учитывая вышеизложенное — адекватного технаря вы не увидите)irreality Автор
07.12.2021 15:26+6Обязан мешать разрабам, должен до всех доколупаться
QA-специалист должен помогать определять риски в выпускаемом продукте уже на начальных этапах. Здесь нет цели мешать разработчикам.
Head of QA же не может ошибаться
Может, и об этом есть отдельный пункт. Главное — уметь признавать свои ошибки и сообщать о них команде.
Профессионал сменит свой привычный инструмент на точно такой же, в менюшках которого он не разобрался
Сеньор сам понимает, когда эффективнее использовать привычный ему инструмент, а когда нужно использовать какой-то другой. И он способен это аргументировать.
А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости.
Это не про то, чтобы самому без помощи копать и никому ничего не говорить. Это про то, чтобы копать в меру своих возможностей, привлекая к проблеме знающих разработчиков и других специалистов. При этом ответственность по задаче не передавать.
LuggerMan
07.12.2021 17:16-1Вы смешиваете мух и котлеты.
Задача QA — она на другом конце конвеера — после разрабов. Начальные риски при выборе технологий ложатся на плечи разработчика, а не QA.
Если сеньор говорит мне, что будет использовать определенный инструмент и только его — я не буду с кислой рожей заявлять ему, что он тогда не сеньор. Возможно ему этого инструмента хватает, а при нехватке проторенных дорог он уверен, что выкрутится, потому что знает инструмент как свои пять пальцев. В статье же я вижу явное противоречие, когда наиболее эффективный инструмент в своих требованиях имеет низкий порог входа — это облака и луна, повторюсь. Говорить при этом о каких-то серебряных пулях не приходится — логика всего абзаца выглядит жутко вывернутой: «не буду писать на Java — сроки вальнем наглухо», «только Appium — он стабилен и я с ним знаком, будет качество».
Задача QA — найти проблему и сообщить, не надо лезть дальше и копать, какая у него может быть ответственность в домейне разработчика? Всмысле копать??? Это хлеб разработчика. Достаточно описания и способа воспроизведения — дальше ждать следующей итерации и не рвать волосы, если она ушла к коллеге. Тут же культивируется какое-то непонятное собственничество над тикетом — job security практикуем?
>> перекидывать ответственность на специалистов, у которых этих знаний достаточно
япооооонамать, серьезно? То есть если мне надо построить дом, мне не вызывать строителя, который будет отвечать за качество своей работы, а самому колхозить? Или вызывать, но отвечать самому? Класс.
Doman
07.12.2021 17:25+5Задача QA — она на другом конце конвеера — после разрабов.
Я извиняюсь, но вы точно понимаете разницу между специалистом по функциональному тестированию и специалистом по обеспечению качества? И что вообще такое - "обеспечение качества ПО"?
LuggerMan
07.12.2021 17:35-2Обеспечение качества (англ. quality assurance, QA) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания, а также — поддержание этих характеристик при хранении, транспортировании и эксплуатации продукции.
DMAIC, может хоть как с черным ящиком работать. Или тестирование уже не мероприятие по обеспечению качества?
Тестирование требований QA все равно не сделает, по факту этим занимается разработка — потому что, внимание — у них достаточно знаний и имеется возможность оценить полноту, однозначность, выполнимость.
Это все, что вызвало внутренние противоречия конкретно у Вас?
tundrawolf_kiba
07.12.2021 17:33+8Задача QA — она на другом конце конвеера — после разрабов.
Вообще-то нет. Задачи QA разбросаны по всему конвейеру — и начинаются сразу после постановки задачи — с тестирования требований к продукту.
Jeisooo
09.12.2021 12:23Я тут, давеча, с аналитиком вычленял методы из бизнес процесса и приоретезировал задачи на разработку, чтобы протестировать и задеплоить бц целиком, а не кусками.
И это было глубоко "До" разработки.
LuggerMan
09.12.2021 12:38-1Поздравляю, ты взял на себя обязанности тимлида!
бц?
ПриорИтИзировал — то бишь высказывал свое классное мнение? Сроки вырабатывал?
Ну я вобщем-то понял, какая тут выборка.Jeisooo
09.12.2021 13:21+2А ты токсичный :) Наверняка тебя ценят как сотрудника.
LuggerMan
09.12.2021 13:24Бгггг. Хавать ваниль и валить проект все могут. По существу есть возражения?
Jeisooo
09.12.2021 13:29По существу твоего ответа мне скажу, что " жестко разграничивать обязанности" - первый шаг к состоянию "перегорел на работе". Встречал много людей, которые знают как лучше и правильнее делать. Обычно они сидели в одной компании очень долго и им уже всё и все не нравились. И на командную работу они плевать хотели.
Распознавать и перемещать на другие позиции таких людей - тоже задача тимлида.LuggerMan
09.12.2021 14:13Все верно, но как всегда есть маленькое «но».
Тимлид команды в данном конкретном случае обязан присутствовать, так как именно он знает команду, ее возможности, слабости, а еще ему отвечать за результат. Размазать ответственность по тонне людей — хорошая конечно практика, прямо на полвека назад отправляет. Пока что не понял, каким боком QA мне здесь помощник, а не сбоку подсел. Очень долго — это сколько? Больше одного проекта? Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки. Я если честно так и не понял — бц? Точно ли хороший подход тестировать что-то сразу целиком, без кусков (нагрузочка)? За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоретезировал задачи»? Как я, к примеру, смогу оценить качество работы такого специалиста по качеству?
Мне кажется, или командная рабоота — это сложение лучших компетенций каждого из команды? Разделение труда и зон ответственности работает лучше, чем одноранговая сеть. То есть сегодня мы вдвоем работаем над проблемой, над которой я собаку сьел — я веду, ты помогаешь, я отвечаю за; завтра ты более компетентен в стоящей перед нами задаче, и все наоборот, но главный принцип — всегда есть точка входа для контроля команды — ответственный за задачу. Таким образом мы не «жестко разграничиваем обязанности», но всегда есть ответственный — при этом по орг. вопросам, срокам и приоритетам — это тимлид, увы. Может я ограничен, может я #ok_boomer, но QA без наличия хотя бы MVP, которое можно assure — не вписывается в такую схему. Где он, поясни, раз уж начали?Jeisooo
09.12.2021 14:56Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов".
И вот это:
" Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.LuggerMan
09.12.2021 15:28Не понял в корне.
Проясним.
За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»? Как дается обратная связь при такой задаче?
QA пишет тесты при TDD?
Как QA влияет на именно процесс при TDD?
Какие метрики есть? Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований, и QA отвечает именно за процесс такого понижения? Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста.
Пока что не продано в моей голове
Jeisooo
09.12.2021 15:48"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?"
Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6.
Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
LuggerMan
09.12.2021 15:53Ох, какое выделение.
Поехали дальше.
Процесса чего? Разработки? Проверки качества?
По последней фразе я могу только вывести, что QA — это тестер, который еще и думает как этим пользоваться — то есть просто хороший тестер.
SDET — это симбиоз разраба и тестера, причем тут QA?
По последним двум не надо ничего доказывать, я спросил пример, а не отписку — it depends немного не катит, тебе так не кажется?
Все еще очень расплывчато, ни одной метрики не названо, оценивать нечего — «сразу видно» — да японамать… Ну го хоть с одной?
Jeisooo
09.12.2021 16:56Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов
или
Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет.
Для пм - сроки тасок и бюджет в человеко\часах
Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
tommycd
07.12.2021 14:40+7Я бы добавил еще 12 пункт про софт скиллы.
Неразговорчивый разраб вполне норм история, неразговорчивый тестировщик- это проблема. Где-то про баг не сказал, риск не обозначил или просто хреново отписался в задаче и сразу косяки всплываютirreality Автор
07.12.2021 16:31+3Согласен, это один из самых важных софт-скиллов. Тестировщику, который плохо умеет выражать свои мысли и не использует коммуникацию в работе, будет трудно дорасти даже до уровня Middle.
Doman
07.12.2021 15:31+14Когда открывал статью, то думал, что очередная копирайтерская компиляция, но нет, действительно, каждый пункт по делу.
Но есть как минимум ещё один пункт, необходимый для Senior QA (да и Dev тоже), который стоит добавить в "Быть про продукт/бизнес" - это отучение от мышления "зонами ответственности". Если для джунов и мидлов полезно ставить такие рамки, чтобы человек держал фокус на своих задачах, то Senior всегда должен думать "за себя и за того парня".
Неоднократно наблюдал случаи, когда в результате ченжей, ломалась интеграция с другой командой на из стороне. А QA разводил руками и говорил "Мы им в начале спринта письмо отправили, и перед релизом ещё одно. Со своей стороны мы все сделали, и этот баг - вне моей зоны ответственности, у них свои QA есть". Формально да, а в итоге в проде половина приложения лежит в руинах, и бизнес несёт убытки. Поэтому, Senior с "зонами ответственности" в голове - не Senior.
А вообще, самая большая проблема - с поиском таких людей. Сами пол года не можем позицию закрыть.
irreality Автор
07.12.2021 16:59+5Senior всегда должен думать "за себя и за того парня"
Да, очень важный момент. Возможно я не настолько часто с таким сталкиваюсь, но когда QA смотрит за рамки своей команды и внутренних процессов, это очень хорошо помогает ему расти. Думаю, и мой собственный рост был в какой-то степени связан с улучшениями вне своей «зоны ответственности».
Diamon33
07.12.2021 21:09+3А можете пояснить момент с "этот баг - вне зоны моей ответственности"?
Со своей стороны мы все сделали, и этот баг - вне моей зоны ответственности, у них свои QA есть". Формально да, а в итоге в проде половина приложения лежит в руинах, и бизнес несёт убытки.
Какой набор действий в этом случае предполагался?
Чем занималась та команда "на той стороне"? После того, как этот Senior QA допинал бы команду "на той стороне" - он пойдет к начальству объяснять, что "команда на той стороне" делает свою работу неэффективно, и ставит по угрозу релиз, или так и будет делать за них свою работу потому, что у него нет зон ответственности?
У команд будет какой-нибудь retrospective meeting, где будет обсуждаться этот момент, или Senior QA без зон ответственности будет набирать себе чужой работы, пока не упрется в лимит времени, своих сил, или не выгорит?
Могу усложнить задачу - что если команда Senior QA и команда "на той стороне" буквально находятся в противофазе часовых поясов?
Никто не спорит с необходимостью коммуникативных навыков, желанием разобраться и довести дело до разрешения т.к. это в интересах развития проекта, но упарываться и загребать чужой жар, да еще и бесплатно с мотивацией "нет зон ответственности" - такое себе занятие.
Ber_Ber
09.12.2021 13:50+1Разве управление ченжами и рисками - не зона ответственности ПМа?
Если QA выявил проблему на определенном этапе, правильно оценил риски и соответственно известил всех об этом свою и другую команды, а в другой команде, которую QA известил, ничего не предприняли по этому поводу(нет ресурсов), то какие в принципе могут быть вопросы к QA? С другой стороны QA может подойти к своим обязанностям формально, написав письма в которых проблема описана общими фразами и в которых мало полезной информации. Но все же, как я полагаю Ваша проблема чисто организационная. Если QA должен делать то, что Вы хотите - "за себя и за того парня", то он должен выполнять функции ПМа.
yakimchuk-ry
07.12.2021 16:40+3Основа для хорошей работы – старание двигать продукт в интересах компании. Из этого вытекает всё остальное, от понимания почему минорные баги меньше чем релиз, и заканчивая выкручиванием рук участникам команды, если их действия явно вредят компании и проекту.
Поэтому просто старайтесь сделать работу хорошо, развить проект, помочь компании.yakimchuk-ry
07.12.2021 16:43+2У меня были случаи, когда люди хотели сделать хорошо, и наотрез отказывались сделать костыль, потому что "так не хорошо делать", и могли сорвать этим релиз и годовые планы нескольких компаний, не говоря про отделы маркетинга, штрафы, и прочее.
В итоге продавливали, сделали не очень красиво (технически), но релиз ушел и все довольны.
Посыл – даже хороший код может вредить если он не вовремя. Всё делается ради бизнеса.irreality Автор
08.12.2021 14:22+2Очень классно работать с людьми, которые принимают решения на основе того, как будет лучше бизнесу, и при этом учитывают специфику своей роли в процессе. Когда цели совпадают — работать интереснее.
Mike-M
10.12.2021 03:42Посыл – даже хороший код может вредить если он не вовремя. Всё делается ради бизнеса.
А должно делаться ради потребителя. И спешка тут чаще всего лишь вредит.
Palomnik
07.12.2021 18:08+3Не согласен со вторым пунктом.
Был у меня в команде как-то один парень. Он мог, найдя ошибку, потратить часа три, докопаться до конкретного места в коде и завести задачу на разработку, где нужно просто поправить это самое место. Т.е. сделать 95% все работы разработчика в данном кейсе.
В то время я не обладал такими навыками в чтении кода, поэтому просто делал примерно 80% всех остальных задач в команде. И когда натыкался на похожую ошибку, просто прикладывал шаги, скриншоты, логи, стектрейсы и т.д.
Технически он был сильнее, но выхлоп от его работы был намного ниже.
Так что у настоящего сеньора не должно быть "разбираться до конца". Он должен оценить какой выхлоп он получит от того, что будет разбираться, какие есть риски по пути, а так же не забыть оценить скорость процесса.
И он должен понимать, что практически всегда "разбираться до конца", проигрывает по эффективности "распараллелить работу, чтобы успеть проверить N задач, пока разработчик занимается выяснением корня проблемы и его фиксом, чтобы успеть сдать релиз вовремя".
stranger1101
07.12.2021 18:58Тоже были очень похожие мысли. Мне сложно говорить конкретно за QA, так как в этой области никогда работать не приходилось, но кажется что это хорошо проецируется на IT в целом.
Как мне кажется, в этом пункте очень важно понимать границы его применимости. С одной стороны, я согласен с автором статьи, что умение человека самостоятельно довести задачу до конца является очень полезным и важном для Senior специалистов.
С другой стороны, ты должен понимать когда нужно остановиться и попросить помощи у коллег, которые более компетентны в данном конкретном кейсе/технологии.
irreality Автор
07.12.2021 19:33+1Он должен оценить какой выхлоп он получит от того, что будет разбираться, какие есть риски по пути, а так же не забыть оценить скорость процесса.
Поддерживаю. Уточню: я имел в виду, что «разбираться до конца» != «разбираться до конца в одиночку». Сеньор всегда найдёт тех, кто ему поможет разобраться с проблемой.
CaptianKaramba
08.12.2021 10:24Я бы скорректировал. Разбираться до конца за разумное время. Копай, но не дальше обеда. Чем больше информации получит разработчик, тем быстрее он поймёт и починит проблему. Мои коллеги порой даже не запариваются, шлепают тикеты а-ля тут был, там нажал, вот скриншот и иногда лог, хотя нужно было выяснить это сервер или клиент, это данные пришли кривые или их обработали неправильно, может есть какие то неявные обстоятельства проблемы, а может просто на стенде что-то с базой не так. Но нет, разработчик же разберется в корне проблемы
Palomnik
08.12.2021 10:50+1Тут есть довольно много зависимостей на разные обстоятельства. Например, два месяца назад я работал в компании, где узким местом всего процесса были разработчики - их было меньше, чем нужно. Поэтому тестирование там было весьма прокачанным и тратило довольно много времени на подробную локализацию дефектов. А сейчас я перешел работать в компанию, где тестирование - узкое место, разработчиков хорошего уровня существенно больше, чем тестировщиков. Поэтому тут время на заведение дефекта минимальное, иначе страдает общий тайм-ту-маркет.
Поэтому я бы не стал однозначно в таком вопросе высказываться - слишком много вводных, и сеньор их должен адекватно учитывать
CaptianKaramba
08.12.2021 12:02+1Я к тому что "Он мог, найдя ошибку, потратить часа три, докопаться до конкретного места" +
"Технически он был сильнее, но выхлоп от его работы был намного ниже." => ваш коллега копал дальше обеда и в этом была его проблема, а не в том что он разбирался в глубь. Технически подкованный QA с нормальным тайм-менджментом экономит кучу времени всем и себе тоже) Мой же мессадж был про то, что есть обратная сторона, когда так чутка дали инфы про баг и побежали дальше. И вы абсолютно правы, все зависит от обстоятельств, но мы так уйдем в ИТ-философию )
OlegXxl
Как мне видится это все во многом справедливо не только для qa senior-ов, но и для других ветвей IT