Книга «How Google Tests Software» теперь на русском!

Полтора года назад, когда вышла книга «How Google Tests Software», я загорелась перевести ее на русский язык. Я давно восхищаюсь Уиттакером, я переводила его статьи, слушала мастер-классы и считаю его самым крутым чуваком в мировом тестировании. Тогда я еще работала руководителем отдела тестирования в «Иннове», и компания поддержала мой проект.

С тех пор многое поменялось: я перестала заниматься тестированием, выпускала приложения для iOS, сейчас работаю продакт-менеджером большого веб-проекта. Уиттакер же еще в 2012 году ушел из Google в Microsoft, громко хлопнув дверью. 

Несмотря на все это, весь прошлый год я работала над книгой: договаривалась с издательством, пыталась организовать группу добровольцев для перевода текста (не получилось), искала переводчика, помогала переводить и редактировала текст, работала с дизайнерами над макетом и обложкой, утверждала корректуру и сверстанные макеты. Проект занял намного больше сил и времени, чем я рассчитывала, но результатом я осталась довольна.

И вот, в январе издательство «Питер» выпустило книгу на русском языке с нашим переводом и дизайном:

Книга уже продается на на Озоне, а еще ее можно скачать в электронном виде за 99 рублей (спасибо издательству Питер, что оно пошло нам навстречу с ценой).

Я хотела сделать книгу такой, чтобы мне самой захотелось прочитать ее. Обложку нарисовал Макс Дегтярев — его иллюстрации всегда хочется рассматривать. (Большинство книг про тестирование оформлены битами и байтами, автоматизация изображена в виде робота, а баги — в виде жуков. Рассматривать не хочется.) 

Мы не стали придумывать мифические аналоги словам «фреймворк», «коммит», «баг» и «фича». Как говорим — так и пишем. В книге разработчики и тестировщики Google рассказывают о своей работе так, как будто сидят напротив. Мы постарались сохранить это ощущение.

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

Этот проект очень личный для меня. Я считаю его своей лебединой песней в тестировании. Спасибо «Иннове», что проект состоялся. Лучшим результатом для меня будет, если в как можно большем количестве команд разработки начнут «тестировать, как в Google», грамотно применяя принципы к своему контексту.

Небольшой анонс: мы подарим книгу всем участникам конференции Agile Days. Читайте, загорайтесь и делайте свою разработку круче! 
Читать далее...

Тестирование должно добавлять ценность

В конце марта выступала на крутейшей IT-конференции в Новосибирске - CodeFest, рассказывала, что тестирование должно создавать ценность, а не просто давать оценку качеству.

В доказательство выступления - презентация и видео.

 За доказательством подхода - приходите к нам, расскажем и покажем, что это работает. И, кстати, нам нужна помощь!

Тестирование как инструмент оценки – в прошлом. Тестирование должно создавать ценность. on Prezi

Читать далее...

Крутое тестирование - это что?

Конечно же, это предоставление информации - максимально полно, максимально быстро, эффективным путем.

Дальше должен происходить анализ информации о багах и проблемах, и выявление причин возникновения проблем.

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

И просто обязательно - владение задачами на решение проблем, помощь и требовательность, драйвинг и в конечном итоге решение проблемы. Часто не своими собственными силами.

Это разработка решений. Это переход на уровень влияния на качество и обеспечения его.

Я уверена, что обеспечение качества должно вырасти из тестирования, а не быть инициативой руководства и внедряться сверху.

Чтобы этого добиться, нужны условия:

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

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

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

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

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

Нам сейчас нужен ведущий тестировщик-аналитик и инженер по автоматизированому тестированию.

Ждем вас, если вы думаете в эту же сторону!

Писать можно мне yulia.nechayeva AT inn.ru, можно на vacancy AT inn.ru
Читать далее...

Повышение качества со стороны тестирования

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

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



Читать далее...

Игра "Нереальное тестирование" на SQA Days, ИТОГИ.

На конференции SQA Days – 10 мы (Иннова) были спонсорами.


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

Судя по отзывам в твиттере и тому, что по просьбам посетителей мы продлили стенд ещё на один день, это удалось!

Фотографии здесь (при клике по фоткам откроются альбомы в ФБ):




Специально для конференции мы придумали игру: Нереальное тестирование (ТМ).

Правила:

Два на первый взгляд одинаковых сайта. Но только не для зоркого глаза тестировщика!
Задача игроков была - найти максимальное количество отличий в двух сайтах за игровую сессию.

