Профессия: тестировщик ПО
Хочу рассказать, что за профессия - тестировщик программного обеспечения - и как я им стала.
На написание поста вдохновила подруга, которая собирается стать тестировщиком. Решила, что проще все описать один раз в статье.
Сразу предупрежу - скорее всего, не всем будет интересно ее читать. Будет много технических терминов и описание процессов. Я писала это в помощь тем, кто начинает или собирается работать в этой сфере.
Многие мои друзья и знакомые спрашивали - а где ты работаешь? И когда я говорила, что я тестировщик в сфере айти, обычно получала кучу вопросов: "А что это? Что ты там делаешь? Ты программист?"
Вот сейчас я наконец расскажу все подробно - что за зверь такой тестировщик, и чем он занимается на работе, когда не постит в фейсбуке котиков.
Для меня все началось с того, что я переехала из Москвы, где проработала несколько лет, обратно в родной Минск. В Москве я работала личным помощником директора крупной компании, и зарплата была приличной. Приехав на родину, я столкнулась с тем, что работы помощником крайне мало, зарплаты маленькие, а требования - ого-го. Из серии "три высших образования, пять языков в совершенстве, опыт юриста и бухгалтера и рост от 180 см". Многие вакансии были даже с интимом (да-да, так и написано прям в тексте вакансии!). Я сначала приуныла, а потом решила, что это отличная возможность сменить профессию. Еще работая личным помощником, я вела корпоративный сайт, в нем был ужасный редактор, пришлось выучить HTML и CSS. Даже думала стать веб-дизайнером, изучала разные трюки.
Стала искать работу в сфере айти - везде нужен опыт, зато зарплаты по сравнению с другими сферами очень приличные. И вот наконец наткнулась на вакансию тестировщика без опыта работы, но с хорошим английским. Я примерно представляла себе, что может делать тестировщик ПО. Постоянно натыкалась на разные ошибки на сайтах в Интернете (собственно, так и взяла под свою опеку корпоративный сайт, где я не только находила баги, но и чинила их). Так что решила попробовать.
Баги - это название ошибок в программе на сленге айтишников. Была такая история когда-то на заре компьютерной эры, когда ЭВМ были очень большими: в компьютере обнаружился сбой. Оказалось, что в него забрался жучок (по-английски - "bug"). Оттуда и пошел этот термин.
Английский у меня свободный, так что меня взяли без проблем. Оказалось, что компания набирала сразу много людей для нового англоязычного проекта. Как показала практика, проще научить тестировать того, кто знает английский и ничего не знает об айти, чем готового тестировщика научить английскому. Компания организовала тренинг в течение нескольких недель, чтобы ввести нас в курс дела.
И вот мы, человек так пятнадцать, сидим на тренинге. Когда все знакомились, выяснилось, что почти все из нас по образованию экономисты-менеджеры. Очень востребованная в Беларуси профессия.
На тренинге нам загадывали задачки на логику и математику, рассказывали, как тестировать наугад, без документации. Давали задания на компьютере - сделать скриншот, быстро набрать и скопировать текст. Ничего сложного. Работали с MS Word, Excel и Access. Писали простые запросы в MySQL.
В общем и целом, тестировщик - это человек, который ищет ошибки в программах, написанных разработчиками. Есть такая аксиома разработки ПО, которую я хорошо запомнила с тренинга: "Программ без багов не бывает".
Тестировщиков по-другому называют Quality Assurance Engineer или просто QA - то есть "инженер, который обеспечивает качество".
Тестировщик - это совершенно необходимый в айти человек. Вот представьте: компания заказала программистам какую-то программу. Допустим, заказчик даже хорошо знает, что именно ему нужно, требования к программе хорошо сформулированы и задокументированы. Программист все сделал и отдал заказчику.
А оно не работает. Или работает не так, как ожидалось. А все потому, что здесь пропущено одно звено.
Перед сдачей программы заказчику, даже еще до того, как программа написана, в игру вступает тестировщик. От него требуется:
1) Узнать требования к программе.
2) Составить план тестирования (это называется - тест-план).
3) Написать все возможные сценарии работы программы (это называется тест-сценарии).
4) В сценариях расписать по шагам, что именно должно происходить при нажатии на ту или иную кнопку, где какой текст должен быть написан, какие сообщения об ошибках, какой цвет иконок - и так далее. Это называется тест-кейсы или юз-кейсы (use cases).
5) Согласовать тест-план, тест-сценарии и тест-кейсы с заказчиком.
6) Наконец, когда программа готова, протестировать ее по своим же написанным кейсам и сделать отчет об ошибках.
Отчет делается в согласованном с заказчиком формате - чаще всего в специальной системе для отслеживания ошибок (на нашем сленге она называется "баг-трекинговая система"). Иногда, если заказчик такой системой не пользуется, отчет делается просто в Excel.
Самые важные детали отчета:
- Описание бага с шагами его воспроизведения.
- Ожидаемый результат (иначе разработчик может просто не знать, как именно этот баг нужно исправить).
- Скриншот - снимок экрана с картинкой неработающего функционала. Если возможно, скриншот нужно прикладывать всегда - разработчики получают большое количество багов, читать долгие описания им некогда, так что если они могут, глянув на картинку, понять, в чем дело - это сильно облегчит их работу. Тестировщиков, которые не прикладывают скриншоты к описаниям багов, очень не любят.
- Приоритет бага, или его важность для починки. Это тоже необходимый элемент, потому что багов может быть больше сотни, и нужно быстро решать, какие чинить в первую очередь. Если ошибка блокирует работу программы или важную функцию - приоритет у нее будет самый высокий. Если это просто опечатка или кривоватый дизайн - приоритет низкий, подождет своей очереди.
На тестировщике лежит большая ответственность - ведь именно он решает, можно ли отдавать программу в пользование! В разных компаниях по-разному, но иногда менеджер проекта буквально спрашивает у старшего тестировщика: "Можно?" И с замиранием сердца ждет ответа, потому как сдавать нужно было еще на прошлой неделе.
Часто тестировщики выполняют еще одну важную функцию - согласование приемки с заказчиком. Это называется "УАТ" или приемочные тесты от английского "User Acceptance Testing".
В этом случае тестировщику еще до того, как программа готова, необходимо написать критерии ее приемки заказчиком. То есть, нужно написать сценарии, которые будут не такими подробными, как тест-кейсы, проверяющие функционал программы. Это более общие шаги, которые пользователь обязательно предпримет при пользовании программой, без углубления в детали. Всем - и заказчику, и исполнителю - известно, что мелкие ошибки в работе программы все равно будут. Все их найти и починить просто невозможно. Поэтому нужно выработать критерии, по которым работа будет принята - жизненно важные для работы функции, которые обязательно должны работать. А остальное починится потом, по мере нахождения пользователями. Программа же в это время вполне себе будет работать и приносить пользу.
Все это я узнала уже после тренинга, в процессе работы. А пока что я имела только совсем общее представление о том, чем придется заниматься.
Потом нам стали объяснять специфику конкретного проекта. Вот тут у меня появились некоторые сомнения относительно моей новой профессии и своих собственных умственных способностей. Абсолютно все было непонятно. Интерфейс у программы очень сложный, документации практически нет, куда тыкать, чтобы получить то, что от меня хотят - кто его знает. К тому же программа состояла из нескольких частей, причудливым образом между собой связанных.
После семи лет тестирования самых разных программ, я уже знаю, что все приходит с опытом. И понимание всяких сложностей, и умение быстро протестировать практически без документации. Чем больше разбираешься в разном программном обеспечении, тем легче понять новый софт. А еще из своего опыта я знаю, что документации почти всегда крайне мало. И даже знаю, почему - за нее, как правило, никто не платит.
На новом проекте нас сразу завалили работой по уши. Почти сразу мы поехали в командировку в Лондон - помогать англичанам с тестированием (как раз тот самый User Acceptance Testing). Работали по 18 часов в сутки. Сейчас я понимаю, что это было отличной школой, но тогда у меня просто взрывалась голова. Где-то через месяц-два работы я уже начала очень неплохо разбираться в том, что тестировала. Стала писать тест-кейсы с закрытыми глазами, а тестировать буквально во сне (работы было ДЕЙСТВИТЕЛЬНО так много).
Теперь я знаю, что на вхождение в любой проект требуется время. Сколько - зависит от сложности программы, наличия понятно написанной документации, коллег, которым можно задавать вопросы. И, конечно, собственной смекалки и опыта.
Вобщем, ничего супер-сложного в работе тестировщика нет. Английский нужен обязательно - большинство проектов англоязычные. Даже для русскоязычных проектов во многих компаниях принято записывать отчеты об ошибках на английском. Еще нужны терпение, усидчивость, внимание к деталям. И любовь к своей работе. Если тестировать вам не нравится, если вы не ловите кайф, находя очередную ошибку - скорее всего, тестировщиком вы долго не проработаете.
Ну а если это вы понимаете, что это ваше призвание, то всегда есть куда расти. Через несколько лет можно стать тест лидом и планировать тестирование целых проектов, распределять тесты, следить за работой младших коллег и обучать их.
Можно уйти в автоматизацию: писать автоматические тесты для программ. Здесь нужно будет подучить основы программирования и какой-нибудь язык, скорее всего, Java. Автотесты совершенно необходимы для крупных проектов, где невозможно охватить все ручным тестированием. И очень востребованы в компаниях.
Если вы любите писать и общаться (как я), можно стать бизнес-аналитиком или менеджером проекта. В ведомстве бизнес-аналитика - требования к программе, их выяснение у заказчика, описание в виде спецификаций, создание прототипов программ. Менеджер проекта занимается организационными вопросами: выясняет срок, который займет проект, следит за тем, чтобы сроки на выполнение отдельных заданий и проекта в целом соблюдались, чтобы каждый делал свою работу и не подводил остальных, распределяет задания, ведет график отпусков, общается с заказчиками и с командой.
Очень часто бывает так, что бизнес-аналитик и менеджер проекта - это одна и та же позиция с широкими обязанностями. Особенно на небольших проектах, где не нужны детальные спецификации и нужна только половинка аналитика, а не целый.
Но об этом - в следующих выпусках.