Главная » Хабрахабр » [Из песочницы] Хочу стать тестировщиком

[Из песочницы] Хочу стать тестировщиком

На самом деле три — четыре года назад мне совершенно не хотелось становиться тестировщиком. Я даже не слышал о такой профессии и не имел совершенно никакого представления, чем эти самые тестировщики занимаются. В то время я был самым настоящим строителем. Бывших строителей не бывает, я и сейчас знаю, как организовать строительную площадку, какой кирпич нужно использовать при возведении перегородок в санузлах, что входит в состав прямых затрат по сводному сметному расчету и что надо делать, если вдруг обнаружил пьяного каменщика, а он отказывается дыхнуть в трубку. Но на тот момент эта была моя стихия. Работать мне нравилось. Не нравилось – получать за свою работу много наказаний и мало денег. Хотелось как-то по-наоборот. Конечно, «много» и «мало» это понятия весьма и весьма относительные. Зарплата в 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. Кроличья нора глубока, но глядя на ее вход, невозможно сразу представить всю глубину ее глубин. Я написал несколько скриптов, выполняющих проверки, используя различные локаторы, но, признаюсь, пришлось порядком поднапрячь знакомого программиста. Это нужно знать для выполнения правильной проверки наличия, либо отсутствия определенных элементов на странице сайта. Впрочем, мой знакомый мне с удовольствием помог, и, Лёха, если ты читаешь этот пост – огромное тебе спасибо!

Английский язык! Да, совсем забыл – еще одна вещь! После этого английский был заброшен за ненадобностью, а некоторое количество англицизмов в повседневной жизни ну никак нельзя назвать языковой практикой. Английский язык я изучал в школе, плюс в детстве мама пыталась учить нас английскому языку дополнительно, и в результате у меня остались какие-то знания. Сейчас уровень моего знания английского языка Pre-Intermediate, я могу составлять фразы и поддерживать несложную беседу, пойму технический монолог, при условии, если собеседник не будет говорить слишком быстро, глотая буквы, тогда я могу потерять нить разговора и мне придется переспрашивать. На стройке он не нужен, но вот в IT он жизненно необходим. Но кто ж слушает маму? Говорила мне мама – учи английский! Ведь есть же интернет! В моем городке из курсов английского только частные уроки от соответствующих учителей, которые хотят подзаработать в свободное время, но мы не ищем легких путей. Но и тут оказалось не все так просто. Lingualeo, Ororo, YouTube, весь английский мир к моим услугам!

Оказывается, за время работы на государство, я настолько привык к пинкам, что теперь, когда их не стало, мне было очень трудно заставить себя сделать хоть что-то. Самостоятельно учиться довольно трудно. – а вот так: садишься за стол, берешь конспект, ручку, включаешь комп, заходишь на ютуб и видишь там видосик про ковку якутского ножа из подшипника, и ну как вот его не посмотреть?? Как это выражалось? С этим очень тяжело бороться, но я смог. Заканчивается все это какой-нибудь статьёй на лурке в два часа ночи, тридцать открытых вкладок и английского там не больше, чем букв в адресной строке браузера. И это помогло. Смог извернуться и дать сам себе пинка под задницу, коль уж она его так просит. Если у кого-то есть такие же проблемы – прочитайте её! А еще мне очень помогла вот эта статья, здесь написано, почему прокрастинаторы прокрастинируют (то есть почему многим людям свойственно откладывать дела на потом), и как научиться управлять собственным временем.

Я попросил взять меня в команду на добровольных началах. Спрашивая у знакомых, кто как-то связан с разработкой, я нашел команду программистов, которые работали над одним интересным проектом, и у них в команде не было позиции QA. К сожалению, неопытных тестировщиков (как и других начинающих работников) брать на работу не сильно хотят. Для меня сейчас наиболее ценен опыт работы, поэтому я предложил поработать у них в команде без оплаты, потому что начинать когда-то нужно. И, со стороны нанимателя, это правильно, но мне от этого не легче. Всем подавай с опытом не менее трех лет и минимум год в качестве автоматизатора.

Команда занималась разработкой и поддержкой браузерного приложения, основной задачей которого являлся расчет стоимости выполняемых работ строительной организации — потенциального покупателя этого приложения с последующим формированием необходимых документов в pdf формате. Меня приняли очень хорошо. UI был на английском и немецком языках, так как заказчиком выступал субъект из Германии. Кроме этого, там было еще много дополнительных фич, которые добавлялись в процессе разработки приложения. Главное то, что я начал участвовать в реальном проекте! Подробно рассказывать о приложении я не стану, так как связан договором о неразглашении информации, да это здесь, наверное, и не нужно. И все заверте…

В команде были разработчики не только из Беларуси, но из Украины. Мы договорились, что участвовать в проекте я буду удаленно. 00 по Минскому времени обычно начинался групповой созвон по Скайпу, в течении которого представитель Заказчика формулировал задачи для выполнения, он же, одновременно являясь тестировщиком, описывал найденные баги и создавал тикеты в Jira. В 11. Это был полноценный рабочий процесс и я был его частью! Разработчики отчитывались о выполненной работе, делились соображениями о способах реализации предлагаемых фич, описывали проблемы, с которыми они сталкивались при разработке и предлагали способы их решения. Как оказалось, мне было несложно понимать английскую речь, а встречающиеся незнакомые слова я сразу выписывал в свой словарик. Все беседы, естественно, велись на английском языке и для меня это был очень полезный и интересный опыт. Сложнее было в те моменты, когда мне необходимо было что-то сказать самостоятельно, но, к чести команды и Заказчика, меня терпеливо слушали и помогали, если мне было трудно подобрать слова.

