Как попасть в IT? История тестировщика из Superjob
Эта статья расскажет правду о том, как я, обычный специалист техподдержки, захотел стать тестировщиком, получил такую возможность, и что произошло со мной за первые три месяца работы на новой должности в SuperJob. Материал особенно будет полезен тем, кто мечтает развиваться и строить карьеру в IT.
От техпода до тестера-стажера
Проработав 4 года на должности техпода, в один прекрасный момент я принял решение, что нужно менять курс, и он увел меня в сферу IT. Считается, что самый легкий путь входа в IT лежит через тестирование.
И... это не так!
Как я представлял работу тестировщика: пиши проверки (типа вводится / не вводится, отображается / не отображается, правильно / неправильно, верно /неверно). Ведь я уже четыре года занимаюсь подобным: проверяю все ситуации, которые попадаются, и если не работает — завожу задачу, описываю её и отдаю в тестирование.
В первые же дни работы, получив первые задачи, мне открылась истинная картина, которая включала в работу тестировщика множество других нюансов. Надо отметить еще тот факт, что на мое решение идти в тестирование повлияла задача по проверке редизайна соискателей, который проводился у нас в прошлом году. Задание было такое: пройтись по кейсам, отметить, всё ли там “ок”. И тогда мне это просто понравилось.
Я предложил свою кандидатуру в наш отдел тестирования. Была организована встреча, по итогам которой я был принят на должность тестировщика-стажера.
И первый месяц дал понять, что легко не будет )
1 месяц. “Сразу в бой”.
Как только я получил своё новое рабочее место и был введен в курс дела, поступила крупная задача на новые «Максимальные тарифы».
Часть полноценного тестирования оказалась для меня новой стеной, которую нужно было преодолеть, при этом применить знания продукта я мог без особых сложностей.
Писать тест-кейсы не было времени, так как уже был сделан анонс новых тарифов и обозначены конкретные сроки. Поэтому было принято решение использовать чек-лист. Я мог на основе своих знаний продукта сделать более плотное покрытие, а опытный тестировщик мог сделать ревью, исходя из своих знаний тестирования.
Мозговой штурм
Написали большое количество проверок под новый функционал, рассматривали все возможные и невозможные варианты, где могла быть хоть какая-то взаимосвязь с новыми тарифами.
По чек-листу после мозго-штурма решено было дополнительно проставить приоритеты к проверкам. Из-за ограничений по времени решили проверить первоначально кейсы с высоким приоритетом, после чего уже можно было выкатывать фичу, а дальше спокойно допроверять с минимальным приоритетом.
[Пример]
Была собрана статистика по самым используемым тарифам + город + количество месяцев. Исходя из этих данных, мы сделали выжимку кейсов и покрыли минимальным количеством кейсов те параметры, которые используют максимальное количество пользователей.
Подготовка к тестированию у меня заняла целый день + на само тестирование ушёл еще один. Новые тарифные планы были проверены, и задача пошла в релиз. По итогам в задаче не было выявлено ни одного бага важного приоритета. От внутренних пользователей (менеджеров) была найдена всего пара ошибок низкого приоритета.
Мы же оценивали проделанную работу и анализировали, насколько успешно было проведено тестирование, что можно улучшить в дальнейшем.
[Пример]
Написание чек-листа происходило одновременно двумя тестировщиками, что создало лишние действия и обсуждения. Приняли решение в дальнейшем сразу разделять активности по задачам: один пишет чек-лист, другой проверяет и дополняет.
К концу первого месяца я стал больше понимать процессы, происходящие в тестировании, осознал, насколько плотно оно связано с разработкой и бизнесом.
Проводились встречи с руководителем отдела, оговаривались мои зоны развития и дополнительные знания, которые необходимы для полноценной работы тестировщиком.
К середине первого месяца моей работы пришел… редизайн.
2 месяц. Редизайн.
Любые изменения помогают смотреть на привычные вещи под другим углом.
В моём случае это был редизайн, который затрагивал не только Frontend (визуальные изменения наподобие цвета иконок и расположения элементов), но и Backend.
Back коварен, так как затрагивает весь функционал, который может не только отвалиться, но и вести себя вызывающе :)
У нас, как у тестировщиков, были две большие задачи:
- дать оценку на тестирование и…
- покрыть все требования кейсами для прозрачности.
В этом процессе я плотно познакомился с Функциональными требованиями (далее “ФТ”), Макетами и Данными.
По макетам сделали отдельный чек-лист, т.к. проверки, связанные с ФТ, не затрагивают расположение кнопок, последовательность, их цвет, тени и пр.
Встречи
Еще одним нововведением в моей работе были встречи.
Они были разные: плановые еженедельные, внеплановые, по обучению, по работе с другими отделами и пр., и все это происходило на регулярной основе.
На еженедельной плановой встрече каждый тестировщик рассказывал, что было сделано за прошлую неделю. Это позволяло быть в курсе всех изменений, а мне, как человеку новому, позволяло получить новые знания о работе и процессах.
Что касается встреч по редизайну, было принято решение, что для ускорения процесса выпуска редизайна необходимо начинать тестирование с этапа готовности ФТ. Тестировщик, создавая кейс, может в любой момент узнать у аналитика, что имелось ввиду по определенному пункту ФТ.
[ Более детально это описано в статье – «Покрытие требований кейсами. Реалии компании Superjob» ]
Не весь функционал является тривиальным, некоторые моменты в шагах имеют неочевидную логику, поэтому аналитик, в свою очередь, мог задавать уточняющие вопросы тестировщикам, если данных было недостаточно или они отсутствовали вовсе.
Я же мог передавать свои знания продукта и ускорять тем самым процесс разработки.
Таблица
Готовые требования от аналитиков отправлялись к нам на ревью. Следить за этапами состояния ФТ мы могли через google docs в таблице аналитиков.
Поначалу таблица имела минимальное описание: Ответственного аналитика и Ссылку на ФТ.
Ее пришлось модернизировать. На встрече, описанной выше, как раз делался акцент на вопросы про “улучшения работы с таблицей”, чтобы там было удобно работать как аналитикам, так и тестировщикам.
Поэтому в таблице появился еще и Ответственный тестировщик.
В процессе работы возникали уточняющие вопросы по ФТ, которые нужно было фиксировать. Комментарии по этим вопросам были большие и читать их неудобно. Или же аналитик вносил какие-то изменения, а я, как тестировщик, мог об этом не знать.
Поэтому мы обсудили и пришли к соглашению добавить в таблицу различные статусы: «Ревью кейсов», «Доработка», «Вопросы к ФТ».
Самым важным, на мой взгляд, решением было перенести архитектуру хранения требований в архитектуру тест-кейсов [TestRail].
Во-первых, это ускорило работу поиска кейсов в testrail.
Во-вторых, мне, как человеку новому в этой сфере, позволило легче ориентироваться в написании кейсов.
Работа с Редизайном продолжается и по сей день, плавно двигаясь к намеченной цели.
3 месяц. Ответственный тестировщик
На 3 месяце работы тестировщиком я был назначен "Ответственным тестировщиком", основными обязанностями которого является:
- приёмочное тестирование (которое проводится раз в неделю);
- проверка ежедневных релизов;
- выливка релиза на продакшн.
За все время работы тестировщиком эта задача была одной из самых сложных.
Большая завязка на работе системы: релиз должен вначале зафиксироваться, а пока этого не произойдет, проверять будет нечего. А задач на проверку может быть очень много или одна единственная, но крупная, которая не может быть отложена.
Был день, когда релиз не фиксировался - не срабатывали автотесты. Из-за этого я много бегал между разработчиками и devops'ами, и уже под вечер договаривался с проджектами на перенос релиза на следующий день.
Выливка произошла только утром.
Здесь я всецело проверил свои знания, уровень коммуникации с людьми и скорость работы.
Подведение итогов или продолжение следует:
Тут я должен описать какой-то сжатый текст по пройденным 3 месяцам...
Выражусь так: до начала работы в тестировании у меня не было полного понимания, что есть “Тестирование” и с чем его едят.
Для меня переход в тестирование — это в первую очередь выход из зоны комфорта. Каждый новый день — это новые задачи, новые знания, которые могут дать понять, как работать с тем или иным случаем.
Тот опыт, который я получил за первые 3 месяца, это, конечно, только начальный уровень. Дальше можно развиваться либо внутри тестирования, либо выбрать смежные направления, такие как менеджмент, системная аналитика, безопасность, производительность, юзабилити.
Объем информации, который получаешь в процессе тестирования, неимоверно большой. Приходится постоянно чему-то учиться.
Очень важный момент: прочитав книги, статьи, просмотрев видео, нужно сразу же эти данные применять, практиковаться и использовать их повсеместно.
Тестирование позволяет полностью оценить продукт, исследовать его, сравнить поведение и в конечном счете — найти ошибки.
Моя же цель как тестировщика — повысить качество продукта путем непосредственного влияния на него. А если я могу влиять на продукт, то я могу влиять и на счастье конечного пользователя!
