Немного о себе
Тестированием в том или ином виде я занимаюсь уже более 10 лет.
Путь в ИТ, как и многие, я начинал с разработки «для себя». У меня всегда был миллион идей, что написать, и таким образом я постепенно развивался. Мне нравилось разбираться в деталях проектов и делать их отказоустойчивыми, и уже тогда было более-менее все равно, на каком языке писать: я умел алгоритмировать, а погуглить синтаксис – вопрос недели.
Где-то в 2005 году я познакомился с человеком, который в буквальном смысле открыл для меня отрасль тестирования. Мне уже тогда показалось, что ее идеология полностью соответствует моим внутренним стремлениям. Человек тот в итоге прошел путь от рядового тестера до технического директора и уже тогда звал меня к себе работать. Но по разным причинам попал я в эту отрасль лишь год спустя, устроившись в компанию Smartbear (на тот момент – Automated QA Corporation), чей инструмент для автоматизированного тестирования TestComplete известен, пожалуй, всем тестировщикам. Правда, попал я не на сам TestComplete, а на другой продукт, Automated Build Studio – по сути, сразу в автоматизацию. В его GUI-подход к автоматизации, кстати, я буквально влюбился, даже написал для себя аналог, когда ушел из компании.
Впоследствии я успел поработать и на зарубежных заказчиков, и на российских. А на данный момент автоматизирую тестирование в российской полностью удаленной компании (на формате работы еще остановлюсь далее).
За время, проведенное в профессии, я понял, что тестирование — это не просто работа, но и своеобразный стиль жизни, который влияет на все аспекты твоей жизни. Будучи тестером, ты просто не можешь жить иначе.
У этого подхода есть как позитивные, так и негативные стороны.
Чем проще задача, тем хуже ты себя чувствуешь
Поиск сложных задач – это не только пристрастие, но и неизбежность.
Сколько бы ты ни учился, в любом инструменте, в любой технологии всегда найдется тот, кто знает больше тебя. И если ты условно «едешь по колее» простого проекта, об этой разнице знаний тебе будут постоянно напоминать. Со всех сторон будет сыпаться критика, что здесь можно было сделать иначе или даже лучше.
Единственный способ этого избежать – искать более сложные задачи, где нет очевидных решений, но есть бессонные ночи в поисках проблем.
К примеру, на одном из последних проектов я столкнулся с разработкой библиотек для Robot Framework в связке с Jython. Конкретно в том случае можно было использовать стороннюю библиотеку для работы с базой данных, и она вроде бы должна была работать, но не работала. Три ночи я потратил на то, чтобы в итоге, читая код самой библиотеки, найти ошибку в документации, которая неверно указывала типы и количество значений на входе. Это была победа и настоящий кайф от ее достижения! И мне нравятся подобные моменты. Это гораздо интереснее, чем «колея» типичного проекта.
Однако стремление к сложным задачам несколько ограничивает круг возможных работодателей. Еще больше его ограничивают дикое тестирование фронтэнда, работодатели без внятного ТЗ на тестирование или имеющие какие-то смутные представления о том, кто такой автоматизатор. Я встречал тех, кто, приглашая на автотестирование, ставит ручные задачи или подключает тестеров к support. Еще довольно много тех, кто экономит на покупке нормального инструментария, предлагая работать чуть ли не в Google Docs. И надо быть готовым к тому, что рынок потенциально интересных работодателей уже, чем тебе кажется.
Высшее образование не тождественно трудоустройству. Важна техническая база и интерес к профессии
На текущем месте работы в число моих обязанностей входит техническое собеседование тестировщиков, поступающих к нам на работу. В ходе беседы я никогда не задаю вопрос о наличии высшего образования, потому что уверен: оно абсолютно не гарантирует присутствие логического мышления. Может быть, мой собеседник имеет докторскую степень, но ни в зуб ногой в тестировании.
Откровенно говоря, я вообще считаю, что тестером нужно родиться. Для этого требуются природная внимательность, усидчивость и какая-то специальная тестерская жилка, когда ты из 1000 документов можешь наобум попасть в один из трех ошибочных. Правда, не все разделяют это мнение.
Важно то, что даже при наличии этой самой жилки нужна хорошая техническая база, которую вряд ли можно получить, закончив двухнедельные онлайн-курсы. Сложно сказать, что обеспечило техническую базу в моем случае. В 90-е доступа к Интернету у меня не было, нужной литературы в библиотеках — тоже, поэтому знания я черпал из FIDO (до сих пор поинты свои помню — 2:5022/5.102 и 2:5022/123.222). А базой именно по тестированию я обязан сертификации International Software Testing Qualifications Board (ISTQB). Кажется, ничего лучше пока не придумали.
Однако довольно редко я встречаю знания по ISTQB у кандидатов на вакансии. Более того, иногда мне кажется, что люди вообще не интересуются отраслью. На собеседованиях у меня есть вопрос про конференции: посещает ли кандидат какие-то мероприятия в сфере QA. И традиционный ответ на него отрицательный. Для меня это показатель серьезности и заинтересованности самого кандидата, а заодно и компаний, на которые он работал. Участие в мероприятиях типа SQA Days, куда я поеду в ближайшее время, стоит денег. И какая-нибудь «шарашкина контора» не будет тратить их на своих сотрудников. Из своего кармана же заплатит лишь тот, кому по-настоящему интересно.
Без опыта никуда
Каждый проект в тестировании заставлял меня изучать новые технологии. Выше я рассказывал о своей «героической битве» с Jython, но ведь придя на тот проект, я не знал ни Robot Framework, ни, собственно, самого Jython (ни даже Python, на котором есть много всего для Robot Framework). Теперь же я, пожалуй, лучше всех в компании разбираюсь в роботе, потому что база в тестировании подсказала подход, а опыт разработки на разных языках и тестирования предыдущих проектов позволил быстро переключиться на новый стек.
Кроме того, опыт позволяет правильно распределить усилия. Я заметил, что новички очень много внимания уделяют негативному тестированию – как бы что сломать. Видимо, стереотипы у них такие относительно профессии. В большинстве случаев их негативное тестирование неважно и ненужно (т.е. растрата ресурсов неоправдана, за исключением тех случаев, когда проект подразумевает необходимость такого тестирования). Лишь с опытом приходит понимание того, что нужно, а что нет, при такой постановке задачи.
Кстати, у меня на собеседованиях есть целый список вопросов, задача которых – выявить наличие именно практического опыта кандидатов.
Все люди раздолбаи. Это вызывает боль, но дает работу
Увы, мир несовершенен.
В разработке это выражается в том, что на тестеров существует спрос. Если бы разработчики замечательно писали код, мы бы остались без работы. С нами же раздолбайство никуда не исчезает, но мы покрываем его тестами.
Сами тестеры, к слову, тоже небезгрешны. Какой бы проект ни попался, вам тоже иногда придется писать «костыли». И с этим ничего не поделаешь – таковы порой условия бизнеса.
Чем лучше ты как тестер, тем больше тебя ненавидят
Разработчики с тонкой душевной организацией, с которыми я сталкивался на прошлых работах, порой очень тяжело относились к багам в их коде, информация о которых появлялась в системе. С их точки зрения, это, видимо, что-то вроде публичного оглашения их ошибок. И чем активнее ты отчитываешься о багах, тем сильнее тебя ненавидят коллеги. В результате в офисе у тебя, конечно, есть какое-то количество хороших знакомых, но примерно треть коллектива начинает тебя избегать, и ты это чувствуешь. Для меня это крайне неприятно.
На удаленке быть тестировщиком легче
Это естественное следствие из предыдущего замечания. Когда ты нажил себе в офисе достаточно «недоброжелателей» с тонкой душевной организацией, ходить по такому помещению становится не очень приятно. Поэтому для себя я уже давно сделал выбор в пользу удаленки. В таком формате непрофессиональные отношения сходят на нет – никаких косых взглядов. Возможно, конечно, я просто не сталкиваюсь теперь с такими характерами. Но здесь и шансов на такое столкновение немного. Мы, к примеру, созваниваемся по видеосвязи только внутри QA-отдела. С разработчиками, на которых я могу повесить баг, общаюсь только в тексте, без каких-либо эмоций. А даже если эти эмоции и будут, в тексте их переживать гораздо проще, чем когда человек по несколько раз в день проходит мимо.
А еще я могу питаться нормальной домашней пищей, оборудовать рабочее место так, как мне хочется. Могу сидеть в жару в одной футболке (помня о видеосозвонах) или даже изменить свои рабочие часы так, чтобы в середине дня выехать в поле и понаблюдать, как начинается осень или природа просыпается от зимней спячки. А самое главное достоинство удаленки – это экономия времени. Я живу неподалеку от областного центра. ИТ у нас существует только там. И если мне работать в офисе в центре, то до рабочего места придется добираться по часу в одну сторону, а по пятницам все полтора. И это время, которое ты просто теряешь: оно не оплачивается, не тратится с пользой. Плюс риск попасть в ДТП и расходники на машину. С удаленкой этих трат и рисков просто не возникает.
Мне кажется, по своей воле я уже не пойду работать в офис. Единственное, чего мне порой не хватает, так это личного общения. Но в целом это вопрос решаемый.
Профессиональная деформация влияет на взаимоотношения с друзьями
К сожалению или к счастью, тестирование – это стиль жизни. Не могу говорить за всех, но именно так это происходит у меня.
Тестирование начинается с требований к проекту. Собственно, его задача – убедиться в том, что продукт этим требованиям соответствует. Целыми днями разыскивая и исправляя проблемы в чужом софте, ты начинаешь заниматься чем-то аналогичным и в своей жизни. Я всегда живу с ощущением того, что все должно соответствовать требованиям. Быть тестером – значит жить по правилам. И если кто-то или что-то выходит за рамки этих правил (законов или собственных норм, сформулированных в голове), у меня это вызывает какой-то когнитивный диссонанс. Я срочно пытаюсь исправить баг или хотя бы заявить о нем. При этом окружающие люди очень часто страдают от того, что ты им постоянно твердишь о неправильных поступках.
Кстати, все это не способствует устранению той самой нехватки личного общения.
Общий комфорт рабочего процесса значит больше, чем кажется на первый взгляд
Выше я говорил по большей части о проектах и взаимоотношении с командой. Но работа, даже удаленная, состоит не только из этих моментов. И вот тут многое зависит от проекта, в который ты попал.
Во-первых, есть банальное материальное обеспечение. Например, удобное кресло, на котором я сейчас сижу, а также 24-дюймовый монитор куплены за счет работодателя. Плюс всякие оплаты спорта и прочие бонусы.
Во-вторых, есть банальная самореализация. К примеру, в одном из проектов, в которых я участвовал (тестирование проекта заказчика на аутсорсинге), меня – единственного из аутсорсеров этой компании – привлекали к собеседованиям сотрудников на данный проект в офис и приглашали на корпоративные мероприятия. Реально ли это в компании, для которой тестеры – безликие винтики механизма? Сомневаюсь.
Так или иначе, мне нравится моя работа. И когда удается решать сложные задачи в интересном проекте, я испытываю настоящее удовлетворение. Однако развиваясь на этом поприще, стоит быть готовым к тому, что подходы к работе затронут все аспекты жизни. А если превратишься однажды в тестера со всеми тараканами, назад дороги не будет.
Автор статьи: Владимир Васяев, Ведущий специалист по автоматизированному тестированию программного обеспечения
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Комментарии (17)
ledascho
06.11.2018 12:11Судя по статье, я со своими тремя сертификатами ISTQB Advanced Level, обучение и получение которых мне оплатила моя «шарашкина контора», не пройду собеседования у автора — у меня нет и не было серьезности и заинтересованности в SQA days или других возможностях послушать, как кто-то другой рассказывает, какой он крутой тестер.
Neusser
06.11.2018 13:33Вот везде пишут пугалки, что разработчики недолюбливают тестировщиков, вплоть до «ненавидят». Ни разу с таким не сталкивался. Возможно, это связано с личными особенностями тех самых тестировщиков.
EvilsInterrupt
06.11.2018 15:37Я тоже не сталкивался. Меня наоборот команда «ненавидит», если что-то пропущу. )))
mipan
06.11.2018 16:48Когда ненавидят тестировщика это показатель неправильного процесса разработки и нездоровой атмосферы в компании, а вовсе не его профессионализм.
И скажите, что кроме «показать заинтересованность» дало вам посещение SQA days и подобных мероприятий? Должны ли кандидаты еще не попав к вам на работу тратить свои средства, чтобы показать интерес?Maxilect_pr Автор
06.11.2018 21:32Выше я ответил уже про процессы. Не возьмусь их оценивать.
Про конференции — я имел в виду немного иное.
Тестирование — активно развивающаяся отрасль. Здесь все меняется довольно быстро, поэтому оставаться «в теме», ни на кого не оглядываясь, сложновато. Не получится сохранять квалификацию, не изучая ничего сверх текущей работы. Вообще зашоренность на работе — это плохой признак. Текущая задача обычно держит тебя в рамках одного направления, в то время, как отрасль развивается, условно говоря, «во все стороны».
Чтобы компенсировать постоянно усугубляющийся перекос в конкретном направлении, можно следить за публикациями передовых команд, смотреть интересные именно технологические (а не 100% самопиарные) доклады на Ютубе. Но, честно говоря, я не встречал на собеседованиях кандидатов, которые бы действительно тратили на это время. Увы. Конечно же, я пытаюсь это обнаружить. Но чаще вижу огромные пробелы в казалось бы элементарных знаниях.
Вопрос про конференции — это своего рода «последняя надежда». Если кандидат не интересуется ничем, но хотя бы съездил на конференцию — значит отрасль ему не безразлична (не все потеряно). Конференция — это не столько подборка конкретных докладов, сколько выбранный оргкомитетом список тем, на которые стоит обратить внимание (в изложении докладчиков конференции или других спикеров — это не так важно).
Конечно же, отрицательный ответ на вопрос о конференциях с лихвой перекроют обширные знания, сертификация и т.п. — тут важно помнить про изначальную цель.Thseru
07.11.2018 11:55Но чаще вижу огромные пробелы в казалось бы элементарных знаниях.
Можете перечислить какими знаниями и умениями должен обладать любой тестировщик?Maxilect_pr Автор
07.11.2018 15:48Тестировщику точно нужны два качества: внимательность и усидчивость. Необходима база в ИТ. А остальному при желании можно научиться.
Вы, вероятно, интересуетесь знаниями, необходимыми для старта карьеры? Рекомендую поискать стажировку в какой-нибудь компании и посмотреть список требований к кандидатам.
manifity
07.11.2018 14:34Что такое Jyton?
Maxilect_pr Автор
07.11.2018 14:34manifity
07.11.2018 14:38Спасибо! А то мне Google постоянно менял на Python, думая что я опечатался. Пошёл изучать. :)
Maxilect_pr Автор
07.11.2018 15:16Откровенно говоря, я не советовал бы использовать Jython с RF (как раз ту связку, что упомянута в моем рассказе).
Robot Framework сам написан на Python, и под него есть много библиотек именно на Python, позволяющих реализовать практически все, что угодно (вообще RF — мощный инструмент, который лично мне очень нравится). Jython — это попытка адаптировать все это «богатство» под разработку на Java. Но в связке RF+Jython многие библиотеки Python не работают (а вместе с тем и все, что использует эти библиотеки — как некоторые библиотеки самого RF).
Своих библиотек под Jython практически нет. Когда мы уперлись в это в «боевом» проекте, пришлось потратить время на ковыряния в тех немногих библиотеках, что все-таки существуют (как было описано выше), а остальные нужные нам библиотеки просто переписывать под Jython своими силами.
Кстати, об этом проекте мой коллега писал статью: habr.com/company/maxilect/blog/424333. Правда, он не акцентировал внимание на том, насколько много усилий ушло на то, чтобы заставить все это корректно работать. Он пришел на проект, когда там была написана уже масса тестов.
И даже несмотря на то, что я в итоге заставил все это работать, от RF на том проекте впоследствии отказались — перешли на стек, более подходящий для разработки на Java.manifity
07.11.2018 15:29Спасибо за пояснение! У нас в компании пока что реализация BDD_Behat + Facebook Webdriver + Selenium Server со своим фреймворком написанном на PHP. То есть мы пишем заранее обусловленные команды на русском языке, а далее смотрим на результат. Нативнее использовать всё таки язык программирования напрямую, но тут появляется более высокий порог входа в компанию, и полностью новая реализация автоматизации тестирования. Компания пока-что на это не готова.
Сам отдельно изучаю Python в связке с Selenium WD. Да и вообще смотрю что да как, чтобы сделать революцию тестирования в нашей компании.
aivazovski
07.11.2018 20:18Никогда не понимал людей который злятся на тестеров. Тестер это твой друг и товарищ, который подтирает твои косяки, пока их никто не увидел. Я наоборот переживаю если ребята ничего не нашли. Значит плохо тестили и это вылезет в продакшене.
lxsmkv
07.11.2018 22:30новички очень много внимания уделяют негативному тестированию – как бы что сломать
Вообще часто встречаюсь с совершенно неверным утверждением, что, мол, задача тестировщика попытаться сломать приложение. Дорогие читатели, выкиньте эту чушь из головы навсегда. Тестировщик ничего не ломает, он находит то что уже было сломано. Задача тестировщика предоставлять информацию о работе приложения. И это включает в себя и положительное тестирование. Ведь обычно больше того, что работает чем того что не работает.
У меня такая стратегия: то что работает, покрывается автотестами. Что не покрыто тестами, проверяется вручную, и заводятся тикеты. Тикет решен — пишется автотест, подтверждающий что оно работает.
Чем лучше ты как тестер, тем больше тебя ненавидят
Это зависит от подачи. Я научился нейтрально подавать информацию и никаких конфликтов у нас нет. Сегодня разработчики сами иногда подходят ко мне, просят что-то проверить, спрашивают есть ли у нас автотесты на какой-то функционал.
[...] тестирование – это стиль жизни. [...] Я всегда живу с ощущением того, что все должно соответствовать требованиям
Я тоже заметил это за собой, но не знал как это описать. Я стал гораздо строже относиться к проявлениям низкого качества, в сервисах, продуктах. Если происходит какой-то косяк или повод для рекламации я не моргнув глазом пишу репорт производителю или продавцу. И безо всяких эмоций добиваюсь решения. Именно эта профессиональная позиция: проблема, если это проблема, должна быть решена. Никаких компромиссов.
В прошлой жизни, я бы наверное не знал как подступиться к описанию, а еще бы мучался писать и оставить как есть.
Кстати, я заметил, что быстро написать полезный репорт — навык, которому нужно обучаться. Меня в свое время на правильный путь навел гневный комментарий разработчика, который был в корне не согласен с моим описанием проблемы. Он сказал:
«Просто скажи, что ты делаешь и что видишь, а не то, что тебе кажется!»
Это был самый полезный урок по тестированию, который я когда либо получал. Я научился писать репорты так, чтобы в них не было тестировщика, а был пользователь. И с тех пор никаких конфликтов с разработчиками у меня не возникало. А я стал следить за своим мировосприятием, ведь это необходимо, также как поверка измерительных приборов.
Free_ze
Возможно, дело в подходе? «Треть коллектива» — это слишком много, чтобы списывать на странности отдельных людей.
Программисты с «тонкой душевной организацией» плохо бы уживались в коллективе, ибо код-ревью твоего кода коллегами
-конкурентамиеще «больнее» для самолюбия, чем просто баги, которые могли быть вызваны кучей факторов, иногда не зависящих от программиста (кривой мерж, неаккуратная работа коллеги с обообщенным кодом, ошибки сборки, конфигурации и т.п.).Конечно, на замечания QA-специалиста обижаться глупо и непрофессионально, но некоторый такт в отношениях должен быть с обеих сторон.
Maxilect_pr Автор
Любопытно, что с «тонкой душевной организацией» я сталкивался далеко не на всех работах (и не зря сделал в статье акцент на прошедшем времени, поскольку последнее время я действительно такого не встречаю). При этом я не возьмусь оценивать, как именно были выстроены процессы разработки в тех компаниях — способствовали они «профилактике» недовольства тестерами или нет. Я лишь отметил, что такой факт имел место.