Лига тестировщиков

Если вы читаете этот текст со своего мобильника или ноутбука, а не собираете коровью мочу где-то в Варанаси, есть очень большая вероятность того, что вы занимаетесь интеллектуальным трудом. Почему? Нет, не потому что вы все такие умные, а потому что сейчас почти все должности, занимаемые людьми – про интеллектуальный труд. Для остального есть машины и дешевый труд из стран третьего мира (об этической стороне такого распределения ништяков по планете поговорим как-нибудь потом. А сейчас давайте возрадуемся тому, что наши рабочие инструменты – это мозг, ноутбук и интернет, а не большое ведро и священная корова)

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

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

Если бы проблема освоения нового навыка упиралась бы только во время – вы все бы уже говорили на 5 иностранных, вышивали гладью и жонглировали огненными булавами. Ну а чо – взял отпуск на неделю, три учебника по английскому (элементали, пре-интермидиат и интермидиат) и словарь. Каждая книжка страниц на 300, словарь – 600. Чистого времени чтения 4 дня. Еще и бухнуть успеется.

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

Мозг имеет лимит. На запоминание, на решение задач, на придумывание чего-то нового. Но мы в упор этого не хотим замечать. Ему нужно время на восстановление, на переключение между задачами, на перенос информации из краткосрочной в долгосрочную память, на то, чтобы просто помигать нейрончиками и попытаться составить их в каком-то новом порядке, чтобы заполучить свою «Эврику!», наконец.

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

Или вот эта чудная привычка «отдыхать» в соц сетях и прочих интернетах. Ну да, перегруженному новой информацией мозгу, не успевшему ее переварить, тысячи новых фоточек, записей, видосиков и эмоционально заряженной информации — это то, что нужно!

Кстати, вы в курсе, что «подумать о неприятной задаче» и «решить неприятную задачу» стоит вашей кукушеньке примерно одинаковых затрат? Поэтому если вы в течение дня 20 раз подумали о том, что надо бы сесть за диплом, но для этого надо найти ту книгу, автора помнит Катька, номер Катьки в старом мобильнике, мобильник в общаге, общага в Купчино, Кощеева смерть в яйце… То ваш мозг, охуев от огромной логической цепочки, которую его заставили 20 раз выстроить заново, перегревается и требует мороженки, сигаретки, подрочить или любого другого несложного действия, приносящего моментальное чувство радости.

А через неделю, опухнув от мороженого и ошизев от онанизма вы будете писать в соцсеточке о том, что «ничего не успеваете, времени нет».

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

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

Ребят, у вас одна лошадь. И больше не будет никогда. И ваша «урожайность» зависит от того, насколько вы качественно о той лошади заботитесь.

Вы ее хорошо кормите? Или мы снова жрем фастфуд, а потом «сбрасываем лишнее» безуглеводными диетами?

Она у вас здорова? Или мы считаем, что панические атаки, фобии, ОКР и рыдания по ночам в подушку — это норма, так и надо и главное посильнее отхерачить себя лопатой?

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

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

Она вообще знает, где поле? Невозможно сделать то, что не знаешь, как делать. Получение первичной информации – это тоже таска, это тоже время, это тоже работа. Это тоже надо помещать в таск-листы и отводить под это время и силы.

Она у вас вообще довольна жизнью? Вы вообще понимаете, что вы делаете, зачем, и кому все это нужно?

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

Успех в вакууме – никому не нужная поебень, в чем бы она не выражалась. Никому нахрен не сдалось ваше высшее образование. Так же как ваше бабло, ваши накаченные жопы и прочие шоколадные медальки.

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

#тамара_какого_хрена

Нельзя

Не отвлекайте программиста по мелочам.

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

Не бойтесь просить о помощи.

Вы не можете знать все. Спрашивать — это нормально! Просто убедитесь, что вы поняли ответ, – не задавайте один и тот же вопрос дважды. Главный принцип командной работы при реализации проекта “Мы в одной лодке и всем будет хорошо, если у каждого будет весло.”. Он позволяет двигаться дальше в одном направлении.

Главное правило QA – никогда не верить словам разработчиков!

«Все должно быть хорошо!» или «Я изменил одну строку в коде, это ничего не сломает» – фразы, после которых стоит насторожиться и перепроверить проект.

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

Не назначайте конкретного разработчика на дефект.

В этом есть аналогия с тем как разработчик закрывает тикет без одобрения QA. Подобное поведение может разозлить

Не занимайтесь микро менеджментом над разработчиком.

«Ты посмотрел багу?», «Как насчет сейчас?», «Когда ты исправишь багу?». Это раздражает, не уменьшая сроки решения проблемы. Поставьте себя на место работника, выполняющего задачи в строгой последовательности. Подобные “пинки” нецелесообразны.

Не принимайте все близко к сердцу, с “толстой кожей” живется проще.

Чрезмерная эмоциональность (негативная) — кратчайший путь к выгоранию. Не позволяйте своим чувствам преобладать над здравым смыслом. В любой момент времени на вашем пути могут попасться высокомерные люди, которых придется терпеть, выполняя при этом поставленные цели и задачи. Правило применимо относительно любого специалиста. “Толстая кожа” столь же необходима, как и тактичность.

Правильно

Обмен знаниями с разработчиками.

Сообщите им о своих подходах к тестированию, найдите «access_key» для каждого разработчика, с которым вам приходится работать. Расскажите о том, как вы собираетесь тестировать продукт. Это поможет избежать некоторых ошибок в коде. Однако такое взаимодействие не всегда возможно по нескольким причинам:

нехватка времени;

организация процессов внутри компании, не позволяющая этого сделать;