У игрока было 10 минут, которые начинались по нажатию на кнопку Старт на первом сайте.

У сайтов были отличия 3х типов:

-- Статические (k=1) – можно обнаружить, на странице не действуя, как пользователь;
-- Динамические (k=2) – могут быть найдены только в ходе «использования» сайтов,
-- Сложные (k=5) – без специальных инструментов не найти!

И были Пасхальные яйца (win, k=7):
Мы заложили в Подвиги несколько пасхальных яиц, нахождение каждого давало 7 очков!
Появление на экране сообщения WIN свидетельствовало о нахождении игроком пасхального яйца.

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

Счет игрока складывался исходя из количества найденных отличий с учетом коэффициента категории. Общий рейтинг составлялся на основании заработанных игроками очков за одну сессию.

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

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

По результатам первого дня поиграть удалось пятидесяти участникам. Легендой стенда стал Петр Родин, который несколько раз отвоевывал первое место, но в итоге занял 4е.

Второй день был менее динамичен, да и длилась игра на 2 часа меньше. Поиграло 33 человека, два призовых места взяли Катя и Вика, выбрав стратегию объединения.

Очень было интересно наблюдать, как люди с разным опытом по-разному подходили к задаче.

Одни сразу же открывали исходники двух «главных» страниц, даже не авторизуясь, проводили в сравнении 6-7 минут, потом заходили внутрь сайтов и тут только понимали, что исследовали лишь малую часть.
Другие первым делом оценивали объем страниц и функциональности сайтов, и лишь потом приступали к поиску.
Одни делали упор на отличия в верстке, другие – в функциональности.
Одни старались найти как можно больше простых отличий, другие выбирали стратегию «мало, но WIN’ов».

Многие меняли стратегию после первого раза.

Отличная иллюстрация для исследовательского тестирования, на самом деле!

Мы оставили сайты в открытом доступе ещё на неделю, до 15 числа можно поиграть вот здесь:
http://inn.webumka.ru/test1/
http://inn.webumka.ru/test2/

На любые вопросы я отвечу в этой ветке форума, здесь же можно меряться результатами. Единственное правило – не спойлить!

15 декабря я опубликую список тех отличий, которые были внесены в приложения санкционированно, то есть – по ТЗ. Интересно сравнить с вашими списками.

Удачи!

Читать далее...

SQA Days 10: Команда, где каждый лидер

Моя презентация с SQA-Days 10.

Хочу поделиться теми принципами, которые помогли мне построить 2 суперэффективные команды тестирования в моей компании. В двух словах: в моих командах каждый специалист является лидером.

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

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

Команда, где каждый лидер on Prezi

Читать далее...

Соратники needed

Привет!

Ищем пополнение в команду тестирования Инновы. Про наши проекты можно посмотреть здесь. На наши мордашки можно поглазеть здесь.

Как устроен отдел.
Как работают игровые тестировщики.
Как работает веб-направление - буду рассказывать на agiledays.

Итак, нам нужен инженер по автоматизации тестирования. Это человек, которому мы доверяем самое основное - ядро проекта. Он читает код, он пишет код, он не только находит баги, но и локализует их. Скажу по секрету, его даже могут привлекать к код-ревью =)

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

Нам нужно расширять направление нагрузочного тестирования, потому что у нас масштабные планы.

Знаете, что самое, на мой взгляд, крутое на этой позиции? Таких вещей две.

Первая - свобода. Свобода для реализации своих идей. Можно менять тулы, можно пробовать подходы, можно участвовать в планировании разработчиков - можно не участвовать =) Вы будете лидером направления.

Вторая - быстрый фидбек. Мы релизим обновления системы самое редкое - раз в три недели. И каждого пользователи ждут, занеся палец над кнопкой мыши. Если мы оплошали - то видим это через минуту. Очень держит в тонусе.

Если Вы вместо Java знаете Python и умеете читать код на C++, я вам открою секрет, мне скоро понадобится и такой специалист.

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

Ну и напоследок, ведущие игровые тестировщики в два легендарных проекта Lineage II и Aion. Нам нужны люди, которые любят игру настолько, что готовы на ней работать. Которые готовы отдавать игре не 5 часов прогулянных пар, а 8 часов рабочего дня. Вы увидите мир игры изнутри. Вы узнаете пользователей с другой стороны.
Если Вы игрок и тестировщик - велкам.

