И так, отвечая на извечный вопрос о том, что нужно знать junior QA engineer.
Первое, о чем стоит оговориться, что на этот вопрос нет правильного ответа примерно по двум причинам:
1 - Понятие Junior и его компетенций меняется от команды к команде и от проекта к проекту.
2 - Набор musthave вещей тоже сильно зависит от проекта, команды, стиля работы и других важных факторов.
Так что всё нижеописанное будет основано исключительно на моем мнении и опыте.

1) Нужно понимать теорию тестирования: что есть дефект, приоритеты(классический вопрос про priority & severity), базовые практики тест-дизайна, понимание того как и зачем писать тесткейсы, понимание того, как локализовать ошибку.

2) Нужно иметь общее представление о предметной области:
Если тестируете веб - общее представление о клиент-серверной архитектуре, всякие пост-гет запросы, и прочеее прочее. + REST и API
Если тестируете мобилы - подробнее почитать про специфику тестирования мобил и чем это отличается от веба, почитать Apple и\или Android гайдлайны по приложениям, почитать про типовые проблемы работы приложений.
ну и т.д. с декстопами, железом, смарт-картами и прочим добром.

3) Базы данных. Иметь общее представление о реляционных и не-реляционных базах данных, уметь написать селектики на SQL, дальше уже плясать от конкретного стека технологий.

В целом все это отлично рассказывается в рамках тематических материалов по тестированию.
Форумы, доклады, видеоуроки и в последнюю, пожалуй, очередь, книги.
Толковых книг по тестированию предельно мало и их довольно сложно найти.


Это касается в основном tech skills, хотя главными для Junior QA являются совсем не они.
Гораздо важнее хорошо работающая голова, понимание что задача тестирования - не найти максимум багов, а проверить, что пользователь приложения получит то, что ожидает получить.
То же самое касается способности и желания учиться, самостоятельно разбираться, гуглить и получать и обрабатывать массу входящей информации.
Это реалии с которыми вам придется жить, без этого никуда. :)

#собеседования #графомания

По поводу тестовых заданий и вопросов на собеседованиях:

В тестировании, как и во всей отрасли, зародилось безумное количество странных обычаев на собеседованиях.
Часто встречающиеся кейсы это:
1) Куча бездумных вопросов по терминологии тестирования и computer science (напр. назовите, пожалуйтса, нам все виды тестирования, которые вы знаете).
2) Куча странных абстрактных задач на "логику" и "сообразительность". Почему канализационные люки круглые, вопросы про количество взвешиваний и монетки, прочие вещи.
3) Абстрактные задачи про тестировании на примере "Протестируйте карандаш".

Первая группа направлена на то, что бы проверить "теоретический базис" кандидата и понять, что он знает, какие книжки читал и т.д.
Это не слишком хорошо работающая история, т.к. единого подхода к терминологии нет.
Более того, знание терминологии совсем не говорит о её понимании, способах и особенностях применения тех или иных подходов и пр.

Вторая группа, теоретически, направлена на то, что бы выявить сообразительных кандидатов. Куда же QA инженер без логического мышления и всё такое.
Подход, в целом, почти работающий, но не имеет ничего общего с реальностью и в большинстве случаев упирается в то, что человек читал\не читал перед собеседованием (этим или одним из предыдущих) способ решения этих задач.
Самый близкий пример из области Computer Science - написание алгоритма сортировки от руки по памяти.
Если человек помнит, как этот алгоритм пишется - это, конечно, здорово. Но с его реальными задачами и знаниями это почти никак не коррелирует.
Зато есть масса тех, кто учит эти алгоритмы наизусть, совершенно не понимая принципов работы и применения оных, просто ради собеседований.

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


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

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

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

BDD-инструменты в тестировании: Pros and cons
#графомания #инструменты

Не так давно пришлось довольно активно форвардить моё мнение на тему внедрения BDD-инструментов на проектах, поэтому решил немного структурировать и закинуть это полотно текста сюда.

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

Если вы задались вопросом, стоит ли вам в своих тестах использовать BDD-инструменты, то прежде всего стоит попытаться ответить себе на извечный вопрос "Зачем?", т.е. какую проблему внедрение этого инструмента должно решить.
"Я слышал это крутая штука" и "Хочется попробовать" - тоже отличный довод, конечно, но не стоит опираться на него как на основной аргумент при принятии архитектурных решений.
Как только вы поймете, зачем оно вам надо, следует взвесить все "за" и "против", сопряженные с внедрением дополнительной технологии.
Ниже я постараюсь выделить наиболее ключевые, на мой взгляд, факторы.

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

