Мое первое тестовое

SPL
А вот такой был ответ от Яндекса:

Потом я попала на одну карьерную выставку и увидела там стенд КРОК — погуглила после сайт и решила откликнуться на одну из вакансий. Сейчас, конечно, смешно вспоминать свою мотивацию — мне понравился офис (аж 11 этажей, не то что в моем прошлом офисе — всего один), то, что с моей Калужской удобно делать пересадку на желтую и бесплатный обед (это ж можно домой булку или яблоко с собой унести). Сейчас студенты, конечно более осознанные :))
Собеседовалась я на стажера-разработчика — все прошло нормально, я решила ситуационные задачки, ответила на вопросы. Но меня не звали. И потом отказали. Тогда я набралась смелости и попросила фидбэк, чтобы понять, как могу усилиться на рынке труда (осторожно, в письме сквозит темное прошлое с мыслями о филфаке). В общем, мне повезло — мне перезвонили и пригласили на позицию стажера-тестировщика. Вот так корректировка бага собеседования привела меня в мир тестирования.

Взрослая работа и первые ошибки
1 декабря 2009 года был мой первый рабочий день в КРОК, но на серьезный проект меня поставили только в феврале. Мы писали софт для Всероссийской переписи населения 2010 года. Одним из условий работы на нем была необходимость сидеть всей командой в одной комнате. Не помню точно, сколько нас было — кажется, почти под 50 человек. Это был кайф кайфный, даже жалею, что такого опыта больше пока что не случилось — теперь команда не то что по комнатам-этажам раскидана, но даже по городам и странам. Кто бы что ни говорил про возможность работать из-под пальмы, но работать бок-о-бок — непередаваемо-вдохновляющие ощущения.
Думаю, локализация всей команды в одной комнате сократила скорость моего въезжания в проект — я всегда была в курсе всех информационных потоков, было слышно, как обсуждают разные части проекта — можно было всегда подойти и присоединиться. Помогла еще моя экстраверсия — героем мема про новичка на проекте я бы точно не стала, страха подойти к команде или к руководителю у меня не было.
Тестировщиков (включая меня) было 6, один из них тест-лид. Тогда у нас не было никакого скрама, было что-то вроде MSF — мы писали большие и полные тест-кейсы, вели всю документацию. В тестировании старались дать каждому тестировщику отдельную подсистему, но бывало, что вместе проверяли одну. У нас был календарный план, и мне почему-то помнится, что у нас был каждый месяц релиз. Про проект, кстати, подробно рассказывали на Хабре, вот здесь можно почитать.
Меня очень вдохновляло то, что я делаю. Ведь результатом моей работы будет то, что несколько тысяч людей, которые будут работать с нашими подсистемами, смогут выполнять свою работу хорошо, значительно сэкономив свое время. И смогут собрать результаты Всероссийской переписи населения, и наверное, разработать какие-то полезные законы. В общем, в то время чувство ответственности зашкаливало, ошибки пропустить просто нельзя. Считаю нереальным везением, что удалось попасть на такой проект в начале карьеры — мне кажется, что для молодого спеца особенно важно понимать, что результат работы можно пощупать, что он реально приносит пользу, а ты не просто что-то тестируешь (как я думала, когда шла в Яндекс). Если этот пост читает кто-то из джунов, мой вам совет — идите в “страшные” проекты, это реально лучшее, что вы можете сделать для своего профразвития. Кстати, пока вспоминала первые месяцы работы, прокручивала в голове факапы, и кажется, собрала комбо. Поделитесь в комментах, какие у вас были кейсы?
У меня было вот так:

• проверяла сначала негативные кейсы, не проверив позитивные
  
• проверяла по настроению, без системы проверок (чтобы быть уверенным, что ты выполнил полное тестирование и ничего не забыл. с этим я разберусь позже, когда займусь своим образованием)
  
• проверяла числовое поле, вводила туда буквы, а они не вводились. А потом оказывалось, что с помощью Ctrl+C-CTRL+V буквы в числовое поле очень даже прекрасно вводились:)
  
• была и совсем дичь: проводя функциональные тесты через UI, не смотрела что там происходит в базе данных, как вся информация сохранилась.