Мы очень разные, но нас объединяет желание делать свою работу хорошо, делать продукты лучше. Мы вместе смеемся и вместе мониторим игровой форум допоздна, чтобы удостовериться, что обновление прошло успешно. Мы ездим на конференции и ходим пить пиво в Пилзнер, а коньяк - в комнату отдыха. Мы даем советы редакторам и принимаем советы от пользователей. Мы дружим с разработчиками, мы понимаем менеджеров, мы стараемся даже понять наших дизайнеров!

Мы - хороший отдел тестирования. Руководство никогда не отказывает нам в расширении штата или приобретении инструментов. Чтобы стать ещё лучше - нам нужны новые коллеги.

Я требовательный руководитель. Мы требовательная команда. А уж требовательнее, чем наши пользователи, нужно поискать =)

Если не боитесь - пишите мне на yulia DOT nechayeva AT inn DOT ru. До встречи!

Читать далее...

Тестирование игр в Иннове: рассказ о работе отдела

Это словесная экскурсия в группу игрового тестирования моего отдела. Это как раз те ребята, о которых говорят, что они "играют на работе" :)



Внешняя среда

Начну с описания внешней системы. У нас 13 игровых проектов. Они разного размера, их разрабатывают разные компании (чаще всего корейские), у них разные процессы, разный жизненный цикл, разная частота обновлений, разное качество и разные изначальные требования к качеству.

На первый взгляд кажется, что Иннова занимается только локализацией, и, казалось бы, что тут тестировать? Нам же дают готовый продукт, тестируйте только локализацию. Но вот эти разные изначальные требования к качеству продуктов играют свою роль. Разные компании-разработчики считают нормальным выпускать продукт на свой (корейский) рынок с определенным количеством известных багов. И это количество у всех, как вы понимаете, разное.

Мы же стараемся свести это количество к минимуму во всех наших играх. Потому что как только мы выпускаем игру в России, она становится «нашей». Мы так считаем.

Процесс тестирования

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

То есть, план тестирования обновления выглядит примерно так:

- тестирование локализации:
--- списки для проверки, сроки

- тестирование новой функциональности:
--- чек-листы для проверки, приоритеты, сроки

- тестирование сборки:
--- смоук-тесты, сроки

- бета-тестирование:
--- задание для игроков, сроки

Я рассказывала про полный цикл тестирования локализованной игры на примере Атлантики.

Процесс взаимодействия с разработчиками зависит от проекта и от компании-разработчика. Баг-репорты могут оформляться в BTS, на нашей или на их стороне, могут собираться в Excel или Google-docs. Взаимодействуют по их исправлению с разработчиками чаще всего тестировщики, но кое-где вся коммуникация проходит через руководителя проекта. Мы подстраиваемся под проект, но вносим в процессы изменения для их оптимизации.

Тестовая среда

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

На QA-стенде проводится внутреннее тестирование, до того, как отдать игрокам на ПТС.

Не любое обновление игры проходит весь путь QA-стенд -> ПТС -> боевые сервера. Некоторые обновления невозможно поставить на ПТС, не задев боевую систему. Такие сразу идут в бой после внутреннего тестирования. Некоторые наоборот, не могут быть нормально протестированы на внутреннем стенде, и они сразу идут вовне к нашим бета-тестерам.

Качество боевого продукта

И все же, приходится выпускать продукты с известными багами. И – бывает, что с критичными. Например, последнее большое обновление легендарного проекта Lineage II High Five Part 4, установленное на сервера 28 декабря, принесло серьезный баг: случайным образом у пользователей клиент игры вылетал с критической ошибкой при телепорте.

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

Это может зависеть, например, от запланированного срока запуска обновления, которого ждут все игроки.

Это может зависеть от неопределенных сроков по решению проблемы от разработчиков.

Я уверена, что если устроить опрос среди игроков, пострадавших от бага с телепортом в High Five, согласились бы они играть без обновления и по сей день, то они все равно выбрали бы предновогоднее обновление.

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

Организация команды

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

В его задачи входит:

- планирование тестирования проекта (или его обновлений)
- организация тестирования проекта (или его обновлений)
-- внутреннее тестирование
-- внешнее тестирование (с помощью бета-тестеров)
- информирование всех заинтересованных лиц о статусе тестирования и состоянии продукта

Тест-менеджер взаимодействует по работе:

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

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






