четверг, 8 декабря 2011 г.

Игра "Нереальное тестирование" на 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 декабря я опубликую список тех отличий, которые были внесены в приложения санкционированно, то есть – по ТЗ. Интересно сравнить с вашими списками.

Удачи!

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

понедельник, 5 декабря 2011 г.

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

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

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

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

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




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

вторник, 22 ноября 2011 г.

Eurostar. Introduction. The first post of our new blog.

Привет!

Мы открыли блог команды тестирования Инновы. Подробнее про нас и про то, зачем мы это делаем, можно прочесть первом поcте: http://www.innovatesting.info/2011/11/about-us.html

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

Первый пост про вчерашнюю 8-часовую сессию Майкла Болтона: вот он.

Пост про выступление Дороти Грэхем: вот
Фотопост с доклада Гойко Адзика: вот
Читать далее...

понедельник, 1 августа 2011 г.

Нужен младший волшебник по тестированию веб-приложений

Привет!

Я ищу коллегу в команду веб-тестирования: молодого специалиста по ручному тестированию.

UPD: специалист найден!


Мы работаем над самыми разными проектами:

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

- система биллинга (связанная с платежными шлюзами, системами рассылок SMS и mail-нотификаций), в которой сейчас более 10 млн зарегистрированных пользователей (из них более 3 млн активных), которая позволяет держать более чем 100 000 «одновременных» коннектов, где самое важное – надежность и производительность;

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

- интеграционные проекты, которые с одной стороны являются красивой витриной для пользователей, а с другой – имеют сложную систему интеграции с игровой и биллинговыми базами;

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

В нашем тестировании несколько направлений:

- автоматизированное тестирование бэкендов (собственный фреймворк на языке Java)
- ручное тестирование (используем Mind Map для фиксации тестов)
- автоматизированное тестирование интерфейсов (Selenium + Java)

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

Профиль нашего будущего коллеги:

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

Если более формально, то:

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

Очень хорошо, если на текущем месте работы вам некуда расти – приходите к нам, у нас есть куда!

Мы готовы помочь вам из "ручного" тестировщика стать тест-дизайнером, тест-аналитиком и специалистом по автоматизированному тестированию в одном лице, если захотите.

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

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


Добро пожаловать!
Принимаю резюме на yulia DOT nechayeva AT inn DOT ru
Читать далее...

вторник, 8 марта 2011 г.

как Тестированию не задерживать Разработку: часть 2

Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.

Спасибо Максу Дорофееву за вдохновение.

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

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

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



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



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



Теперь посмотрим на сервисный отдел тестирования. Ему поступают одновременно три задачи от разных заказчиков на тестирование.

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

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

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



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

Давайте посмотрим, что будет, если тестировщики будут давать фидбек после выполнения первоприоритетных тестов, и заказчики тут же будут приступать к фиксу:



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

А если мы можем выпустить задачу ДО завершения финального цикла (с известными минорными багами), то посмотрите, насколько раньше это можно сделать!



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



Видим, что от времени жизни задачи на тестирование зависит время жизни всей задачи.

И в такой схеме легко находится Полезное-потом время.

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


Если говорить терминами Lean, то тестирование, будучи сервисом, может работать на сокращение сроков выпуска продуктов путем уменьшения потери времени из-за ожидания.

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

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


Обязательные условия для того, чтобы это работало:

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

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

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

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


Продолжение следует...






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

как Тестированию не задерживать Разработку. часть 1

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



Презентация вот:


Видео будет чуть позже.

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

Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.

Постановка задачи и метод решения.

Начну с правды: Тестирование не самодостаточно.

Тестирование само по себе не несет для продукта никакой бизнес-ценности. (Я здесь не говорю про компании-аутсорсеры, которые этим зарабатывают, я имею ввиду тестирование в процессе разработки продукта).

Задача на тестирование – это всегда часть старшей задачи: задачи на разработку, задачи, на верстку, на архитектурное решение, на текст, на сценарий, на идею, в конце концов.

И бизнес-ценность для продукта имеет именно та, старшая задача.

Для простоты назовем команду, выполняющую старшую задачу, заказчиком тестирования.

Понятно, что методы и подходы к тестированию зависят от старшей задачи. И – что самое важное – процессы. Процессы тестирования зависят от процессов, по которым выполняется старшая задача.

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

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

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

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

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

Если мы говорим о задачах на тестирование длиной менее одного дня каждая, то планирование здесь практически невозможно. Я не верю в выполнение тремя заказчиками плана по постановке задачи на тестирование с точностью до часа. Если вы запланировали, что одна задача придет к вам в 11 часов, другая в 15 и третья в 17, то будьте уверены, что они все придут к вам в 17-30 =)

Время, которое старшая задача проводит в тестировании, можно условно разделить на три вида:

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

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

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

И в целях уменьшения времени на выполнение старшей задачи, очень важно оптимизировать время на тестирование. Ключевой момент – старшая задача должно КАК МОЖНО МЕНЬШЕ ждать, пока задача вернется с тестирования. При этом экономия времени не должна влиять на качество работы тестирования.

Задача тестирования - максимально эффективно тратить Полезное-сейчас время, максимально сокращать для заказчика Бесполезное время и сделать невидимым Полезное-потом время.

Хороший сервис тестирования должен работать по трем основным принципам:

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

Чтобы этого добиться, есть несколько инструментов:


1) максимально мелкие задачи на тестирование


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


2) правильно расставлять приоритеты в тестировании


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

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

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

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


3) практики тест-дизайна


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

-- по глубине тестирования (например: смоук, акцептенс, функциональные)

-- по объектам тестирования (например: дизайн – верстка – функциональность фронт-энда – функциональность бек-энда)

-- по сценариям тестирования (позитивные-негативные)

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

И выполнять их нужно, разумеется, соответственно выбранным приоритетам.


3) разумно подбирать момент оформления багов


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

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

Иногда, если баг очевиден, нужно сказать вслух, и пока разработчик его правит – оформить.


4) давать предварительную оценку качеству


Работая не первый день над проектом, тестировщик всегда может оценить в сравнении качество реализации текущей задачи заказчиком от других. Это можно делать на основании метрик, например, «количество багов, найденных в результате прогона тестов приоритета 1» , или «количество багов на единицу системы (сценарий, страница, таблица)».

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


5) кроссфункциональность сотрудников


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

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

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


6) исследовательское тестирование


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

Умение без специальной подготовки сесть и выполнить задачу на тестирование, использую подходы 1, 2, 3 и 4 – вот, что значит исследовательское тестирование.

Ну и плюс некоторые практики:

- сессионность
-- сессия 1: тестирование + оформление багов
-- сессия 2: запись выполненных тестов
-- сессия 3: анализ выполненных тестов, расширение, приоритизация
-- сессия 4: выполнение расширенного набора тестов

- парное тестирование:
-- пилот выполняет тесты
-- штурман подсказывает и записывает


7) Полезное-потом время должно быть обязательно!


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

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

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

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

-- Жестко запланировать время, например: каждую пятницу с 15-00 отдел тестирования задачи у заказчиков не принимает, а занимается внутренними. Если этого правила придерживаться очень жестко, то все привыкнут и будут планировать свои задачи так, чтобы отдавать их на тестирование до пятничного утра.


продолжение следует...





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

понедельник, 28 февраля 2011 г.

Соратники needed

Привет!

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

воскресенье, 20 февраля 2011 г.

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

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

image

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

Начну с описания внешней системы. У нас 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 одной из ключевых было написано:

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

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






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