company_banner

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

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

    Месяц подготовки: чтение пресловутого Романа Савина “Тестирование дот ком”, просмотр роликов на YouTube и практика в создании тест-кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.

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

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

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

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

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

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

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

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

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

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

    Так можно получить новые знания и закрепить ранее приобретенные. А когда ты подойдешь с вопросом к коллеге, ему будет приятно осознавать, что ты проделал хоть какую-то работу сам, прежде чем бомбардировать вопросами его/ее.

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

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

    Вывод

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

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

    Kolesa Group
    Строим классифайды в Центральной Азии

    Комментарии 9

      +1
      Хороший список. А qa тут не при чем, вообще. Все универсальнее
        0
        Хорошие советы для любой специальности. Простите, но по-моему каждый из пунктов очевиден, и статья не за служенно здесь.
          0
          Не очевиден каждый пункт ни разу. Проблема тут в другом, даже прочитав статью, молодой джун все равно сделает ровно те же «ошибки». Без опыта это все не воспринимается, как рабочая парадигма. Плюс очень много зависит от руководителя и от коллектива в целом
            0
            Согласна с вами, эти вещи становятся очевидными через какое-то время, не сразу. И, конечно, уроки лучше усваиваются через набивание своих шишек, но приятно видеть, что ты не один кто сталкивался с этим.
          0
          душевненько
            +1
            Вы извините, но делегирование задач — прерогатива руководителя. Вы свои задачи делегировать никому не можете с джуно позиции. А если ваш руководитель видит, что один QA пинает балду, когда у второго есть зависшие задачи, и ничего не делает, то это проблема руководителя.
            На тему «брать ответственность на себя» — у нас в свое время был тренинг, во время которого очень хотелось дать по роже тренеру этому. До сих пор воспринимаю эту фразу, как оскорбление.
              0

              Отличная статья! Нравится подача, и, думаю, будет полезна джунам в любом направлении.

                0
                Вероятно в пункте про делегирование уместнее было бы сказать про умение говорить нет. Многие дауны грешат тем, что набирают на себя кучу дел, только потому что у них о них спросили. А затем страдают от того, что ничего не могут успеть. Да собственно сам же таким был когда-то.
                  0

                  Делегирует руководитель подчиненным) а джун просит помощи или говорит что не может справиться)

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое