7 QA-шных грехов, которые помогут или помешают тестировщику (стать тем, кем ты хочешь)

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

image

Привет, меня зовут Иван, я работаю руководителем горизонтали автоматизаторов в Skyeng. Занимаюсь менеджментом ресурсов автоматизаторов, внедряю процессы, которые упрощают работу ребят, пишу инструменты для команды (слак-бот, всякие интеграции с TMS и др.), менторю начинающих автоматизаторов и, иногда, пишу авто-тесты.


Ручные тестировщики и начинающие автоматизаторы из компании часто спрашивают у меня, как им определиться с дальнейшим развитием. Я выделил 7 проблем, с которыми сталкивался сам, постарался рассказать, как боролся с ними и как можно обратить некоторые из своих слабых сторон на пользу себе и окружающим. Учиться на своих ошибках — хорошо, а на чужих — еще лучше. Надеюсь, мой рассказ поможет вам пойти вторым путем :)


Эгоизм


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

Я сам начинал с техподдержки. Без эгоизма в тех условиях не выжить. Каждый день на работе я задавал вопросы по личкам и получал очень информативные ответы: «погугли», «хз», «наверное», «делай как сам знаешь». Уже тогда я понимал, что что-то идёт не так. Все пеклись за себя и своё время. Помогать новым сотрудникам считалось зазорным: это была обуза, ответы давались без желания объяснить. Работал принцип Колизея: выжил — значит можешь работать дальше.


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


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


Но оказалось, что я не так понял концепт команды. Зачем обычно набирают новых людей в команду QA? Чтобы её «расшить». Следовательно, от её сплочённости зависят показатели качества всего проекта. Ты отвечаешь не только за себя: поэтому из новичка в QA не пытаются выжать всё, а стараются как можно быстрее погрузить в процессы, максимально менторить, отвечать на вопросы и помогать всеми силами.


Так случилось и со мной. Я был поражён, когда получал ответы на свои вопросы: развёрнутые, с примерами, иногда и созвонами, чтобы показать материал наглядно. И могу честно сказать: это круто — чувствовать, когда ты нужен команде.


Мораль главы: не будь эгоистом — всегда уделяй время своим коллегам. Ты человек, и они тоже люди. Всем нужно общение и помощь. Помог ты, помогут и тебе. Я всё ещё верю в карму. Быть эгоистом — это зазорно. Так что если ты собираешься в QA из «Колизея» — оставь эгоизм, всяк сюда входящий :) А теперь немного о том, как войти в QA.


Нерешительность и страх перемен


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

В 2016 году я, будучи студентом 3-го курса технического университета, решил искать работу, которая как-то связана с ИТ. Друг предложил пойти с ним в техподдержку Skyeng. Честно говоря, я не сразу согласился: мне сложно коммуницировать с людьми, обычно боюсь первым начать разговор и чувствую себя неловко при общении с незнакомыми. Но затем рискнул и прошёл собеседование.


Уже через 3-4 месяца я точно понял, что мне нужно расти над собой и пойти во что-то более айтишное. Мой друг тогда перешёл в отдел QA. Общаясь с ним, я открыл для себя совершенно новую область в разработке — тестирование ПО! С первого взгляда это было именно то, что мне нужно: я хотел набраться опыта, залезть с головой в программную часть и расти дальше — ведь учился я на разработчика.


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


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

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


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


Сотрудник техподдержки постоянно будет сотрудником техподдержки, как его не назови. Мануальный тестировщик — это только начало пути. Человек осваивается в ИТ-среде, понимает возможные точки роста: хард-скиллы ручного тестирования, автоматизация тестирования, проектный менеджмент, менеджмент QA, аналитика, разработка и многое другое. Часто бывает, что зарплата начинающего QA равна зарплате сотрудника техподдержки, но при этом ты работаешь на перспективу и повышаешь свою стоимость, получая опыт на боевых задачах и качая скиллы. «Движовое» окружение, интересные и сложные задачи, возможности роста в любую сторону — это склонило чашу весов.


