Есть мнение, что “войти в айти” легче через тестирование. Будучи на третьем курсе, я part-time подрабатывала асессором. Тогда я впервые попробовала себя в тестировании, увидела первые чек-листы (я еще не знала, что они так называются). “Войти в айти” не было моей целью, потому что я уже и так училась на программиста, но сама идея тестирования меня очень увлекла. Так на последнем курсе я устроилась на стажировку в Kolesa Group.
Месяц подготовки: чтение пресловутого Романа Савина “Тестирование дот ком”, просмотр роликов на YouTube и практика в создании тест-кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.
Чтение книг != тестированию реальных продуктовых задач. Так, в ходе работы я сталкивалась с интересными кейсами и проблемами. Теперь, уже будучи миддлом, я рефлексирую и вижу паттерны поведения, которые тормозили мое развитие в профессии. Ошибки, на которые, будучи джуном, я не обращала внимания, но которые позже стали моей болью. Ошибок было куда больше чем три, но именно эти я повторяла из раза в раз, не отдавая себе отчета.
0. Не просить помощи
Когда я была стажером, мне очень хотелось показать себя, потому что от этого зависело, возьмут ли меня на работу. Но даже после успешного прохождения испытательного срока я взяла свои стажерские “наклонности” в junior-позицию. Я могла работать над парой задач в то время, когда еще парочка висела в бэклоге. И в тот же момент я частенько пыталась решить какие-то сторонние вопросы и проблемы. Итог: несколько висящих в воздухе задач, ожидающих меня, в то время как другой тестировщик мог быть свободен.
Я не говорю, что стараться и делать больше, чем нужно, — это плохо. Плохо — неразумно оценивать свои возможности и строить из себя героя в попытках сделать все. Не сделаешь. А если и сделаешь, то не так качественно, как мог бы. Просить помощи не зазорно. Грамотно делегировать нагрузку и задачи — круто. Своевременные релизы и тщательно проверенные фичи — лучшее, что может быть для продукта и бизнеса.
Вывод: проси помощь. Все мы люди и иногда нуждаемся в ней. Не успеваешь — делегируй, но не злоупотребляй. Грамотно оценивай свои возможности и время.
1. Бояться задавать вопросы или задавать слишком много вопросов
Я интроверт, к тому же время от времени страдаю синдромом самозванца, поэтому когда у меня возникали вопросы, очень стеснялась подходить к старшим товарищам. Мне казалось, что мои вопросы глупые и вообще я сама могу найти на них ответы.
В большинстве случаев так и есть, ответы на какие-то вопросы легко можно найти после пары минут гугления или поиска в stack overflow. Вопросы, связанные с бизнес-логикой, особенностями архитектуры и различными workflow, можно найти в документации (если в компании она, конечно же, ведется). Но сейчас я говорю о специфических вопросах, ответы на которые можно узнать лишь у коллег. Я могла тратить до 30 минут своего времени на гугл-поиски, поиски в документации компании, просмотр кода и даже иногда пыталась сама додумать ответ на свой вопрос (кстати, так делать не стоит). Итог: много потраченного на поиски времени и, возможно, так и не найденный ответ. Помочь избежать этого могли 5–10 минут общения с коллегами.
Но у этой медали есть обратная сторона — задавать слишком много вопросов. Даже не так. Задавать вопросы без предварительно проведенного самостоятельного исследования. Бывают случаи, когда человеку легче подходить каждые пять минут с новыми вопросами, в то время как ответы на них можно было бы найти самому.
Вывод: иногда действительно продуктивнее просто спросить у коллег то, чего ты не знаешь. Но перед этим всегда нужно самому провести небольшой поиск ответа на вопрос и собрать все вопросы, которые возникли по ходу.
Так можно получить новые знания и закрепить ранее приобретенные. А когда ты подойдешь с вопросом к коллеге, ему будет приятно осознавать, что ты проделал хоть какую-то работу сам, прежде чем бомбардировать вопросами его/ее.
2. Не брать на себя ответственность
Когда ты джун, ты получаешь простые задачи и несешь меньше ответственности. Ты понимаешь, что есть более опытные коллеги, которые в случае чего придут на помощь и решат проблему. Например, при релизе забаганной фичи ты знаешь, что откат к предыдущей версии сделает кто-то другой. И так во многих вещах. Но для роста нужно научиться брать на себя ответственность и решать проблемы самому, брать инициативу и просить более сложные задачи, быть в эпицентре и помогать во время факапов. При совершении ошибок признавать их и искать пути решения. Брать ответственность не только за свои задачи, но и за качество продукта в целом.
Вывод
Через принятие ответственности можно выйти на новый уровень задач и новые челленджи, которые помогут в твоем профессиональном росте. Не бойся ответственности — она твой друг.
Это были ошибки, которые я совершала не раз. Если быть честной на 100 %, я даже сейчас их иногда совершаю. Но это абсолютно нормально. Осознание проблемы — первый шаг на пути к ее решению.
Не очевиден каждый пункт ни разу. Проблема тут в другом, даже прочитав статью, молодой джун все равно сделает ровно те же «ошибки». Без опыта это все не воспринимается, как рабочая парадигма. Плюс очень много зависит от руководителя и от коллектива в целом
Согласна с вами, эти вещи становятся очевидными через какое-то время, не сразу. И, конечно, уроки лучше усваиваются через набивание своих шишек, но приятно видеть, что ты не один кто сталкивался с этим.
Вы извините, но делегирование задач — прерогатива руководителя. Вы свои задачи делегировать никому не можете с джуно позиции. А если ваш руководитель видит, что один QA пинает балду, когда у второго есть зависшие задачи, и ничего не делает, то это проблема руководителя.
На тему «брать ответственность на себя» — у нас в свое время был тренинг, во время которого очень хотелось дать по роже тренеру этому. До сих пор воспринимаю эту фразу, как оскорбление.
Вероятно в пункте про делегирование уместнее было бы сказать про умение говорить нет. Многие дауны грешат тем, что набирают на себя кучу дел, только потому что у них о них спросили. А затем страдают от того, что ничего не могут успеть. Да собственно сам же таким был когда-то.
9
4900
Хороший список. А qa тут не при чем, вообще. Все универсальнее
Хорошие советы для любой специальности. Простите, но по-моему каждый из пунктов очевиден, и статья не за служенно здесь.
Не очевиден каждый пункт ни разу. Проблема тут в другом, даже прочитав статью, молодой джун все равно сделает ровно те же «ошибки». Без опыта это все не воспринимается, как рабочая парадигма. Плюс очень много зависит от руководителя и от коллектива в целом
Согласна с вами, эти вещи становятся очевидными через какое-то время, не сразу. И, конечно, уроки лучше усваиваются через набивание своих шишек, но приятно видеть, что ты не один кто сталкивался с этим.
душевненько
Вы извините, но делегирование задач — прерогатива руководителя. Вы свои задачи делегировать никому не можете с джуно позиции. А если ваш руководитель видит, что один QA пинает балду, когда у второго есть зависшие задачи, и ничего не делает, то это проблема руководителя.
На тему «брать ответственность на себя» — у нас в свое время был тренинг, во время которого очень хотелось дать по роже тренеру этому. До сих пор воспринимаю эту фразу, как оскорбление.
Отличная статья! Нравится подача, и, думаю, будет полезна джунам в любом направлении.
Вероятно в пункте про делегирование уместнее было бы сказать про умение говорить нет. Многие дауны грешат тем, что набирают на себя кучу дел, только потому что у них о них спросили. А затем страдают от того, что ничего не могут успеть. Да собственно сам же таким был когда-то.
Делегирует руководитель подчиненным) а джун просит помощи или говорит что не может справиться)