%202.svg)
.svg)
.svg)
.svg)
.svg){kind=icon}
.svg)
.svg)
.svg)
.png)
.png)
.png)
.svg)
Мы точно знаем, что делаем. Программа Профессия Инженер по тестированию создана ведущими EdTech-компаниями, лидерами рынка онлайн-образования. — GeekBrains, Skillbox
.png)
%402x.png)
Привет! Меня зовут Илья, и с сентября 2013 года я занимаюсь ручным тестированием. Сейчас работаю ведущим тестировщиком в Bell Integrator. В этой статье я расскажу, как начать карьеру в сфере QA, чем высокооплачиваемый тестировщик отличается от обычного и как прокачаться, чтобы тебя ценили. Главным образом буду говорить о ручном тестировании, но затрону и автоматизированное.
Я получил диплом экономиста, пару лет поработал по специальности — и понял, что заниматься этим я себя заставляю. Ушёл. Около года провёл в продажах и параллельно искал, чем заниматься дальше. И вот однажды я вспомнил кое-какую статью про тестирование и разговор со знакомым, который тестировал телефоны Motorola.
В порядке эксперимента я обновил резюме на hh.ru — сменил желаемую должность на «тестировщик». В тот же день получил приглашение на собеседование и совет, что подучить. Основное — виды и уровни тестирования, реляционные базы данных и классы эквивалентности (одна из техник тест-дизайна). Я вбил это в поисковик и попал на сайт protesting.ru. Информация там структурирована и хорошо изложена. Почитал, вник.
На следующий день я успешно прошёл собеседование в компанию с броским названием S&T International. Так начался мой путь в тестирование и IT в целом. Но не всё так просто. Получить работу — ещё не значит стать крутым специалистом. Поэтому самое интересное началось дальше.
Основная задача тестировщика — дать актуальную информацию о качестве продукта. Это правильный ответ на один из главных вопросов собеседования :)
Проверять качество ПО помогают специальные инструкции — тест-кейсы. В них подробно описан каждый шаг и ожидаемый результат. Тестирование по кейсу — работа, которую часто доверяют джуниорам, особенно на крупных проектах.
Чем быстрее ты работаешь и чем лучше понимаешь, в какой последовательности проходить тесты, тем больше тебя ценят.
Чтобы получать высокую зарплату, надо знать теорию тестирования, техники тест-дизайна, терминологию, SQL-запросы. Очень важно представлять себе сферу деятельности компании. Главные заказчики IT-услуг сейчас — банки, страховые фирмы и телеком. Идёшь работать в банк? Подучи банковские термины. А если собираешься тестировать оборудование для нефтегазового сектора, на одной теории далеко не уедешь. Придётся изучать «железо».
Кроме того, нормальный тестировщик умеет пользоваться командной строкой, понимает, что такое клиент-серверная архитектура и реляционные базы данных, зачем нужен XML и какую роль он играет в работе ПО.
Крупные интеграторы любят гонять кандидатов по теории и терминам. Это у них как сито. Чем больше правильных ответов, тем выше твой балл и зарплата, на которую ты можешь претендовать.
Но иногда простые вопросы могут поставить в тупик даже опытного пользователя. Например, какие поля обязательны при заведении бага. Новичку нет смысла такое заучивать — он работает в баг-трекере, где обязательные поля проверяются автоматически. Пока не заполнишь — данные не отправишь. А опытный тестировщик, который всё это вносит уже не глядя, может зависнуть — как автослесарь, которого спросили, что такое машина.
Чтобы войти в профессию, мне хватило материалов с protesting. А в более продвинутых темах я разобрался, обучаясь в GeekBrains по профессии «Тестировщик ПО». Например, освоил более сложные техники тест-дизайна, чем классы эквивалентности. Эти знания пригодились.
Приведу пример «до» и «после». На телефонном собеседовании в крупном банке меня спросили, какие техники тест-дизайна я знаю. Ответ их не устроил, но мне дали ссылку на тест, где надо было набрать от 65% правильных ответов. Увы, в тот раз мне даже поисковик не помог — настолько хитро были поставлены вопросы. А вот после курсов этот же тест на другом собеседовании я уже прошёл и получил предложения от нескольких отделов того же банка. Правда, всё равно к ним не пошёл — отпугнули бюрократией. Но это другая история.
Ясное дело, одной теории мало. Опытный интервьюер спросит, как работает техника на практике и почему в данной ситуации ты предлагаешь именно её. Кроме того, важно уметь пользоваться специализированным ПО. Возможно, кто-нибудь оценит твою обучаемость и поверит, что ты быстро освоишь новые инструменты, но чаще работодатель ищет готового специалиста.
В банке мне дали схему XML-сообщения в виде таблицы с описанием полей и указанием, обязательны ли они. Нужно было проверить все варианты отправки сообщения.
В крупной розничной сети предложили более масштабное задание. Показали схему работы кассового складского оборудования и тестовую БД. Требовалось установить СУБД Firebird, написать несколько SQL-запросов для формирования выборки и составить тестовую модель по схеме работы.
Но обычно на собеседованиях рисуют упрощённую схему и просят описать, как ты будешь это тестировать. Могут предложить нештатную ситуацию: «Не успеваем всё протестировать, но сроки сдачи переносить нельзя». Или: «За день до релиза обнаружены критические баги. Можно ли выходить в продакшен?». На первый вопрос единственного правильного ответа нет, а на второй — «Нельзя».
Другой пример — задание на автотестирование от разработчика ПО. Надо написать на Python класс Deposits, который парсит страничку www.banki.ru и собирает информацию из блока «Предложения месяца > Вклады». Результат должен выглядеть как таблица, где напротив названий вкладов — проценты. Дополнительно просят реализовать дочерний класс, который наследуется от Deposits и подбирает наиболее и наименее выгодный вклад.
Самое обстоятельное собеседование было в HeadHunter. Начали с большого предварительного интервью. Спрашивали, почему занимаюсь тестированием и каким проектом горжусь. Просили рассказать о самом интересном (!) случае из практики, а ещё — в чём состоит тестирование, что такое качество, какой у меня опыт автоматизации, какие пять команд Linux я чаще всего использую в работе. Ещё просили назвать две-три книги или статьи по тестированию и программированию, а затем рассказать, что я из них вынес. На очном собеседовании давали тесты по SQL-запросам и командам Linux.
Кстати, когда вас спросят, какие книги по тестированию вы прочли, рекомендую назвать «Быстрое тестирование» (Калбертсон, Браун, Кобб) и «Тестирование DOT COM» Романа Савина. Чтобы понимать, о чём речь, прочтите хотя бы вступление к каждой из этих книг, а лучше — первую главу :)
Есть несколько уровней мастерства тестировщика.
Джуниор. Ты проходишь подробные тесты, составленные кем-то другим. Задумываешься, на чём они основаны, и внезапно открываешь для себя существование документации. Отныне ориентируйся на неё! Даже если тест-кейс ей противоречит.
Тестировщик. Ты тестируешь программу по документации и ориентируешься на описание функциональности. Тест-дизайнеры как отдельные работники — редкость, поэтому ты сам придумываешь, как протестировать приложение, чтобы отловить все возможные ошибки. Сам пишешь подробный план тестирования и тест-кейсы. Дальше группируешь тест-кейсы логически и раздаёшь джуниорам. Это уровень старшего и ведущего тестировщика.
Исследователь. Самый сложный уровень — exploratory testing. Нет ни тестовой модели, ни подробной документации (в лучшем случае — список задач для разработчиков). Задача — найти все баги ПО. Тут придётся включить фантазию и моделировать работу конечного пользователя. Да не простого, а пользователя-ломателя.
Иногда ты будешь сталкиваться с трудностями тестирования в ограниченной среде. Придётся проверять, как работает твоя программа при получении сообщений из другой системы, к которой у тебя нет доступа. Можно координироваться с коллегами из других систем либо справляться самому. Во втором случае надо уметь пользоваться вспомогательным ПО типа SoapUI и Postman.
Но прежде всего надо разобраться:
Полезно уметь подключаться к серверу или удалённой машине с помощью программ типа WinSCP. Но они только показывают файлы (в том числе логи), а для отправки команд серверу понадобится изучить ещё и Putty либо аналог.
Плюс надо понимать, что такое командная строка, и знать основные команды Linux. Открою секрет: на первых порах можно ограничиться пятью командами, но их придётся запомнить.
Перефразируем дядю Паркера: «Большая зарплата влечёт большую ответственность» :) В самом начале карьеры, когда что-то не работает, можно поднять лапки и закричать «караул!». Мол, это вопрос не на мою зарплату. Но это плохой способ.
Если хочешь профессионального и зарплатного роста, учись определять, на чьей стороне проблема. Вызвана ошибка сбоем в работе программы или дело в забитом кеше, зависшем сервере, связанном приложении? Порой надо банально проверить соединение с интернетом.
Если «ничего не работает», надо понять, что не работает в первую очередь. И знать, кому звонить и писать, куда бежать с этими неполадками. Я всегда держу под рукой список фамилий и контактов по зонам ответственности.
Важно уметь отвечать на вопросы. Это особенно пригодится, когда придётся вводить в курс дела новичков или подрядчиков-аутсорсеров. А ещё — на презентациях для представителей бизнеса, которые вы наверняка будете проводить (или как минимум в них участвовать).
Профессиональный рост бывает вертикальным и горизонтальным.
Для вертикального роста надо развивать административные и управленческие навыки, но и про техническую часть не забывать. Пусть ты уже не ловишь баги лично, но как руководитель должен понимать, кому передать задачу и как распознать обман, когда подчинённые говорят: «Сделали всё, что могли, но это надо тестировать четыре дня».
Горизонтальный рост требует выбора. Если ты хочешь развиваться в ручном тестировании, надо глубоко вникнуть в устройство системы и работу программы. Освой все инструменты ручного тестирования — не зацикливайся на одном. Дальше на этом пути возможен рост до аналитика.
Второй вариант — изучить программирование и идти в автоматизацию. Правда, уже есть ПО, где автотесты можно делать без кода. Но привычка решать всё нажатием кнопки снижает потолок развития специалиста. В непонятной ситуации придётся бежать за помощью к тому, кто знает и понимает больше.
В автоматизированном тестировании свой инструментарий, но для успешного роста надо разбираться в системе и архитектуре не хуже «ручника». В дальнейшем с этой дорожки можно свернуть в разработку.
Помимо автоматизации есть ещё нагрузочное тестирование. Тут тоже надо быть немного программистом (писать скрипты) и аналитиком — уметь анализировать результаты.
Третий путь — совместить предыдущие варианты и стать универсальным специалистом. Для этого необходимо подтянуть навыки программиста и аналитика.
Я хочу попробовать себя в Data Science. Тут очень пригодится школьный и университетский курс математики и статистики.
Некоторые руководители ошибочно полагают, что тестировщик — это личинка программиста или аналитика. Они с недоверием относятся к сотруднику, который «застрял» в тестировщиках. Но всем не угодишь. Тут к месту вспомнить басню про мальчика, мельника, осла и общественное мнение.
Мне запомнилась статья, где сказано, что хороший тестировщик «обладает ломательной психологией» :) Ещё говорят, что он должен понять то, чего не понял разработчик. Лично я считаю, отличие здесь — в направлении внимания к продукту. Разработчик глубоко знает узкую тему, а тестировщик меньше роет вглубь, но смотрит шире.
Ведущий или главный тестировщик представляет, как работает система в целом и как взаимодействуют её компоненты. В этом он похож на архитектора и системного аналитика. Но архитектор знает технические особенности на уровне разработчика и лучше, а аналитик составляет документацию и доносит до разработки требования заказчика.
Очень важное для тестировщика качество — твёрдость характера. В спорах с разработчиками и начальством часто приходится настаивать на своём. Коллеги могут быть недовольны — но если уступить, крайним при проблемах в промышленной эксплуатации всегда будет тестировщик! Об этом стоит помнить.
Как всякий айтишник, тестировщик должен быть любознательным и дотошным, ведь ему предстоит всю жизнь учиться. Немного перфекционизма не повредит.
Привет! Меня зовут Альберт. До недавнего времени я работал руководителем сервисного центра по продаже и ремонту грузовых автомобилей в Астрахани. Начинал с должности простого автомеханика, после был автоэлектриком-диагностом и лишь потом перешёл в административную сферу.
Любовь к автомобилям была не единственной. В юношестве я увлекался 3ds Max и предпринимал робкие попытки освоить Turbo Pascal. В общем, как и многие мальчишки, всячески стремился к компьютерам. Набранных на ЕГЭ баллов хватало для того, чтобы пойти в любую сферу, но, выбирая между ИТ и автомобилями, я выбрал последний вариант.
Позднее, занимаясь диагностикой, я получал огромное удовольствие, разбираясь в электрических гидравлических и пневматических узлах, изучая схемы, устанавливая закономерности и находя причину неисправности. Можно сказать, это был первый опыт тестирования. Но, если честно, тогда было гораздо сложнее.
После пары лет в должности руководителя я начал понимать, что достиг потолка в профессии, во всяком случае, в своём регионе. Небольшая клиентская база была завоёвана на 70-80 %. Прибыльность регионального подразделения, которым я руководил, перестала расти. Выхода было два: менять профессию либо город.
Конечно, я сразу подумал про IT. Во-первых, это рынок, который растёт огромными шагами и за последние 10-20 лет изменил жизнь каждого человека на земле. Во-вторых, это иной уровень зарплат, задач, отсутствие как такового потолка развития. На обратной чаше весов было упущенное время и ощущение, что отсутствие профессионального образования, неподходящий опыт работы и возраст создадут огромные сложности в штурме новой карьеры.
К счастью, сейчас почти у каждого человека есть друг из IT, у которого можно спросить совет. Мой рассказал мне о профессии тестировщика. С его слов, в этой сфере менее высокий порог входа в IT, нежели в разработку. Он уверил меня, что устроиться в тестирование реально при должном упорстве. Оставалось лишь углубиться в предметную область, почитать литературу, пройти какие-нибудь курсы.
Моим проводником в QA была книга Романа Савина «Тестирование дот ком». Сразу после этого записался на курсы GeekBrains.
Само обучение не было сложным. Во всяком случае для меня. Впрочем, с одной поправкой — я не сдавал и половину домашних заданий. Причина была не в сложности или лени, просто это занимало много времени. Основная работа, семья… всё это мешало качественно делать домашки. В остальном наполнение курсов являлось достаточным и даже более для старта в реальном проекте. Дополнительную информацию я искал лишь для лучшей усваиваемости и расширения зоны внимания. В частности, изучал языки веба.
Образование — это не развлекательный процесс, он требует усилий и концентрации. Кроме того, заплаченные деньги лишний раз мотивируют на то, чтобы довести дело до конца.
Буквально с первых уроков я находил аналогии между тестированием в IT с текущей работой в автосервисе. Уже знакомые алгоритмы поиска неисправностей помогали находить баги в ПО. И наоборот — хотя европейские бренды грузовой техники очень качественно относятся к описаниям бизнес-процессов, именно алгоритмы и методы, изученные на курсах, помогли мне полноценно понять теорию обеспечения качества на производстве. Например, мне удалось внедрить в автосервисе подробное пошаговое описание «кейса» неисправности автомобиля, которое заносит мастер-приёмщик при приёмке в заказ-наряд.
Я хотел бы сказать, что сразу после окончания курсов нашёл новую работу, но в реальной жизни, как вы знаете, такое бывает редко. Ещё 14 месяцев на старом месте я слушал «обещания» руководства — как правило, беспочвенные. Но вместе с тем было невероятно сложно бросить предприятие в которое было вложено столько сил и времени.
В общем, я взялся за рассылку резюме: откликнулся на 4 вакансии на hh.ru. Сразу же получил один отказ, ещё две компании отвергли меня без лишних слов позже, а вот из четвёртой пришло задание. Для меня это уже был успех. Когда же я прошёл онлайн-собеседование, выполнил ещё одно домашнее задание и получил приглашение на финальный этап, казалось, что новая карьера вот-вот начнётся. Но нет. Два с половиной часа общения с тимлидами прошли безрезультатно. С одной стороны — сразу огромный опыт, с другой — упадническое настроение.
Но спасибо родным, поддержавшим меня в тот период. Они не дали повесить нос и поставить крест на карьере в IT. Я взял отпуск на работе и поехал в Москву, для нового поиска. Теперь поменял тактику – откликался буквально на все вакансии тестировщиков, где «опыт» не был обязательным пунктом. Каждый день выходили новые вакансии, и я снова на них откликался. Обзванивал их, если не получал ответа. Мотивацию черпал в основном на YouTube, особенно хочу отметить канал АйТи Борода — с точки зрения психологии и профессии почерпнул для себя много нового.
В общей сложности я откликнулся и позвонил в 50 IT-компаний за 5 дней.
Но ни одна из них не прислала мне даже приглашение на интервью: лишь около 20 отказов.
Параллельно искал место по текущей профессии и даже получил два оффера от сервисных центров. Но никакого желания работать здесь у меня не было. С таким «уловом» поехал домой. Но на обратном пути в Астрахань у меня раздался звонок из одной IT-компании с приглашением на собеседование, а через несколько дней – ещё один. Моей радости не было предела!
В следующие же выходные я поехал в Москву. Меня собеседовал руководитель отдела разработки компании ООО «Альтаир». Спрашивал о том, что уже приходилось делать в рамках стажировки на курсе, плюс общие вопросы на понимание работы компьютера и сетей. Через 3 дня я получил оффер. Как говорится, профит.
Что я могу сказать про новую профессию? Первые дни выдались очень напряжёнными. Казалось, что я понимаю лишь процентов десять задач. Даже приходилось на каждой планёрке вести конспекты, весь сленг гуглить или разъяснять у новых коллег. Но уже через неделю я освоился и начал приносить пользу команде. Очень повезло, что меня распределили на новый проект в молодой коллектив. Это помогло меньше комплексовать по поводу своего опыта, быстрее найти язык с коллегами и с головой уйти в работу.
Что касается зарплаты, то с учётом аренды жилья в Москве я даже немного проиграл, но это неудивительно, ведь это только начало пути, где есть огромные горизонты для роста. А на прежнем месте при соизмеримых деньгах расти было уже некуда. Ну и, конечно, здесь чище, теплее, куда меньше проблем в общении с клиентами (пока вообще нет) и интереснее.
Несмотря на то что в QA-сфере я недавно, уже в ближайших планах есть изучение одного из популярных языков программирования на хорошем уровне для тестирования по методу белого ящика. А дальше — кто знает? Возраст, образование и опыт в другой сфере не будут мне помехой — теперь я это знаю точно.
Привет! Меня зовут Сергей, я из Саратова. У меня среднее техническое образование по специальности «менеджер по отраслям». После учёбы я работал водителем — развозил людей на автобусе по городу. Потом доставлял грузы в транспортной компании «Энергия».
Там я проработал где-то полгода и понял, что расти просто некуда. Ну кем я стану? Старшим водителем? И чего я в жизни добьюсь? Попробовать себя в тестировании посоветовала знакомая, которая окончила курсы и успешно устроилась на работу. Ну и друзья говорили, что у меня хорошо с компьютером — попробуй.
Сначала я пытался самостоятельно обучаться по каким-то видеоурокам, форумам, литературе в интернете. Но было очень тяжело, ведь не было наставника — никто не мог объяснить, что нужно делать, как должно получиться и как не должно.
В 2018 году случайно наткнулся на GeekBrains. Заинтересовало! Купил курс по тестированию ПО в рассрочку через банк, а чтобы оплачивать учёбу продолжал работать водителем.
Проблема во время обучения была одна — той зимой в Саратове выпало очень много снега. Дороги не чистили и были огромные пробки. В этот судьбоносный период я выходил из дома где-то в 6 утра, а заканчивал работу примерно в 11 вечера. Ещё где-то час искал, как выехать с места работы, потому что туда, где я живу, было проблематично доехать. И так с понедельника по субботу.
Домой приходил после часу ночи, смотрел прошедший вебинар (благо это получалось хоть через 2-3 дня), делал домашку. Иногда даже удавалось попадать на онлайн-трансляцию, но так везло очень редко.
В остальном никаких проблем не было. Во время обучения радовало обилие примеров, живого опыта. Очень понравился преподаватель Алексей Соколов — я у него и первый уровень прошёл, и второй. А наставником у меня был Сергей Смирнов — он мне помог с первыми шагами на сайте, когда-то я сам не понимал, куда направиться.
Между уровнями у нас была интересная стажировка на Недвижимость Mail.ru — искали баги, отклонения. Во время практики возникала масса вопросов по терминологии — мы писали в чат, спрашивали, разбирались. Алексей всё простыми словами объяснял. Некоторые студенты задавали углублённые вопросы, но новичкам тоже было понятно и интересно. Ответы получали все, главное было — не стесняться.
Незадолго до окончания учёбы я начал искать удалённую стажировку, потому что в Саратове тестировщику без опыта работы очень сложно трудоустроиться. Нужно минимум высшее техническое образование, которое я, кстати, планирую получить чуть позже.
В разделе «Карьера» на GeekBrains я наткнулся на стажировку в онлайн-школе «Тетрика». Честно признаюсь, основным критерием выбора было минимальное количество требований. Отправил туда резюме и всё сложилось. Стажировался октябрь и ноябрь. С декабря 2019 года уже полноценно там работаю. И отлично! Из минусов — зарплата пока минимальная.
Включаться в проект было сложно. Приходилось искать терминологию в интернете, либо у разработчиков спрашивать. Самое трудное было — понять принцип, ожидаемый результат на какие-то определённое действия. Ещё из-за того, что никогда не работал удалённо, было сложновато распределить свой день. А в остальном — ничего такого.
Кстати, всего я откликнулся минимум на 100 вакансий. У меня не было времени сидеть и ждать ответ от одного работодателя. Как мне правильно сказал один умный человек: «Поиск работы — тоже работа».
Близкие до сих пор не понимают, чем я занимаюсь. Старая школа — привыкли, что деньги зарабатывают руками. Отцу объяснял так: «Вот представь, открываешь ты молоко в тетрапаке, а у тебя крышечка оторвалась — это баг, то чего ты не ожидаешь от привычных вещей». А он мне: «Всё равно ничего не понимаю, не объясняй. Работается отлично — значит, всё хорошо! :)».
Для более подготовленной аудитории всё-таки расскажу, как проходит мой день. Если разработчики оставили какие-то сложные задачи в рабочем чате до начала рабочего дня (до 12 часов по Саратову), я тестирую и смотрю, что они выкатывают на бету. Потом выбираю задачи в трекере — стараюсь брать от одного разработчика, чтобы они были на одной ветке программного кода.
Потом проходит стендап-отчет по предыдущему дню: рассказываю, какие задачи закрыл, какие открыл. После отчёта разбираюсь с теми, которые взял. Если нахожу баги, то их перепроверяю и списываюсь с разработчиками. То есть не сразу «баг-репорт, быстрее, надо записать»! А контактирую с ответственными за задачу и уточняю у них ожидаемый результат. Заканчивается рабочий день тем, что тестирую ошибки, которые есть, перевожу их в другое состояние, либо закрываю задачу. И так с понедельника по пятницу.
Никогда не останавливайтесь! Никогда нельзя останавливаться на знаниях, которые дал один человек. Нужно обратиться ко второму, третьему, десятому источнику! Узнать, как считают другие, как они подходят к вопросу. К примеру, в одной книге пишут, что кто-то получил определённый результат с помощью таких шагов. А в другой — этот же результат можно получить десятью разными способами. Не надо слепо руководствоваться одним источником!
И главное — нужно понять, что ищешь в тестировании. Чего ждёшь, куда хочешь стремиться и зачем ты вообще сюда пришёл. Лично мне было интересно ломать программное обеспечение и ставить его в неудобное положение на негативных тестах.
Я для себя организовал «слоёный торт» по саморазвитию, которым занимаюсь в промежутках от основных дел. День — повышаю словарный запас, уровень своих знаний, прокачиваю скилы. То есть именно умственное обучение. Сейчас, например, читаю книги «Экстремальное тестирование для стартапов» и «Тысячеликий герой». Следующий день — физическая нагрузка. Можно, например, гири потягать.
По специальности сейчас изучаю логи для тестировщика, чтобы доступно показывать разработчикам, что я делаю для получения бага. В планах обучиться на автотестера, это хоть и сложнее, но интереснее. Здесь важно учитывать человеческий фактор, предусмотреть «защиту от дурака». Поэтому дальше возьмусь за REST API и Selenium — для автоматизированного тестирования.
Потом хочу перейти в разработку. То есть ставлю себе цель последовательно пройти такие шаги: использование ПО, автоматизированное тестирование, изучение языков программирования. Стоять на месте не буду!
