Рамин
Специалист Superjob.ru

Как попасть в IT? История тестировщика из Superjob

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

Как попасть в IT? История тестировщика из Superjob

От техпода до тестера-стажера

Проработав 4 года на должности техпода, в один прекрасный момент я принял решение, что нужно менять курс, и он увел меня в сферу IT. Считается, что самый легкий путь входа в IT лежит через тестирование.

И... это не так!

Как я представлял работу тестировщика: пиши проверки (типа вводится / не вводится, отображается / не отображается, правильно / неправильно, верно /неверно). Ведь я уже четыре года занимаюсь подобным: проверяю все ситуации, которые попадаются, и если не работает — завожу задачу, описываю её и отдаю в тестирование.

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

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

И первый месяц дал понять, что легко не будет )


1 месяц. “Сразу в бой”.

Как только я получил своё новое рабочее место и был введен в курс дела, поступила крупная задача на новые «Максимальные тарифы».

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

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

Мозговой штурм

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

По чек-листу после мозго-штурма решено было дополнительно проставить приоритеты к проверкам. Из-за ограничений по времени решили проверить первоначально кейсы с высоким приоритетом, после чего уже можно было выкатывать фичу, а дальше спокойно допроверять с минимальным приоритетом.

[Пример]

Была собрана статистика по самым используемым тарифам + город + количество месяцев. Исходя из этих данных, мы сделали выжимку кейсов и покрыли минимальным количеством кейсов те параметры, которые используют максимальное количество пользователей.

Пример
Пример

Подготовка к тестированию у меня заняла целый день + на само тестирование ушёл еще один. Новые тарифные планы были проверены, и задача пошла в релиз. По итогам в задаче не было выявлено ни одного бага важного приоритета. От внутренних пользователей (менеджеров) была найдена всего пара ошибок низкого приоритета.

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

[Пример]

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

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

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

К середине первого месяца моей работы пришел… редизайн.


2 месяц. Редизайн.

Любые изменения помогают смотреть на привычные вещи под другим углом.

В моём случае это был редизайн, который затрагивал не только Frontend (визуальные изменения наподобие цвета иконок и расположения элементов), но и Backend.

Back коварен, так как затрагивает весь функционал, который может не только отвалиться, но и вести себя вызывающе :)

У нас, как у тестировщиков, были две большие задачи:

  • дать оценку на тестирование и…
  • покрыть все требования кейсами для прозрачности.

В этом процессе я плотно познакомился с Функциональными требованиями (далее “ФТ”), Макетами и Данными.

По макетам сделали отдельный чек-лист, т.к. проверки, связанные с ФТ, не затрагивают расположение кнопок, последовательность, их цвет, тени и пр.

Встречи

Еще одним нововведением в моей работе были встречи.

Они были разные: плановые еженедельные, внеплановые, по обучению, по работе с другими отделами и пр., и все это происходило на регулярной основе.

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

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

[ Более детально это описано в статье – «Покрытие требований кейсами. Реалии компании Superjob» ]

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

Я же мог передавать свои знания продукта и ускорять тем самым процесс разработки.

Таблица

Готовые требования от аналитиков отправлялись к нам на ревью. Следить за этапами состояния ФТ мы могли через google docs в таблице аналитиков.

Поначалу таблица имела минимальное описание: Ответственного аналитика и Ссылку на ФТ.

Ее пришлось модернизировать. На встрече, описанной выше, как раз делался акцент на вопросы про “улучшения работы с таблицей”, чтобы там было удобно работать как аналитикам, так и тестировщикам.

Поэтому в таблице появился еще и Ответственный тестировщик.

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

Поэтому мы обсудили и пришли к соглашению добавить в таблицу различные статусы: «Ревью кейсов», «Доработка», «Вопросы к ФТ».

Самым важным, на мой взгляд, решением было перенести архитектуру хранения требований в архитектуру тест-кейсов [TestRail].

Во-первых, это ускорило работу поиска кейсов в testrail.

Во-вторых, мне, как человеку новому в этой сфере, позволило легче ориентироваться в написании кейсов.

Работа с Редизайном продолжается и по сей день, плавно двигаясь к намеченной цели.


3 месяц. Ответственный тестировщик

На 3 месяце работы тестировщиком я был назначен "Ответственным тестировщиком", основными обязанностями которого является:

  • приёмочное тестирование (которое проводится раз в неделю);
  • проверка ежедневных релизов;
  • выливка релиза на продакшн.

За все время работы тестировщиком эта задача была одной из самых сложных.

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

Был день, когда релиз не фиксировался - не срабатывали автотесты. Из-за этого я много бегал между разработчиками и devops'ами, и уже под вечер договаривался с проджектами на перенос релиза на следующий день.

Выливка произошла только утром.

Здесь я всецело проверил свои знания, уровень коммуникации с людьми и скорость работы.


Подведение итогов или продолжение следует:

Тут я должен описать какой-то сжатый текст по пройденным 3 месяцам...

Выражусь так: до начала работы в тестировании у меня не было полного понимания, что есть “Тестирование” и с чем его едят.

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

Тот опыт, который я получил за первые 3 месяца, это, конечно, только начальный уровень. Дальше можно развиваться либо внутри тестирования, либо выбрать смежные направления, такие как менеджмент, системная аналитика, безопасность, производительность, юзабилити.

Объем информации, который получаешь в процессе тестирования, неимоверно большой. Приходится постоянно чему-то учиться.

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

Тестирование позволяет полностью оценить продукт, исследовать его, сравнить поведение и в конечном счете — найти ошибки.

Моя же цель как тестировщика — повысить качество продукта путем непосредственного влияния на него. А если я могу влиять на продукт, то я могу влиять и на счастье конечного пользователя!