Я говорю про автоматизацию тестирования.

Что? Да!

Пожюрила конкурс тестировщиков от платформы Codenrock, а заодно постаралась по-простому объяснить, как работают локаторы в вебе. Тема для меня не новая, но по-прежнему любимая. До сих пор горжусь тем, как придумала аналогию между веб-страницей и картой мира!

https://youtu.be/otbxFYpqzdw

Виды статического тестирования

Помню, когда впервые открыла силлабус ISTQB (вроде ещё 2011 года), я аж крякнула от досады: зачем мне знать виды-подвиды статического тестирования, я же не буду смотреть код?

Привет из будущего, Настя: будешь, причем по своей инициативе.

Оказывается, статическое тестирование (или, как его называет Г. Майерс, human testing) — это действительно интересно. Хотя бы для понимания, как много времени, свободы и возможностей нам дают IDE, тестовые фреймворки и линтеры, которых у нас хоть одним местом жуй.

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

Enjoy!

Немного о будущем

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

В общем, сегодня вечером предполагается редизайн.
Новое название, новое лого и проба нового формата постов.
Не теряйте — это всё тот же старый добрый Bugbuster's notes, только теперь, в процессе реализации моих больших и маленьких планов, более полезный: с рассуждениями, основанными на опыте, записями в формате блога и полезностями, которые, смею надеяться, пригодятся как начинающим, так и опытным специалистам.

Погнали!

Ручное тестирование по Майерсу

Да, тема меня зацепила, так что я решила подвести итог свои рассуждениям и вкратце рассказать:
1. Что мы привыкли понимать под ручным тестированием
2. Что под ним понимает Майерс
3. Почему трактовка Майерса интересна
4. Что, на мой взгляд, важнее всего в любом тестировании

Ну и, собственно, новый формат. Пока тестирую, так что на коленке и 3 минуты :)
https://youtu.be/WH3ONc9RLFg

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

Сначала я работала в компании, специализирующейся на заказной разработке ПО. Там я получила бесценный опыт работы с разными стеками, проектами разной длительности и разного масштаба, технологиями автоматизации от PHP+Codeception до Cypress, по пути потрогав Python и Java.

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

Теперь я работаю в рекламном отделе продуктовой компании, что позволяет мне удлинить ножку буквы Т в моём T-shape развитии. Я узнаю, как работают технологии, почему принимаются те или иные решения, как поддерживается большая система и многое другое. От 20 до 50% моего времени уходит на написание автотестов, что оказалось для меня оптимальным балансом.

Моя ценность сейчас — качаться как специалистка, развивать свой канал и учиться информативно преподносить знания о тестировании окружающим. Хочу делиться своим огоньком со всеми :)

Мы с Юлей Лях, крутой тестировщицей из JetBrains, чуть больше года назад организовали сообщество тестировщиц QA sisters, которое уже насчитывает пясти 700 человек.
Кроме того, я люблю и ценю деятельность Women in Tech Russia — поэтому выступаю там как делегат по Санкт-Петербургу. Изоляция 2020 вмешалась в наши планы, но мы всё равно провели много крутых мероприятий — например, зацените QA-школу, которую я организовывала и координировала.

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

Друзья! Мы активно растем и ищем тестировщика бэкенда в команду ВКонтакте :)

Я работаю тут более полугода и могу со всей уверенностью порекомендовать ВК.
Чудесные люди, которые реально поддерживают, рассказывают новое, помогают в обучении (конференции, внутренние активности, задачи, которые стимулируют рост, причем есть возможность реально выбрать, куда ты хочешь расти — я сейчас, например, много работаю с мобилками, потому что заявила, что они мне интересны).
Ну и, разумеется, достойная ЗП и соцпакет топчик — компенсация питания, ДМС со стоматологом и кучей клиник, компенсация спорта.

Мой руководитель постоянно спрашивает, всё ли у меня в порядке, просит, чтобы я говорила ему, если "кто-то обижает" :) А меня даже не обижает никто, наоборот, я каждый день думаю, чем же заслужила такое удовольствие, такой кайф от работы и команды.

И, что для меня невероятно важно, я чувствую к себе отношение по дефолту как к знающему, толковому специалисту, с первого дня. Такая вот презумпция компетентности.

Короче, откликайтесь, давайте общаться! У нас действительно офигенно!

https://vk.com/jobs?w=job144 — можете при отклике упомянуть, что вы от Насти З. :)

Women in Tech - год в России

12 декабря 2019 года прошло первое в России мероприятие Women in tech, ознаменовав открытие движения в нашей стране. Год спустя, мы рады оглянуться назад, провести ретроспективу и оценить работу, которая была сделана за этот непростой и оригинальный год.

