На самом деле три — четыре года назад мне совершенно не хотелось становиться тестировщиком. Я даже не слышал о такой профессии и не имел совершенно никакого представления, чем эти самые тестировщики занимаются. В то время я был самым настоящим строителем. Бывших строителей не бывает, я и сейчас знаю, как организовать строительную площадку, какой кирпич нужно использовать при возведении перегородок в санузлах, что входит в состав прямых затрат по сводному сметному расчету и что надо делать, если вдруг обнаружил пьяного каменщика, а он отказывается дыхнуть в трубку. Но на тот момент эта была моя стихия. Работать мне нравилось. Не нравилось – получать за свою работу много наказаний и мало денег. Хотелось как-то по-наоборот. Конечно, «много» и «мало» это понятия весьма и весьма относительные. Зарплата в 300 долларов в месяц для главного инженера — это более чем достаточно. Так рассуждал директор ПМК и его, наверное, можно понять. «Наверное» — потому что у меня этого не получилось. Честно говоря, я даже и не пытался понять, почему в конце месяца морально выматывающей работы я получаю вшивых триста баксов и еще должен этому радоваться. На мои вопросы о повышении зарплаты я натыкался на недоумевающий взгляд и выслушивал пространные рассуждения о далеких перспективах в будущем, нетерпеливости молодого поколения, сложной экономической ситуацией в наше непростое время, и один раз даже услышал вопрос, звучавший буквально: «А зачем тебе деньги?». После подобных заявлений, я все больше убеждался в том, что нужно коренным образом что-то менять. Но вся проблема была в том, что в нашем провинциальном райцентре найти альтернативу можно только если твой дядя – большой начальник, либо у тебя есть деньги для разворачивания собственного бизнеса.
Работая в производственном отделе (еще до того, как меня назначили на должность главного инженера), мне приходилось все время проводить за компьютером, где я рассчитывал стоимость строительных работ, набирал всевозможные акты, протоколы, чертил в автокаде различные строительные узлы, планы, лазил вконтактике, сёрфил новости, в общем, занимался исключительно полезными и умными вещами. Естественно, я воображал себя очень продвинутым пользователем компьютера, потому что мог установить винду, фотошоп, прописать айпишники в настройках сетевой карты.
Как оказалось, моих знаний компьютера на уровне пользователя Microsoft Office и Opera (которыми я втайне гордился) для того чтобы стать хотя-бы junior QA, было совершенно недостаточно. Я бы это сравнил, например, с человеком, который пришел устраиваться на работу водителем автобуса, имея большой опыт поездок в качестве пассажира. Разбираться нужно было во всем сразу и практически с нуля. Но, я ведь хотел что-то поменять, и я решился.
Первой была книга Романа Савина «Тестирование DOT COM». Книга очень интересная, читается легко, и дает представление о профессии в целом. После этого я записался на недельный курс для начинающих тестировщиков. Этот курс должен был в условиях, приближенных к реальности, обучить юных падаванов премудростям тестирования. Вкратце, каждый вечер на закрытом форуме выкладывался вебинар длительностью примерно 20-30 минут и выдавалось задание по теме на примере тестового сайта. От нас требовалось написать домашнее задание и выслать его куратору, который либо принимал его, либо с замечаниями отправлял назад. Тут меня ждало разочарование и вот почему: Курс был действительно очень приближен к реальности. Если в выполненных заданиях куратор, а это была девушка, обнаруживала ошибки, то она не указывала на них, а задавала «наводящие вопросы» — и объясняла такое поведение тем, что в реальной жизни работодатель не будет выслушивать вопросы работника, а сам их будет задавать. Моя проблема была в том, что я во многих случаях так и не понял, куда наводят эти самые наводящие вопросы и какие на самом деле были ошибки в выполненных заданиях. Всего в курсе было шесть тем, в каждой от одного до трех домашних заданий и честно говоря, я выполнил только первые три домашки, да и то не на отличную оценку. Все остальное время ушло на разгадывание ребусов куратора и попытки схватить что-то из новых тем, чтобы успеть понимать, что происходит в общем чате группы. Двое из пяти человек группы справились со всеми заданиями и получили вожделенные сертификаты. Остальным, в том числе и мне, пришлось довольствоваться полученными знаниями. Этот опыт несколько меня обескуражил. Но несмотря на понимание того, что легко не будет, я решил не отступать.
Далее я искал чего-бы потестировать в реальных условиях, и в одном чатике мне предложили поработать над небольшим сайтом с поиском. Сайт был сделан очень просто, минимальный UI, система поиска и все. Прежде всего нужно было составить цель моей работы — поиск багов, подготовка баг-репортов, составление чек листа, написание тест кейсов, выполнение автоматизации при помощи Selenium IDE.
Я взялся за дело. Были составлен чек лист и тест кейсы, которые я зарепортил на GitHub. Были найдены и баги. Это действительно очень здорово, когда находишь баг, этакий фантомный жучок, который хитро спрятался и его нужно поймать. Работа над сайтом вернула мне настроение, испорченное неудачно пройденным курсом. Руки чесались заняться чем-нибудь еще.
На помощь пришел Python. Я начал изучать этот язык, как и все остальное, буквально с нуля. Писал “Hello world” (куда ж без него), знакомился с синтаксисом, печатал import this и читал дзен, узнал об основных понятиях ООП, таких как наследование, полиморфизм, инкапсуляция, а главное: понял, что программирование – это особое , мне кажется, что написать хороший код не легче чем, например, написать поэму. Есть статья «Не будите программиста» и в ней очень здорово написано, как мыслят программисты. Я не программист, но начинаю их понимать. Профессия тестировщика это не профессия программиста, но знать основы программирования ему просто жизненно необходимо. Нельзя, ведь, тестировать автомобили, ничего не зная об их внутреннем устройстве хотя бы в общих чертах. Кроме этого, при помощи питона можно написать коротенькие автоматические тесты, импортировав фреймворк unittest.
Кроличья нора глубока, но глядя на ее вход, невозможно сразу представить всю глубину ее глубин. Оказалось, чтобы пользоваться unittest, необходимо иметь представление о языке разметки HTML, знать, что такое ID элемента, как использовать CSS и XPATH селекторы, что такое теги, основные элементы страницы, etc. Это нужно знать для выполнения правильной проверки наличия, либо отсутствия определенных элементов на странице сайта. Я написал несколько скриптов, выполняющих проверки, используя различные локаторы, но, признаюсь, пришлось порядком поднапрячь знакомого программиста. Впрочем, мой знакомый мне с удовольствием помог, и, Лёха, если ты читаешь этот пост – огромное тебе спасибо!
Да, совсем забыл – еще одна вещь! Английский язык! Английский язык я изучал в школе, плюс в детстве мама пыталась учить нас английскому языку дополнительно, и в результате у меня остались какие-то знания. После этого английский был заброшен за ненадобностью, а некоторое количество англицизмов в повседневной жизни ну никак нельзя назвать языковой практикой. На стройке он не нужен, но вот в IT он жизненно необходим. Сейчас уровень моего знания английского языка Pre-Intermediate, я могу составлять фразы и поддерживать несложную беседу, пойму технический монолог, при условии, если собеседник не будет говорить слишком быстро, глотая буквы, тогда я могу потерять нить разговора и мне придется переспрашивать. Говорила мне мама – учи английский! Но кто ж слушает маму? В моем городке из курсов английского только частные уроки от соответствующих учителей, которые хотят подзаработать в свободное время, но мы не ищем легких путей. Ведь есть же интернет! Lingualeo, Ororo, YouTube, весь английский мир к моим услугам! Но и тут оказалось не все так просто.
Самостоятельно учиться довольно трудно. Оказывается, за время работы на государство, я настолько привык к пинкам, что теперь, когда их не стало, мне было очень трудно заставить себя сделать хоть что-то. Как это выражалось? – а вот так: садишься за стол, берешь конспект, ручку, включаешь комп, заходишь на ютуб и видишь там видосик про ковку якутского ножа из подшипника, и ну как вот его не посмотреть?? Заканчивается все это какой-нибудь статьёй на лурке в два часа ночи, тридцать открытых вкладок и английского там не больше, чем букв в адресной строке браузера. С этим очень тяжело бороться, но я смог. Смог извернуться и дать сам себе пинка под задницу, коль уж она его так просит. И это помогло. А еще мне очень помогла вот эта статья, здесь написано, почему прокрастинаторы прокрастинируют (то есть почему многим людям свойственно откладывать дела на потом), и как научиться управлять собственным временем. Если у кого-то есть такие же проблемы – прочитайте её!
Спрашивая у знакомых, кто как-то связан с разработкой, я нашел команду программистов, которые работали над одним интересным проектом, и у них в команде не было позиции QA. Я попросил взять меня в команду на добровольных началах. Для меня сейчас наиболее ценен опыт работы, поэтому я предложил поработать у них в команде без оплаты, потому что начинать когда-то нужно. К сожалению, неопытных тестировщиков (как и других начинающих работников) брать на работу не сильно хотят. Всем подавай с опытом не менее трех лет и минимум год в качестве автоматизатора. И, со стороны нанимателя, это правильно, но мне от этого не легче.
Меня приняли очень хорошо. Команда занималась разработкой и поддержкой браузерного приложения, основной задачей которого являлся расчет стоимости выполняемых работ строительной организации — потенциального покупателя этого приложения с последующим формированием необходимых документов в pdf формате. Кроме этого, там было еще много дополнительных фич, которые добавлялись в процессе разработки приложения. UI был на английском и немецком языках, так как заказчиком выступал субъект из Германии. Подробно рассказывать о приложении я не стану, так как связан договором о неразглашении информации, да это здесь, наверное, и не нужно. Главное то, что я начал участвовать в реальном проекте! И все заверте…
Мы договорились, что участвовать в проекте я буду удаленно. В команде были разработчики не только из Беларуси, но из Украины. В 11.00 по Минскому времени обычно начинался групповой созвон по Скайпу, в течении которого представитель Заказчика формулировал задачи для выполнения, он же, одновременно являясь тестировщиком, описывал найденные баги и создавал тикеты в Jira. Разработчики отчитывались о выполненной работе, делились соображениями о способах реализации предлагаемых фич, описывали проблемы, с которыми они сталкивались при разработке и предлагали способы их решения. Это был полноценный рабочий процесс и я был его частью! Все беседы, естественно, велись на английском языке и для меня это был очень полезный и интересный опыт. Как оказалось, мне было несложно понимать английскую речь, а встречающиеся незнакомые слова я сразу выписывал в свой словарик. Сложнее было в те моменты, когда мне необходимо было что-то сказать самостоятельно, но, к чести команды и Заказчика, меня терпеливо слушали и помогали, если мне было трудно подобрать слова.
Свою работу начал с изучения приложения. Нужно было знать, что оно, собственно, может делать. Документации не было, практически, никакой. Единственным документом, который я смог увидеть, была презентация PowerPoint со слайдами, на которых были скрины сайта с комментариями, как все должно работать. Поразмыслив, я начал писать некий текст со скриншотами страничек приложения, который мог бы являться прикладным пособием, помогающим человеку, незнакомому с продуктом, разобраться в особенностях программы. Но очень скоро его пришлось забросить, так как нужно было тестировать сайт.
Разработка программного обеспечения в нашей команде велась, на мой взгляд, по принципам гибкой модели (agile model). Одним из тезисов Agile-манифеста является цитирую: “Работающий продукт важнее исчерпывающей документации”. Хорошо это, или плохо — об этом написано много и единой точки зрения на этот счет, насколько я успел понять, нет. Но одно было понятно наверняка: здесь проблемы решались по мере поступления, и долгосрочное планирование практически не велось. Все это было связано с тем, что команда была совсем небольшой – 5 человек, я пришел шестым. Программисты, реализовав какую-нибудь фичу, либо закрыв очередной баг, давали мне задание протестировать изменяемую область приложения. Все работы велись на тестовом сервере, релизы на рабочий сервер выкатывались после тестирования не реже одного раза в неделю. Моей задачей было smoke тестирование, я просто заходил на страничку и проверял, не сломалось ли чего-нибудь. После этого я проверял (насколько мне позволяли мои постепенно увеличивающиеся знания продукта), как работает остальной основной функционал. Я находил баги! Баг-репорты я поначалу оформлял как New issues в GitHub но вскоре мне разрешили оформлять их тикетами в Jira.
Было очень интересно найти баг, повторить его в разных браузерах, разных операционных системах (я установил Ubuntu 16.04 и Windows 10 64 bit на своем компьютере), потом описать его, описать шаги для его воспроизведения, приложить скриншоты. Категорийность бага определял руководитель проекта. Он же просматривал созданный мной тикет и давал замечания, если они были. Для собственного удобства, я записал простейшую тест-сюиту в Selenium IDE, которая открывает все странички приложения последовательно, начиная с регистрации на сайте, проверяя его работоспособность — по сути smoke test, но даже это отлично ускоряло прогон чек-листа.
Нужно было начинать писать тест-план, о котором я читал, но как-то с трудом представлял себе этот документ. Про тест-план есть в книге Святослава Куликова “Тестирование программного обеспечения. Базовый курс”, и я прочитал, что это достаточно объемный документ, который, цитата: “описывает и регламентирует перечень работ по тестированию, а также соответствующие техники и подходы, стратегию, области ответственности, ресурсы, расписание и ключевые даты”. Из цитаты становится понятно, что такой документ не создашь за полчаса работы. Не создашь его и за один день, поэтому я принялся обдумывать основные положения тест-плана, делая какие-то наброски для себя. Но написать тест-план мне так и не удалось. Совершенно неожиданно для меня, руководитель проекта в общем чате сообщил о прекращении разработки приложения. Связанно это было с тем, что у Заказчика отсутствовали средства для финансирования разработки приложения. Команда была расформирована, и я остался не у дел. Признаюсь, я был довольно-таки разочарован, так как, не имея представления о финансовой стороне проекта, я не задумывался о возможном сворачивании всей работы над проектом. Расставаться с командой было жаль, но я получил рекомендации, и, самое главное, опыт, а это было очень здорово!
Что мне хочется сказать в итоге: моя история еще далеко не завершена. Это пока еще её самое начало. Сейчас я ищу работу удаленно в качестве junior QA, хочу участвовать в реальном проекте и готов работать в течении испытательного срока без оплаты труда, ведь мне нужен опыт, много опыта.
В целом я хочу сказать, что профессия тестировщика очень интересная. Я где-то читал про то, что тестировщиком работать скучно, однообразно и тому подобное, на что могу однозначно ответить — нет! У тестировщика очень нескучная работа, ведь это постоянный креатив, необходимость мыслить неординарно, уметь искать и находить нужную информацию в самых разнообразных источниках и этому нужно учиться. У каждого, кто пришел в тестирование своя история и у всех она разная, но с одинаковым результатом – работать в команде на позиции QA над реальным проектом. Я хочу получить этот результат, и для его получения я уже сделал немало. Да, признаюсь, пару раз были такие моменты, когда я начинал сомневаться в своем решении, но, поразмыслив, я понимаю, что решение правильное, просто это моя дорога и не всегда она прямая и ровная.
Если Вы решили стать тестировщиком – это классно! Нужно постоянно идти вперед, даже если кажется, что все очень сложно и непонятно. Будут подводные камни, будет непросто, к этому нужно быть готовым и каждую неудачу рассматривать как ступеньку вверх. Пусть мой рассказ послужит неким импульсом для тех, кто решил выбрать эту профессию, но еще не решился сделать первый шаг. Шагайте смело! У Вас все впереди!
Автор: Vlad_Zankevich