Нужно было знать, что оно, собственно, может делать. Свою работу начал с изучения приложения. Единственным документом, который я смог увидеть, была презентация PowerPoint со слайдами, на которых были скрины сайта с комментариями, как все должно работать. Документации не было, практически, никакой. Но очень скоро его пришлось забросить, так как нужно было тестировать сайт. Поразмыслив, я начал писать некий текст со скриншотами страничек приложения, который мог бы являться прикладным пособием, помогающим человеку, незнакомому с продуктом, разобраться в особенностях программы.

Одним из тезисов Agile-манифеста является цитирую: “Работающий продукт важнее исчерпывающей документации”. Разработка программного обеспечения в нашей команде велась, на мой взгляд, по принципам гибкой модели (agile model). Но одно было понятно наверняка: здесь проблемы решались по мере поступления, и долгосрочное планирование практически не велось. Хорошо это, или плохо — об этом написано много и единой точки зрения на этот счет, насколько я успел понять, нет. Программисты, реализовав какую-нибудь фичу, либо закрыв очередной баг, давали мне задание протестировать изменяемую область приложения. Все это было связано с тем, что команда была совсем небольшой – 5 человек, я пришел шестым. Моей задачей было smoke тестирование, я просто заходил на страничку и проверял, не сломалось ли чего-нибудь. Все работы велись на тестовом сервере, релизы на рабочий сервер выкатывались после тестирования не реже одного раза в неделю. Я находил баги! После этого я проверял (насколько мне позволяли мои постепенно увеличивающиеся знания продукта), как работает остальной основной функционал. Баг-репорты я поначалу оформлял как New issues в GitHub но вскоре мне разрешили оформлять их тикетами в Jira.

04 и Windows 10 64 bit на своем компьютере), потом описать его, описать шаги для его воспроизведения, приложить скриншоты. Было очень интересно найти баг, повторить его в разных браузерах, разных операционных системах (я установил Ubuntu 16. Он же просматривал созданный мной тикет и давал замечания, если они были. Категорийность бага определял руководитель проекта. Про тест-план есть в книге Святослава Куликова “Тестирование программного обеспечения. Для собственного удобства, я записал простейшую тест-сюиту в Selenium IDE, которая открывает все странички приложения последовательно, начиная с регистрации на сайте, проверяя его работоспособность — по сути smoke test, но даже это отлично ускоряло прогон чек-листа.
Нужно было начинать писать тест-план, о котором я читал, но как-то с трудом представлял себе этот документ. Из цитаты становится понятно, что такой документ не создашь за полчаса работы. Базовый курс”, и я прочитал, что это достаточно объемный документ, который, цитата: “описывает и регламентирует перечень работ по тестированию, а также соответствующие техники и подходы, стратегию, области ответственности, ресурсы, расписание и ключевые даты”. Но написать тест-план мне так и не удалось. Не создашь его и за один день, поэтому я принялся обдумывать основные положения тест-плана, делая какие-то наброски для себя. Связанно это было с тем, что у Заказчика отсутствовали средства для финансирования разработки приложения. Совершенно неожиданно для меня, руководитель проекта в общем чате сообщил о прекращении разработки приложения. Признаюсь, я был довольно-таки разочарован, так как, не имея представления о финансовой стороне проекта, я не задумывался о возможном сворачивании всей работы над проектом. Команда была расформирована, и я остался не у дел. Расставаться с командой было жаль, но я получил рекомендации, и, самое главное, опыт, а это было очень здорово!

Это пока еще её самое начало. Что мне хочется сказать в итоге: моя история еще далеко не завершена. Сейчас я ищу работу удаленно в качестве junior QA, хочу участвовать в реальном проекте и готов работать в течении испытательного срока без оплаты труда, ведь мне нужен опыт, много опыта.

Я где-то читал про то, что тестировщиком работать скучно, однообразно и тому подобное, на что могу однозначно ответить — нет! В целом я хочу сказать, что профессия тестировщика очень интересная. У каждого, кто пришел в тестирование своя история и у всех она разная, но с одинаковым результатом – работать в команде на позиции QA над реальным проектом. У тестировщика очень нескучная работа, ведь это постоянный креатив, необходимость мыслить неординарно, уметь искать и находить нужную информацию в самых разнообразных источниках и этому нужно учиться. Да, признаюсь, пару раз были такие моменты, когда я начинал сомневаться в своем решении, но, поразмыслив, я понимаю, что решение правильное, просто это моя дорога и не всегда она прямая и ровная. Я хочу получить этот результат, и для его получения я уже сделал немало.

Нужно постоянно идти вперед, даже если кажется, что все очень сложно и непонятно. Если Вы решили стать тестировщиком – это классно! Пусть мой рассказ послужит неким импульсом для тех, кто решил выбрать эту профессию, но еще не решился сделать первый шаг. Будут подводные камни, будет непросто, к этому нужно быть готовым и каждую неудачу рассматривать как ступеньку вверх. У Вас все впереди! Шагайте смело!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Mini AI Cup #3: Пишем топового бота

Участники много спорили о том, что будет работать и что не будет, высказывались и проверялись идеи от простых if’ов до обучения нейросетей, но топовые места заняли ребята с, так называемой, "симуляцией". В начале осени завершился конкурс по написанию ботов Mini ...

[Из песочницы] Fullstack – почему это клево, или как получать от работы удовольствие

Недавно на Хабре разгорелись нешуточные баталии в комментариях к заметке Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать Я попробую высказать свою точку зрения о том, что фуллстек – это на самом деле клево, ...