- Да, ваши тесты действительно будут написаны на довольно корявом, но всё таки псевдонатуральном языке (напр. Gherkin в контексте Cucumber) и теоретически любой заглянувший в этот текст сможет понять, о чем вообще идет речь.
Тут, правда, надо собраться с силами и честно ответить себе: часто ли не-технические специалисты заглядывают вам в автотесты (или, например, тестовую документацию) и насколько им это вообще нужно? Я бы сказал, что в большинстве случаев из моей практики в автотесты никогда не будет смотреть кто-либо не способный прочитать и примерно понять код этих автотестов.

- Вся техническая реализация и логика действий пользователя будет скрыта под оберткой из Test Steps написанных на Gherkin, и из этих Test Steps уже будут собираться тесты.
Соответственно любое изменение логики тестов потребует сначала изменения кода, а затем уже BDD-сценариев.
Любое добавление новых сценариев потребует написания сначала кода, а затем уже BDD-сценариев.
Как результат - количество работы с кодом в рамках автоматизации на самом деле не уменьшается.
Единственное исключение - когда у вас уже написано большое количество базовых Test Steps (по сути тестовый фреймворк, имплементирующий все возможные действия пользователя) - из этих Test Steps можно будет собирать Test Scenario почти не залезая в код.

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

2. Тестовые сценарии будут выглядеть консистентно, независимо от того, что в них тестируется
Это, на мой скромный взгляд, один из наиболее существенных плюсов BDD-инструментов, который и сподвиг лично меня использовать Cucumber на одном из проектов.
Ваши тестовые сценарии - это всегда BDD-сценарии, описанные одинаково. С точки зрения читаемости тестов совершенно не имеет значения, что происходит под капотом: тестируется поведение в браузере, API, вызываются миграции, генерируется Brainfuck код - это все будет выглядить как последовательность Given X, When Y, Then Z.

3. BDD-фреймворки навязывают определенную структуру проекта, тестов и разделения логики действий с логикой теста.
Разделение тестов на Feature, Scenario и Test Values, да и в целом структура Cucumber проектов, дает хороший пинок в сторону того, что бы правильно разделять логику тестов.
Имплементация действий пользователя лежит в Steps, логика тестов лежит в Features, все вспомогательные ручки лежат в Hooks и Support.
Это помогает избежать типичного бардака с перегруженными логикой тестами, монструозными методами, файлами на 30000 строк и прочим.
Отдельный приятный плюс - вполне себе удобная запускалка + репорты из коробки, которые предлагает Cucumber. Вполне достаточно для старта, что бы не приходилось подключать сторонние инструменты.

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


Минусы:
Тут, на самом деле, всё достаточно прозаично и очевидно.
1. Использование BDD-инструментов увеличивает затраты времени на написание автотестов.
Чем больше и сложнее (с логической точки зрения) проект, тем больше сценариев и шагов для них придется писать, тем большее количество кода придется в них оборачивать.
Надо понимать, что это ещё одно место в вашем проекте, которое неободимо поддерживать, причесывать и рефакторить. Более того, чем больше сценариев - тем сложнее сохранять DRY в Test Steps и делать их пригодными для переиспользования.
По моему опыту, иногда больше времени тратится на организацию именно BDD шагов и сценариев, чем на написание кода.

Я бы сказал, что если вы уже знакомы с инструментом, то его использование даст +20% к времени на написание тестов. Если вы параллельно с ним знакомитесь - то можно смело умножать время на 2, т.к. придется разбираться, дебажить, рефакторить, разбираться дальше и пр.

2. Это дополнительная зависимость в вашем коде, которая может служить органичением и\или точкой отказа тестов.
Если вы в проекте какой-то инструмент, то все его ограничения, особенности и баги - становятся вашими ограничениями и проблемами. Это отдельная точка дебаггинга (код выполняется корректно, но при выполнении BDD сценария дает false positive\false negative). Это дополнительная внешняя зависимость, с которой придется считаться и для которой придется городить костыли: если вас, например, не устраивает логика работы встроенного Background - готовьтесь плясать с бубном, делать миллион кастомных Hooks и отлаживать как это будет работать.
Иногда самым безболезненным и быстрым решением становится форкнуть и "допилить" под себя, но думаю мне не стоит объяснять в какой геморрой это выливается в долгосрочной перспективе.
Это и дополнительная зависимость окружения, которая может уронить ваши тесты: у меня на проекте у Cucumber и Unirest был конфликт зависимостей между друг другом, причем возникающий довольно рандомно. Пришлось потратить изрядно времени, что бы найти workaround для запуска.