Я — подмастерье vs Я — наставник
В КРОК развита система наставничества — у каждого нового сотрудника есть человек, который помогает ему адаптироваться в компании в целом и в рабочей команде. Ну и вообще в любом профразвитии без наставника никуда :) Как правило, им логично становится наиболее опытный член команды. Сейчас я вспоминаю и понимаю, что мой наставник меня редко хвалил и как-то редко был доволен моей работой — в общем, суровый тестировщик. Я из тех людей, которых мотивирует не злость от того, что он получил тройку (“уу, ну я сейчас всех победю!”), а пятерка с минусом. Мой наставник же действовал от противного (почему я об этом не говорила — вопрос хороший) — он был очень дотошный (что не удивительно для тестировщика) и делал акценты на том, что у меня не выходило, объяснял, как это можно исправить или не допустить в следующий раз. Но зато его первую похвалу я помню до сих пор. Я написала тест-кейсы для одной подсистемы и он сказал: “Идеально, отличная компоновка кейсов, всё логично, проверки хорошие. Всё здорово”. Видимо, меня это так поразило, что я помню это до сих пор. И тогда же я поставила себе “галочку”- поняла, что могу, что я не потеряна для тестирования:)
Когда я сама стала наставником, мне выпал шанс закрыть все профгештальты — за себя и за того парня, как говорится. Я тогда только стала тест-лидом, к нам на проект пришел молодой человек из другого отдела. По факту, это была я несколько лет назад — все, что он знал про тестирование, было “ошибки есть, их не может не быть” (Дима, если ты читаешь сейчас эту статью, а я надеюсь, что ты читаешь, я передаю тебе огромный привет!)
И вот тут я оторвалась — я старалась разнопланово обсуждать его работу, подсовывала
разные статьи и обучающие видео, концентрировалась на успехах, передавала свой опыт — как составлять тест-кейсы, как тестировать процессы. Кстати, Дима сейчас тоже тест-лид, у него собственные проекты, а еще он помогает набирать специалистов в компанию и проводит собеседования.
Кстати, стать наставником — один из лучших способов избежать выгорания в профессии. Во-первых, делиться знаниями реально приятно. Во-вторых, это мощнейшая точка роста — как софт скиллов, так и собственных профессиональных качеств. Все мы очень умные и реализовавшиеся — до первого очень умного новичка :)
Порефлексировав, я поняла, что этот опыт, кроме радости “воспитания” нового спеца дал мне еще вот что:

• я изменила свой подход к работе — иначе стала смотреть на тщательность — у нас появились Definition of Done. Если я раньше считала нормой что-то вроде “Умри, но найди все ошибки, будь мастером придирчивости и дотошности”, то я сейчас я выстраиваю свои проверки ровно с ожиданиями и договоренностями, не пытаюсь перепрыгнуть через свою голову.
  
• умею определять критичные компоненты проекта
  
• стала более заботливым специалистом — я лучше понимаю, как себя ощущает новичок в карьере, развила профессиональную эмпатию.

Тестировщик без базы — быть или не быть
После 1,5 лет работы подмастерьем я задумалась о профильном образовании — университетские знания совсем не пригодились. Ну, разве что при тестировании методом белого ящика я читала код и понимала, что там написано (как никак, мы разные языки программирования в универе изучали). Но справедливости ради добавлю, что именно математическая база мне точно помогает — как минимум, комбинаторика каждый день используется. В нагрузочном тестировании нужна теория вероятности, всякие там перцентили, когда анализируешь результаты и структурируешь. Еще теория случайных процессов — наличие этой базы мне позволяет структурировать свои проверки по процессам, где есть статусы, переходы из статусов, длинные пути, циклы внутри пути.
Я была тестировщиком без базы — и хотя работала я хорошо (пусть и под странным девизом “найди все, что не так, а как найдешь — не важно”), понимала, что мне не хватает системы, чтобы как-то оптимизировать хаотичный набор моих действий. Помню, когда впервые узнала о существовании тест-дизайна, классов эквивалентности, граничных условиях, Pairwise и такая: аааа, так вот как надо!
В попытках образоваться я прошла несколько курсов на software-testing, но если честно, они были слегка мимо меня, не могу сказать, что было полезно. Но зато я очень оценила (и всячески рекомендую) их “Школу тест-менеджеров” — она все супер разложила по полочкам и упорядочила мой огромный практический опыт. На этом курсе было 8 вебинаров — учили оценке трудозатрат, целям тестирования, техникам тест-дизайна, какие метрики собирать. Тот курс меня так зарядил, что я потом все то время, что работала тест-лидом, продолжала распространять свои знания и понятия о прекрасном тестировании, как надо и как не надо. Совершенно точно после курса про тест-менеджмент я стала осознанным тест-лидом, проактивным, а не реактивным, стала вести статистику.
Как бы все сложилось, если бы у меня была база? Хочется дать ответ, что с ней мое развитие пошло бы быстрее. Но ведь не факт. Сейчас, когда провожу много собеседований, вижу, как многие прошли курсы по тестированию, сыпят всякими словами вроде: “ооо, я провожу смоук тестирование”, “оооо, тестирование черного ящика”. Но обширная теоретическая база часто означает недостаток практики. У меня же было полно практики, и скорее, когда я училась, то примеряла свои примеры из работы на ту теорию, которую рассказывали, и сразу представляла, что и где могла бы применить, или как стоило по-другому построить кейсы.
Еще одним мощным рывком в моем профессиональном развитии стал мой первый проект в роли тест-лида — все потому, что я люто накосячила и узнала реальную цену ошибок. А также, что вообще есть такие понятия, как Severity и Priority, что может быть блокирующий дефект, но который не нужно исправлять в первую очередь. А есть критический — и вот им как раз нужно заняться самым первым. С тех пор я с первых дней работы на новом проекте определяю, что точно должно работать в любых обстоятельствах, количество пользователей, кто они, на что это может повлиять. Больше рассказать не могу :)