Кроме того, если требуется массированная атака (например, проверить сборку клиента на всех серверах проекта), то тут на помощь приходит команда поддержки пользователей: они знают контент игры и готовы помочь. Здесь тестировщик опять же выступает в роли постановщика задачи.

Планирование работы команды на день происходят на утренних стендапах. Основные вопросы, которые обсуждает команда, это:

- «Я сегодня буду заниматься этим»
- «Мне сегодня нужно 4 человека на тестирование этого»
- «Я сегодня не загружен, кому нужно помочь?»

Подход владельца

У нас в компании есть понятие «драйвер задачи». Это значит «быть её владельцем», быть самым заинтересованным в её решении. Понятно, что тестировщик многого не может сделать самостоятельно:

- он не может напрямую повлиять на скорейшее исправление бага разработчиками
- он не может напрямую повлиять на ускорение установки
- он не может управлять инженером
и т.д.

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

Человек, который в случае возникновения трудности, просто напишет письмо, сложит руки и будет ждать – нам не подходит.

Мои тестировщики – это менеджеры своих проектов. Проектов по тестированию проектов. Владельцы процесса.

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

Я считаю неправильным самой делать это за всех, поэтому я учу делать это своих ребят. Это развивает их, и это дает свободу мне как руководителю заниматься более стратегическими задачами.

Side-effect

Правда, side-effect у такого подхода тоже есть. Ребята видят все стороны проекта, общаются со всеми участниками проекта, с почти всеми отделами в компании. Их видят, за ними наблюдают. И они растут.

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

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

На уровне компании

Не все проекты тестируются отделом тестирования. У нас в Иннове полностью и целиком за свой проект отвечает его руководитель. В том числе и за его качество, и за его тестирование. Я как руководитель сервисного отдела, являюсь владельцем своего направления, и, чтобы оставаться конкурентоспособной, должна предоставлять проектам услугу тестирования с таким качеством, чтоб руководители у меня её заказывали. То есть, если вдруг мои тестировщики начнут лажать, то руководитель проекта вправе отказаться от услуг моего отдела и обустроить себе тестирование самостоятельно. Любыми методами.

Или он может не заказывать её по другим причинам. Например, в нескольких небольших проектах тестирование осуществляется самой командой проекта. Потому что цикл тестирования обновления очень небольшой (несколько часов), контента немного, и внутри команды проще выделить время «Вот прямо сейчас все сели и побежали», чем ставить задачу в мой отдел.

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

В таких проектах мы выступаем как носители экспертизы: можем подсказать, помочь написать тесты, подсказать, как правильно оформить артефакты.

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

Спасибо вам, ребята!

Читать далее...

Отдел тестирования: цель первой итерации достигнута

На момент, когда я пришла в Иннову, в компании не было тестирования. Моей задачей было – сделать его. Не набрать отдел, не тестировать продукты, а именно – сделать тестирование .

Надо отметить, что тестировать у нас надо не только игрушки. У нас серьезный отдел разработки, который не дает нам скучать. Как, впрочем, и мы ему. Наш основной продукт разработки – это система, связывающая воедино все наши игры, игроков и партнеров. Пользователям он известен как Фогейм.

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

Но, обо всем по порядку…


Когда я пришла, готовился к запуску Айон. Подключение Айона к боевой системе я (тогда ещё единственный тестировщик во всей компании) я проверяла по-живому. Как сейчас помню свои ощущения, когда через несколько минут после запуска озвучили онлайн в десятки тысяч и такое же количество прошедших платежей!

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

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

После Атлантики, ребята уже самостоятельно организовывают тестирование больших обновлений. Почти каждый из них – тест-менеджер своего проекта. Работа организована так: «Чей проект сейчас активен, тот и главный». Это значит, что если сейчас в работе обновление Lineage II, то тест-менеджер может рассчитывать на руки и головы всей команды. Но во время тестирования другого проекта он сам станет тестировщиком на нём, попадая под управление своего коллеги.

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

Я не знаю, как это происходит у других компаний-локализаторов, но у нас так: при планировании функционального тестирования обновления мы пользуемся релиз ноутами для пользователей! Других нет. Компании-разработчики считают, что дают нам продукт в уже оттестированном виде и поэтому нам не нужна внутренняя документация для разработки.