3. Это дополнительный инструмент в стэке технологий с которыми придется работать
Это, очевидно, усложняет и вхождение в проект новичков, и поиск новых людей в команду.
Проблема не такая уж и серьезная, на первый взгляд, но по факту +1 инструмент в и так немаленьком стеке QA - это довольно серьезная нагрузка для человека, который выходит на проект.


Подводя итог: Я бы ещё раз упомянул, что да, очевидно BDD-инструменты дают свои преимущества.
Стоит ли игра свечь - очень контекстозависимый вопрос, на который нет единого ответа для всех команд и инструментов.
Мне кажется, что в большинстве случаев использование BDD-инструмента становится эффектным, но вредоносным оверхэдом. Технологией ради технологии.
Это не мешает многием ребятам автоматизировать с использованием Cucumber (и других аналогичных инструментов) и делать это хорошо, но потратив те же силы и время на структуру, корректность и чистоту кода они, возможно, добились бы ещё больших успехов.

Про влияние HIPPO на процесс разработки.
Мне кажется, что любой тестировщик в своей работе сталкивался с тем, что кто-нибудь из топ менеджеров нашел в продукте баг, и вот уже вся команда бросила свои плановые задачи и усиленно дебажит, чинит и выкатывает обновление.
Для ситуаций, когда решения о способе реализации, критичности задач или других факторов разработки принимаются не на основе объективных критериев, а на основе мнения конкретного, обычно находящегося высоко в иерархии компании, человека был выведен отдельный термин - HIPPO.
HIPPO - акроним, расшифровывающийся как Highest Paid Person's Opinion.
Термин этот касается не только, и не столько, процесса разработки, а вообще принятия решений внутри компании, но и в разработке имеет своё яркое отражение.
Мне хотелось бы поговорить о том, как HIPPO-эффект влияет на процесс разработки, стоит ли с ним бороться и если да, то как.
Ниже я буду использовать термин HIPPO в двух значениях: как мнение, но чаще как носителя этого мнения (хотя правильнее было бы сократить до HIPP)

Несколько коротких тезисов, которые хочется выделить:
1. HIPPO определенно имеет значение.
Как правило человек на такой должности знает продукт, customer needs или предметную область лучше, чем среднестатистический сотрудник компании.
Поэтому если мы говорим не о ситуации "мнение vs аргументы", а о "мнение vs мнение" - стоит прислушаться к HIPPO.

2. Принимать решения стоит на основе цифр и аргументов, а не на основе мнений. Всегда, когда это имеет смысл.

3. Если вы можете сделать as HIPPO-says и это не повредит продукту - сделайте так, но попытайтесь понять почему именно так.

Почему HIPPO-эффект это плохо:

1. Принимая HIPPO как правильное by default вы можете переключаться на менее приоритетные задачи.
Вместо того, что бы деливерить полезную нагрузку продукта для всех пользователей, вы катите хотфикс для непонятного числа пользователей только потому, что один из них - C-Suite officer.

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

3. Приоритет HIPPO перед аргументами убивает инициативу.
Просто потому, что когда твоё обдуманное и взвешенное решение задвигают по причине "Так сказал босс" - в следующий раз ты и не захочешь ничего предлагать.

4. Это сдвигает фокус разработки с "сделать продукт хорошим" в сторону "удовлетворить хотелки топ-менеджмента".

Почему HIPPO важен и его стоит слышать:
1. Как я уже писал выше: в большинстве случаев человек, обладающий HIPPO не просто так занимает свою должность.
У него может быть больше технической или бизнес экспертизы, опыта или понимания пользователей и потребностей бизнеса.
У него, банально, больше информации, чем у среднестатистического члена команды.

2. Принятие решений на основе недостаточной информации - одна из обязанностей носителя HIPPO.
В конце концов, итоговую ответственность за продукт будет, как правило, нести именно он.
Тут весьма уместна одна из цитат, которая звучала в обсуждении HIPPO с коллегами:
> Если у вас есть аргументы - давайте, если аргументов нет - опираемся на мнение. Моё.

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