Зацените качество камер смартфона тогда — здесь я в своей первой рабочей командировке в Ростов-на-Дону в качестве тест-лида, приехала к пользователям, чтобы побеседовать с ними.

На фотке: наша командная магнитная доска в комнате, свободная зона для творчества:) “Мистика в кубе, объезжаемая на сивой козе”. Эта фраза очень хорошо описывала одну ситуацию на том проекте :)
Два выгорания за 5 лет
В 2016 году я была в профессии семь лет — стала крутым тест-лидом и любила свою работу — даже слишком. Только спустя время я поняла, что это было выгорание, а не преданность делу. Я не психолог, но, возможно, мой опыт будет полезен — выгорание не всегда проявляется только усталостью и апатией. Что было у меня:

• я стала контрол-фриком — я знала абсолютно все о каждой детали проекта и ни на секунду не давала себе и окружающим расслабиться
  
• я повернулась на идеальности — ошибок быть не могло, нужно было делать на 101% сразу, другой результат я от себя не принимала
  
• я думала только о работе — я просыпалась с почтой и засыпала с почтой. За ужином дома я говорила только о работе. Тогда я ждала первого ребенка, но даже мысли о таком крутом изменении в моей жизни не отвлекали меня от задач на проекте. Я даже год в декрете заходила в почту каждый день, чтобы проверить, не развалилось ли там без меня все.

Как с этим справиться — не знаю, у меня случилось так, что я ушла в декрет (не специально, так вышло). Потом первый декрет перерос во второй — и я выгорела уже от сидения дома.
Я вернулась в офис незадолго до пандемии — успела побыть в старых условиях буквально пару месяцев. Меня немного подотпустило — оказаться в привычной среде было приятно, а заодно выйти на один из самых крутых проектов в моей карьере (он пока под NDA, но если будет можно, расскажу об этом в отдельном посте).
Но чувство, что я попробовала в тестировании уже все, что можно, не отпускало. Ирония в том, что идти по классическому пути развития тестировщика — в разработчики, большие руководители, бизнес-аналитики — мне не хотелось. Мне нравилось (и нравится до сих пор) тестирование — просто был нужен новый челлендж, что-то совсем необычное.
Несколько месяцев назад я поняла, что еще больше, чем тестированием, мне хочется заниматься улучшением процессов, поиском проблем в процессах именно в проектах и командах. Так я стала агентом изменений в департаменте разработки программного обеспечения (ДРПО) — помогаю командам стать адаптивными.
Что это за зверь такой — агент изменений?
Начну издалека.
В феврале 2020 года (еще “до всего”) я сходила на очный тренинг по Scrum. Очные тренинги, кто помнит такое?:) Я и до этого давным давно слышала про всякие стори-поинты, спринты, дейли скрам, но применять на проектах не получалось — то ли знаний не хватало, то ли еще чего-то. А тут получилось и информацию новую получить, и сразу же обкатать в работе в группах.
Как был устроен тренинг: после каждого часа теории мы разбивались на группы для отработки навыков на практике. Задания на первый взгляд могут показаться очень легкими (например, нам раздали бумажки и предложили найти соответствие между ценностью Agile и ее описанием), но здорово помогали в игровой форме закрепить информацию. А еще была понятна структура — вот 5 событий, у каждого есть таймбокс, присутствующие люди, цель, артефакты на входе и выходе.