Тестировать приходится по описаниям изменений в виде «Добавлено 20 новых квестов для асмодиан в Бездне» или «Изменены показатели умений Огня» . Поэтому мы проверяем только на работоспособность внесенных изменений и проводим регрессионное тестирование. На «логичность» изменений проверяют наши бета-тестеры. Именно они, люди, которые знают мир игры лучше всех, могут сказать, что «похоже, разработчики ошиблись. Не может этот шлем давать такой бонус! Это подорвет экономику сервера». И они часто оказываются правы.

Работа с бета-тестерами – это то достижение, которым мой отдел может гордиться. У моих ребят очень теплые отношения с бета-тестерами. Это отдельные группы людей, которым интересно нам помогать, и они сидят в скайп-конференциях, пишут в закрытой группе на форуме, выполняют задания и ждут новых обновлений. Заменить, например, группу из 40 человек постоянных помощников по тестированию Lineage II можно, конечно, группой специалистов по тестированию. Но это был бы худший вариант, так как точечные удары людей, хорошо знающих контент, в нашем случае намного эффективнее планомерного прочесывания со знанием подходов.

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

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

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

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

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

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


В моих целях на 2010 одной из ключевых было написано:

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

Ну что ж, получилось! Мы успешная часть успешной команды.

Читать далее...

ищу себе в команду волшебника (UPD: волшебник найден)

Компания Иннова известна в России как локализатор и издатель онлайн-игр, таких как Lineage II, Aion, Atlantika, Point Blank и другие.

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

И вот, мы ищем коллегу в команду тестирования веб-приложений.

Мы ждём, что он (или она):

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

Дополнительными плюсами будет знание Unix, опыт настройки сетей, знание языка программирования.

С свою очередь, мы обещаем:

- профессиональную команду
- хороших и интересных людей в коллективе
- интересные задачи
- не мешать расти и приветствовать инициативу
- и разные плюшки от компании

Мы находимся на метро Павелецкая.

Писать мне на yulia DOT nechayeva AT inn DOT ru

Читать далее...

О тестировании одной игры с картинками

Мир геймдева для обитателей мира разработки «человеческого», как я его называю, софта, это что-то непонятное и сказочное. Тестировать гномов, заводить баг на эльфа, моделировать тестовое окружение для осады замка. Я рассказывала на SQA days 7, в чем специфика тестирования игр.

Недавно мы запустили Атлантику. Это игра от корейского разработчика NDoors, которую можно охарактеризовать двумя словами: ММОРПГ и пошаговый_бой.

Все, больше про саму игру ничего не будет. А будет про её тестирование.

Да, эту игру мы не разрабатывали, а лишь локализовали, выпустили и поддерживаем, но тестирования тоже было много.

Что тестировать в локализованной игре?

Как я уже рассказывала в своем докладе, тестирование игры делится на тестирование функциональности, контента и геймплея. Так как игра, которая локализуется, уже запущена в других странах (как минимум, в Корее, а в случае Атлантики – и в Европе, и в США), то геймплей мы считаем за наименее рискованную область. Потому что, во-первых, эта часть обкатана на продакшне в других странах, то есть количество ошибок здесь меньше всего, а во-вторых, эти ошибки в геймплее эффективнее оставлять на откуп игрокам бета-тестерам.

Поэтому мы тестируем контент и функциональность

Почему функциональность, возникает вопрос. Ведь функциональность тоже оттестирована в других странах. Конечно, она тестируется разработчиком ещё до выпуска оригинальной игры, и на уровне кода, и на уровне пользовательского тестирования. Но, в игре огромное количество комбинаций, и одна и та же функциональность в каждой сущности сочетается с модельками (либо интерфейсным диалогом), анимацией, озвучкой и текстом. Велика вероятность ошибки именно в нашей сборке клиента.
Мы сочетали тестирование контента с тестированием функциональности.

Да, надо отдельно сказать, что, конечно же, для тестирования контента 100 уровня нам не приходилось неделями качаться, а для получения нужного квеста искать NPC (Non Player Character) по лесам. Имея аккаунт с определенным свойством в базе, получаешь доступ к инструменту администрирования, который позволяет сделать с существующим контентом игры практически все: перемещаться по координатам, призывать NPC, получать нужные предметы, оружие и одежду, повышать и понижать уровни, учить умения пачками и т.д.

Вернемся к тестированию

Типичный чек-лист для проверки выглядел так (на примере игрового предмета):