4. Несмотря на то, что это HIPPO - это все ещё мнение одного из ваших коллег.
Его важно слышать, слушать и уважать.
Если ваш CTO просит добавить ссылку на его Github в футер вашего проекта - просто сделайте это. Это избавит вас от лишних конфликтов, а пользователям не принесет никакого вреда.

Что можно противопоставить HIPPO и как сдвигать вектор принятия решений в сторону объективных метрик, вместо субъективного мнения?

Тут, как и всегда, нет silver bullet.  Всё зависит от конкретных ситуаций и людей.
Но несколько советов всё таки есть:
1. Собирайте и работайте с объективными данными:
Метрики, статистика, конкретные аргументы в пользу вашего решения - это то, что может переубедить человека.
Противопоставлять своё субъективное мнение HIPPO - бессмысленно и контрпродуктивно.

2. Не стоит слепо соглашаться или отказываться от решений HIPPO.
Постарайтесь выяснить, почему мнение именно такого, что за ним кроется и как вы можете его изменить.
Диалоги с людьми, при всей их отвратительной сложности, творят чудеса.

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

4. И ещё один пункт про диалоги: Общайтесь с носителями HIPPO.
Объясняйте, почему слепое следование их мнению вредно для команды.
Предлагайте варианты решения этой проблемы.
Старайтесь найти компромисс.

5. Придерживайтесь здравого смысла.
Не стоит вступать в конфликт только ради того, что бы оспорить HIPPO.


На этом, наверное, всё.
Ну, и по заветам многих крутых ребят:
Старайтесь делать так, что бы любая фича, которую вы добавляете была прозрачна и измеряема.
Сколько пользователей, как они ей пользуются, где возникают проблемы. Всё, что вы можете собрать о работе продукта должно собираться.
Это сложно, долго и дорого, но это позволяет вам понимать, как пользуются вашим продуктом.
Познав это можно не только побороть HIPPO, но и сделать классный продукт.

Не совсем про тестирование и QA, но поскольку это почти про то, чем я сейчас занимаюсь, поделюсь:
https://m.habr.com/post/435816/
Интересный пост (с еще более интересными ссылочками на nature и пр.) про то, что часто просто технологического решения недостаточно.
В некоторых областях применения нельзя просто сказать "Ну, вот здесь немного нейросетевой магии и вот результат".
Тебе нужно сделать процесс принятия решения прозрачным, понятным и предсказуемым. Для регуляторов, клиентов, стейкхолдеров.
А в некоторых случаях эта задача куда сложнее и объемнее, чем сам decision making.
Более того, чем больше будет объем анализируемой информации, а дерево принятия решений - объемнее, тем сложнее будет это объяснить примитивному человеческому разуму.

Простите, друзья, но не могу с вами не поделиться.
Я, безусловно, очень ценю и радуюсь тому факту, что некоторые люди из этого канала и за его пределами периодически пишут мне с вопросами про тестирование и всякое вокруг него.
Это прекрасно и я всегда стараюсь по мере сил и времени ответить (или найти ответы) на вопросы, которые в меня прилетают.
Теперь коротко о том, как не надо это делать.
Я всегда рад обсудить, побеседовать, поделиться своим мнением и видением с людьми, которым по какой-то парадоксальной причине это интересно.
Но, простите, дорогие друзья, думать за вас, делать тестовые за вас и проходить собеседования за вас я не готов и не хочу.

Так что всем, кто хочет побеседовать - велкам в личку @azshoo, возможно в какой-нибудь из этих бесед родятся идеи и мысли о том, что тут ещё можно написать.
Всем, кто хочет, что б за них подумали и написали - гореть в аду и страдать самим.

Stay tuned.

Делегировать сложно.

Когда долгое время работаешь в маленьких командах, в бесконечном режиме аврала и ритме "Всё горит. И ты горишь. И ты в аду." - очень быстро привыкаешь, что things need to be done и, как правило, если не сделаешь ты, то никто не сделает.
Это порождает очень порочную привычку подминать под себя задачи, вместо того, что бы передать их кому-то ещё.
Результат этой практики вполне ожидаемый - ты становишься боттлнеком. Времени, нервов и сил не хватает на всё и это возвращает тебя в уже привычный филиал ада, но в ущерб деливерингу задач.
Осознавать границы своих возможностей и ресурсов - особый дзен для любого человека, который может (или вынужден) сам придумывать и ставить задачи.
Это и про готовность назвать реальные сроки, вместо удобных, и про то, что бы сказать "мы не можем сделать это своими ресурсами, нужны ещё люди" и про то, что бы отказаться от иллюзии контроля и отдать задачу кому-то ещё.
Возможно, он будет делать её дольше, хуже или вообще не так, как сделал бы ты. Но альтернатива этому одна - ты перегружен задачами и не сделаешь вообще ничего.