На фото — самая впечатляющая часть тренинга. Города + Lego = любовь. С каждым раундом мы понимали, что лажаем и лажаем — но к третьему выровнялись и получилось круто.
После двухдневного тренинга я вернулась к себе в проект — вся заряженная, с воплями и предложениями. А давайте начнем проводить дейли? А давайте начнем проводить ретроспективы? Понемногу процесс пошел, но мы еще не были скрамом. Потом в мае в команде КРОК появились Agile-коучи, и на первую встречу-знакомство я пришла, вооруженная кучей вопросов про ретроспективы. В середине сентября мне рассказали про идею агентов изменений в нашем департаменте, и я с радостью туда вписалась. Почему? Потому что еще два года назад, когда я была в декрете и грустила, я думала: “А что же я люблю делать? Что же у меня хорошо получается? Кем же мне работать?” Ответив самой себе на эти вопросы я поняла, что мне очень нравится вдохновлять людей какой-то идеей. Когда я сама чем-то проникаюсь и ко мне спускается инсайт, мне хочется как можно скорее им поделиться со всеми доступными мне людьми :)
Я сразу же побежала к своему РМ (ресурс-менеджеру) и поделилась, что узнала про такую инициативу и мне туда очень нужно, потому что это мое на все 100%. РМ, конечно, расстроился, ведь это значило потерять ведущего тестировщика в команде, но поддержал меня в этом решении — принуждаловки у нас нет, внутри всегда поддерживают желание сотрудника менять вектор развития своей карьеры, даже если он такой неожиданный и нестандартный.
Как появилась идея агентов изменений? Честно говоря, не знаю всей предыстории, потому что ворвалась в проект не на этапе идеи, но расскажу, как я понимаю нашу мотивацию сейчас.
Три главных человека у нас в департаменте решили, что будущее — точно за гибкими методологиями, они в них верят. И это значит, что команды должны быть точно такими же — адаптивными и самоорганизующимися. Почему? У адаптивных команд никогда не бывает ситуации, что на почту пришло письмо про проблему на стенде, а потом ее каждый час дергают: ну что, получилось? А кто ответственный? А какие сроки? В адаптивных командах люди сами нацелены на решение проблем, им важно не просто завершать свои задачи, а работать как единая команда, совершенствовать процессы внутри себя и им для этого не нужен менеджер, который придет и скажет: “С сегодняшнего дня на дейли отвечаем на три вопроса!” Команды САМИ решают проблемы, потому что они — сложившийся коллектив с большой степенью осознанности.
Эту трансформацию я прочувствовала на себе — до того, как стать агентом изменений, я тоже ждала, когда на меня спустят задачу. На встречах с заказчиком я стеснялась задать вопрос — вдруг я задам невпопад, а потом окажется, что под вопросы будет отдельный блок в конце встречи, была не очень инициативна. Сейчас мне эта разница особенно бросается в глаза — между командами, которые только стали на путь адаптивности, и более продвинутыми.
Если кратко, то вот результат, к которому мы стремимся:

• команды самоорганизуются и саморефлексируют
  
• менеджер не занимается “подбадриванием” и раздачей задач
  
• наши заказчики довольны, мы работаем с ними на результат и в единой команде
  
• команды быстро адаптируются к изменениям на рынке
  
• агенты изменений не нужны как класс

Мир меняется очень быстро. И если ты не будешь бежать в два раза быстрее, то, как мы все знаем из “Алисы в стране чудес”, никуда попасть не сможешь. Но быстро бежать и перестраиваться, когда у тебя нет навыка рефлексии внутри команды, сложно. Хочется, чтоб в дальнейшем команды умели генерировать изменения внутри себя сами, а не с помощью приходящего человека — агента изменений.
Из ближайших целей — мы хотим, чтобы про нашу инициативу знали не только в ДРПО (нас около 600 человек сейчас), но и как минимум 1000 человек за пределами департамента — всего нас в компании 3000+. Хотим поработать с 15 проектами и оценивать их конкретными измеримыми метриками, а не только на уровне ощущений “было-стало”.
Сейчас в нашей команде 1 Agile-коуч и 8 агентов изменений. Мы еженедельно собираемся на синхронизации, ведем общую доску активностей в Trello — с нашими общими целями и целями каждого агента изменений. Работаем по спринтам, в конце спринта — анализируем, что удалось, а что нет.
Что мы делаем?
Мы приходим в проект, из которого поступил запрос, и начинаем исследование — посещаем несколько проектных встреч, где наблюдаем, как проходит дискуссия, вокруг чего она строится, как команда общается друг с другом на встрече. Затем мы проводим интервью с каждым членом команды и готовим перечень проблем с пояснением и доказательствами того, как она связана с конкретными потерями (чаще всего это потеря времени, см. бережливое производство, оно же Lean). По каждой проблеме мы даем рекомендации — какие Agile-инструменты могут помочь ее решить., которые бы помогли проработать эти проблемы. Рекомендации — это что из Agile-инструментов (есть вот такая громадная карта инструментов от Deloitte, часть из них мы используем).

