Мои 3 ошибки, которые я совершала как junior QA engineer

Есть такое мнение, что “войти в айти” легче через тестирование. Будучи на 3 курсе я part-time подрабатывала в Яндексе в качестве асессора, тогда то я и впервые попробовала себя в тестировании и вообще впервые увидела чек-листы (на тот момент я еще не знала, что они так называются). “войти в айти” не было моей целью, т.к. я уже училась на программиста, но сама идея тестирования меня очень увлекла. Так на последнем курсе я устроилась на стажировку в Kolesa Group. Месяц подготовки: чтение пресловутого Романа Савина “Тестирование дот ком”, просмотр различных роликов на youtube и практика в создании тест кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.

Чтение книг != тестированию реальных продуктовых задач. Так в ходе работы я сталкивалась с интересными кейсами и проблемами. Сейчас как middle тестировщик, я рефлексирую и вижу паттерны поведения, которые тормозили мое развитие как специалиста. Ошибки, на которые будучи джуном, я не обращала внимания, но которые позже стали моей болью. Ошибок, конечно же, было больше чем 3, но именно эти я повторяла из раза в раз и не отдавала себе отчета.

0 Не просить помощи

Будучи стажером мне очень хотелось показать себя, т.к. от этого зависело буду ли я принята в штат. Но даже после успешного прохождения испытательного срока я взяла свои стажерские “наклонности” в junior позицию. Я могла работать над парой задач. Еще парочка могла висеть в бэклоге. И в то же время я могла пытаться решить какие-то сторонние вопросы и проблемы. Итого: несколько висящих в воздухе задач, ожидающих моего свободного времени (в то время как другой тестировщик мог быть свободен).

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

Takeaway: проси помощь: все мы люди и иногда нуждаемся в ней. Не успеваешь — делегируй, но не злоупотребляй. Грамотно оценивай свои возможности и время.

1 Бояться задавать вопросы или задавать много вопросов

Я интроверт, к тому же время от времени страдаю синдромом самозванца, поэтому когда у меня возникали вопросы, я очень стеснялась подходить к старшим товарищам. Мне казалось, что мои вопросы глупые, и вообще я сама могу найти на них ответы. В большинстве случаев так и есть, ответы на какие-то вопросы легко можно найти после пары минут гугления или поиска в stack overflow. Вопросы, связанные с бизнес логикой, особенности архитектуры и различные workflow можно найти в документации (если в компании она, конечно же, ведется). Но сейчас я говорю о специфичных вопросах, ответы на которые можно узнать лишь у коллег. Я могла тратить до 30 минут своего времени на гугл поиски, поиски в документации компании, просмотр кода и даже иногда пыталась сама додумать ответ на свой вопрос (кстати, так делать не стоит). Итог: много потраченного времени на поиски и возможно не найденный ответ. 5–10 минут общения с коллегами могли помочь избежать этого.

Но у этой медали есть обратная сторона — задавать слишком много вопросов. Даже не так. Задавать вопросы без предварительно сделанного research. Бывают случаи, когда человеку легче подходить каждые 5 минут с новыми вопросами, в то время как ответы на них можно было бы найти самому.

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

2 Не брать на себя ответственность

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

Takeaway: важно быть вовлеченным и стараться брать на себя ответственность. Через принятие ответственности можно открыть для себя новый уровень задач и новые челленджи, которые помогут в росте тебя как специалиста. Не бойся ответственности — она твой друг :)

Если в какой-то из ошибок ты нашел себя — это не повод расстраиваться. Любое обучение требует времени и благодаря ошибкам это обучение может стать более эффективным. Это были мои ошибки, которые я делала не раз. Если быть честным на 100% даже сейчас порой я могу их совершать. Но это абсолютно нормально. Важно осознанно подходить к своей работе (да и к жизни, в целом) и уметь видеть и распознавать эти ошибки, ну и не менее важное — работать над ними.

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