Приходится бить себя по рукам, набираться соответствующей экспертизы и медленно идти к этому самому дзену.

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

Тем временем напомню, что моя личка всегда (зачем-то) открыта для вас. Бросайте своими идеями про то, что хотелось бы почитать.

Периодически приходится врываться и вести крестовый поход во славу нормального UX, Customer Care и банального здравого смысла.
К сожалению, каждый раз больно, горит и, конечно же, ни к чему не приводит.
В этот раз небольшой холивар про ТинькоффТрэвел и то, как делать не надо.
Стена текста в моём фейсбуке, кому интересно:
https://www.facebook.com/azshoo/posts/1373758819437797

Вишенкой на торте всей этой истории является то, что очень многие из людей в этом канале так или иначе пересекались с ребятами из тестирования Тинькоффа.
Красивые выступления на конференциях, сладкие речи о том, что мы совсем не обычный душный банк, а делаем крутой продукт и вот это всё.
Знаете, господа куаки, того, кто пустил эту фичу в продакшен надо бить по рукам.
Просто потому, что это пофигизм на грани профнепригодности, когда ты просто даешь посонам из твоей команды автоматически менять пользовательские данные без возможности редактировать результаты.

Пока я работаю над парочкой постов, которые у меня успели реквестировать, пришло время воспользоваться административным ресурсом.
Для одного из моих pet projectов мне нужна ваша помощь.
Подробности в ФБ:
https://www.facebook.com/azshoo/posts/1405683129578699

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

#грейды

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

Для того, что бы говорить о развитии и продвижении между грейдами нужно, для начала, всё таки установить сетку самих грейдов.

Junior. Под определение джуниора попадает человек, который обладает общими знаниями о тестировании и том, как решать наиболее типовые сценарии, но при этом требует менторинга, обучения и в некоторой степени контроля работы.
Например, джуниору может требоваться подробное описание того, что он должен проверить, возможных подводных камней и необходимого объема работы. Речь не о том, что бы посадить человека бездумно проходить написанные за него тест-кейсы, а скорее о том, чтобы направлять и вовремя останавливать человека, ревьюить его работу и объяснять, где - недостаточность покрытия тестами, а где явный оверхед.
Формально, джуниор может справляться с этим и без ментора, руководствуясь только помощью гугла и встречающимися граблями, но тогда ни эстимейты, ни качество его работы, фактически не предсказуемы.

Middle. В отличие от джуниора, миддл уже научился решать типовые задачи, встречавшиеся на его пути. За время работы он успел более-менее разобраться в используемом стеке технологий, платформе и специфике продукта, собрал какой-то опыт хождения по граблям и этого хватает для того, что бы решение типовых задач не вызывало у него проблем, относительно укладывалось в данные им эстимейты и давало ожидаемый результат.
Менторинг по прежнему полезен и нужен, но в основном активное участие более опытных коллег требуется, когда человек сталкивается с новыми областями знаний, инструментами или спецификой задач - в этих ситуациях миддлу не хватает имеющегося опыта для того, чтобы решить как, с помощью каких инструментов и в каком объеме необходимо тестирование.

Senior. Синьор обладает достаточной экспертизой, чтобы решать задачи в новой для него предметной области, с неявными требованиями и\или неявным поведением на основе опыта, который у него уже есть.
Он способен найти и провести аналогии между его задачей и уже имеющимся у него опытом, выбрать или придумать оптимальный (или наиболее подходящий на текущий момент) способ решения задачи.
Он способен оценить объем затрат, требующихся на изучение и освоение нового инструмента, изучения специфики задачи и\или других research задач, понимает в каком направлении двигаться и т.д.
Это не значит, что синьор знает всё. Это значит, что на основе уже полученного опыта синьор может предположить, какие решения могут быть у той или иной задачи, оценить плюсы и минусы того или иного решения, выбрать и применить оное.

Lead. Лид - самый сложный грейд, потому что есть несколько направлений, в которых можно и нужно лидить команды. Довольно часто их не получается совмещать у одного человека.