- предмет вызывается
- присутствует модель
- отображаемое название соответствует вызываемому предмету
- название не содержит ошибок
- название помещается при показе
- название соответствует модели
- предмет появляется в инвентаре
- информация о предмете соответствует названию
- информация не содержит ошибок (грамматических)
- информация отображается правильно (полностью, помещается в интерфейс)
- информация соответствует работе предмета (если написано +10 к защите – реально дает +10 к защите)
- правильное сообщение при невозможности использовать предмет
- предмет выкидывается персонажем
- правильное сообщение при выкидывании предмета
- другие связанные сообщения

Всё это выглядит в экселе примерно так:



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

Немного цифр

Та версия Атлантики, которую мы начинали тестировать, содержала около 2000 NPC и монстров, почти 7000 предметов, 500 локаций, около 800 умений, много интерфейсов и очень много квестов. Втроем этот объем осилили за 2 месяца (с перерывом на новогодние праздники).

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

Я бедный крестьянка, пустить ночевать, моя бежать долго-долго

Самый простой пример ошибки локализации – неверный пол. «When I was in Rome», говорит безликий ресурсный файл переводчику. «Когда я был в Риме», - басом говорят нам буквы с экрана. А на самом деле это хрупкая барышня.



Небольшое лирическое отступление о процессе перевода текстов игры. Он происходит в два этапа: сначала просто перевод, а потом редактура. В этих активностях участвуют разные люди, с разными специализациями. Но и те, и другие первоначально работают только с текстами. Так что реплика «Да вы что, промптом переводили?» - это на самом деле не минус переводчикам, а минус тестированию, которого, возможно, вообще не было.
Ни переводчику, ни редактору невдомек, что слово «Mammoth» может быть переведено иначе, чем «Мамонт», но глаза тестировщика явно видят баг:



Или другой пример: только видя картинку и понимая назначение предмета, можно определить, что свиток неправильно называется стопкой, а клей – ну никак не лекарство:


Или, например, квесты, которые подразумевали ввод правильного ответа в текстовое поле.

Ответ, принимаемый программой, почему-то не был вынесен в ресурсные файлы, а был упрятан в код, поэтому квест, где нужно было дать ответ на вопрос: «А в каком городе Вы встретили Японского городового?» принимал поначалу ответ «Tokyo», что совершенно неочевидно для русскоязычного пользователя.

Переведите картинку!

Много текстов оказалось картинками. Мы переводили, запрашивали сорцы картинок, наши дизайнеры переделывали их, разработчики вставляли в клиент, мы тестировали.
Естественно, цикл исправления такого рода ошибки намного дольше, чем просто ошибка в тексте.

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


Фикированная длина кнопки – головная боль игрового тестировщика

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



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

Были и нерешаемые случаи. Например, для кнопки, смысл которой «Собрать одним действием все, упавшее со всех убитых врагов после боя», нам было выделено всего 7 символов. Даже самый короткий вариант, который приходил на ум «Взять всё» содержал аж 9 символов. Игроки тоже не смогли придумать подходящий вариант. Попытка обозвать это действие «Мародер» тоже ни к чему не привела. В итоге, эта кнопка так и называется "Обыскать всех", что откровенно не помещается в предназначенную для надписи область, но решили пожертвовать красотой в угоду понятности.



Я не знаю правил пер
еноса текста, ты во
обще о чем?

Изначально, все тексты в игре при переходе на новую строку просто рвали слово. В корейском языке слова переносятся по слогам (иероглифам), без дефиса и в любом месте. Мы были удивлены, узнав, что в Европе и США играют с такими переносами. Мы добились частичного исправления, и теперь в игре переносы в текстах диалогов с NPC реализованы по словам. Но, как видим, не везде.

Было	Стало

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

Кавычки нам ни к чему

Или такой случай: имеем список из ~500 книг типа Книга «Смертельный выстрел», прочтя которую, персонаж обучается умению. В команде призыва предмета в игре при тестировании вводим полное название – получаем предмет без кавычек в названии.



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

Ресурсные файлы для слабаков!

Надо сказать, что Атлантика имеет очень большой недостаток для нас как локализаторов. Как вы себе представляете софт, который предполагается локализовывать? Ну, очевидно: все тексты вынесены в ресурсные файлы, все общие элементы вынесены в переменные, все упоминания общих элементов ссылаются на эти переменные. С этим здесь были проблемы.