Я выбрал долгую и «туманную» перспективу: сначала вкладываешься, потом пожинаешь. Но есть одно но: чтобы добиться результата, нужно постоянно самосовершенствоваться, думать головой, брать ответственность за свои действия и идти на риски, которые не всегда могут окупиться. Страшно. Но я решил, что мечты надо добиваться любыми силами, и начал готовиться к собеседованиям. Специально взял отпуск, чтобы понять и впитать всю возможную литературу и лучшие практики. Но этого оказалось недостаточно… Это интересный опыт: быть уверенным в том, что всё знаешь, но тебя никуда не берут.


«Непроактивность»


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

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


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


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


Но! Придя второй раз, я столкнулся далеко не с джуниорскими вопросами: спрашивали про пентестинг и всё такое. Кажется, со мной не захотели возиться. Но! Я написал другому тимлиду тестирования и сразу договорился о третьем собеседовании.


Мы просто по-человечески общались: я ответил на все вопросы, кроме одного, и был точно уверен, что меня возьмут! А в итоге «Прости, но взяли человека с опытом». Если до этого момента я не понимал, что такое «мораль ниже плинтуса», то вот тогда вкусил это в полной мере.


Моя проактивность резко упала. Я даже почти перегорел. Однако… Через месяц я попросил о четвёртом собеседовании. И в этот раз решил пойти на отчаянный шаг — попросился работать в QA на парт-тайме, хотя бы бесплатно. И ребята согласились. Теперь моей задачей было совмещать работу в техподдержке (8 часов в день) и параллельно работать Trainee QA на подхвате (4 часа в день). Я начал писать тест-кейсы, майндмэпы, тестировать что-то простое вроде правок в вёрстке, проходить тест-ран из 4000 кейсов. Сказать, что я был счастлив, — ничего не сказать.


Приходилось потеть по 12 часов в день 5 (а иногда и 6) дней в неделю на протяжении месяца, но это того стоило. Когда испытательный срок длиною в месяц подошёл к концу, меня взяли в QA! Я даже был удивлён, потому что успел продолбать один критикал, но ребята сказали, что я не знал продукт, и поэтому они дали мне шанс всё исправить.


QA для меня было неизведанной областью, глаз не успел замылиться — и я тут же увидел колоссальный фронт для нововведений. Естественно, процентов 90 моих предложений выкидывали в мусорку. Но хотя бы аргументированно :) Именно конструктив добавлял ещё больше сил генерировать идеи, к которым в итоге нельзя было подкопаться.


Из-за моего рвения постоянно улучшать процессы меня перевели в другой отдел, я стал тимлидом команды тестирования. Около года я «лидил» команду ручного тестирования, но параллельно сам проявил инициативу и совершенствовался в автоматизации, в чём мне очень помогал коллега Андрей AndrewQA777 Шальнев. Ну а год спустя я всё-таки решил идти в хард, поэтому перешёл на фуллтайм автоматизацию. Нетрудно догадаться, что в автоматизации мне тоже сиделось крайне неспокойно: в свободное время я начал обучать других ребят автотестам, ревьюить код коллег, советовался с разработчиками, как лучше что-то написать. В какой-то момент оказалось, что я по факту руководил уже 5 проектами в автоматизации. Я вырос из «суетолога» в лида, который может аргументированно проталкивать хорошие процессы и внедрять их. Конечно, не всё сразу получалось, т.к. в начале были проблемы с расфокусом на задачах, но я научился планировать и приоритизировать их. После этого лиды всей гильдии тестирования пришли к выводу, что пора отдать мне все проекты автоматизации, чтобы улучшения происходили повсеместно.


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


Недооценка себя


Как-то раз я чуть не ушёл из Skyeng. Я уже полгода работал лидом ручных тестировщиков, мне нравилась команда, процессы, мы буквально дружили всей командой, понимали друг друга с полуслова. Но случилась одна до ужаса банальная история…

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


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


PDP заключался в доработке фреймворка автотестов (внедрение API-тестов в код), адаптации автотестов под тестовые окружения и расширении покрытия проекта автотестами. Я предоставил подробный отчёт, что покрыл, как это сделал, где добавил стабильности. Но после очередного 1-на-1 с тимлидом я узнал неприятную новость для всего проекта: нам жестко урезают бюджет, полностью останавливают найм новых сотрудников и, естественно, на повышение зарплаты средств нет и подавно. Я расстроился, но решил попробовать снова договориться о новом PDP, тоже сроком на 3 месяца. Все пункты я сделал ещё до конца срока PDP, но в итоге снова узнал, что бюджета на повышение ЗП не было.


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