Первое направление - управление командой, менторинг и обучение. Это касается и распределения ресурсов, развития людей, предоставления возможности развития людям в команде и прочие вещи, близкие к управлению командой и людьми.

#грейды
Второе направление - управление технологиями и инструментами. В рамках этой компетенции лид за счет своей экспертизы может оценить, какие инструменты и практики для каких задач применимы, что лучше использовать в той или иной ситуации и в рамках той или иной команды. Это не значит, что лид принимает (или должен принимать) это решение единогласно. Это значит, что при возникновении потребности (проблемы) его экспертиза позволяет ему предложить несколько вариантов решения с плюсами и минусами, или же провести ресерч и предоставить нужную информацию команде.

Третье направление - управление качеством и его критериями, процессами тестирования и куа. Здесь - определение подходов к оценке текущего качества, выявление проблем, их причин и способов их решения (и, что важно - ответ на вопрос нужно ли их решать на текущий момент), стратегические решения о том, куда развивать процессы и подходы в тестировании, как и в каком объеме это необходимо компании.


В итоге, можно выделить несколько ключевых векторов, по которым идет развитие по мере повышение грейда:
1 - Объем экспертизы. Глубина знания предметной области, общий кругозор в вопросах технологий, инструментов (как в тестировании, так и за его пределами), проблем и рисков, сопровождающих те или иные ситуации и практики.
2 - Автономность. По мере роста экспертизы, человек становится всё более автономен в рамках своей работы. Это, как я уже говорил, не значит, что он должен делать всё сам. Это значит, что его экспертизы хватает для того, чтобы иметь возможность решить эту задачу или "продать" свое решение другим. Чем больше экспертизы, тем меньше будет затрат для такого решения.
3 - Глобальность восприятия. По мере продвижения по грейдовой структуре перед человеком встают все более глобальные задачи. Не просто двигать задачи, а решать, что является критерием завершения задачи. Не просто использовать инструмент, а решать, почему именно этот инструмент и когда его стоит использовать. Не просто обеспечивать приемлемое качество релизов, а помогать команде определить, насколько качественный продукт им нужен.
4 - Максимализм. Только джуниоры все возводят в абсолют. Чем выше грейд, тем чаще человеку приходится принимать решения о том, что в текущий момент времени "делать правильно" - деструктивная политика.
Одна из типовых задач для лида - формировать процессы тестирования и QA так, чтобы это не вредило поставкам в продакшен. Типовая задача для синьора - "сейчас сделать быстро, завести задачу на рефакторинг в беклог". Осознание ограниченности собственных ресурсов и необходимости неидеальных решений - прямое следствие расширения экспертизы и способности адекватно оценивать затраты времени и возможные риски.

#грейды
Вторая часть вопроса про грейды про то, как же между ними расти.
Тут, как и всегда, нет silver bullets и все сильно зависит от человека, но ниже моё субъективное представление, что именно должно помочь:
1. Выбирайте места работы, где у вас будет достаточно свободы и задач.
Идеально отлаженные процессы и построенные воркфлоу дают привлекательное спокойствие и комфорт, избавляя от кровавых пятничных деплоев, бесконечных хотфиксов и всяческой ругани.
Обратной стороной этого рая становится то, что у вас появляется четко ограниченный пул задач и ответственности, за который нет возможности (а что важнее - необходимости) выходить.
Это станет проблемой ровно тогда, когда вы научитесь решать задачи в отведенной для вас области и расти станет некуда.
Возможность (и необходимость) самому принимать решения, иногда в условиях лютейшего стресса и бесконечных дедлайнов, самому изучать и выбирать инструменты и подходы, самому принимать решения о готовности релиз кандидата к мастеру это опыт, который помогает сильно расти.

2. Меняйте места работы.
Это очень спорный пункт, но я придерживаюсь мнения, что смена работы дает очень хороший буст в плане навыков. Ты учишься быстрее разбираться в новых технологиях и продуктах, видишь как разные команды решают одни и те же задачи и с какими проблемами они сталкиваются. Это позволяет получить больше разного опыта, чем обычно может предложить одна компания.
Важный момент: это не значит, что стоит менять работу просто ради смены работы. Это значит, что если ты ощущаешь что научился решать задачи на текущем месте - то пора двигаться дальше.

