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

Нельзя

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

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

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

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

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

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

Коллеги, (хоть и будущие🙈) нужна помощь.
В общем решила я сменить сферу деятельности. Посмотрев видосы на YT, очень уж заинтересовала профессией «Тестировщик»
В ближайшее время начинаю обучение.
Да-да, я читала сотни комментариев типа: «можно обучаться самостоятельно», «много инфы в гугле», «на YT все бесплатно» но, все же.. я решила обучаться на курсах.
На данный момент, я стою перед выбором этих самых курсов.
Посмотрев на длительность курсов на многих платформах, поняла, что не готова тратить ГОД,НО, при этом,учиться по 1.5-3 часа в неделю 🤦🏽‍♀️ (на данный момент я не работаю, и готова полностью отдавать своё время обучению и только)
Исходя из всех программ курсов, поняла, что на данный момент 90% учат мануал+автоматизацию и соответственно решила двигаться так же. Отсеяла большенство курсов из-за длительности (ну и цены), осталось на примете всего два.
Один из них- «Be-tester»: Aбсолютно не распиаренный, со слабым маркетингом ( по сравнению с GB, skillbox итп), и к тому же обучение не 100к как везде, а 15К😲, и учиться подозрительно мало (опять таки сравнивая с большинством) мануал-1мес и автоматизацию-1месяц. Я понимаю, что оооочень много будет на самообучении и они бегло будут рассказывать теорию, но все же, насколько вероятно что они эту инфа за месяц дают доступно? Есть ли смысл в этом курсе?
Может кто-то обучался у них или знакомые/коллеги? Есть живые отзывы? Т.к в гугле все отзывы на 5 звёзд😅
Второй- «Нетология»: длительность 8мес, стоимость 55 (а не 100😂😂) На вид у них программа как-то более обширнее (но это не точно😅) В таком случае, планирую спустя 4мес обучения ручного попробовать трудоустроиться🤞
А так же самый сложный вопрос, т.к я выбираю из двух платформ и практически не шарю, может кто-то согласился бы мне помочь с выбором? Мне нужно сравнить программы обучения т.к мне новичку трубно понять что реально нужно в курсе, а что лишнее, либо чего не хватает 🙏

В ответ на комментарий: @Rtypo68,

#comment_224031777

Я удивлен, что люди как-то находят не самый топовый пост, который был написан мной (каким-то чуваком)  91 месяц назад! Но я хочу рассказать, как моё кредо из поста, цитирую:

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

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

На тот момент на пикабу мне написал только 1 человек с предложением, я отправил ему резюме, но он после перестал выходить на связь.
В районе 2-3 месяцев я продолжал искать работу, от отчаяния я даже оставил шансы попасть в IT и прошел собеседование в КОПИЦЕНТР (печать визиток и так далее...).
В первый рабочий день я отработал ровно 1 час! Я сразу понял, что или я хороню свои желания и свои навыки и остаюсь здесь, либо оно мне вообще ни разу не уперлось и нужно идти дальше, даже если будет тяжко (нехватка денег отличный стимул!).

Поиск шел дальше. В какой-то момент мое резюме попало в компанию, которая занимается продажей и поддержкой софта для судов, морских станций и т.п. Им нужен был человек в саппорт. На самом деле компания небольшая, всего 15 человек. Основная разработка была в Европе, а тут мы просто продавали софт и занимались поддержкой его на территории СНГ.
На одном из корпоративов мне запомнились слова ген. дира: "Когда мы тебя собеседовали, я не был уверен что ты вообще что-то понимаешь, образование: колледж по специальности повар, не инженер, не моряк, вообще никак к нашему продукту и нашей специфики не относится, но я решил пойти на эксперимент под давлением главного инженера." А потом он сказанул вот как в Хоббите:

За время работы в саппорте я начал общаться с IT отделами разных нефтегазовых компаний, помогал саппортить наши сервера (2 стойки всего), ездил в командировки и прямо в море решал проблему с нашим ПО на судах... Я бы не сказал что это был "классический саппорт", мои обязанности были намного шире и сейчас я понимаю что если захотеть, то все можно выучить, даже если ты не понимаешь как делать, да просто нужно начать и там дальше потихоньку поедет или пойдет!

В один момент я понял что работа стала статичной, не было новых вызовов, да и мы не сильно растем (в плане роста компании). Параллельно я уже был на 3-м курсе заочки по специальности "Информационные системы и технологии". Согласитесь,  с дипломом повара менять что-то было бы тяжело? :)  Параллельно я начал изучать рынок IT и искать чем мне заниматься дальше. Наткнулся на профессию: "Тестировщик программного обеспечения", решил что это звучит круто и обязанности даже были схожи с некоторыми моими (я передавал репорты найденных нами дефектов разработчикам), пошел на курсы и успешно их закончил.

Далее начались поиски нового места. Предложения были, по зарплате даже не меньше чем я получал в саппорте, но в один момент когда я выходил с собеседования где-то в ебенях СПБ, мне позвонили из компании Wargaming  и предложили поучаствовать в конкурсе на стажировку.
Я заинтересовался, при чем даже стажировка оплачивалась (что-то в районе 18 т.р.), но сначала нужно было пройти этот конкурс и как бы не гарантировалось, что я туда попаду, а у меня на руках уже есть 2 предложения о работе. Взвесив все, решил рискнуть, так как геймдев компаний в СПБ не так много, а крупных и известных мировых так вообще по пальцам пересчитать можно. Это будет хороший опыт и строчка в резюме.

Конкурс прошел, стажировку завершил, в штат попал. Работал над интересным проектом (мы делали консольную версию World of Warships), тут конечно я отхватил много опыта, познакомился с прекрасными людьми, вообще все было круто! Но я немного начал выгорать по некоторым факторам, так что в какой-то момент решил, что после релиза буду искать что-то новое, тем более я дорос до уровня Middle QA.

Мне предложили оффер по знакомству, с хорошей зарплатой и вроде интересным проектом. Моя внутренняя интуиция напряглась в первый день работы, при чем ощущения были схожи с тем, что было в первый день КОПИЦЕНТРА. Я оказался не в том месте, после громадного game dev гиганта оказаться в компании, которая работает по праздникам, полностью распределенная (все на удаленке) стало ясно, что это абсолютно не мое, ну и процессы буксовали, а все прошлые QA уволились и там оставалось 2.5 человека, при чем 0.5 это я. Свалил я в тот же день, меня конечно пытались уговорить и рассказывали, что тут перспективно и так далее, но я доверял своим личным ощущениям и ушел.

Дальше были собеседования, ну и в какой-то момент я попал в ОККО (онлайн-кинотеатр). На самом деле мне было стремно переходить из game dev тестирования в тестирование мобильное.
Но, как показала практика: "тестирование, оно и в Африке тестирование", просто нужно за время испытательного срока понять специфику проекта, а подходы в сути одни и те же. В этом проекте я дорос до уровня ведущего специалиста по тестированию. А потом зеленый банк нас купил и я решил уйти, так как менеджерский буллщит вообще не для меня, мы тут пилили нашей ламповой компанией продукт и у нас были крутые условия, а потом все каскадно начало меняться и многие плюшки убрали. Поэтому в какой-то момент за 2 недели, было 15 заявлений на увольнение от тех. дира, системных архитекторов, ведущих разработчиков и тестировщиков (на самом деле, всем нам предложили хорошие условия в новом стартапе и мы свалили :)

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

P.S. Простите что получилось сумбурно, но не хочется растягивать на несколько постов.