![](https://habrastorage.org/webt/r-/g5/0z/r-g50z-uoybv7ktbwgdg0ykoiyo.jpeg)
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).
Поэтому сегодня всё реже можно полагаться исключительно на морально-волевые качества для входа в IT в свете возросших аппетитов рынка и обилия конференций, курсов, тренингов, литературы, статей и прочих информационных источников, которые находятся на расстоянии вытянутой руки начинающих специалистов.
Безусловно, всё больше компаний стараются выращивать специалистов у себя под крылом, осыпая счастливчиков новыми знаниями и навыками, заодно повышая лояльность к компании. Однако и в этом случае перед компаниями и их специалистами встают животрепещущие и острые вопросы…
Как не потеряться в многообразии информации, которой наполнен интернет и мир вокруг?
Что учить самим или чему учить своих бойцов?
В своей статье я постараюсь в общих чертах рассказать, что нужно знать и уметь, чтобы работать специалистом в области обеспечения качества в наиболее популярных и востребованных направлениях. Поехали!
Нижепредставленные специальности составляют преобладающую долю рынка спроса и предложения тестировщиков, а потому (и ввиду отсутствия достаточного и актуального опыта работы) в статье, увы, не будет разделов про perfomance и десктоп-специализации.
Материал для этой статьи базируется на собственном опыте работы с блестящими специалистами моих команд, на результатах преподавания в МГУ, МГТУ и онлайн-курса, а также на сотнях проведённых собеседований и десятках нанятых QA-специалистов разных профилей. Не претендую на исключительную правоту своего взгляда, однако считаю, что мой опыт позволяет моей точке зрения быть достаточно компетентной.
Черты характера
Было бы странно полагать, что с возросшими требованиями к техническим аспектам работы тестировщиков значимость личностных качеств уменьшилась или исчезла вовсе. Более того, я уверен, что черты характера лежат в основе успешного специалиста и имеют решающее значение при схожих знаниях и навыках. Ведь мы работаем не с human-интерфейсами к Stack Overflow и Википедии, а с живыми людьми, которые остаются таковыми и в офисе, и дома. Поэтому так важно учитывать качества личности в контексте предстоящего выбора отрасли, профессии и специальности в ней.
Почему я так считаю? Всё очень просто! Я легко могу отправить специалиста на курсы или конференцию, заказать книги или провести тренинги по нюансам тест-дизайна, языкам программирования, SQL, сетям и прочим техническим аспектам, чтобы через некоторое время получить первые результаты и в дальнейшем приумножать их, закрепляя полученную информацию на практике. Однако нельзя отправить на курс «Как перестать бегать за офисными плюшками и начать инвестировать в собственные знания», «Как перестать быть безответственным вруном и начать жить честно», «Как перестать быть серой мышью и стать увлечёным человеком», «Как перестать ненавидеть людей и научиться работать в команде» и рассчитывать на ощутимый результат после прослушивания. Увы, это правда жизни, внутреннее несогласие с которой позволяет широкому пласту «инфобизнесменов» зарабатывать на непокорных, жаждущих изменить свои фундаментальные столпы и черты характера единичным тренингом или серий онлайн-вебинаров. Именно поэтому так важно обладать на старте правильной жизненной мотивацией и качествами для работы в IT и в QA в частности. Итак, что же важно?
Мотивация учиться и склонность к самообучению
Честно ответьте себе на вопрос: нравится ли вам учиться? Не разово, а на постоянной основе. Готовы к единственному прыжку, который волшебным образом выведет вас «в дамки», или страстно желаете ежечасно и ежеминутно впитывать в себя новые знания? IT — это сфера, где достаточно неудачно моргнуть, и вы уже на обочине индустрии. Не стоит рассчитывать, что прочитав за год книгу по тестированию, вы раскроете для себя врата в дивный мир новых знаний, которые позволят вам быть в тренде на десятилетие вперёд. Идеально, если для учёбы вам не всегда нужен мудрый наставник и учитель и вы в состоянии самостоятельно усадить себя за новую книгу, вебинар или курсы.
Ответственность
Оцените свой уровень ответственности. Простой способ: озвучьте для начала сами себе несколько своих самых крупных ошибок в жизни. Не получается? Речь не о вашей безупречности, вспомните, что не ошибается только тот, кто ничего не делает. Вспомнили? Если только пару мелочей, то это грустный показатель. Хуже только, если вспомнив ошибки прошлого, вы тут же внутренне обвинили в них кого-то другого или обстоятельства, а не признали свою ответственность за произошедшее. А вот если вы вспомнили парочку крупных фейлов, где виноваты были именно вы, да ещё и вспомнили как их исправили, то дела с вашей ответственностью обстоят сильно лучше. Вышка — это когда вы не только исправили ошибку, но и застраховались от неё на будущее так, чтобы она не повторялась. Ответственный подход к работе — залог успешной карьеры в любой области, а потому и для тестировщика это крайне важная черта. Главное — не перегибать и знать меру, ведь гиперответственность — не всегда хорошо.
Увлечённость
Вы увлечённый человек? Вот честно, чем вы увлекаетесь? Ничем особенным? Или это много мелких хобби, которыми вы занимаетесь раз в год? Может, что-то большое, но времени постоянно не хватает, а потому хобби ждёт лучших времен. Человек остаётся человеком и в офисе, и когда выходит из него. И если человек действительно увлечён чем-то в обычной жизни, значит, и в работе его можно чем-то увлечь настолько, что он будет засиживаться вечерами или изучать вопрос на выходных по собственной инициативе. Задача грамотного руководителя и самого специалиста — найти такие задачи. Конечно, важно при этом доводить начатое до логического завершения и не бросать на полпути. Тестировщик не может быть «сухарём». А вот если он горит своей работой и продуктом, то результативность такого сотрудника будет выше.
Гибкость поведения
Важная черта для работы в современных IT-компаниях и в QA в частности — это гибкость. Новые знания и веяния приходят со скоростью ветров Юпитера, устоять в стиле Гендальфа Серого «Ты не пройдёшь!» перед индустрией крайне сложно и не всегда целесообразно. А потому довольно важно уметь подстраиваться под новые условия работы, будь то генеральная линия компании, новые продукты, команда, методологии работы или инструменты. Чем гибче сотрудник, тем больше шансов у него карьерно развиваться в IT.
Коммуникабельность и контактность
Без сомнений, можно быть успешным специалистом, будучи довольно замкнутым, но при этом глубоко погружённым в свою задачу, однако научиться чему-то новому и обучить окружающих больше шансов у общительного и контактного человека. Необязательно каждому быть великим оратором и публично выступать на мероприятиях, но важно уметь находить общий язык с коллегами, грамотно изъяснять свои мысли устно и письменно. В работе тестировщика это довольно важные черты, ведь общаться нужно много и часто, и чем больше вы про QA, тем глубже и детальнее вы погружаетесь в смежные сферы, где умение выстроить коммуникацию — половина успеха.
Командность
Тестировщику необходимо быть командным игроком. Неважно, работаете вы в сервисной модели тестирования или тестировщики интегрируются внутрь каждой команды. Очень важно, чтобы вы давали «чувство плеча» своей команде, чтобы они могли положиться на вас, а вы на них. Один в поле не воин — для тестировщиков это ещё и история про дальнейший рост в карьере. Ведь именно команда, как ваше ближайшее окружение, является первостепенным источником знаний, которые вы будете получать о продукте, процессах и технологиях. Если вы командный игрок, то в тестировании вы добьётесь бoльших успехов, чем одиночка.
Инициативность и решительность
Как известно, под лежачий камень вода не течёт, а потому инертность выйдет вам боком и в профессии тестировщика. Хороший тестировщик — проактивный, не ждёт пинка от коллег и руководителя, а сам приходит с новыми решениями и предложениями. Если тестировщику один раз сказали «это не баг, а фича», то он не должен опускать руки. Вместо этого надо брать инициативу и излагать свою точку зрения. Безусловно, не стоит впадать в крайности и спорить по любому поводу, но и соглашаться со всем, что скажут, не стоит. В основе работы хорошего тестировщика не только критическое мышление, подвергающее проверке на прочность окружающий мир, но и умение в нужный момент сформировать собственную позицию и отстоять её перед окружающими.
Этот список можно ещё продолжать и дополнять, я выделил ключевые черты на основе собственного опыта. Безусловно, речь не идёт о том, что если у вас нет этих качеств, то вы профнепригодны. Но можно с уверенностью утверждать, что чем меньше из заявленных качеств будет в вас, тем будет сложнее и вам самим, и вашей команде, и вашему руководителю. Любые исключения допускаются, что лишь подтверждает правило.
Основы тестирования
Нижеперечисленные знания и навыки нужны абсолютно любому тестировщику вне зависимости от его специализации. Эти вещи — основа основ, учатся быстро и легко, особенно если тут же закрепляются практикой. Настоятельно рекомендую всем без исключения начинающим специалистам погрузиться в заявленные ниже темы. Вооружившись этими знаниями, вы сможете открыть для себя бескрайний мир тестирования ПО, со временем освоив любое из направлений, но знания, заложенные в фундамент, останутся востребованными всегда.
Классификация видов тестирования
Даже начинающий тестировщик должен иметь базовые представления о различных видах тестирования, когда они используются и для чего. Это сухая теория, которая сама по себе не нужна, но без неё «класть поверх» практику может быть мучительно больно и долго, а попутно ещё и велосипедов выдумаете, да граблей известных соберёте. Не ленитесь, ознакомьтесь, благо источников уйма. Зато потом с лёгкостью сможете на собеседованиях проходить задачки уровня «протестируйте карандаш».
Локализация ошибок и багрепортинг
Мало ошибку найти. Крайне важно ошибку нужным образом локализовать, установив как можно больше обстоятельств и условий для её стабильного воспроизведения. Более того, необходимо обрести навык составления качественных баг-репортов. На своих лекциях и при работе с командой я часто использую следующее сравнение: «Ваш баг-репорт хороший в том случае, если вы вышли на улицу, взяли за руку первую попавшуюся бабушку, и она смогла воспроизвести дефект по вашему описанию или верифицировать его отсутствие».
Техники тест-дизайна
Базовые вещи, которые часто в том или ином виде проверяют на собеседованиях или в домашних заданиях, давая задачки уровня «протестируйте форму для ввода чисел» и «напишите автотесты на нашу форму авторизации». Важно не просто зазубрить, что такое «классы эквивалентности» или «анализ граничных значений», но и уметь использовать различные техники в любых условиях, комбинируя их.
Системы баг-трекинга, управления знаниями и тестами
Канули в небытие те времена, когда баг-репорты писали на листах, а тестовую документацию, чек-листы и тест-кейсы вели в гугл-доках (да-да, я знаю, что некоторые до сих пор пишут, и иногда это даже удобно). На смену этому самопалу пришли профессиональные инструменты — баг-трекинговые системы (из наиболее популярных стоит отметить Jira, Redmine), системы управления знаниями (Confluence, Wiki и другие) и системы управления тест-кейсами (TestRail, Zephyr, TestLink и т.д.). Базовые принципы работы с инструментами можно получить, вписываясь в открытые программы бета-тестирования или установив софт самостоятельно (на рынке есть как бесплатные решения, так и условно-бесплатные в масштабе ознакомительных сессий).
Методологии разработки ПО
Глубокого понимания методологий разработки ПО на начальных этапах тестировщику, может, и не потребуется, важно хотя бы на пальцах понимать отличия наиболее популярных (Waterfall, Scrum и Kanban). Но со временем ему придётся погружаться всё глубже и глубже в методологии, подбирая соответствующие подходы и техники при тестировании в контексте того или иного процесса разработки. Важно быть готовым к такому и уделять определённое внимание этой стороне вопроса.
Клиент-серверная архитектура
Большинство современного ПО строится на китах клиент-серверного взаимодействия. Тестировщику важно быть в контексте этой архитектуры, понимать принципы её работы, основные преимущества и недостатки. Это позволит не только лучше проводить испытания в ходе своей работы, но и при необходимости понимать, каким образом найденные дефекты нужно локализовывать, правильно определяя, на чьей они стороне.
Операционные системы
Принципы работы операционных систем, что они из себя представляют и какие вообще бывают — общие знания, которые, как правило, упрощают жизнь тестировщика. Даже понимание трендов замещения десктопных ОС мобильными, а также владение навыками работы с ОС на уровне пользователя уже плюс. А если погружаться в этот вопрос глубже, то со временем необходимо будет обзавестись навыками настройки и использования целой плеяды ОС (из самых популярных стоит отметить Android, Windows, iOS, macOS, Linux).
Клиентское тестирование веб-приложений
Один из наиболее простых и распространённых способов попасть в тестирование — начать тестировать веб-приложения. Эта специализация — одна из самых распространённых на рынке, однако ей на пятки вовсю наступает направление клиентского тестирования мобильных приложений. В любом случае нужно понимать, что такой вектор развития — один из наиболее доступных в самом начале карьеры. По этой тематике есть масса обучающих материалов и статей. При желании потом можно развиваться в любом другом направлении, чаще всего это автоматизация или всё те же мобильные устройства (например, после освоения тестирования веб-приложений под мобильные устройства).
Браузеры
В контексте клиентского тестирования веба важно понимать устройство тонких клиентов, браузеров в частности, а также их отличия, специфику рендеринга и работы скриптов, движков под капотом, версионности, дополнительного инструментария браузеров и т.д. Тестировщику важно всегда держать в голове популярность использования того или иного браузера у реальных пользователей продукта, чтобы распределять тесты наиболее эффективным способом. Самые популярные: Google Chrome, Safari, Firefox, Opera, Internet Explorer.
Консоль разработчика в браузере
Веб-тестировщик должен уметь пользоваться консолью разработчика в браузере (как минимум работать с элементами на странице и сетевыми запросами). В случае работы с элементами страницы тестировщик должен понимать, как локализовать их или при необходимости изменить, а в случае с сетевым взаимодействием — уметь разбираться в последовательности запросов и полученных ответов. В идеале нужно знать различные http-методы (GET, POST, OPTIONS и другие), знать коды ответов (10Х-50Х), уметь читать заголовки и тела ответов.
HTML, CSS, JavaScript
Чтобы тестировщик лучше понимал, из чего состоят и как устроены современные веб-страницы, будет крайне полезно иметь хотя бы базовое представление о HTML, CSS, JavaScript. Эти знания также помогут локализовывать ошибки, связанные с конкретными элементами на странице, быстро находить их и при необходимости менять на клиентской стороне.
Бэкенд-тестирование
Отдельная вселенная — это бэкенд-тестирование. Этот мир лишён рюшек и красивостей, в нём нет места графическим интерфейсам, только мерцающий курсор в консоли, горы текста и чистая логика приложений. Специфическое направление тестирования, которое не всегда легко даётся новичкам. Обычно требует более тщательной технической подготовки специалиста на старте.
Модель OSI
Базис, с которого стоит начинать бэкенд-тестировщику, — это модель OSI. Несмотря на то, что в большинстве случаев тестировщику вряд ли пригодятся уровни ниже прикладного и представительского, будет неплохо, если он будет понимать, где находятся эти уровни относительно других, в чём их специфика и как они применяются.
REST. SOAP. JSON-RPC
REST, как архитектурный стиль клиент-серверного взаимодействия, лежит в основе современного интернета. Понимание требований к REST-архитектуре должно быть в арсенале знаний бэкенд-тестировщиков, равно как и знания о стандартах, используемых в нём (HTTP, JSON, XML). В отдельно взятых направлениях не менее важным может оказаться знание протоколов SOAP (а вместе с ним XML, XSD, WSDL) и JSON/XML-RPC, их возможностей и ограничений.
Командная строка
Без навыков владения командной строкой бэкенд-тестировщик не сможет обойтись в большинстве случаев. На начальном этапе достаточно будет базовых вещей в духе работы с папками и файлами, их создания, чтения, перемещения и т.п. Эти знания позволят тестировщику, например, работать с серверными логами для локализации дефектов. А со временем вы уже не сможете обходиться и без bash-скриптов, работы с файловыми дескрипторами, конвейерами и регулярками.
cURL. Postman. SoapUI
Для тестирования REST API на стартовом уровне отлично подойдёт утилита командной строки cURL, которая позволит тестировщику отправлять тестовые запросы и получать ответы, разбирать их и сравнивать фактический результат с ожидаемым. Более продвинутым и одновременно более казуальным (за счёт наличия GUI) инструментом тестирования API является Postman, навыки использования которого также весьма полезны. А если нужно тестировать SOAP API, то идеально подойдёт инструмент SoapUI (на самом деле с ним можно тестировать и REST API).
Базы данных
Тестировщику важно знать и уметь работать с СУБД, в первую очередь с SQL (MariaDB, MySQL, PostgreSQL, MS SQL). И наиболее востребованным является знание SQL. Очень часто в описании вакансий есть упоминания про этот навык, который звучит как «Знание SQL на уровне простых запросов». Как правило, для начала достаточно знать базовые вещи уровня INSERT, SELECT, DELETE, UPDATE, WHERE, ORDER BY, в некоторых случаях нужны JOIN, INNER JOIN, RIGHT JOIN, LEFT JOIN. Кроме того, несомненным плюсом будут знания и навыки работы с NoSQL БД (MongoDB, Cassandra). Они позволят тестировщику сверять ожидаемые и фактические результаты в ходе выполнения тестов при работы с данными.
Клиентское тестирование мобильных-приложений
Молодое и, пожалуй, самое популярное направление в тестировании. Оно наименее исследовано, здесь не так много устоявшихся канонов, сильнейшие флуктуации то и дело охватывают эту специализацию. С одной стороны, это довольно простое для освоения направление на первых порах, с другой — требует от тестировщика быть постоянно на острие трендов, знаний и навыков, чтобы не вывалиться за обочину истории.
IDE
Для тестировщика мобильных приложений важно освоить на базовом уровне среду разработки (XCode для iOS, Android Studio для Android). Знания этих инструментов позволяют осуществлять локальные сборки приложений, при необходимости и с помощью разработчиков конфигурировать их под нужды тестирования, лучше локализовывать баги, читая клиентские логи, и даже работать с исходниками приложения. Кроме того, в IDE есть возможность запуска приложения через эмулятор, что может пригодиться тестировщику.
Инструменты мониторинга HTTP/HTTPS-трафика
Тестировщик обязан понимать клиент-серверную архитектуру и уметь локализовывать ошибки с её учётом. И если в тестировании веб-приложений для этого обычно хватает консоли разработчика, то для мобильных приложений нужно использовать специализированное ПО (Charles, Fiddler, Wireshark), которое позволит перехватывать и анализировать сетевые запросы. Т.е. с помощью этих инструментов в большинстве случаев можно довольно точно определить, на чьей стороне проблема. Более того, они позволяют подменять запросы, эмулируя то или иное поведение ПО (как со стороны клиента, так и со стороны сервера). Это нужно не только для локализации проблем, но и для проведения ряда испытаний в рамках тестирования приложения.
Сервисы дистрибуции мобильных приложений
Для тестирования разных версий приложений необходимо иметь базовые навыки работы с сервисами дистрибуции мобильных приложений, например, Fabric (Crashlytics), HockeyApp, TestFlight. Они позволяют не только получить нужные сборки для тестов, но и анализировать статистику использования, а также работать с падениями приложений, локализуя проблемы и выясняя их причины.
Автоматизация тестирования
Я не стал разграничивать автоматизацию тестирования по направлениям, выделив её в отдельную специализацию. Безусловно, есть ряд принципиальных различий между автоматизаторами тестирования веба, бэкенда и мобильных приложений, но в этом разделе мне хотелось бы консолидировать наиболее важные знания и навыки, которые востребованы инженерами по автоматизации тестирования вне зависимости от их специальности. Стоит отметить, что автоматизация тестирования сама по себе довольно сложна не только с технической точки зрения, но и с точки зрения практик тестирования. А потому настоятельно рекомендую смотреть в эту сторону, предварительно освоив не только общие моменты, но и одно из направлений, перечисленных выше. Если вы научитесь тестировать руками, вам будет проще и понятнее заниматься автоматизацией.
Язык программирования
Обилие языков программирования открывает перед тестировщиками широкие возможности для получения новых знаний и навыков для применения на практике. Выбрать из многообразия языков наиболее подходящий — непростая задача. Рекомендую руководствоваться тремя принципами.
Первый:
сложность обучения языкам — штука довольно относительная, ведь кому-то проще даётся модный стильно-молодёжный Python с динамической типизацией, а кому-то легче с жёстко типизированной и структурированной Java со статической типизацией. Важно попробовать и понять, твоё это или нет.Второй:
ориентируйтесь на сообщество, у которого вы сможете обучиться языку. Это в равной степени может быть как внешнее комьюнити (форумы, курсы, тренинги и т.п.), так и внутреннее (коллеги по цеху тестирования или даже разработчики). Однако стоит помнить, что равняться исключительно на коммьюнити не стоит, особенно если речь идёт о разработчиках. Безусловно, они эксперты в области своего языка, но не стройте радужных иллюзий, что они начнут помогать вам писать функциональные автотесты на регулярной основе (это очень редкий кейс), да и в специфике тестирования они далеко не всегда могут быть столь же компетентными.Третий:
ориентируйтесь на тестовые фреймворки и инструменты, которые используют в связке с языком программирования, и их популярность в среде тестировщиков. Это поможет вам в случае возникновения специфических проблем не остаться наедине с трудностями и найти поддержку на стороне.На основе опыта последних лет самыми популярными языками в контексте тестирования я бы назвал Python, Java, PHP, а в мире мобильной разработки — нативные языки Kotlin, Objective-C и Swift.
Тестовые фреймворки
Дабы тестировщику не приходилось начинать автоматизацию с изобретения собственных велосипедов и чтобы, минимизировать встречу с граблями, автоматизаторы тестирования часто используют тестовые фреймворки (xUnit, nose, unittest, pytest, TestNG, Cucumber) в зависимости от языка, на котором пишут тесты. Важно освоить эти базовые фреймворки, чтобы сделать работу с тестами наиболее эффективной и удобной.
Драйверы и надстройки для автоматизации тестирования
Помимо тестового фреймворка специалисты по автоматизации тестирования должны использовать драйверы, которые позволяют взаимодействовать с приложением через программный интерфейс вместо графического. Без них не обойтись, если вы собираетесь автоматизировать клиентские приложения. Если вы собираетесь работать с вебом, то обязательно нужно изучить Selenium WebDriver, если с iOS — XCUITest, а для Android вам пригодятся Espresso и UI Automator (нативная поддержка от Google), вариативно — Robotium или Selendroid. Для пущего удобства используют надстройки, которые, с одной стороны, усложняют инструментарий специалиста по автоматизации, а с другой — дают дополнительные возможности. Особое внимание рекомендую тут уделить Appium и Cucumber.
Системы отчётности результатов автотестов
Какие бы автотесты вы ни писали, по завершению было бы неплохо иметь возможность получить отчёт о проведённом тестировании, да такой, чтобы не мельтешило в глазах от строчек текста. Наиболее популярной сейчас, пожалуй, можно назвать разработку отечественных коллег — Allure. Инструмент всё чаще используется для удобной визуализации результатов выполненных автотестов, в нём есть возможность группировки тестов по компонентам вашего приложения или задачам, в контексте реализации которых проводятся испытания.
Системы контроля версий
После того как вы напишете свой первый автотест, вам непременно захочется писать ещё и ещё, а затем модифицировать, ускоряя работу, расширяя логику, углубляя проверки, а потом и поделиться результатами с коллегами. Хранить каждую из версий ваших тестов локально, раскладывая по различным папкам, архаично, трудоёмко и неудобно. Поэтому логично перенимать лучшие практики от программистов и научиться пользоваться системами контроля версий. Из наиболее популярных стоит отметить Git, SVN, Mercurial, TFS. Замечу, что Git доминирует на рынке и при прочих равных стоит использовать именно его. На начальном этапе тестировщику потребуется знание того, что такое commit, push, pull (force), fetch, checkout, branch, merge, rebase, revert.
Системы непрерывной интеграции
Запустив свой первый автотест, вам непременно захочется делать это ещё и ещё, а со временем даже поделиться с кем-то этой возможностью. И тут на помощь придут инструменты непрерывной интеграции, такие как Jenkins, TeamCity, Bamboo. Скорее всего, у коллег-разработчиков есть свой CI-инструмент для сборки проектов, возможно, даже и для запуска unit-тестов. Чтобы примкнуть к ним со своими функциональными автотестами будет здорово, если вы будете понимать принципы работы этих инструментов. А если ничего подобного у коллег ещё нет, тогда вы будете первопроходцем и сможете делать удобные параметризированные запуски своих автотестов (на разных хостах, с разными данными и т.д.) по факту изменений, запросу или по расписанию.
Возврат инвестиций от автоматизации тестирования
Последним, но не наименее важным, является знание методики подсчёта возврата инвестиций от автоматизации тестирования. Речь идёт хотя бы о приближённом представлении, какие тесты стоит автоматизировать и поддерживать, а какие лучше даже не пытаться. Если коротко, то отталкивайтесь от важности функционала и тест-кейса, который вы собираетесь автоматизировать, закладывайте трудозатраты и сложность разработки автотеста, а также потенциальную потребность, частоту и сложность его обслуживания и поддержки. Ведь одно дело, когда речь о ключевом нативном функционале, на который написаны все элементы фреймворка и прогнозируются минимальные трудозатраты на поддержку автотеста, и совсем другой разговор, когда речь идёт об автотесте на экспериментальную фичу, которую раскатили на 1% аудитории, фреймворк ещё не поддерживает этот функционал, который вдобавок интегрируется с нестабильными внешними сервисами, да ещё и переделывать егособираются ближайшие пару месяцев. Уметь определять, когда писать автотест, а когда нет — важный навык для специалиста по автоматизации тестирования.
Управление командой тестирования
Помимо становления экспертом в области тестирования популярным путём развития современного тестировщика является рост вертикальный, в управленца командой тестирования. В идеальном кейсе управленец должен уметь делать то же самое, что и команда, которой он будет руководить, однако это не обязательно. Если при этом он будет в части вопросов компетентнее своей команды — ещё лучше, но вот что уж точно чрезмерно, так это абсолютное превосходство во всех вопросах. В конечном итоге, управление командой — это история про обмен опытом, знаниями и компетенциями. Какими же личностными и профессиональными качествами должен обладать хороший тимлид?
Лидерство
Я глубоко убеждён, что лидерство — прирождённое качество, недаром Генри Форд говорил: «Спрашивать, кто должен быть боссом, всё равно что спрашивать, кто должен быть тенором в этом квартете». Тем не менее, можно научиться лидерству. Ведь есть и обратное мнение, что лидерами не рождаются, а становятся. Безусловно, лидерские качества, есть в каждом из нас. Другое дело, что для одних руководить и воодушевлять людей —это дар и мана небесная, а для других — кошмар и адовые муки. Сложно себе представить, что кто-то из читателей сознательно выберет путь развития в управленцы, зная, что это будет приносить дискомфорт и неприятности. Всё-таки с желанием быть лидером у управленца значительно больше шансов на успех.
Решительность
Управленец должен уметь принимать решения. Кажется, что это очень просто, но люди часто сталкиваются с собственной нерешительностью. Когда речь идёт о серьёзных вещах, то некоторые люди и вовсе впадают в ступор, всячески оттягивая принятие решения, опасаясь ответственности и последствий. Для управленца это неприемлемо, поэтому ему важно развивать свою решительность, чётко понимая ситуации, когда действительно есть время для принятия решения, а когда нужно действовать здесь и сейчас.
Формирование команды
Умение работать с командой, формировать её, направлять и развивать — важные качества руководителя. Группа людей — ещё не команда. Изначально у них могут быть разные цели и задачи. Пока они не объединены идеей, не мотивированы и не жаждут плечом к плечу преодолевать трудности, они не могут быть командой. Задача хорошего руководителя — сплотить людей, склеить их, подбирая задачи и выставляя цели, которые будут приводить к формированию настоящей команды. Для этого потребуется и умение подбирать новых людей, и находить подход к своим сотрудникам, а при необходимости и с кем-то попрощаться. Вам надо научиться работать с разными людьми, развивая свои способности находить общий язык с командой, формировать её и развивать для эффективной совместной деятельности.
Планирование
Навык планирования нужен и рядовому специалисту, а для руководителя он становится необходим, как воздух. Ведь управленец распоряжается не только своим временным ресурсом, но рабочим временем целого подразделения, а потому должен уметь распределять его грамотно, вдумчиво и эффективно. На начальном этапе необходим как минимум уровень тактического планирования — на день, неделю, месяц. В конечном итоге руководитель должен научиться мыслить стратегически, ставить задачи не только на видимый горизонт событий, но и перешагивать за него. Это, несомненно, сложно, однако не значит, что этому не нужно учиться. Нужно! Особенно, если вы хотите стать хорошим руководителем.
Навык убеждения и ведения переговоров
Становясь руководителем, вы должны уметь отстаивать не только свою позицию, но и точку зрения вашего подразделения, лицом которого вы по сути являетесь. А это значит, что, во-первых, вы должны научиться убеждать в собственной точке зрения свой коллектив, а во-вторых, в некоторых ситуациях должны уметь принимать и отстаивать мнение своей команды. Вести переговоры от лица своих сотрудников — сложная задача, и получить этот навык автоматом не получится. Потому начинающему тимлиду стоит обратить внимание на прокачку этого навыка, а опытный и так уже знает, что без умения грамотно аргументировать и защищать свою позицию руководителю будет крайне сложно найти общий язык и внутри коллектива, и за его пределами.
Позитивное мышление и умение мотивировать
Руководитель — глава подразделения, от его взгляда на вещи зависит и поведение его сотрудников. На вас лежит ответственность за моральное состояние команды, её боевой дух и уровень мотивации. Руководителю важно понимать, что у каждого сотрудника свои мотиваторы, и способы воздействия на членов коллектива должны быть разными. Хороший руководитель источает не только уверенность в завтрашнем дне и решительность в своих поступках, но и позитивное отношение к вещам, которое он транслирует своей команде, приободряя её, ставя новые задачи.
Итого
![](https://habrastorage.org/webt/ej/qu/q-/ejquq-8esrvs7o3i4lt2tayorwu.jpeg)
Итак, чтобы войти в IT через тестирование, знать нужно довольно-таки много, а чтобы развиваться и стать профессионалом — ещё больше. Важно понимать, что у вас всегда есть выбор — быть экспертом в определённой области с глубоким погружением в специальность или стать широкопрофильным специалистом. На рынке требуются и те, и другие, так как всё зависит от конкретной компании, принципов формирования команд и рабочих процессов. Если уверены, что вам это действительно интересно, и что эта дорога вам по зубам, смело ступайте по ней, впереди много удивительных открытий и новых знаний.
Еще раз хочу напомнить о важности определённого характера для работы в IT и тестировании в частности. Помните, что на курсы по языкам программирования и СУБД можно отправить любого, а вот на курсы по тяге к саморазвитию и увлечённости, которые бы позволили бы успешно пройти первые курсы, увы, отправить никого не получится.
Надеюсь, что статья оказалась полезной для тех, кто её прочитал, будь то новичок или опытный специалист, ведь выбор профессиональных линий развития в области тестирования достаточно велик, чтобы в нём слегка потеряться. Напомню, что вся эта история — in my humble opinion, а потому не судите строго и не забрасывайте тапками. Буду благодарен за конструктивную обратную связь.
Всем качества!
Комментарии (31)
Shm-Alex
17.10.2018 17:50Кажется вы описали какого-то сферического тестировщика вакууме который в конце концов становится лидером команды. В общем какой-то сомнительный план и черезмерная мотивация. В жизни тестировщик, который тестирует руками не имеет времени на самообучение — он в яме постоянных задач — у него не хватает времени на самообучение. Автоматизированные тесты очень дороги в поддержке, и задач, в которых цена ошибки настолько велика чтобы оплачивать поддержку автотестов не так много и все они либо в банковском секторе либо в критическом по типа авиации /медицины/ атомные станции etc.
И переходить с уровня на уровень практически не возможно- только для очень энергичных электронов — возможно сразу только впрыгивать на потенциальный уровень авто тестировщика например. Но мне кажется это удел ребят которые спрыгнули с энергетического уровня разработчиков кода.pifagor_mc Автор
17.10.2018 17:59Никто и не говорит, что нужно выучить все специализации, чтобы состояться как специалисту, это скорее скупы мастхэвных знаний и навыков, которые нужны для той или иной специализации. Тестировщик может быть широкопрофильным, а может и экспертом в конкретном направлении.
Про автоматизацию, сейчас экономически целесообразная автоматизация тестирования существует в десятках и сотнях компаниях на отечественном рынке, все довольно легко считается и оправдано.
Про «не имеет времени» и «переход на следующий уровень» абсолютно не согласен, смотрите пункт про саморазвитие и увлеченность. За последние 8 лет в моих командах развились десятки высококлассных специалистов и управленцев, кто-то начинал вообще без навыков тестирования, у кого-то были первичные знания и небольшой опыт, но сейчас это Профессионалы, работой с каждым из которых я горжусь. Кто-то стал экспертом ручного тестирования, кто-то автоматизатором, кто-то Тим-лидом, некоторые ушли из тестирования и стали руководить разработкой или продуктом. Я и сам когда-то начинал младшим тестировщиком, пройдя длинный путь до директора по качеству. Всё в наших руках;)medoed36
18.10.2018 18:51Сперва вы пишите:
В своей статье я постараюсь в общих чертах рассказать, что нужно знать и уметь, чтобы работать специалистом в области обеспечения качества в наиболее популярных и востребованных направлениях.
Ключевое слово тут «в общих чертах», то есть идет речь про обязательный, минимальный набор знаний для хорошего специалиста.
Затем идет такое:
А со временем вы уже не сможете обходиться и без bash-скриптов, работы с файловыми дескрипторами, конвейерами и регулярками.
Про bash и регулярки в принципе понятно, но объясните, зачем остальное среднестатистическому, но все же хорошему специалисту по тестированию?
Вообще во многом статья выглядит так:
- Налили воды про личные качества, что применимо к любой профессии
- Добавили личного опыта, который в прочем очень даже неплох — это плюс
- Получилось слишком мало — накидаем еще немного терминов, которые скорее всего не пригодятся, но пусть будут
pifagor_mc Автор
18.10.2018 19:02Я в деталях очерчиваю знания и навыки, что нужны на входе, а для того, чтобы не возникло ощущения, что работа с консолью ограничивается командами чтения файлов и работы с папками набрасываю о перспективах, в которые окунется специалист, выбрав эту дорожку для себя.
Про личные качества бы не писал, если бы за последние несколько сотен собеседований не зафейлил изрядное количество кандидатов именно по этим чертам. Ну и вдобавок, как мне кажется, в статье неплохие приемы для самодиагностики на предмет ответсвенности, увлеченности и т.д. А то ведь на собеседованиях все потом горазды рассказывать какие они ответственные и увлеченные, только последние 5 мест работы они меняли из-за начальства, коллег, проекта и кризиса, а не из-за собственных просчетов. Да и с увлеченность беда такая, что даже хобби нет, а те, что есть в состоянии «нет времени, когда устроюсь на новое место, то снова начну заниматься».
somatiq
17.10.2018 18:36А вы описываете совсем уж ручную макаку в вакууме. В реальности на проектах (хотя, где-то, конечно и не повезёт) будет хватать моментов, когда нужно будет учиться чему-то новому именно чтобы продолжить то самое тестирование ручками.
g0rd1as
17.10.2018 22:02А как вам такая ситуация: кончился один проект, ручного тестера перебрасывают на другой и говорят, что тут ты будешь автоматизировать тесты на джаве и селениуме, потому что надо!? Такая ситуация у меня однажды возникла. Я, естественно, не возражал и какие-то основы джавы подобрал буквально за 2-3 недели.
valery1707
18.10.2018 12:52Автоматизированные тесты очень дороги в поддержке, и задач, в которых цена ошибки настолько велика чтобы оплачивать поддержку автотестов не так много и все они либо в банковском секторе либо в критическом по типа авиации /медицины/ атомные станции etc.
У меня мнение обратное: ручное тестирование не масштабируется вообще никак.
Авто-тесты же очень хорошо масштабируются.
Авто-тесты могут быть дороги в поддержке если идёт постоянная и кардинальная смена интерфейсов, которые эти тесты используют. Если интерфейсы меняются хотя бы не кардинально, то и поддержка будет не очень сложной.
Понятно что просто перевести всё ручное на автоматическое будет сначала дорого. Но зато полная проверка системы которая в ручном режиме занимала N часов может быть проверена за N минут. Это ли не профит для бизнеса?
P.S.
Я не тестировщик, а разработчик если что.
Drvesina
18.10.2018 19:03Я начинал с ручной макаки и сейчас занимаюсь автоматизацией в загранице.
Секрет успеха прост: «нужно шагать так широко, чтобы штаны трещали, но не рвались»©.
Я менял работодателей. Каждый новый шаг всегда приводил к усложнению задач. Началось с тупого выкликивания кейсов, затем ручная работа с минимумом автоматизации, дальше минимум ручной работы максимум автоматизации и вот сейчас 100% автоматизации.
4 шага, 4 работодателя, ~4 года.
Как пройти такой путь за такой срок в рамках одной, даже крупной, компании я не представляю.
polarnik
18.10.2018 02:03Спасибо, за статью. Заголовки могут служить каркасом оценки кандидатов: «Кандидат коммуникабелен, основ тестирования не знает, обладает знаниями языка Java, претендует на лидирующие позиции». Приведённые факторы встречаются в разном сочетании.
В команде нужны разные люди — весёлый, терпеливая, умный, в платье, с бородой,… и гитарист. Это шутка, в которой лишь доля шутки. А для сложных систем нужны команды.pifagor_mc Автор
18.10.2018 19:50Благодарю! Рад, что статья пришлась по нраву. Согласен по поводу оценки кандидатов, у меня есть комплексное решение оценки кандидатов, в котором под сотню различных качеств, знаний и компетенций. При случае сделаю статью с рекомендациями по использованию этого решения. Возможно также окажется полезным этот материал. Stay tuned!
nick_gabpe
18.10.2018 11:54Открывая вакансию senior QA engineer компания может искать 3 различных человека:
1 инженер — автоматизатор который большую часть времени будет заниматься написанием автотестов и их поддержкой
2 инженер который будет заниматься ручным тестированием и написанием текстовой документации.
3 инженер который поставит тестирование в данной компании и наладит все связанные с тестированием процессы.
Порой люди сами не знают кого ищут.
lightman
18.10.2018 12:41Из километрового списка требований невольно сложилось впечатление что тестировщик — чуть ли не самая сложная должность в IT сфере.
pifagor_mc Автор
18.10.2018 20:00Ну это скорее список ингредиентов для горячего самобытного коктейля специалиста. Все знать совсем необязательно. Каждый выберет свой состав и соберёт профессиональный портрет, что ближе лично ему.
Am0ralist
18.10.2018 22:00Читая статью не мог избавиться от навязчивой ассоциации с одним из объявлений , которое про «требуется сисадмин».
ranebull
19.10.2018 07:06Честно говоря, не увидел здесь системного администратора. ТС описал лишь базовые вещи, которыми должен обладать тестировщик. Если он чего-то не знает — можно изучить в процессе.
masb
19.10.2018 12:12нетипизированный Python
С каких пор так? Всегда думал, что Python имеет динамическую — строгую типизацию.
orangevaya
19.10.2018 12:12Большое спасибо за отличную статью! Читала и почти на каждом предложении яростно кивала. :)
pifagor_mc Автор
19.10.2018 12:13Благодарю за обратную связь, делитесь с коллегами, уверен, будет полезно :)
dariaamir
19.10.2018 12:13Теперь хотя бы понятно, откуда берутся на собеседованиях вопросы обо всём на свете, кроме того, что реально будет нужно в проекте.
В проекте не будет возможности заняться автоматизацией — спросят про основы ООП. Все машины в команде на Винде — спросят про линуксовую командную строку. Написанием тесткейсов занимается отдельная команда — попросят тестировать лифт или карандаш. У тестировщиков нет доступа к БД — обязательно будут просить написать SQL запрос на бумаге.
Не бывает живых людей, которые знают всё и хороши в любой области. Куда важнее понять, куда лично ты хочешь двигаться и развивать именно эти направления. А не бежать за всеми поездами одновременноpifagor_mc Автор
19.10.2018 12:14Отчасти для конкретизации направлений и писал эту статью, позволит не искать сферического супер-тестировщика-всезнайку, а найти специалиста в нужном профиле.
scor4er
19.10.2018 12:15Образ современного программиста. Что нужно знать и уметь
— Вам нужно быть коммуникабельным, решительным, лидером, верить в свои силы и уметь постоять за себя
— Уметь программировать
— Знать языки программирования
— Знать фреймворки
— Уметь запускать прграммы
Ура! Прекрасная, глубокая статья готова, выкладываю на хабр.pifagor_mc Автор
19.10.2018 12:16С удовольствием прочитал бы такую статью в разрезе различных специальностей/направлений, ведь разработкой хотят заниматься десятки тысяч людей, но сталкиваются с такой же проблемой, что и тестировщики, то есть не понимают, что именно нужно учить для каждого конкретного профиля в первую очередь, а что можно отложить на потом или не изучать вовсе.
katamathesis
19.10.2018 12:17Из праздного любопытства было бы интересно взглянуть на проект, в котором все тестирование организованно «по методичке» — тест-стратегия, тест-кейсы и т.д. Хотя под такой грудой формулярства было бы тяжело работать.
Имхо, по собвественному опыту понял, что главное в тестировщике не увлеченность в саморазвитии (что де факто стандарт для IT-отрасли) и даже не стартовые знания, а некоторый склад ума, позволяющий легко и с интересом относится к обьемным, монотонным и повторяющимся задачам, из которых по сути состоит любой проект, особенно после некоторого времени работы на нём, когда проходит эффект новизны. В свое время подобный формат задач привел меня к выгоранию и потере какого-либо интереса к проекту, команде, нуждам заказчика. И никакие возможности по саморазвитию и повышению скиллов не спасли, просто не тот уровень работы. После чего решил сменить профиль деятельности и не прогадал в итоге, о времени работы тестировщиком, за исключением пары проектов, вспоминаю с ужасом.pifagor_mc Автор
19.10.2018 12:21Такие проекты есть, уверен. Возможно, там не все кусочки паззла собраны, но зато самые нужные в конкретном месте.
Про стандарт, очень хотелось бы, чтобы в профессию приходили замотивированные, увлечённые и склонные к самообучению люди, однако, в индустрии полно и аморфных тюленей с сомнительной денежной или имиджевой мотивации, а то и вовсе людей, которые просто хотят быть на хайпе.
Выгорание на работе происходит у всех, даже у самых замотивированных, увы. Причем по личному опыту, чем более мотивированным был человек, тем громче и с бОльшими последствиями он демотивируется. В духе поговорки про «чем больше шкаф, тем громче падает»:( Знаю немало кейсов переходов в тестирование из разработки и наоборот, универсальной профессии не существует. Рад, что в итоге обрели свое место и задачи, которые не вызывают печали и ужаса.
yarric
А кто тогда остаётся заниматься QC?
z3apa3a
А возможен QA без QC?
pifagor_mc Автор
QA вполне себе продолжает выполнять функции QC, ну и падаванов для более простой работы никто не отменял. Это естественный ток вещей- от простого к сложному.
yarric
Просто QA — это не то же самое, что QC. Странно читать такое от преподавателя QA/QC.
pifagor_mc Автор
Я в курсе, но QC часть QA, потому человек с компетенциями и знаниями QA вполне может выполнять функции QC. То если человек перешёл на следующий уровень, то это не значит, что предыдущий становится ему недоступным. Ну и в компании всегда есть поросль, которая подхватит пул задач QC.
PositiveAlex
Я бы вообще не разделял эти понятия. Есть процесс обеспечения качества и есть процесс его проверки. Это просто части одного целого. От размера проекта и компании зависит то, кто чем занимается. В маленьком проекте организацией и выполнением занимается один человек, в большой — уже есть куча ролей, каждая из которых делает какой-то свой кусок.