О работе девушки-тестировщика игрового проекта

в 15:00, , рубрики: game development, qa, vircities, Блог компании IlkFinKom, боль, женская история, кот, социальная игра, Тестирование игр

Привет!

Меня зовут Александра, я работаю тестировщиком игрового проекта VirCities, о котором рассказал в общих чертах мой коллега ранее в этой публикации. В свою же очередь, я хотела бы поделиться своей историей о том, как же живется девушке в «мужском царстве» GameDev и через что пришлось пройти в ходе разработки нашего проекта.

О работе девушки-тестировщика игрового проекта - 1
Крайне необходимый и полезный в работе девайс.

Все началось с переезда в соседний город в октябре 2012 года. По образованию я профессиональный переводчик с английского и новогреческого на русский, но так сложилось, что в основном я переводила техническую литературу, в том числе и по программированию. Как-то раз, одолеваемая тягостными думами о том, что редактор не заплатил мне за последний перевод книги и пропал, на глаза мне попалось объявление о наборе на курсы тестировщиков в одной крупной IT-компании. А почему бы и нет? Английский, сами понимаете, на уровне, а постоянная работа с техническими материалами уже не вызывали никакого трепета перед непонятными многим аббревиатурами типа UI. Проект, на базе которого нас обучали был «суров» и относился к медицине, и достаточно быстро набил всем нам оскомину, но бросать тестирование мне не хотелось. После окончания курсов я приступила к поиску работы и натолкнулась на объявление о поиске тестировщика игрового проекта. Так я и попала в команду VirCities.

Начало работы

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

Я сразу же решила узнать, что не так было с тем самым злополучным квестом, который не смогла сдать. Все оказалось до боли тривиально — это не баг, это фича ©. Все упиралось в систему юзабилити, которую потом пришлось переделывать, а потом еще раз, при переходе на мобильную платформу. Если в кратце, то собака была зарыта в том, что после выполнения квеста нужно было идти на отдельную вкладку квестов, находить нужный, открыть и только потом ты получал доступ к заветной кнопке СДАТЬ. Ад, Гоморра и Содом. И все это приходилось тестировать, ну вы сами все понимаете. Сейчас мы работаем над приведением в единый стиль и мобильного, и веб-функционала, что само собой, так же доставляет немало радостных моментов.

Все мы работаем удаленно и разбросаны иногда на тысячи километров друг от друга. Все общение и обсуждение рабочих моментов велось через скайп-конференции.

Немного о команде и положении дел

Правда, я была не единственной девушкой в команде. Была еще девочка-копирайтер, но она всегда, как мне казалось, тихо сидела в углу и жевала клей — ее не было ни видно, ни слышно 99% времени. Мне же, исходя из специфики работы постоянно приходилось пинать разработчиков и доказывать им, что вот тут, да-да, именно тут, все же баг и хватит списывать на фичи, работайте уже. Обычная, будничная ситуация для любого QA-инженера, как я думаю. Процесс пинания разработчиков часто осложнялся тем, что количество документации по проекту поражало воображение. Строго говоря, ее попросту не было.

Приходилось использовать внутреннюю wiki, которая готовилась для игроков, где шатко-валко описывалась игровая механика и предполагаемая работа тех, или иных модулей проекта. Это спасало только частично, потому что документация по UI и работа бэка описаны просто нигде не были, единственный источник информации — головы разработчиков. Почти полгода мне приходилось заниматься львиную долю времени в основном эксплоративным и регрессионным тестированием, т.е. тыкаться носом как слепой котенок во все углы подряд.

Конечно, по ходу работы и роста команды все эти «детские» болезни мы смогли преодолеть, потому что на определенном этапе стало понятно даже самым тугим — без документации и описания того, что как и когда делалось нормальный продукт мы выпустить не сможем. Очень повезло и в том, что все рабочие трения с разработчиками, в итоге, никак не повлияли на наши взаимоотношения как команды, чему я очень рада.

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

Есть отличная шутка про то, что было бы, если бы врачи работали как программисты:

— Доктор, у меня болит нога, помогите!
— Очень странно, у меня такая же нога и ничего не болит.

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

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

Привет, автоматизация!

А вот потом началась самая боль — автоматизация функциональных тестов тогда еще веб-проекта с использованием селениума. Капитан нашего корабля принял решение нанять мне в помощь еще одного парня, с которым мы неплохо поладили. В последующем именно на него легла основная нагрузка по составлению тест-планов и тест-кейсов, я их ревьюила, а потом уже вместе мы покрывали их автоматическими тестами.

Т.к. опыта в программировании или знания какого-либо языка программирования у меня не было (книга про Питон для детей не считается же, ну), то был избран читерский вариант: берем инструмент Selenium IDE, записываем сценарий, экспортируем для связки Ruby+Rspec, подшаманиваем боем в бубен и получаем профит.