3. Изучайте смежные области, новые платформы и технологии.
QA - очень обширная область. Хороший QA может копаться в коде, ревьюить дизайн, править документацию и требования от аналитиков или бизнеса, предлагать и внедрять свои идеи и решения в продукт, процессы и воркфлоу команды.
Эта экспертиза не берется из ниоткуда, это все требуется изучать. Читайте и смотрите новое про программирование, про дизайн, про новые продукты в рамках и за рамками вашей области знаний.
Помимо очевидной пользы для общего кругозора вы наберетесь новых идей и, возможно, поймете что ещё, помимо тестирования, вам интересно.
Пробуйте писать код. Пробуйте сделать продукты. Ходите на хакатоны и митапы. Помимо очевидного изучения нового это даст возможность посмотреть на решаемые тобой задачи с другой стороны.

4. Учитесь коммуницировать, слышать других, отстаивать и продавать свою точку зрения.
Мне потребовалось довольно много времени что бы понять, что не все проблемы нужно решать прямо сейчас. Что не все тесты должны быть зелеными. Что не всё нужно автоматизировать. Что иногда пятничный релиз без тестов - это действительно лучшее, что можно сделать.
Ещё больше времени потребовалось, чтобы перед тем, как предлагать решения для существующих костылей научиться выяснять почему именно это было сделано именно так. Спойлер: довольно редко причиной было "решили сделать хреново, потому что можем".
Работа QA превращается в бесконечное общение с того момента, когда ты выходишь за рамки тестирования релизов. Как только тебе нужно выбирать инструменты, строить практики или определять, как и когда нужно тестировать продукт - начинается необходимость продавать своё видение ситуации. Учитесь формулировать и доносить свои мысли, сомнения и идеи. Это важно.
Во многом благодаря этой необходимости вы читаете этот текст.

5. Помните про ограниченность своей экспертизы и то, что все происходит в контексте.
Важно понимать, что нет универсальных практик, процессов и решений. Если ваш опыт подсказывает вам, что стоит внедрить несколько проверенных практик и жизнь в компании наладится - попробуйте задать себе вопрос, почему их не применяют до сих пор. Возможно, что-то мешает их внедрению. Возможно, в конкретном случае они не решат тех проблем, которые решали на ваших предыдущих местах работы.
Возможно, от них отказались осознанно и на это тоже могут быть причины.

Все эти истории достаточно общие и выглядят как советы в духе "Выйди из зоны комфорта", но, к сожалению, это обратная сторона того, что они не привязаны к конкретным ситуациям.

Привет, друзья!
Раз уж вы все ещё читаете этот канал, значит что-то интересное я всё таки пишу.
Но, без вашей помощи мне бывает довольно сложно понять какие именно темы заслуживают внимания и постов.
Поэтому, если вдруг у вас есть идеи\пожелания\предложения для постов - смело пишите мне в личку.
Если у вас есть вопросы, на которые хотелось бы получить ответы - вы тоже можете смело писать, возможно некоторые из них потом оформятся в тему для поста.
В общем, в любой непонятной ситуации - пишите @azshoo.

Ну а пока я работаю над постом про то, какие из обучающих материалов я могу посоветовать.
Stay tuned.

Довольно часто прилетают вопросы про то, какие материалы для обучения тестированию я могу порекомендовать.
Какие книги читать, на какие курсы пойти, где классный ютуб-канал на котором всё просто и понятно разложено.
Мне, надо признать, чертовски тяжело ответить на этот вопрос, потому что за свои ~6 лет работы в QA мне так и не довелось прочитать ни одной книги по тестированию целиком.
К некоторым из книг я обращался, что бы лучше понять конкретную тему, к некоторым - что бы увидеть точку зрения автора на тот или иной вопрос.
Ниже будет список материалов, которые я смело могу рекомендовать. Часть из них касается непосредственно тестирования и может быть полезна новичкам желающим разобраться в азах тестирования, часть из них - больше для общего кругозора и дальнейшего, более глубокого изучения Computer Science, часть - про конкретные технологии и инструменты.
Традиционный дисклеймер: не стоит забывать, что в вопросах обучения нет silver bullets, работающих идеально для всех. Разные люди усваивают информацию по разному, для каких-то тем достаточно послушать подкаст, а в каких-то ты не разберешься пока сам не сядешь писать код. Остается только пробовать и экспериментировать.