23 декабря в 19.00 мы приглашаем вас на ламповый онлайн-митап, где мы:
1. Поговорим с участницами нашего движения, которые поделятся историями о том, как изменилась их жизнь за этот год и какую роль в этом сыграли школы и митапы Women in Tech;
2. Подведем итоги года и расскажем о планах на следующий;
3. Послушаем и зададим вопросы классным спикерам, которые выступят на актуальные сейчас темы.

Наши спикеры:
🔺 Анна Обухова поделится советами, как сохранить и приумножить энергию;
🔺 Дарья Пушкарская расскажет про софт-скиллы, необходимые программистам;
🔺 Анастасия Заречнева расскажет, как нетоксично к себе оценить свои профессиональные навыки.

Регистрация - https://women-in-tech.timepad.ru/event/1501471/

Приходите и зовите подруг и друзей!

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

https://teletype.in/@qa_nastasiya/2020bye

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

Поэтому, пожалуй, Status Verified уходит на неопределенной длительности каникулы :) Буду постить сюда какие-то анонсы и приколюхи, если будет настроение. Но предлагаю больше особо не рассчитывать на сильную загрузку канала — как можно видеть, его развитие не входит в мои планы в новом году.

Спасибо за то, что были со мной эти 2 с небольшим года! Было очень круто и приятно писать и делиться новостями, мыслями и полезностями. Меня по-прежнему можно найти здесь, в телеграм, или в QA sisters, или в других местах, — я особо не шифруюсь и буду рада поболтать, что-то подсказать или зареферить вас в Команду.

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

Обещала же, иногда будут полезности :)

Сегодня отпраздновали год Women in Tech в России, и, по ощущениям, это был самый классный мой митап этого года.

Записи уже на Youtube: https://youtube.com/playlist?list=PLX8CoEC1s3-Gr1wSd9NvYsLGQDMWaLwTV

Если бы меня попросили порекомендовать начинающему IT-специалисту одну и только одну книгу, я бы, не сомневаясь, выбрала именно эту — "Девять алгоритмов, которые изменили будущее".

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

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

Мы рады сообщить о запуске программы MENTOR IN TECH, которую мы организуем вместе с коллегами из Women in Big Data!

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

Зачем вам эта программа:
🔺Не можете решиться на важный шаг в карьере?
🔺Чувствуете, что готовы выйти на новый уровень, но что-то вас останавливает?
🔺Рядом нет профессионала, готового поделиться опытом и помочь вам вырасти?
🔺Не знаете, как двигаться к карьерным целям?

Mentor in Tech - бесплатная программа менторинга, которая поможет вам достичь новых вершин и результатов.

Вы можете выбрать себе ментора по одному из направлений:
🔺Вход в IT
🔺Технологии (data science, machine learning, Python/C++/Java programming, аналитика, QA, etc)
🔺Digital marketing
🔺Карьера и лидерство
🔺Стартапы

Это уникальная возможность бесплатно получить консультации топовых специалистов и расширить свой нетворк. Участницы отбираются на конкурсной основе.

📅Прием заявок уже начался и будет проходить до 10 февраля. О результатах отбора мы сообщим 15 февраля. Менторинг-сессии стартуют 22 февраля и длятся в течение 3х месяцев (минимум 3 сессии за весь период).

Регистрация и детали программы доступны по ссылке: http://mentorintech.tilda.ws/

Тестирование для нетестировщиков

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

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

Буду очень благодарна за репосты и расшаривание.

Менять и меняться — это нормально.

Этой весной я получила один из самых необычных, интересных и полезных опытов моей жизни — стала менторкой двух тестировщиц в рамках программы Mentor in Tech.

Сама программа прекрасна, и я рада, что смогла прикоснуться к ней: здесь и мастер-классы от замечательных специалистов IT-индустрии, и мастермайнды для участниц, и сбор фидбека, но главное — три сессии «ментор-участница», на которых мы, менторы, можем ответить на вопросы, разобрать рабочие ситуации и подсказать, в какую сторону двигаться менти, чтобы развиваться в желаемом направлении.

Что самое прекрасное, — это двусторонняя работа, и часто, размышляя над запросами моих менти, я ловила себя на том, что нахожу в своей жизни и работе отклики их ситуаций и задач.
Например, мы с одной из девушек начали взаимодействие с запроса на то, как работать со стажёрами и быть хорошим тимлидом от этапа собеседования и найма и далее, а потом переключились на техническое развитие и самообучение, потому что ситуация в жизни и работе у менти довольно сильно изменилась.

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

Мы часто боимся изменений извне: привычные процессы и обстановка помогают мозгу меньше грузиться простыми задачами и выполнять их «на автомате». Лично у меня к этому добавляется ощущение страха неизвестности: нет гарантий, что перемены принесут нечто лучшее, а здесь и сейчас есть стабильность и четкое понимание, что хорошо, а что не очень.
Тем не менее, самый существенный рост происходил в моей жизни ровно тогда, когда я больше всего боялась что-то изменить: переход в физмат-школу, поступление в другой город и переезд в третий город на ПМЖ. А как страшно было впервые подавать заявку в формочку для спикеров конференции…

Ещё бывают перемены, которые приходят изнутри. Например, ты всю жизнь думаешь, что хочешь развиваться в одном направлении, а потом пробуешь другое и совершенно безвозвратно влюбляешься. И это тоже нормально!
Мир вокруг нас стремительно меняется, мы сами узнаем новое и понимаем, что что-то больше, а что-то меньше подходит нам на данном этапе. Это не предательство своих идеалов и не метания; это тоже часть роста, которую так или иначе необходимо прожить и понять.

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

QA: shift left? Shift right?

В далёком 2018 году я писала пост со своими горькими размышлениями и важной на тот момент дилеммой: оставить тесты некрасивыми, неструктурированными, но писать их быстро одной рукой, а второй успевать тестировать новые фичи, или же писать тесты красивые, аккуратные, по канонам Page Object Model, но ничего не успевать кроме этих тестов.

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

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

17 мая стартует новый сезон Podlodka QA Crew – онлайн-конференции для QA-инженеров, которая, как мне кажется, за прошедшие 3 сезона успела завоевать столько внимания благодаря клёвым докладам и формату, заточенному под онлайн, что уже не нуждается в отдельном представлении.

Конференция пройдет в формате двухнедельного интенсива. У каждой недели своя тема, и темы этого сезона — ровно то, что я хотела бы знать тогда, в далеком 2018 году, и то, что до сих пор остаётся для меня актуальным.

На первой неделе “Shift-left: QA до этапа тестирования” будут разобраны техники, процессы и инструменты, которые еще до начала тестирования позволяют вовлечь всю команду в процесс QA и добиться максимального качества.

На второй неделе “Shift-right: QA после этапа тестирования” мы посмотрим на QA под другим углом. После выпуска релиза борьба за качество не прекращается, поэтому мы обсудим, что можно и нужно делать, чтобы выйти из нее победителями.

Помимо докладов в программе множество нескучных форматов: рулетки кейсов, батлы, лайв-кодинги и не только.

А ещё вы сразу получите бессрочный доступ к записям всех сессий, — лично я это просто обожаю, потому что, во-первых, не всегда получается успеть послушать доклад в live-режиме; во-вторых, на "Подлодке" уже не раз случалось, что я сначала увелеченно внимаю докладу в прямом эфире, а потом переслушиваю, конспектирую и повторяю. Потрясающий опыт!

Крутые спикеры, общение в слаке с другими участниками и полезные сессии – все это уже с 17 мая! Расписание уже на сайте, подключайтесь!

Оффбоардинг

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

Однако, делая шаг к чему-то новому, очень важно не забывать о том, что ты оставишь после себя там, откуда уходишь.
Многим знаком термин онбоардинг, а вот как назвать обратный процесс — оффбоардинг? Пусть будет так :)
В рамках этого текста я буду называть оффбоардингом последние 2-3 недели в компании, из которой мы уходим: с момента информирования нашего руководителя и до последнего дня.

Что я считаю для себя важным сделать, покидая компанию?

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

2. По возможности описать и сохранить инфу о фичах/проектах, с которыми работала.
Это будет полезно не только тестировщикам, но и другим членам команды. Дело в том, что аккумулирование знаний по фичам в одном человеке происходит чаще, чем нам бы того хотелось. Это нормальный процесс: невозможно быть в курсе всего, и распределение ответственности внутри продукта помогает углубиться в свои задачи, не беспокоясь за покрытие остальных функций. Тем не менее, надо отдавать себе полный отчет в том, что твои знания могут казаться супер-очевидными тебе, но их отсутствие сильно усложнит работу другому человеку.
Даже если в команде ситуация идеальная, и все знают обо всём поровну, описание фич/проектов, с которыми мы работали, упростит онбоардинг нового специалиста.

3. Если работа требовала каких-то особых знаний, либо есть неочевидные процессы, к которым, тем не менее, многие привыкли — задокументировать их.
По той же причине, что и прошлый пункт, но необходимость здесь более очевидна. Например, когда я уходила с руководящей позиции, мне было максимально важно описать процесс 1-1, собеседований и ревью — не потому, что было желание, чтобы все делали так же на 100%, а потому что это были знания, подкрепленные опытом, и я понимала, что новому сотруднику на этой позиции такие знания могут упросить интеграцию в коллектив и добавить понимания, как «было раньше».