Чаще всего, каждое упоминание термина содержало именно его название, а вовсе не ссылку на переменную. И одно и то же понятие вполне себе могло было быть переведено по-разному (переводчик-то не один):



Или так:



Локализация – это не только перевод

Специально для выпуска игры в России разработчики создали локации Москва и Санкт-Петербург. В них легко можно узнать знакомые архитектурные сооружения.
С локальными NPC сложнее, без подписей иногда трудно догадаться :)



Для того, чтобы опознать Курбского, придется дождаться, пока он перестанет делать facepalm:



Тестируем не только тексты

Плюс, конечно же, смоук-тест каждой сборки клиента (даже если он включает только исправления текстов). Такой смоук-тест содержит проверку основной функциональности игры и занимает 1-2 часа работы одного человека + полчаса групповой игры.

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

И даже это не самое важное. Самое важное – баги сборки. Нет гарантии, что в следующей сборке не забудут положить папку с текстурами NPC в Москве, и игроки не будут бродить по пустынному городу в поисках хоть кого-то, кто дал бы им квест.
Нет гарантии, что новый билд правильно установится. Потому что малейшая ошибка в шифровании, чексуммы не сошлись, и сервер не видит часть своих компонентов.

Или даже вот такая штука:
В книге-информации об игре все описания NPC съехали на одну позицию. Внезапно. Смотришь крестьянина, а информация тебе показывается о Путешественнице – следующему по списку NPC. К слову, этот баг очень долго не могли исправить. Если я не ошибаюсь, больше месяца он продержался.



Помощь пользователей

Тестирование любой игры делится на 3 части: внутреннее тестирование, закрытое бета-тестирование и открытое бета-тестирование. Тестирование локализованной игры – не исключение.

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



В итоге, за период альфа тестирования (2 недели) было найдено и исправлено 95 багов локализации и 31 баг самой игры.

Как научить пользователя правильно описывать баг

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

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

Закрытое бета-тестирование

После окончания фазы внутреннего тестирования, мы раздали аккаунты зарегистрировавшимся, открыли публичный сервер и началось ЗБТ.

В ЗБТ версии открыли + 20 уровней контента, поэтому основная масса ошибок пришлась именно на эту, неоттестированную область. Тем не менее, для проекта неправильно задерживать ЗБТ ради выкатки пользователям полностью «вылизанной» версии. Во-первых, им хочется поскорее, во-вторых, они хотят помогать! Здесь важно выбрать good enough, подходящий для аудитории данной игры.
Судя по отзывам наших бета-тестеров, мы оправдали их ожидания довольно высоким качеством.

ЗБТ – это такая стадия, в которой ещё находится много багов. Просто в силу закона больших чисел. Если 1000 игроков прочесывают все одно и то же, то вероятность, что они найдут баг, пропущенный одним человеком, очень велика.

Именно на этапе ЗБТ уже становится возможным выявить баги конфигурации сервера, например, что турнир начинается каждый день в 18-00 и заканчивается через 5 минут, если не набралось 10 участников (каждая цифра – это параметр), или что ограничение на охоту снимается в 6 утра только для персонажей, соответствующих определенным условиям.

Баги локализации, которые находили наши бета-тестеры во время ЗБТ, в основном, касались текстов квестов. Естественно, что тестировщик, читая сотый квест за день, глазом не видит те мелочи, которые выискивает пытливый взгляд игрока-бета-тестера, претендующего на получение внутриигровой лошади после релиза за активное участие в тестировании.

Были и перлы. Естественно, мы не можем ограничить ни возрастной, ни образовательный уровень, ни уровень энтузиазма игроков, поэтому многие «баги» с форума так и не перекочевали в багтрекинговую систему.

Пропущен мягкий знак, сообщает нам пользователь – ну не знаком человек с высоким слогом:



Зато слог геймеров – это отдельный язык. Чего стоят баг-репорты типа:

- «хоть я и нуб,не умею ставить изображения,но в "Морской дворец" есть дыра,там где 1-ые боссы,адмиралы последите за ними,и 1 из них зайдет в то место,где находится дырка»
- «не берётся почта пробовал в разных разрещениях но всё равно»

То есть, моим ребятам приходилось не только переводить с русского на английский баги для разработчиков, но и с геймерского на русский баги для редакторов.

Или вот ещё феноменальный отчет:

- «Не помню где и куда бежал - заметил что тень от дерева передвигается по мере моего приближения» - репорт без видео.

За период ЗБТ было найдено и исправлено 93 бага локализации и 22 бага игры.