#книги
Теоретия и базис тестирования.
Все эти книги содержат почти идентичный набор знаний и информации, однако, они написаны с фокусом на разных вещах и разными языками.
Agile Testing: A Practical Guide for Testers and Agile Teams, by Lisa Crispin
The Art of Software Testing 3rd Edition by Glenford J. Myers
A Friendly Introduction to Software Testing by Bill Laboon
A Practitioner's Guide to Software Test Design by Lee Copeland

Про всё остальное, начиная с программирования:
Серия Head First от O`Riley
Learning Python, by Mark Lutz
Python Testing with pytest: Simple, Rapid, Effective, and Scalable by Brian Okken
Experiences of Test Automation: Case Studies of Software Test Automation by Dorothy Graham, Mark Fewster
Software Architecture in Practice by Len Bass , Paul Clements
Building Microservices: Designing Fine-Grained Systems by Sam Newman
The Pragmatic Programmer: your journey to mastery by David Thomas, Andrew Hunt
The Art of Readable Code: Simple and Practical Techniques for Writing Better Code by Dustin Boswell, Trevor Foucher
Code: The Hidden Language of Computer Hardware and Software by Charles Petzold  
The Algorithm Design Manual by Steven S S. Skiena
Grokking Algorithms: An illustrated guide for programmers and other curious people by Aditya Bhargava
Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability by Steve Krug


#курсы
На практике, почти все курсы посвященные тестированию и QA очень похожи по своему наполнению и больше зависят от того, насколько вам комфортна форма подачи материала, преподаватель и уровень нагрузки.
Единственный курс по тестированию в моем личном опыте - это курсы по автоматизации на Java от Software Testing и Алексея Баранцева, в далеком 2013 году. Тогда, к сожалению, я не вынес для себя ничего полезного из этих курсов, но при этом для очень многих он был полезен и интересен.
(Оставлю здесь место для рекламы своих курсов, если они когда-нибудь появятся)
Безотносительно тестирования, я смело могу порекомендовать несколько курсов которые, на мой взгляд, пригодятся любому человеку, погружающемуся в IT:  
1) Python For Everyone, Coursera.
Отличный стартовый курс про программирование на Python от университета Митчигана. С довольно слабой нагрузкой и без хардкора, но как раз позволяющий понять, как вообще писать код и с чего начать.
2) Harvard, CS50.
Вводный курс в Computer Science от Гарварда, ставший фактически нарицательным в вопросах того, как надо обучать людей программированию. Большое количество материала, довольно хардкорная программа, потрясающие объяснения и интересные задачи. Это сложный курс, но, на мой взгляд, он того стоит.

3) Курс по Java (да и вообще вся программа) от Computer Science Center на Stepik. CSC - одни из немногих ребят, кто делает действительно крутые образовательные программы по computer science в России. Это может быть сложно и больно, но вы получите крутой опыт.


Лично для меня, максимально эффективным инструментом все ещё является гугл.
Найти статью про решение конкретной проблемы или работу с конкретным инструментом - значительно проще, чем искать подходящую книжку и нужную тебе информацию в ней.
Наглядный пример этого подхода - Medium, который полнится постами посвященными тестированию и QA, почти по любой теме.
Они, безусловно, довольно поверхностны и основаны на том опыте, который есть у автора блога, но при этом в большинстве случаев служат хорошей пищей для размышлений и позволяют получить все нужные кейворды для последующего поиска и более углубленного изучения конкретных тем.
Насколько примеров статей, которыми мне хотелось бы поделиться:
#статьи
Типы тестирования и общий обзор подходов и практик в тестировании:
https://medium.com/edureka/types-of-software-testing-d7aa29090b5b
https://medium.com/tech-tajawal/software-testing-the-road-map-5807a5590886

Основные заблуждения по поводу QA и тестирования:
https://medium.com/lyon-testing/misconceptions-about-software-testing-d4f80a9ec657

Просто подборки ссылок на блоги и платформы, где есть тексты про тестирование и QA:
https://medium.com/@sarahelson81/top-17-software-testing-blogs-for-2019-lambdatest-7c60d5bfe176
https://medium.com/qasymphony/9-great-software-testing-blogs-you-probably-dont-follow-but-should-84c0bd53ea3c

Любопытный взгляд на тестирование микросервисов:
https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16

Думаю, что это не последний пост с хэштегами по разным материалам, т.к. собрать все материалы сходу и в одном посте оказалось сложнее, чем я думал.
Stay tuned, друзья.