На новом месте я сразу сказал, что для меня важны обязательства не только со своей стороны, но и со стороны проекта, в котором я работаю. И на меня сразу заложили бюджет на повышение ЗП на год. Я знал, что, выполнив поставленные задачи, получу то, что заслужил. Так и случилось. Happy end :)


Мораль этой истории следующая: надо любить то, что ты делаешь, но и не забывать любить себя.


Неумение превращать свои слабые стороны в сильные


Лень закаляет характер, если вспомнить, сколько требуется усилий, чтобы её побороть. (с) Тристан Бернар.

Сам по себе я очень ленивый человек. (с) я

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


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


По соседству был отдел автоматизации тестирования. Я был знаком оттуда с Андреем AndrewQA777 Шальневым ещё со времен работы в техподдержке, у нас сразу сложились хорошие отношения. Я стал интересоваться, как работает автоматизация, и, немного поговорив с ним, понял, что это:


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

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


Именно не желая день за днём щёлкать однотипные задачки, я закопался в многочисленные доклады, статьи и литературу (начиная с общей теории у Куликова и заканчивая описанием технической документации Jasmine, Protractor, WDIO, Selenium и др.) по теме автотестов. Так и началась моя карьера автоматизатора.


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


Зависть


Я уже не раз упоминал про своего друга. Настало время познакомиться с ним поближе. Его зовут Туан. Сейчас он возглавляет ключевую команду QA-core в компании. И с самого начала я ему завидовал — конечно же, в хорошем смысле. В том плане, что равнялся на него.

Мы учились в одном университете. Именно Туан первым нашел работу в Skyeng и привел сюда меня. Общаясь с ним, я понял, как можно совмещать работу с учёбой. Именно он одним чудесным вечером позвонил мне и сообщил, что есть вакансия и со мной хотят поговорить.


А через несколько месяцев Туан сообщил печальную (для меня в тот момент) новость, что он уходит в какой-то там отдел QA. Отчасти поэтому я стал думать, что мне тоже надо двигаться дальше. Если он смог, то и я попробую. После этого были те самые неудачные собеседования, но в конце концов я тоже попал в QA. И снова работал со своим другом.


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


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


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


Неудовлетворенность собой


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

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


Ни один из этих вариантов нам не подходит, поэтому напоследок я хочу поделиться тем, как сам боролся с этими ситуациями.


Выгорание


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


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


Как бороться с этим? Честно, я бы с радостью ответил, но еще не нашёл действенного решения для себя. Пока мне помогают следующие моменты:


  • почаще брать отпуск (на неделю раз в 2-3 месяца);
  • чаще менять локацию, из которой работаешь (на удалёнке это сделать проще);
  • строить диаграмму Ганта для своих задач (крутая практика, помогает чётко распланировать задачи на определённый срок);
  • планировать активности в календаре (например, с 10:00 до 11:00 я пишу код, с 11:00 до 12:00 — на созвоне, с 12:00 до 14:00 ресёрчу новый инструмент и т.д.).

Основная суть этих практик — не сидеть на одном месте и отсеивать входящие запросы для достижения максимального фокуса на текущих задачах.


Отсутствие мотивации


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


Отсутствие поддержки


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


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


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

Источник: https://habr.com/ru/company/skyeng/blog/558656/


Интересные статьи

Интересные статьи

«Вот если бы каждый житель планеты скинулся мне по рублю, то я бы с умом потратил их на общее благое дело» — наверное, каждому когда-то приходили на ум такие мысли, особенно, когда есть...
Видеореклама набирает все больше оборотов: пользователи лучше реагируют на видео, чем на статические картинки и баннеры, а рекламные системы постоянно увеличивают количес...
Мы запустили «Актион Акселератор» и ждем всех, кто делает MOOC-курсы, решения в духе «Education 4.0», сервисы для обмена знаниями, онбординга и управления персоналом. Пом...
Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Things You Should Know As a Web Developer» автора Anuupadhyay. Написание тысячи строк кода и превращение в веб-сайт — одна из творч...
Статья подготовлена с целью дать разработчикам общие понятия об уязвимостях, с помощью которых можно создать для вас проблемы в нормальной работе сайта. Так же даются рекомендации по защите от этих уя...