Примеры конкретных рекомендаций — практики из Kanban Maturity Model, которые помогают команде перейти с одного уровня зрелости на следующий, какие-то события из Scrum, своевременная обратная связь друг другу.
В одном проекте мы раньше сроков выкатили финальный релиз, причем не увеличивая команду — просто по-другому распределили работу. Стали по-другому проводить демо заказчику: раньше просто показывали то, что сделали за спринт, фиксировали замечания, отвечали на вопросы. А теперь мы стали еще спрашивать обратную связь — как им вообще результат. И оказалось, что заказчики не только про замечания и доработки — они еще бывают в восторге. Это очень сильно стало мотивировать команду на работу над следующими спринтами. Как будто тебе не только двойку в дневник поставили, но и пятерку туда за домашку застолбили:) А еще мы изменили нашу доску в Jira, стали пользоваться там Kanban-доской и добавили фильтры по имени каждого человека, добавили визуальное отображение заблокированных задач (а раньше это никак не было видно, нужно было держать в уме). Вся проектная команда перестала забивать на доску, и доска в Jira зажила активной социальной жизнью. А еще придумали Trello-доску для организации работы с другими компаниями, которые тоже были задействованы в этом проекте.
Сейчас я получаю огромный заряд энергии и вдохновения от того, чем занимаюсь — я провожу много встреч и вижу, как они влияют на людей, сколько инсайтов с них они уносят. Тестирование перестало меня зажигать так, как раньше. Да, я по-прежнему люблю улучшать мир, но нашла себе более актуальное применение, где количество энергии (ресурса) у меня в разы больше.
Мне кажется, что такое развитие тестировщика — не исключение из правил. Знаю, что многие тестировщики уходят в менеджеры проектов, в скрам-мастера — мне кажется, что тестирование и обеспечение качества (QA) (кстати, интересно, какое количество в мире холиварных статей на тему QA, QC и просто тестирования существует:)) очень близки по духу скрам-мастерам и агентам изменений. Я бы сказала, что агент изменений — это что-то вроде скрам-мастера, только он помогает настроить вообще все, что угодно, и при этом нацелен на осознанность.
***
Закончить пост хочу вопросами.
Тестировщики, за что вы любите свою профессию и что вас держит? Как начинали свой путь? Если развиваетесь в автотестах — тоже очень интересно узнать, как к этому пришли? (кстати, мы сейчас расширяем команду QA Automation инженеров — детали тут). Если вы ушли из тестирования, то что делаете сейчас и делает ли вас это счастливыми? Если вернулись, то почему?
Моя почта для связи — AnLivenskaya@croc.ru. В комментах тоже буду рада пообщаться :)
===========
Источник:
habr.com
===========
Похожие новости:

• [Программирование, Развитие стартапа, Карьера в IT-индустрии, Научно-популярное] Исповедь CTO: путь развития технического директора в стартапе (перевод)
  
• [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр] Когда QA-специалист становится профессионалом в игровой индустрии? (перевод)
  
• [Исследования и прогнозы в IT, Карьера в IT-индустрии, Удалённая работа] [Исследование] Как удалёнка поменялась за последний год
  
• [Тестирование веб-сервисов] Багрепорты могут быть простыми (перевод)
  
• [Тестирование мобильных приложений] Чек-лист тестирования мобильных приложений
  
• [Информационная безопасность, Карьера в IT-индустрии] Сдать OSCE: вызов принят
  
• [Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр, Карьера в IT-индустрии] В тестировщики пойду: 10 вопросов про то, как переквалифицироваться в специалиста по тестированию
  
• [Карьера в IT-индустрии, Читальный зал] Уроки выживания. Что делать с токсичными руководителями
  
• [IT-инфраструктура, Серверное администрирование] Купили гарантию на серверное железо: что может пойти не так?
  
• [Управление персоналом, Карьера в IT-индустрии] Что делать с неэффективным сотрудником, который считает, что он отлично справляется (перевод)

Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_karera_v_itindustrii (Карьера в IT-индустрии), #_professionalnoe_vygoranie (профессиональное выгорание), #_testirovanie (тестирование), #_karera_testirovschika (карьера тестировщика), #_agent_izmenenij (агент изменений), #_motivatsija (мотивация), #_qa_engineer, #_karera_v_it (карьера в ит), #_blog_kompanii_krok (
Блог компании КРОК
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_karera_v_itindustrii (
Карьера в IT-индустрии
)