Тестировщик по жизни

У QA в работе много интересного: новые фичи, сложные баги, расследования, логика, процессы. Но есть и другая сторона. Это то, что может довести даже спокойного человека до белого каления. Очень частая фраза, которая может означать: «Я не хочу ждать, но и объяснять, что проверять, тоже не буду». Видимо от QA в этот момент ждут телепатических и экстрасенсорных способностей, которых, конечно же, нет. Поэтому понять QA может совсем не то, что задумал автор. «Ну там всё понятно должно быть». А оно никому ничего должно...

В какой-то момент в карьере почти каждый сильный тестировщик оказывается на развилке: либо идти в лиды, либо остаться крутым сеньором и просто делать задачи. Хотя переход в лиды это не столько рост, сколько смена деятельности, ведь это совершенно другая работа! Многие хотят стать лидом. Это выглядит привлекательно: больше влияния, участие в принятии решений, развитие команды, управление процессами. Лид много времени тратит на 1-to-1 встречи, найм сотрудников, обсуждение процессов, планирование релизов, решение конфликтов, защиту команды перед менеджментом...

Ни один QA от этого не застрахован, и рано или поздно это случится с каждым: баг проскользнёт на прод. Это неприятно. Иногда даже очень! Но это не конец карьеры и точно не автоматическое увольнение. Первое, что нужно сделать: Как говорит Николай Картозия (продюсер и ген. директор телеканала «Пятница») в своих интервью: «Стадия о*уевания не является обязательной». Паника только всё усугубляет и толкает на необдуманные слова и действия. Потом будут вспоминать не баг, который вы пропустили, а то, как вы себя повели после этого...

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

У меня часто такое бывает в жизни: жена работает за ноутбуком и у неё что-то не работает. Она пытается понять в чём дело, пытается разобраться, но проблема остаётся. Тут подхожу я и всё чудесным образом начинает работать. А вот ещё распространённая ситуация – разработчик говорит: «Не воспроизводится!» А у меня всё очень даже воспроизводится, очень стабильно. Созваниваемся, пытаемся воспроизвести баг вместе и в этот момент он воспроизводится. Это и есть эффект присутствия. Когда QA рядом (даже на звонке) система начинает «вести себя честно»...

Этот вопрос регулярно всплывает у новичков в тестировании. Кто-то говорит, что без кода в IT делать нечего. Другие уверяют, что хороший QA может работать полностью вручную. Правда, как всегда, где-то посередине. На 1-м курсе университета у нас был предмет «Введение в программирование», где мы изучали язык программирования С (Си). Однако начинали мы не с синтаксиса языка, а с изучения логики, алгоритмов и блок-схем. Это дало нам базу, на основе которой, изучив синтаксис любого языка, можно писать программы...

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

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

QA работает не только с кнопками, кодом и багами, но и с людьми. И часто именно софт-скиллы определяют, насколько ты приживёшься в профессии и в команде. Вот 5 ключевых навыков, которые реально помогают в работе: QA общается со всеми: разработчиками, аналитиками, менеджерами, пользователями. Умение донести свои мысли так, чтобы тебя поняли – половина успеха. Хорошая коммуникация снижает недопонимание и ускоряет решение проблем. В QA редко что-то делается в одиночку. Нужно договариваться, подстраховывать друг друга, помогать коллегам...

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

В мире QA часто говорят о технологиях, инструментах и процессах, но редко – о людях. А ведь именно люди помогают нам расти быстрее всего. Одним из таких драйверов роста является менторство. У меня впервые появился «подопечный» в стартапе. Проектов становилось больше, и я просто перестал успевать делать всё сам. Тогда я нанял себе джуна в помощь. Это был новый опыт: с одной стороны – передача знаний, с другой – необходимость делегировать часть задач. На первый взгляд плюсы очевидны: можно разгрузить себя от рутинных задач и освободить время для стратегических вещей...

В корпорациях многое уже отлажено: процессы, форматы отчётов, инструменты. Здесь можно научиться дисциплине, корпоративному общению, обзавестись полезными контактами. Есть и очевидные плюсы: лицензии на любые инструменты, шикарные офисы, ДМС, оплачиваемое обучение. Но при всей комфортности у такого подхода есть и обратная сторона – малоподвижность. Даже небольшое изменение в процессе может утонуть в бесконечных согласованиях. В стартапах всё иначе. Тут нет готовых правил, а значит, у тебя появляется свобода выбора...