банальное нежелание разработчика сотрудничать с тестером.

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

Будьте честны.

В противном случае это разрушит вашу репутацию.

Будьте готовы защищать дефекты, о которых сообщаете.

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

Сохраняйте хладнокровие под давлением.

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

Обсудите тестовые кейсы с разработчиком.

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

Описывайте дефекты понятно.

Говорите на языке разработчика, если можете. В ином случае, старайтесь писать как можно проще. Хорошо описанный баг со всей его информативностью и полнотой погружения в проблему со стороны разработчика будет максимально быстро исправлен. Соответственно, команда QA оперативно приступит к повторному тестированию проблемного участка.

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

Терпение, только терпение.

Научитесь справляться с трудными и самовлюбленными людьми. Это общее правило, применимое к любой сфере, как и в случае с хладнокровием.

Почему это «токсично» и как сформулировать вопрос правильно

После релиза пользователь сообщает о неприятном баге в продакшене. Звучат сигналы тревоги, жужжат уведомления и летают электронные письма. Команда бросает все и экстренно фиксит баг. Хотфикс проверен, пользователь успокоен, и все выдохнули с облегчением. Позже менеджеры встречаются с топ менеджерами на закрытых встречах, чтобы обсудить «как это могло случиться» и «почему это никогда больше не повторится».

На следующий день те же самые менеджеры, ещё не оправившиеся после вчерашнего допроса, обращаются к своим тестировщикам и спрашивают: «Почему вы не нашли этот баг?»

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

К сожалению, это некорректный вопрос. Даже с наилучшими намерениями обращенный напрямую к QA вопрос будет выглядеть как обвинение. ЕСТЬ вопрос, который следует задать. Он мало, но существенно отличается, и он адресован не QA.

Прежде чем мы перейдем к этому вопросу, давайте немного поговорим о том, почему «Почему-вы-не-нашли-эту-ошибку?» так плохо.

Во многих командах есть человек(или роль), который занимается качеством, обычно их называют QA, QE или «тестировщик». Для простоты я буду называть их всех QA. Эти люди обладают глубоким пониманием предметной области, критически мыслят, бросают вызов предположениям, наслаждаются созидательным разрушением и являются экспертами в поиске хитрых, незаметных и неочевидных ошибок, коварно всплывающих на поверхность, несмотря на все усилия команды разработки по созданию качественного программного обеспечения.

Используя это описание, легко представить QA как «сеть», которая отлавливает ошибки. Ошибки непреднамеренно создаются разработчиками, и QA — это сеть, которая существует для того, чтобы отсеивать эти ошибки, прежде чем они попадут в продакшен. Эта мысль до сих пор довольно распространена в умах многих команд и менеджеров.

Таким образом, когда баг попадает в продакшен, довольно логично обратиться к «сети», чтобы определить, как дефект прошел через нее. Очевидно, в «сети» была какая-то дыра, и нам нужно найти её и заткнуть. С другой стороны, возможно, была некоторая проблема с тестовым покрытием или применением практик QA, это необходимо выявить и исправить.

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

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

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

Отказавшись от метафоры QA-это-сеть, мы можем понять, почему прямой вопрос команде QA: «Почему вы не нашли баг?» настолько токсичен - вопрос выделяет всего одну роль, выполняющую один шаг, и накладывает на них ответственность, которую они одни не могут и не должны брать на себя. Вопрос слишком узок, он сводит сложный процесс разработки программного обеспечения к одному шагу, а затем уточняет, почему этот шаг не удался. В вопросе подразумевается «вы» как ответственная сторона за упущение дефекта: ВЫ (QA) должны были найти ошибку, но ВЫ этого не сделали.

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

Другие менеджеры это понимают, но все же задают этот вопрос. Их мало, но они существуют. Эти люди сознательно ищут козла отпущения. Им нужен кто-то, на кого они могут указать пальцем. «Эта проблема с продуктом X — не МОЯ вина, это QA ДОЛЖНЫ были найти все ошибки!». Работать на такого менеджера все равно, что парковаться под голубями — это всего лишь вопрос времени, пока ты хлебнешь горя.

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

Другие версии этого токсичного вопроса: «Готовы ли мы к продакшену?» и «Вы (QA) одобряете релиз?». Оба они являются просто упреждающими версиями оригинала, и оба предполагают, что QA может выполнять роль идеальной сети для отлова всех ошибок. По сути, оба вопроса говорят: «Обещайте мне, что ошибок не будет!», или, говоря прямо, «Давайте официально заявим, что ваша репутация, а не моя, пострадает, когда мы неизбежно найдем ошибки».

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

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

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

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

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

Таким образом, правильной постановкой вопроса становится: «Почему МЫ не нашли этот баг?» и что еще более важно, вопрос должен быть адресован всей команде. Новая формулировка вопроса и изменение аудитории позволяет тщательно изучить каждый этап и каждого человека, вовлеченного в процесс разработки. Вопрос правильно распределяет ответственность, чтобы определить изменения, которые могли бы эффективно и действенно предотвратить подобные дефекты в будущем.

Например: не слишком ли поверхносты процедуры code review? Являются ли user stories и DOR четко определенными и поддающимися проверке? Достаточно ли тестового покрытия в api тестах? Должна ли команда UX дизайнеров проверять элементы пользовательского интерфейса на ранних этапах? Достаточно ли разнообразны тестовые данные? Является ли архитектура продукта действительно декомпозируемой? Проблемы в любой из этих и тысячи других частей процесса разработки могут на самом деле быть основной причиной проблем с качеством, а не тем фактом, что QA «пропустил» дефект. Новая формулировка вопроса позволяет это понять.

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

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

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