Распространено мнение, что самый быстрый путь в IT лежит через тестирование. Так ли это и что нужно знать будущему тестировщику, рассказывает Александр Логунов, инженер по тестированию КОМПАС-3D, автор статьи на Хабре, спикер конференции DevConf АСКОН.

Ты по образованию инженер-приборостроитель. Как ты оказался в тестировании программного обеспечения?

Мою специальность можно назвать универсальной: в Рязанском радиотехническом университете мы изучали электронику, статистику, немного программирование. Так что мое образование дало мне широкий простор для выбора места работы, например, я мог прийти на любой завод и при трудоустройстве ответить на любой вопрос.

Первые пять лет после окончания вуза я действительно работал на заводах, а потом захотелось сменить обстановку. Оставаться конструктором, работая с гостайной и попрощавшись с загранпаспором, у меня желания не было. Но одновременно был опыт работы с разными системами проектирования (САПР), поэтому вакансия инженера по тестированию КОМПАС-3D в АСКОН показалась мне подходящей.

Что еще привлекло тебя при выборе работодателя?

Мне была интересна тема создания САПР, а в России не так много подобных компаний. К тому же, офис разработки находится в Рязани, где я живу. Поэтому все сложилось.

Насколько сложно было входить в новую профессию?

Совсем несложно. Но чтобы стать специалистом по тестированию, нужно иметь опыт работы с теми решениями, которые ты собираешься тестировать, потому что эта работа очень похожа на повседневное использование продукта. И хотя с КОМПАСом я сталкивался только в университете, был хорошо знаком с CAD-системами как с классом программного обеспечения.

Сколько времени тебе понадобилось, чтобы полностью влиться в работу?

Чуть больше месяца. Испытательный срок длится три месяца, из которых первые два – это учеба: сначала изучение КОМПАСа, а затем – тестирования. Потом начинается настоящая работа. Но я пришел в АСКОН в конце весны, накануне сезона отпусков, поэтому на второй месяц ко мне уже «прилетела» задача по тестированию конвертора. Тогда я и понял, что работа оказалась именно такой, как я себе представлял.

Понадобилось ли тебе дополнительное обучение, курсы?

Мне кажется, каждый, кто входит в IT, подумывает о том, чтобы освоить разработку хотя бы простых скриптов. Мне тоже это было интересно, и я воспользовался предложением АСКОН пройти курс по Python. А поскольку были задачи, которые предстояло решить с помощью этих знаний, то и учеба шла довольно бодро.

Кроме того, когда я первое время приходил на митинги разработчиков, то не понимал, что они мне говорят. Казалось, есть «поле» тестировщиков и «поле» программистов, а между ними – пропасть. Но мы используем общие инструменты и занимаемся одним делом. Поэтому тут курс по Python тоже помог – я стал лучше понимать разработчиков.

А какой заводской опыт ты перенес в АСКОН?

Раньше я очень много «ковырялся» в ГОСТах и на испытательном сроке находил ошибки, с ними связанные: опечатки, устаревшие стандарты, — или в обучающих материалах замечал шаги, которые, с точки зрения конструктора были не совсем целесообразны.

Однако со временем от частностей я стал переходить к общему и видеть больше закономерностей. Если первое время я относился к КОМПАС-3D в большей степени как пользователь (и тут сказался мой предыдущий опыт), то постепенно во многих местах начал видеть общее, закономерное поведение. Теперь это позволяет за меньшее время покрыть автотестами больше случаев. Но одновременно притупляется конструкторское «чутье», уступая место «чутью» тестировщика, когда в большей степени смотришь на нутро продукта.

Кроме программистов, с кем еще ты работаешь?

С аналитиками – еще до начала итерации разработки они составляют требования, заводят так называемые истории в баг-трекере. Если у меня возникают какие-либо вопросы при их чтении, я их сразу задаю аналитикам.

Кроме того, инженер по тестированию помогает аналитику уточнить задание. Обычно в самом начале оно еще не полностью проработано. Поэтому и нужно сначала «пощупать» продукт, чтобы затем передать корректировки.

Чем еще занимается тестировщик?

Несмотря на расхожее мнение, в наши обязанности входит не только поиск ошибок, но и сопровождение ошибок, которые нашел кто-то другой, в том числе пользователи. Техподдержка заводит ошибку, а мы должны упростить сценарий работы с САПР. Но мне больше всего нравится находить истинную причину проблемы, азарт вызывает именно «расследование» вылета. Если КОМПАС упал, то это успех.

Чей?

Только тестировщика :)

А что насчет срочных задач?

Они иногда случаются, например, когда приходят ошибки от приоритетных заказчиков, которые нужно разобрать вне очереди. Тогда приходится немного ужаться или часть текущей задачи перенести на начало следующего спринта. Но запросов, которые бы совсем выбивали нас из графика, не бывает.

Что требуется от команды, чтобы тестирование проходило слаженно?

Очень важно наличие в команде человека, который знает, кто насколько загружен, и который мог бы перераспределить задачи.

Ты упомянул, что тебе было интересно изучать Python. Расскажи подробнее о том, куда это привело.

Мне интересно все, что связано с автоматизацией. Это творческая работа: мне нравится что-нибудь сделать, нажать на кнопку и увидеть результат. К слову, по этой же причине в старших классах я изучал веб-верстку.

Сейчас заниматься автоматизацией мне позволяет как раз знание Python. Например, один из подготовленных скриптов помог ускорить автотесты, а как следствие — избавиться от лишней и даже вредной информации. Также на Python я написал программу, которая дает возможность искать КОМПАС-документы с определенными параметрами (прим.: подробнее читайте в статье на Хабре).

Почему, по-твоему, автоматизация – это творческая работа?

В Рязанском подразделении она в основном делается по собственной инициативе. Планируя работу на спринте, мы стараемся его не перегружать. Обычно есть немного свободного времени как раз в начале, когда программисты еще не «выкатили» задачу на тестирование. Тогда мы можем закрыть долги по предыдущим спринтам, либо выполнить какую-то дополнительную работу: подготовить статью или написать какой-нибудь полезный скрипт.