Открытое бета-тестирование

Между ЗБТ и ОБТ последовал небольшой перерыв, так как готовили новый сервер, рассчитанный уже на другие объемы игроков.

ОБТ – это такой этап, когда уже могут играть все, кто хочет, но при этом игра ещё имеет право содержать баги. И игра в это время абсолютно бесплатная. Если у неё бизнес-модель абонплаты, то люди не платят подписку, если у неё модель free-to-play, и она зарабатывает на продаже внутриигровых предметов, то в этот период эти предметы в ней просто нельзя купить. В игру еще не встроен магазин и она не подключена к биллингу.

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

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

Итого за период ОБТ было найдено 36 багов локализации и 9 багов игры.

Лучший баг Атлантики за время ее тестирования

«Оставил чара на ночь АФК рыбачить. Был дисконнект по причине смены IP-адреса провайдером. С утра не смог зайти, выкидывало в окно логина при попытке подключиться к серверу.
Люди в игре сказали что мой чар он-лайн и продолжает рыбачить.»

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

Тестируем деньги

Пока на сервере, который в будущем собирался стать продакшном, бета-тестеры начинали строить свои империи, на тестовом сервере вовсю тестировалась версия для продакшна. Та, которая была призвана уже приносить прибыль. Тут появился игровой магазин, подключенный к биллинговой системе, тут появился контент этого магазина – предметы, на которые игроки тратят свои реальные деньги. Тут и сундуки с оружием, и свитки телепортации, и лошади, ускоряющие передвижение.

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

С Днем рождения!

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

Чуть позже начнется работа по подбору и организции группы бета-тестеров, которые будут помогать нам тестировать обновления, но это потом.

Заключение

Это первый проект моей команды в Иннове, и, могу сказать, что мы провели тестирование хорошо.

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

Я не рассказала здесь о тестировании сайта, о тестировании инсталлеров, о тестировании системы автоапдейта, о тестировании интеграции с защитой игры Frost, о тестировании скачивания клиента с файлоотдачи, о тестировании интеграции игры с биллингом, о конфигурационном тестировании, о тестировании реферальной системы, о выстраивании процесса работы с локализаторами и с корейскими разработчиками. Это все обычные для вас вещи. О них интересно было бы послушать игрокам. А вам я рассказываю штуки, которые банальны для них.

Конечно, мы решили не все проблемы. Вот некоторые из тех, которые остались:

- большое количество файлов в клиенте не способствуют быстрой скачке: 4 гиговый клиент содержит больше 30 000 тысяч файлов
- перенос слов в чатах и системных сообщениях по-прежнему осуществляется простым разрывом слова
- не переведены некоторые всплывающие во время боя сообщения: Bonus, Skill Up, Exp+ и т.п.
- не помещаются трехстрочные описания миссий, несмотря на наличие места в интерфейсе:



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

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

Читать далее...

Тестирование игр: фан или тяжелый труд?

Индустрия геймдева по очень нехорошей тенденции далека от индустрии разработки обычного, "человеческого" софта. Люди, работающие в этих двух мирах, очень редко переходят из одного в другой. Человек, поработавший в геймдеве, либо прикипит к нему всей душой и ни на что не променяет, либо сбежит отсюда очень быстро и никогда не вернется.

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

Конечно же, очень явно для меня видны отличия в области тестирования. Об этом я рассказывала на SQA Days 7, которая проходила в мае этого года в Харькове.
Рассказать хотелось очень много, поместилось, как всегда, очень мало :)

Читать далее...

Познакомлюсь с тестировщиком. Москва.

Я ищу к себе в команду инженера по контролю качества с опытом работы в тестировании не менее 2 лет. Не Гербалайф =)

Компания Innova Group.

Я гарантирую интересные задачи в тестировании игровых и около-игровых приложений, поддержку инициатив, хорошую дружную команду, совместную работу всей команды разработки продукта над его качеством.

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

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


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

Большим плюсом является опыт в применении автоматизированного тестирования.

Условия, предлагаемые компанией:
- Официальное оформление по ТК РФ
- Работа в офисе
- Занятость - полный рабочий день
- График работы: пн-пт, 10:00 - 19:00
- Работа в передовой и активно развивающейся компании

Зарплата по результатам собеседования и заведомо не ниже рыночной.

Мой контакт: julia.lorien DOG gmail DOT com





Читать далее...