Привет, Habr! Меня зовут Екатерина, и я руковожу тестированием и непрерывно ищу новых специалистов в свою команду. По опыту работы в трех компаниях могу сказать: только 13% поиска превращается в реальных сотрудников. Не буду разбирать, как работает воронка подбора квалифицированных кадров в IT – это задача HR’ов – здесь мне хотелось бы рассказать о том, как крупные компании расширяют воронку за счет корпоративной интернатуры и постараться вдохновить тех, кто только планирует попробовать себя в этой профессии.
Технология поиска своего сотрудника в штат – как подбор одежды: вы не купите заведомо великий или тесный вам пиджак. Так же и в найме должно совпасть много факторов, чтобы кандидат встроился в команду и внес вклад в прибыльность проекта, а не наоборот. А потому преимущество кандидата без опыта – это его потенциал.
Готовность учиться
Исключительный профессионал и новичок развиваются по одной схеме, в так называемом цикле развития компетентности:
- Осознанная некомпетентность: понимают, чему следует научиться
- Осознанная компетентность: пробуют знание на практике, пока не добьются успеха
- Неосознанная компетентность: получают навык и доводят его до автоматизма
В сухом остатке гуру от новичка отличает количество завершенных циклов.
В IT-среде обучение – непрерывный процесс: появляются новые языки, технологии, инструменты, подходы и отмирают старые. Как говорила черная королева Л. Кэрролла, «нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее».
Увы, у сотрудников с опытом случается застревание в квадрате неосознанной некомпетентности – тот самый случай, когда человек освоил несколько методологий, научился пользоваться парой инструментов и решил, что знает достаточно для решения любой задачи. В свою очередь, кандидат без опыта находится в квадрате осознанной некомпетентности, понимает свое положение и готов вкладывать максимум усилий в освоение новой информации.
Нет «лишнего» опыта
Опыт каждого кандидата – уникальная комбинация знаний и навыков. Как я говорила ранее, каждый навык получен в результате сложной работы и безусловно должен быть оплачен. С другой стороны, проекты тоже уникальны и могут нуждаться лишь в части опыта кандидата. По формуле тройственной ограниченности обычно проект не желает платить за навыки, в которых не нуждается и обязан учитывать расходы на получение навыков, которых нет у потенциального сотрудника.
Кандидат без опыта – чистый лист, и все, чему он научится в компании, будет оправдано и оплачено.
Не накопилось «вредных» предустановок
В продолжение темы о проектной индивидуальности и треугольнике ограничений рассмотрю блок расходов подробнее. Процессы, технологии и инструменты всегда собраны из расчета целесообразности – если, конечно, проект окупаем.
Традиционно тестировщики объясняют свою профессиональную деятельность так: тесты должны быть написаны в TestLink, в формате тест-кейсов и специальный человек должен распределять, кто какие тесты будет выполнять, традиционные чек-листы в excel – это неправильно, а на этапе MVP-продукта во главе угла стоят простота и минимальные затраты.
Кандидат без опыта же не успел накопить предустановок, его надо вводить в должность с нуля и есть возможность ввести правильно.
Как стать тестировщиком
Оптимальным вариантом для начинающего тестировщика может стать корпоративная интернатура. После обучения, в отличии от школы, компания рассчитывает на долгосрочное сотрудничество, ожидает увидеть в потенциальном интерне реальный интерес к делу, подтвержденный действием. Ведь важно помнить, что выбор профессии – ответственная задача. Достаточно представить, во что превратится ваша жизнь, если каждый день вы будете укладывать рельсы, тогда как любите выращивать цветы.
В области тестирования не зря написано огромное количество литературы, которая, в свою очередь, усваивается лучше, если вы знаете, что ищете. Вот список, на мой взгляд, подходящих новичку вопросов:
- Что значит провести функциональное тестирование черным ящиком?
- Чем руководствоваться при выборе тестов, если время сильно ограничено и все протестировать не получится?
- Какую информацию следует приложить к дефекту, чтобы его воспроизвел кто угодно?
- Откуда, кроме требований к продукту, можно узнать «ожидаемый результат» поведения системы?
- Какой дефект вы посчитаете блокирующим?
- Какая информация и в какой форме должна запомниться после тестирования, что и в каких условиях бы вы протестировали, а что нет?
Перед прочтением заварите чашку чая, расслабьтесь, поразмышляйте, как звучат ответы. Осмыслили? Приступайте!
Если вы предпочитаете легкое чтиво, в качестве первой книги я рекомендую бестселлер Р. Савина "Тестирование DOT com". Если же вам проще разобраться в информации, когда она структурирована по полочкам, почитайте "Тестирование программного обеспечения. Базовый курс" С. Куликова.
Техническая часть
По крайней мере раз в месяц у меня случается диалог:
— Q: Что нужно, чтобы стать тестировщиком?
— I: Нужно знать теорию тестирования, обладать некоторыми навыками разработчика и администратора тоже, и еще многое другое.
— Q: Что же тут сложного?
— I: <длинная и вдохновенная тирада>.
Техническую осведомленность в тестировании нельзя переоценить, но, если нужно выбирать с чего начать, я бы отметила SQL. Базы данных есть практически во всех системах, реляционные превалируют. Хорошо знакомит с SQL А. Бьюли в книге "Изучаем SQL", а для выполнения упражнений потребуется накатить бекап с таблицами и данными. Для кого установка своей базы – пока слишком сложная задача, пройдите базовый онлайн-курс по SQL.
В целом же вам наверняка понадобятся все технические знания, что у вас уже есть. Задумайтесь: каким ПО вы пользуетесь, что умеете переустанавливать, настраивать, пользуетесь ли диспетчером задач, когда-либо прописывали ли переменные среды, настраивали себе домашнюю сеть или открывали DevTool в браузере. Выпишите все, что может быть полезным и актуализируйте свои знания.
Практическая часть
После теоретической и технической подготовки ваш естественный шаг – попробовать себя в роли тестировщика: проанализировать требования, решить, а потом описать что и как будете тестировать, выполнить тесты, передать дефект команде разработки, а также здраво оценить, что именно вам нравится в этой деятельности и почему.
Для этой задачи наилучшим образом подойдет краудсорсинговая платформа – например TestBirds (доступна на русском языке) или uTest (только на английском). Все что вам нужно -– это заполнить профиль, пройти несколько тестов и дождаться своего задания по тестированию.
В качестве альтернативного варианта предлагаю протестировать любимый сайт, игру или приложение на смартфоне: исследуйте продукт, определите, какую ценность представляет объект, какие задачи с его помощью можно решать. В качестве требований возьмите «Соглашение»/«Инструкцию пользователя»/FAQ: вам подойдет любая описательная информация о продукте. Более того, личный пользовательский опыт тоже подходит.
Ваша задача – выбрать одну функцию и изучить, как она работает в различных условиях, с разными данными, при разных настройках. Напишите на нее тест-кейсы, опишите все дефекты, которые найдете и попросите коллегу выполнить поставленную задачу. Повторил так, как было задумано? Отлично. Если же нет, скорректируйте документацию и передайте найденные дефекты в службу поддержки, приложите к описанию свое мнение о том, как дефекты влияют на работу функции. Приятная награда за проделанную работу – апгрейд любимого сервиса.
Заключение
Итак, вы получили начальные знания и уверенность в выборе профессии – теперь отразите свои достижения в резюме. Проделанная работа – ваше безусловное преимущество на собеседованиях, и вы можете трезво задуматься о карьере в той компании, где особенно хотите работать.
Небольшие компании нередко берут кандидатов без опыта в тестировщики, и в них представится возможность испытать все и сразу – возможно, построить тестирование с нуля. Крупные же компании, как правило, процессоориентированны с большим штатом специалистов по тестированию, внедряют на проектах зрелые процессы. Интернатура в них – это хороший способ войти в профессию без стресса, наращивать зону ответственности постепенно.
Если вы полностью определились, рекомендую два варианта поиска:
- Пассивный поиск: разместите свое резюме на всех известных работных сайтах
- Активный поиск: в большинстве ИТ-компаний есть портал, на котором подробно представлены проекты, и, конечно, вакансии. Исследуйте, что предлагают потенциальные работодатели и отправляйте свое резюме напрямую – так оно быстрее дойдет до адресата
Самым заинтересованным желаю удачи в самоопределении, и добро пожаловать в профессию!
TheGodfather
Я бы слово «функциональное» убрал отсюда. Никому и никогда в реальной жизни эти странные слова толком не пригождаются, а на некоторых собеседованиях прям заваливают вопросами типа «какие типы тестирования вы знаете \ чем отличаются тестирование Х от Y» — абсолютно бесполезные имхо. Какая, собственно, разница, UX ли или «функциональное», если в итоге вы один фиг сабмитите багу с описанием.
Или там мучают вопросами аля «расскажите про регрессионное тестирование» — да блин, любое тестирование после первого взгляда на фичу в некотором смысле регрессионное, вот не пофигу ли, как его называть.
KiyashevaEkaterina Автор
Доброго вечера. Мне жаль, что статья Вас огорчила, чем бы Вы заменили раздражающие термины?
Вообще любая терминология необходима для понимания друг друга. Если Ваша команда решила назвать регрессионное тестирование «охотой на бабочек» и все в точности понимают, что и в какой последовательности будут делать во время этой операции и какой результат получат, смело называйте его своим термином. Однако Вы сможете им пользоваться только внутри своей команды, другие тестировщики и команды Вас уже не поймут.
(Хорошим) Результатом тестирования я все же считаю не столько заведенные дефекты в тесте, сколько НЕ заведенные дефекты после выпуска релиза.
centroid
Слишком много теории. Мне кажется ту теорию которую спрашивают, особенно терминологическую, нужно знать только для прохождения собеседования, дальше она не работает.
Большинство трудовых задач решаются тем что их решают, независимо от того работал ли ранее с областью или нет. Главное, чтобы входило с специфику работ. А в тестировании, что там такого прям сложного.
Если человек смышленый, но не знает вашей терминологии, это помешает ему в работе настолько сильно, что он не справится от их неужели такого большого количества и сложности?
Эти определения описываются парами фраз. Большинство из них достаточно услышать один раз, а после показа первого реального теста где он оказывается именно таким, вообще не забываются.
Насколько я знаю, программистов берут на новую работу с новым специфичным языком для соискателя спокойно, в расчете на самообучение в процессе.
KiyashevaEkaterina Автор
Не знаю, какую теорию и как спрашивали на собеседованиях у Вас, возможно опрос действительно был избыточным. Лично я на собеседованиях акцентируюсь на опыте и навыках кандидата. В статье есть еще 2 части, кроме теоретической, но раз именно она вызывает резонанс давайте на ней остановимся
ну терминология все же не моя личная, и, как мне кажется, смышленный человек без труда осилит одну небольшую книгу ;)
Оглянитесь вокруг, все компьютеризировано — передвижения, связь, платежи, развлечения, медицина, оборонка — все сферы жизни пронизаны системами, среди них есть жизненно важные и бесконечно сложные, и каждая из них кем-то протестирована. Представьте, если тестирование будет не качественным хотя бы в половине случаев, Вы просто огорчитесь, если сломается любимая игрушка, ну а если упадет самолет? Так что не соглашусь, что тестирование — это просто. Цена ошибки может достигать миллионов рублей и человеческих жизней. Погуглите, сколько стоят самые дорогие баги
Теория — это база для будущих навыков, соглашусь, что заучивание терминов, пожалуй последнее, что нужно делать) Теорию нужно… «разобрать», тогда и термины Вы запомните без заучивания.
К примеру, под «фунциональным тестированием черным ящиком» лежат подходы к тест-дизайну с помощю которых Вы будете выполнять полезные тесты, и не тратить время на бесполезные. «Черноящичные» техники самые простые из всех существующих, поэтому стоит начать с них. Под «выбором тестов в ограниченных временных рамках» лежат подходы к приоритезации тестов, а это позволит Вам не выпускать в Prod блокирующие дефекты. Начните изучение и другие теоретические вопросы в списке окажутся не такими уж теоретическими и совсем не про термины
Am0ralist
Особенно эта мысль навязчиво крутится в голове, работая с медсистемами…
Более того, количество окружающих багов настолько велико, что даже не возникает желание писать о них разработчикам вне своей работы. В которой мои должности не содержали никогда названия «тестировщик» или «специалист по тестированию».
akryukov
Мне вот любопытно, а как конкретно вы представляете себе "большинство трудовых задач"?
Я не согласен с тем, что определения достаточно услышать один раз. Ниже в комментариях уже есть случай, когда человек не понимает смысла регрессионного тестирования, хотя наверняка слышал его определение.
Если определения такие простые, почему бы не запомнить их до устройства на работу, а не после?
TheGodfather
Ага, именно, вы все правильно говорите, что терминология просто хаос вокруг. Конкретно в этом случае я вроде написал — я бы просто убрал слово «функциональное», ибо оно не несет смысловой нагрузки, но при этом бросается в глаза. Из вашего же предложения, там есть слово «черный ящик» — вот оно, хоть и не менее бесполезное на практике, но является вполне себе устоявшимся и общеизвестным понятием в отрасли, по крайней мере, можно увидеть, в курсе ли человек, что вообще происходит вокруг.
А вот если меня спросят про «регрессионное» или «функциональное» тестирование на собеседовании — первые пару минут я совершенно осознанно порассказываю про хаос терминологий =) А на одном собесе так жесть была, когда собеседующие начали спорить и самоутверждаться, говоря, что я неправ (да, компания была русскоговорящая). Но зато стало понятно, куда идти не стоит. Для меня это скорее как красно-желтый флаг на собесе о компании — если говорят\спрашивают что-то про «функциональное»\«регрессионное» тестирование — что-то здесь не так.
И если, например, хаос в уровнях тестирования (юнит\интеграция\систем | маленькие\средние\большие) еще понятно, что употребляется время от времени в почти всех командах, и стоит смотреть на терминологию, то вот про «функциональное» все не так просто. За годы реальной работы мне не встречался, в общем-то, кейс, когда мы серьезно обсуждали эту терминологию просто потому, что она не нужна в реальной работе (обсуждали именно в контексте хаоса терминологии, не больше). Абсолютно ни разу за 7 лет работы в тестировании не нужны были слова ни «регрессионное», ни «функциональное», ни там «юзабилити» -тестирование. Ну т.е. конечно полезно понимать, что приложение-то можно проверить с разных сторон, но вроде как для смышленного человека это очевидно, о чем тут говорить-то.
Ну вообще оно и так некачественное, это видно, особенно если вы сами — тестировщик :D Еще скажите, что неправда?
UnhappyPanda
Не пофиг, хотя бы потому, что когда надо будет одним предложением описать текущий статус разработчику, какое тестирование тут было сделано, то сказать функциональное закончено, регрессионное сделано сделано на половину и надо еще столько-то времени, а нагрузочное еще не начинали и на него надо еще столько-то, то это как минимум намного быстрее и точнее, чем пытаться описать то же самое своими словами
TheGodfather
Вы сможете в двух словах описать грань между функциональным и регрессионным? В какой момент автотест на новую фичу переходит в категорию «регрессионных»? Откуда это будет знать разработчик?
Мои разработчики обычно заинтересованы в конкретных вещах, типа «я тут ПР на прошлой неделе залил, ты потестил?» или «есть проблемы в коде, который мы в препрод пушнули?». И ответы уровня «все ок», «вроде работает, но я ж вон десяток багов тебе повесил», «основная фича работает, сейчас смотрю в деталях, к вечеру закончу», «блин, руки не доходили посмотреть еще», «вообще все плохо, вон два Critical же висит» — более чем достаточные и понятные и мне и разработчику.
Но, конечно, если вы в вашей команде договорились, что у вас есть уровень тестирования «кошки», «бананы» и «крокодилы», то да, можно сказать «кошки ок, бананы в процессе, к крокодилам не приступал» и в рамках вашей конкретно команды это будет норм. Но быстро сломается, если вы попробуете говорить с другими человеками из других команд. И в этом случае разницы между «регрессионным», «интеграционным» и «кошками» нет никакой, ибо и те и другие от команды к команде могут отличаться целиком и полностью и требуют объяснений перед началом разговора, про какие же тесты вы говорите. А то ведь то, что у вас «интеграционное» у других называется «регрессионное», а у третьих «крокодилы». Без переводчика не обойтись.
UnhappyPanda
Если в двух словах, но функциональное тестирование — тестирование намеренно измененного или нового функционала. Регрессионное — тестирование на возможные проблемы в уже имеющемся прочем функционале. Разработчик прекрасно видит эту разницу хотя бы потому, что он знает, планировал ли он изменение конкретно в этом функционале, или это поменялось что-то другое где-то в другом месте, чего он не планировал.
TheGodfather
Ну грань-то где? На вопрос-то ответите? ;)
vlad_egrv
в момент когда фичу зарелизили и пофиксили пострелизные баги, и фича получила набор неизменных тестов которые рутинно прогоняются каждый последующий релиз.
UnhappyPanda
Я уже ответил выше. Новый относящийся к конкретной фиче функционал / прочий уже имеющийся функционал. Я не знаю, как утрировать еще больше и объяснить еще проще.
akryukov
Терминология нужна для нахождения общего языка.
Агрессивное пренебрежение общепринятыми терминами фактически значит, что вы не хотите находить общий язык со специалистами в своей сфере.
Если вы не хотите перенимать общий язык, то и в повседневной работе с вами тоже скорее всего будут конфликты на ровном месте.