Но и тут боль началась почти сразу — связка Ruby+Rspec некорректно работала под Win. Уж не знаю, почему, но не работала. Спасло меня то, что ранее я познакомилась с профильным для меня, как порядочной девушки, линем, а именно Ubuntu, которая всегда висела второй системой в ожидании звездного часа. Смахнув пыль с Ubuntu и обновившись до последней актуальной версии на нее были накачены необходимые для работы пакеты. И вот тут уже Rspec+Ruby пошел-поехал как надо.

Радость, слезы счастья, танцы на улицах? Уже! Selenium IDE выдает странный выхлоп в некоторых случаях, поэтому тесты приходилось очень существенно допиливать. До этого момента я и раньше иногда пользовалась порталом stackoverflow, но теперь он стал моим лучшим другом, почти как мой кот. Как итог IDE был, по сути, заброшен — проще написать тест руками.

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

А еще селекторы. Долбаные селекторы, с помощью которых вебдрайвер цепляется за элементы UI. Во многих случаях он не цеплялся. Самым прозрачным решением для меня было использовать xpath.
Я не думаю, что я рассказала о каких-то принципиально новых проблемах в тестировании, да и не претендовала на это. Описанное выше — боль того, с чем мне пришлось столкнуться работая над VirCities. Практически для каждого нового функционального теста мы находили свои решения, но все равно у нас есть небольшой процент ложных срабатываний.

А вот потом пришло озарение, о котором рассказывалось в предыдущей статье и мы начали переход с веб-платформы на мобильную. Этот период моей жизни я называю Великая Боль 2014 года.

Тестирование на мобильных платформах

Командование поставило мне, как проверенному бойцу следующую задачу: найти решение для автоматизации функциональных тестов на мобайле. А мобайл у нас и под iOS, и под Android и под WinPhone.

Что делать в подобных ситуациях? Правильно, гуглить! И хорошо погуглив, мы нашли для себя такой вариант как Appium. Подходит для Android, так и для iOS. Установка там была описана простая, запускается тест также через Rspec, использует тот же гем селениум-вебдрайвер, все нам знакомо и «легко реализуемо».

Ага, уже. У меня все посыпалось на первом же шаге — установке Android SDK ( Appium с iOS работает только под MacOS, поэтому начала с адроида — не было у меня еще мака :) )
Android SDK не хотел становиться, не хотел видеть PATH, да много еще чего не хотел. В общем, поставила.
Дальше больше — сам Appium. Я его ставила через npm -g, но нужно это было делать не из-под рута — такие были рекомендации по его установке. А без рута он устанавливаться не хотел. А с рутом — не хотел работать. Тадам! Магия! Выход был найден (открыть папку для записи, привет, кэп), все пути и зависимости настроены, Appium запущен. Это все заняло 7,5 часов моего рабочего времени. А написание первого теста и его запуск заняли 5 минут, все как я люблю :).

Так-c, как вы поняли, аппиум был покорен, тесты пишутся, обновляются и поддерживаются. Окей, справились, живем. Имеется небольшая боль в определением локаторов, но родные инструменты SDK с этим, вроде как, справляются. Ну и само собой, иногда приходится использовать методы тыка, куда же без них.

Посмотрев, что у меня все хорошо и я нахожусь опять в состоянии душевного равновесия, руководство посчитало, что функциональных тестов будет мало. И вновь мне была поставлена задача: покрыть код проекта тестами с использованием связки Jasmine+Karma. Как я говорила раньше, все мои знания языков программирования ограничивались детской книжкой по изучению питона и никакого опыта и знаний в js у меня не было.

Конечно, один из разработчиков помогал мне советами, но особо часто его шатать было нельзя, ему же свои задачи делать надо. Плюс он использует coffeescript, backbone и еще кучу страшных полузнакомых для меня слов и иногда от его помощи легче не становилось.

Что делать?

Был пройден курс js на кодакадемии, затем изучен док по coffeescript, склонирован проект из нашего репо. Установлены все библиотеки и зависимости. После всего этого я написала самый элементарный тест типа:

describe 'wow, such test', ->
 it 'should run the test', ->
  expect(@foo).toBeDefined.

И-и-и Karma выдает ошибку и даже не запускает тест!

В общем, как можно было уже догадаться, конфиги karma, jasmine и requirejs не были настроены. Гугл в помощь! Через несколько попыток и вариаций конфигурационных файлов и структуры тестового проекта на локальной машине все срослось. И мой such test был успешно завершен (я заменила @foo нужным значением из рабочего проекта). Это было великолепно.

Сейчас уже написано энное количество тестов, все успешно выполняются, я продолжаю над ними работать и подумываю также использовать и SinonJS для этой связки, но еще не пришла к окончательному решению. Вполне возможно, что в ближайшее время руководство придумает для меня еще какое-нибудь приключение.

Ну и еще я хотела бы поделиться своим опытом возвращения в состояние душевного равновесия. Все просто — это кот и страйкбол.

Познакомьтесь, мои красавцы:

image

И так как мы видим, что желающие потрогать нашу игру имеются в достаточных количествах, закрытой альфе для читателей Habrahabr, Geektimes и Мегамозг быть однозначно!

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

Всем спасибо за внимание :)

Автор: smartdrop

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js