4. Починить то, что не работает.
Например, нестабильные автотесты, неактуальные репорты или задачу, которая висит в in Progress уже 2 недели. Это довольно очевидный пункт, но я даже словами не могу описать, сколько радости приносит напоследок добить-таки проблему, которая довольно долго стреляла и расстраивала.
Да, не круто, конечно, делать такие штуки в последний момент. Но это определенно лучше, чем проявить безразличие и не делать вообще.

5. Проинформировать о том, что не удалось починить.
Например, про нестабильные автотесты :D Мне кажется, это просто хороший тон, и тут даже не стоит вдаваться в подробности.

6. Записать итоги работы.
Для себя на будущее. Провести небольшую ретроспективу. Что удалось сделать? Что хотелось, но не удалось? Что было круто? Что улучшила бы? Всё это желательно хотя бы тезисно зафиксировать.
Во-первых, это поможет в будущем: когда яркие воспоминания станут тускнеть, будет возможность вспомнить, почему ты работала в этой компании (и каковы были причины ухода), — земля круглая, а в мире IT так вообще велики шансы поработать в одном месте более раза.
Во-вторых, когда-то придется обновлять резюме, и лучше записать свои обязанности и достижения, пока они свежи в памяти.
В-третьих, анализ сделанного — неотъемлемая часть осознанного развития, поэтому он не будет лишним.

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

Спасибо, Команда 💙

Про тестовую отчетность

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

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

Как тимлидам QA-команд, так и единственным в команде/проекте QA иногда приходится работать с отчетностью — иногда это условный отчет о тестировании, иногда — результаты прогона тестов; в иных случаях могут быть и другие форматы: все зависит от внутрикомандных договоренностей. На мой взгляд, имеет смысл познакомиться с тем, как составлять отчетность, в любом случае, даже если это занятие кажется далеким от нынешних обязанностей.
В конце концов, понимание, какие артефакты показывают результаты нашей деятельности, помогает дисциплинировать себя и способствует умению наглядно продемонстрировать себе условные "до" и "после" — если не по запросу извне, то по крику самозванки внутри.

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

Как же тогда быть?
Читать, искать и разбираться. Ведь, как мы все помним, тестировние — это не про ручные и автоматизировнные сценарии; это про мышление, рассуждения и умение собрать из разных крупиц информации то, что будет работать именно для вас.

По этому поводу — небольшая подборка того, что можно почитать на тему.

🔹 https://www.instagram.com/p/COP6BSKnR0U — блог Натальи, Senior QA в DataArt. Наталья пишет о собеседованиях, карьере и тестировании в целом, — а по ссылке вы найдете пост про то, что можно включить в отчет о тестировании (даже если кажется, что вообще нечего!).

🔹 https://habr.com/ru/company/performance_lab/blog/207512 — довольно старая, но вполне годная статья про написание отчета о тестировании с очень важным вопросом: для кого мы его формируем?

🔹 https://sergeygavaga.gitbooks.io/kurs-lektsii-testirovanie-programnogo-obespecheni/content/lektsiya-5-ch4.html — лекция (в задокументированном виде) про тестовую отчетность. Мне нравится, что там есть упоминание Definition of done.

Задачу нормально поставьте.

Многие разработчики и тестировщики очень не любят работать с плохо проработанными задачами.
Неустанно повторяя древнюю мантру про "нет ТЗ - ..." они выступают на конференциях с рассказами о том,
как классно у них получилось перевоспитать аналитиков и менеджеров, что б им приносили хорошо проработанные задачи.
Или наоборот делятся болью в профессиональных чатиках мол "бардак, прилетают задачи без описания".

Меня эти дискуссии неизменно печалят.
В основном потому, что многие люди действительно считают, что вот так - это хорошо, а по другому - это плохо.
Реальность, конечно, немножко сложнее.

Тут есть несколько моментов, о которых надо помнить.

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

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

Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.

Помните, что разные подходы работают для разных команд.

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

Классический подход "вот вам супер-подробное ТЗ, превратите это в код" - обратная крайность.
Это стандартные проектные рельсы, которые легко масштабировать и можно получать прогнозируемый результат.
Минус в том, что результат - средненький, скорость - тоже.
Создать что-то действительно классное с таким подходом довольно сложно.

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

Детально проработанные задачи могут нести за собой не меньший набор проблем и ограничений, чем задачи, прилетающие без описания вообще.

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

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

Статья родилась на основе моих соображений после прочтения поста в Т—Ж о входе в IT.

https://telegra.ph/Testirovshchik-prosto-klikaet-07-22

Как ставить задачи джунам?

Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.

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

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

- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати, explain analyze до/после поможет понять детали»
- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из users в `availableUsers`» можно написать тоже самое + добавить «Кстати, про именование можешь посмотреть классный доклад или почитать мини-книжку Naming Things!».
- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться

А есть ещё мнения по этому поводу?

Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать.