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

Мир геймдева для обитателей мира разработки «человеческого», как я его называю, софта, это что-то непонятное и сказочное. Тестировать гномов, заводить баг на эльфа, моделировать тестовое окружение для осады замка. Я рассказывала на 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+ и т.п.
- не помещаются трехстрочные описания миссий, несмотря на наличие места в интерфейсе:



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

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

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

Живут, как тестировщик с программистом

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

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

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

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

Как раз сейчас я краем глаза смотрю запись гран-при Канады Формулы 1.

Феноменальный пример слаженной, однонаправленной командной работы. Есть 2 части команды: собственно, перформер, пилот, человек, который на виду, который пожинает лавры в глазах публики, но который на каждой пресс-конференции говорит про работу всей команды, и есть та самая команда-тыл, которая смотрит на его работу на трассе, анализирует её и говорит в шлемофон: «Кубица сменил резину на жесткую, Барикелло тоже, не дай себя обойти». А теперь представьте, что команда отлавливает ошибки пилота и злорадно сообщает ему «Из-за того, что ты не сменил резину на прошлом пит-стопе, потерял 2 секунды во время дождя». Как только части команды начинают работать друг против друга – она обречена на провал!

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

Признаки того, что ваши программисты и тестировщики не Правильные:

- от тестировщиков звучат фразы «наколбасил им багов, пусть теперь разгребают»

Это идет от старших тестировщиков и от общей атмосферы в коллективе. Я ещё не видела ни одного неопытного тестировщика, который бы думал так с самого начала.
Если старший коллега хочет вырастить злобное чудовище, которое радуется при нахождении бага не потому, что теперь пользователь получит на одну ошибку меньше, а потому, что насолил программисту, то ему стоит продолжать в духе «Давай, сынок, покажем этим кодерам, что за какашку они выпустили бы без нас ». Но если он хочет, чтобы тестирование работало не против программирования, а совместно с ним на качество продукта, и ведет себя соответственно, то никогда в его команде не будет такого.

- от программистов слишком часто звучит презрительное «это не баг»

Это значит, что каждый баг воспринимается как личный тычок: «Это твоя личная ошибка, слышишь? Ты непрофессионал. Хорошие программисты пишут без ошибок, а ты баг сделал, эх, ты». Думаю, что здесь проблемы надо искать в личности такого специалиста. Адекватный человек, направленный на развитие, использует любую критику для совершенствования, а не для обид. Тем более, когда критикуют работу, воспринимать это как личную критику – выглядит как болезнь.

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

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

- тестировщики заносят баги, не интересуясь их дальнейшей судьбой

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

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

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

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

Уверена, что список можно продолжить.

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

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

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

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

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

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

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

А/Б сплит тестирование: что общего у оптимизаторов и тестировщиков?

Попытавшись найти в яндексе информацию про A/Б сплит тестирование, обнаружила, что все ссылки ведут на сайты для оптимизаторов и "продвигателей" сайтов.

Ни одной ссылки на сайт для маркетологов, продакт-менеджеров или тестировщиков.А ведь это так замечательно вписывается в концепцию Business Driven Testing: инструмент, который позволяет понять, нравится ли пользователю то, что мы сделали?

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




Большинство из вас знает концепцию A/Б сплит тестирования как метод определения, какие из элементов на странице способствуют цели веб-страницы, а какие нет.
Например, типичным тестом является сравнение двух разных хидеров на главной странице. Один из них может превосходить по показателям другой, и – опа! – вы в курсе, как привести страницу к лучшей производительности (здесь под производительностью имеются ввиду маркетинговые показатели, дальше станет ясно).

На самом деле, с помощью A/Б сплит тестирования можно делать намного больше.

1) Можно использовать A/Б сплит тестирование для того, чтобы лучше понимать желания ваших посетителей и их приоритеты во время посещения вашего сайта;

2) Можно использовать A/Б сплит тестирование для решения специфических проблем с вашими страницами. Другими словами, у вас в руках инструмент диагностики, призванный показать, что не так и как это исправить;

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

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

Наши собственные результаты, перечисленные в этом рассказе, как раз показывают, как много может быть достигнуто и изучено с помощью «простого» А/Б сплит теста.



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

ТЕСТ1: Тестирование влияния Новостей на количественные показатели реакций на имейлы.

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

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

В имейле 2 мы написали текст без специального упоминания о событии, но все также ссылающегося на «последние события в новостях»

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

Мы протестировали нашу рассылку на 337 466 емейлах-участниках.
Мы подвели итоги после 12 дней, хотя клики продолжали потихоньку сыпаться и после.

Вот результаты после первых 12 дней:

Результаты тестирования имейлов
	Имейл A	Имейл Б
Послано имейлов	168 733	168 733
Кликов	5 119	4 395
Кликов к показам (CTR)	3.03%	2.60%
Продаж	175	122
Конверсия (Клики в продажи)	3.42%	2.78%
Конверсия (Имейлы в продажи)	0.104%	0.072

Что здесь нужно понять: Имейл А (специально упоминавший новость и события, связанные с ней) значительно опережает имейл Б. CTR вырос на 16,5%, а полная конверсия (имейлов к продажам) на 43,4%.

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

ТЕСТ 2: Тестирование определенной проблемы

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

Мы устроили A/Б/В сплит тест для тестирования этой гипотезы:

Страница А была оригинальной страницей.

Страница Б – содержала сильно укороченные данные и использовала «click here» текст, чтобы привлечь посетителей вниз страницы. Эта страница отображала процесс заказа на 1024x768 мониторе, а на 800x600 мониторе она показывала копию заказа основного продукта

Страница В была радикально переделана таким образом, что процесс заказа был частично виден на мониторах с разрешениями 800x600 и выше. Здесь использовались 2 колонки, чтобы сделать доступной больше информации «выше перегиба».

И вот результаты нашего тестирования:

А/Б/В сплит тест
	Страница A	Страница Б	Страница В
Процент показов	34%	33%	33%
Новых продаж	244	282	114
Изменение	N/A	15.57%	- 53.28%

Что здесь нужно понять: Страница Б превзошла первоначальную на 15,57%, страница В оказалась совершеннейшим фейлом.

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

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

ТЕСТ 3: Опровержение предположения тестированием «очевидного» и извлечение уроков из результатов.

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

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

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

Какая же из версий выиграла? Общепринятая точка зрения нашептывала нам, что персонализированная версия выиграет. И вот результаты нашего тестирования:

A/Б сплит тест
	Версия A (персонализированная)	Версия Б (безличная)
Конверсия	34.6%	39.9%

Что здесь нужно понять: Версия Б превзошла версию А на 15,3%.
В этом случае, наши ожидания касательно выигрыша персонализированной страницы не оправдались.

И здесь нужно отметить 2 момента:

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

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

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

Резюмируя А/Б тестирование:

Использовали ли вы А/Б тестирование раньше или нет, следующие шаги могут помочь вам формализовать обычный порядок тестирования и улучшить ваши результаты.

Правила А/Б сплит тестирования для «Landing Pages» (страница, на которую попадает посетитель клацнув на рекламу, либо перейдя по ссылки с результата поискового запроса):

1) Развивайте ваши возможности и выбирайте правильные инструменты.

Инструменты для А/Б сплит тестирования могут варьироваться от простых CGI скриптов до сложных приложений. Но, даже без сложных возможностей А/Б сплит тестирования, последовательные тесты – это возможность для вас открыть много нового про ваши страницы.

2) Определите вашу контрольную страницу.

Ваша контрольная страница будет той страницей, по отношению к которой вы будет тестировать всю последующую работу по оптимизации. Если вы только начинаете А/Б Тестирование, вашей контрольной страницей будет ваша текущая «landing page» до оптимизации. Когда новая страница превзойдет существующую контрольную страницу, тогда она станет контрольной в последующем тестировании.

3) Установите Цели и Параметры вашего тестирования.

Чего вы пытаетесь достигнуть с помощью А/Б тестирования? Вы гонитесь за подписчиками, за повышением конверсии или за увеличением ROI ваших PPC (pay-per-click) кампаний. Ваши цели будут определять ваши параметры тестирования, которые в свою очередь определят потенциальный успех ваших усилий по тестированию.

4) Определите ваш интервал «достаточности тестирования».

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

5) Создайте 1-3 радикальных редизайна.

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

6) Измерьте такие редизайны с помощью А/Б Сплит тестов.

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

7) Определите вашу новую контрольную страницу, базируясь на результатах.

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

8) С помощью традиционного Variable-Specific А/Б тестирования оптимизируйте переменные для тестирования:

Заголовка
Призыва к действию (call to action)
Картинок и графики
Цветов
Конфигураций элементов страницы и т.д.

Заключительные комментарии.

Вам нужно запомнить несколько важных моментов про A/Б тестирование:

1) Даже если вы не можете провести настоящий А/Б тест (где 2 версии страницы показываются одна после другой для разделения посетителей вашего сайта), очень легко провести последовательный А/Б сплит тест.

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

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

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

3) Тестирование предлагает компаниям неоценимую возможность произвести на руководство компании и менеджмент сильное впечатление предложенными изменениями для улучшения.

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

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

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

5) Обеспечьте процесс тестирования ваших веб-сайтов и имейлов. В рассказе выше мы обозначили для вас правила «как начать». В дополнение, держите документ – шаблон для A/Б тестирования, который поможет вам вести процесс экспериментирования.

ABTestingTemplate.doc

Удачи!

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

Тестирование - это не просто тестирование

Мой рассказ на Softwarepeople 2010, плавно перетекший в диалог со слушателями. Рассказываю, что тестирование может работать на успех продукта, а не только на корректность функциональности приложения.
Я уже очень давно думала про Business Driven Testing, и вот, наконец-то, собралась рассказать о таком подходе.

Тестирование - это не просто тестирование

View more presentations from Julia Nechaeva.

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

Прекрасное про обращение с багами

Спасибо, Рома.

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

2 вебинара и 5 конференций за 3 месяца

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

8 апреля – я читаю вебинар на базе Software-testing.ru на тему «Работа с требованиями: Анализ, тестирование. Версия 2.0». Посмотрев на материалы и отзывы первого вебинара, я немного переработала структуру, добавила ещё 2 метода тестирования требований (в зависимости от формата их представления) и практически убрала из вебинара работу слушателей. Она все равно неуправляема, людям неинтересно работать в одиночестве перед монитором, не советуясь с коллегами, не обмениваясь шутками :) Поэтому всю практику я покажу своими руками на одном примере, а работу слушателей всю вынесу в домашнее задание. Вот у меня и появилось место для больше методов :) И домашнее задание тоже немного видоизменю, учтя пожелания слушателей предыдущего вебинара.

Кстати, если вы читаете этот пост, то с вероятностью 100 процентов организаторы дадут вам 10 процентную скидку на оба вебинара из серии «Аналитика для тестировщиков 2.0»

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

22 апреля – второй вебинар из серии «Аналитика для тестировщиков 2.0» - «Работа с требованиями: управление изменениями».

22 апреля же, сразу после окончания вебинара я бегу на SoftwarePeople, где я рассказываю про то, как тестирование может влиять на успех продукта. Хватит уже отводить нам роль проверяльщика за программистом! Мы хотим приносить больше пользы! Мы не можем видеть, как прекрасный с точки зрения надежности и устойчивости продукт, в котором исправлены все баги с важностью выше, чем «вообще-вообще-неважно», оказывается никому не нужным!

Ну, и хочу послушать, что думают об этом люди.

23 апреля я просто слушаю доклады второго дня Softwarepeople": Саша Орлов, Сурен Самарчян, Стас Фомин, Гриша Печенкин, Сергей Архипенков, Влад Балин, Макс Дорофеев, Стас Давыдов, Костя Кондратюк, Стас Калканов, Асхат с Никитой… Я правда не знаю, как тут не разорваться.

13 мая я хочу поговорить о тестировании на Dev-Labs у Славы Панкратова в Киеве. Вот как раз думаю, о чем бы рассказать. Скорее всего, поделюсь своими мыслями о значимости тестирования на уровне всего продукта и с киевскими коллегами. Разумеется, уже учитывая опыт общения с московскими.

14-15 мая я в своем родном городе Харькове провожу 2 дня на SQA Days. Расскажу о том, чем работа в тестировании игр отличается от работы в тестировании «обычного» софта. И отличается ли вообще? ;-) Конечно же, буду присутствовать на таком значимом событии, как встреча организаторов Харьковского QA Club’a с питерскими активистами Ромой Твердохлебовым и Лешей Лянгузовым. Обмен опытом организации сообщества в своем городе – это что-то уникальное. Хочу также пригласить туда некоторых из своих бывших студентов, чтобы они посмотрели на все многообразие подходов и методик, проблем и задач, решений и озарений в тестировании.

И как член программного комитета совершенно официально заявляю, срок подачи докладов продлен до 15 апреля. Подача докладов приветствуется, благо – форматы разные, на любой вкус. А аудитория в Украине благодарная, ребята интересные, вы уж мне поверьте.

Май богат на события, 14-16 мая в Москве пройдет Конференция разработчиков игр 2010. Куда я не попадаю из-за моей верности профессии, а не отрасли =) Хотя, интересно безумно. Но туда пойдет мое Дневное Лицо большая умница Степа Корчагин, которому будет всучен диктофон и список докладов, которые надо записать.

5 июня я буду в Черновцах «тормошить IT-сообщество» города, по выражению пригласивших меня организаторов =) Зарождение профессионального сообщества – это всегда маленькое чудо и колоссальная работа. Надо поддержать ребят, которые задумали эту конференцию.

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

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

Swiss Testing Day отчет

Конференция Swiss Testing Day проходила в Цюрихе, в здании Конгрессхауса, что сродни московскому Дому союзов, только современнный. Зайдя туда, я, если честно, удивилась. Мне показалось, что я попала на тусовку по случаю защиты докторской. Или, на крайний случай, прием по случаю назначения нового директора банка. Множество людей в костюмах, средний возраст где-то около 40.
Регистрация открывается в 8 утра, открытие конференции в 9. В 8-05 уже полно народу, который активно между собой общается.

Выставка спонсорских стендов. Это именно что выставка. Не стенд со скучающим человечком рядом, а ряд 2х2 секторов, в каждом из которых по несколько человек, монитор, материалы и конфеты-кепки-футболки =)

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

В 9-10 начал говорить Джеймс Виттакер. В течение почти часа Джеймс, размахивая руками и приводя примеры из области медицины, рассказывал о том, как они в Гугле подходят к тестированию. Он вообще непревзойден, на мой взгляд, в способности приводить жизненные примеры к тестировщицким ситуациям и проблемам. Задумываешься.

Доклад Building a Successful QA Organisation проводился в довольно необычной форме: парный доклад от руководителя подразделения компании, предоставляющей услуги по тестированию и контролю качества, и представителя компании-вендора, которая пользуется их услугами на протяжении 7 лет. Такой себе, двухсторонний взгляд на вещи. Докладчики рассказали об эволюции их отношений по цепочке: need based – reliability - trust - partnership.

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

А тут рассказали именно о том уровне. О том, как однажды стало понятно, что нельзя продавать ресурсы, надо предоставлять услугу. О том, что принимать ключевые решения они оставляют вендору, давая ему все на то вводные. О том, как перейти от resource based модели к service based модели отношений с заказчиком.

И, все-таки, для того, чтобы построить успешные отношения в любой отрасли – нужна любовь =) (Егор Егоров, привет!)

Worldwide Testing - Join the Crowd. Это как раз то, что я сейчас внедряю у себя в компании. Бета-тестирование. Правда, у нас с Эвальдом немного неравные позиции =) У меня уже есть сотни тысяч пользователей наших продуктов, из которых можно найти нужное количество лояльных и готовых помогать. Но, тем не менее, у него эта практика достаточно успешна.
Не соглашусь с подходом докладчика, где во главе угла такого подхода он ставит дешевость такого метода.


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

То есть, это опять же, про любовь =)

Полуторачасовой перерыв на ланч, при условии, что Конгрессхаус находится в 150 метрах от озера… мммм =)

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

How we Test Software at Microsoft – Биджей менее эмоционален, чем Джеймс, да и вообще, Гугловцы кажутся более бесшабашными, чем Майкрософт. В плане новаторства и всяких интересных плюшек. Всегда интересно послушать,как это делают монстры. Применять ли - другой вопрос.

Why not use the Fast Lane to reach a higher Test Maturity Level? – про Model Based Testing и про тул, который разработали в Сименсе и успешно используют. Надо сказать, что это не первый доклад, который я слушаю про Model Based Testing, но это первый, который заставил меня об этом задуматься.

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

Ну а потом, как вы уже знаете, было St. Patrick’s Day Party =)

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

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

St Patrick's Day in Zurich with celebrities in Testing

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

Пишу этот пост на борту самолета Москва-Цюрих, в 16:40, 16 марта 2010 года. Лечу навстречу событию, которое должно было случиться больше 4 месяцев назад.

Днем позже, 17 марта, мне доведется посетить конференцию Swiss Testing Day, куда я попала приглашенным гостем по ходатайству Джеймса Виттакера, известной в тестировщицкой среде специалиста, который сейчас работает в Сиэттловском Гугле на должности Test Director.

Вечером того же дня, который ко всему ещё и День Святого Патрика, будет сделано это фото, которое показывает, что тестировщики тоже люди, тоже любят пиво и тоже ценят языческие праздники =) На ней слева направо: Биджей Роллисон (Microsoft), я, Тимур Хайруллин (Яндекс) и Джеймс Виттэкер (Google)



О самой конференции отчет я напишу обязательно, как только она закончится, а сейчас, пока лечу, хочу рассказать о том, как это все произошло. Такая себе, простая тестировщицкая сказка =)


А началось все в августе 2009. Когда Тимсон рассказал мне о конференции GTAC и дал линк на выступление Джеймса Виттакера на GTAC 09, тогда ещё он работал в майкрософте. Ну, мои отношения с конференциями вы знаете, да? (Начиная с 2008 года я побывала на 9 конференциях в области тестирования и разработки софта, выступила на 7, дважды была в оргкомитете и вот уже третий раз вхожу в программный комитет). Я очень ценю то, что на конференциях можно пообщаться с людьми, которые делают что-то, что меня интересует. Они делают это хорошо, и они готовы рассказать, как они это делают. А тут – Гугл, Виттакер, Цюрих, АААААААААА…...

По правилам GTAC 09, регистрация происходила в течение августа, принимались заявки до 28 августа, затем в течение нескольких дней оргкомитет рассматривал их и, начиная с 3 сентября, рассылались утвержденные приглашения и отказы.
Я была просто уверена в том, что получу подтверждение, ведь при подаче заявки я расписала свою активность в русскоязычном сообществе тестировщиков в графе «Why do you think you should get the GTAC conference».
И вот, 4 cентября я получаю письмо с текстом «Thank you very much for applying to attend GTAC 2009. Unfortunately due to an overwhelming response we do not have a place for you this year». Это, правда, было очень неожиданно. Хорошо, что у меня большой монитор, который скрыл мои эмоции от коллег.

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

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

«Let me explain why I’m striving to get GTAC……………………………………………

The main purpose of GTAC is to give people an opportunity to share their experience and knowledge on testing field. You really do a great job. Thanks for this.
I do the same for Russian-speaking testers. I often speak at different conferences and seminars because I do see a lack of lore in testing community. I am sure that we should communicate more with each other, speak about our problems and ideas and get common solutions…………………

My contribution in it is organizing a conference for Russian-speaking testers. I am a member of Organizing Committee of ‘Software Quality Assurance Days’ conference that is the biggest event for QA and QC engineers all over ex-USSR area………………….

We give a chance to our testers to find people who are also hands-on with testing and to swap their knowledge……………………………………………………

So we are working in the same field with you. I do believe that there are a lot of things I can learn from you. Also I’m sure that you are happy with such events and communities existing. We work hard to let people work easier…………………………………………………

So I’d like to ask you to review my request for getting GTAC one more time. I hope that you let me participate it because grain of knowledge I’ll get there will be planted into fertile ground. I promise.»

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

«Julia - thank you for your enthusiastic plea for re-consideration - unfortunately, we decided on the participants and waiting list, have informed all of them, and will have to see what level of cancellation there will be - so far, very very few have declined the invites.»

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

Но я знаю, кто может понять.
Джеймс Виттакер. Ну конечно! Не может такой клевый и здоровский дядька не отреагировать на мое желание. Тем более что он к этому времени уже стал Test Director в Google. Тем более что он наверняка будет там выступать. Раздобываю его контакт, и мое следующее письмо летит к нему. Виттакер ответил на следующий день. В достаточно дружеском тоне он написал, что

«I am sorry you didn't get accepted to GTAC, but I understand that the number of applicants this year was exceptionally high. As it turns out, I am not going either as I have a product release I have to attend to here in Seattle.
Thanks for the note. I enjoyed reading is and am glad to see the passion you have for this discipline. I hope we'll meet in person some day.»

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

1 – «The closest I will get is Norway in February where I'll be speaking. As that conference gets closer I will be sure and update you.»

2 – «My new book is out now and I'd love to get it translated. (Речь идет о его книге Exploratory Software Testing.) Any chance you can make it to Norway in February? I'll forward details of the conference when I get them. I'll also be visiting our Google office in Switzerland on that trip as well.»

Тут уже монитор меня не спас =) Да и зачем было скрывать мои эмоции =)

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

Тут Виттакер был бессилен. Но зато наше общение вылилось в перевод цикла его статей «7 пороков тестирования», которые опубликованы в моем блоге и на software-testing.ru. Кстати, перевод первой статьи я выложила как раз в первый день GTAC 09, как бы в отместку =)

Вяло обмениваясь письмами в режиме 1 письмо в неделею с темой «ещё одна статья переведена и выложена» - «Oh, great, thank you», я полностью успокоилась, и меня греет финальная фраза в последнем письме от организаторов GTAC «we're looking forward to hopefully seeing you in one of the upcoming GTACs in the next years!»

И вот, 23 ноября, я получаю письмо от Джеймса :

"
It's looking likely that I will be a keynote at the Swiss Testing Days in Zurich on March 17. I am sure I can pull some strings and get you involved in the Zurich event. "

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

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

И ещё – прислушивайтесь, пожалуйста, вдруг вы можете помочь тому, кто кричит неподалеку =)

Спасибо,
А я буду дальше любоваться облаками =)

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

День знаний от Лаборатории качества - отзыв злого полицейского.

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

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

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

Сразу вопрос к ребятам-организаторам: на кого были рассчитаны доклады? Целевая аудитория хотя и была объявлена, но, боюсь, не понималась самими тренерами. Попытка сделать как можно обобщеннее сыграла злую, хотя весьма предсказуемую шутку.


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

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

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

В итоге получилось непонятно, на кого этот рассказ был рассчитан:

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

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

- На тест-дизайнеров? Так любому тест-дизайнеру (неважно, выделенная это должность или просто одна из исполняемых ролей) все сказанное и так известно. Если же не известно и он пришел этому учиться – то В ПЕРВУЮ ОЧЕРЕДЬ нужно было рассказать, откуда эти изменения берутся и как их обрабатывать.

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

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

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

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

Тем более, что это ну никак не соответствовало заявленной теме доклада. Если же Вы рассказываете для тех, кто только собирается стать профессионалом, то НЕЛЬЗЯ в голом виде подать за 30 минут всю сложность поддержания мотивации у сотрудников, которой им придется заниматься в будущем. Превратное мнение о том, что менеджер ДОЛЖЕН ДЛЯ ВСЕХ делать задачи интересными вырождается в неправильное поведение будущих менеджеров с их командой.

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

Павел начал свой доклад с того, что «я не пророк, и моё мнение не единственно верное», закончил же проповедями «забудьте о материальной мотивации», за что и был пойман аудиторией и окончательно запутан =) Уважаемый Павел! Как раз люди, которые отвечают лишь за сроки своей работы, никогда не смогут сделать продукт лучше, они смогут лишь сделать его так, как им сказали.

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


Наташа Руколь – интересный докладчик. Если бы можно было разделить её харизму на всех – всем бы хватило и было бы веселее =) Озвучен прекрасный менеджерский подход «показывать общую картинку и место конкретной задачи в ней».

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

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

Доклад Михаила Давыдова послушать не получилось - убегала собираться на самолет.


Совет ребятам на будущее – четко определяйте целевую аудиторию, которую вы хотите учить, и понимайте, что она уже знает, а о чем ей нужно ещё рассказать. И обязательно приподнимайте завесу уровня (а то и нескольких уровней) выше. Ведь тестировщику, которого учат правильно описывать баги, нужно знать, как тот или иной баг повлияет на конечное качество продукта; тест-дизайнеру, пишущему тест, нужно понимать цели тестирования на каждом этапе; тест-менеджеру, принимающему решение о расширении тестового покрытия, нужно понимать, откуда взялось это дополнительное время на тестирование в проекте и что рассчитывает этим выгадать менеджер проекта. Если этот менеджер, конечно, заинтересован в успехе проекта, а не работает лишь за «сдать в срок» =)

А если в докладах ещё и будут раскрываться заявленные темы – то цены такому обучению не будет.

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

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

Жду отзыва от Ромы, который скрасил мне галерку =) Кстати, Рома готовит презентацию про классификацию тренеров, coming soon.

Ага, вот ещё, что. Нашла Очень Положительный Отзыв (тм). Хочется задать вопрос очень простой вопрос автору: чему Вы научились на тренинге?

Собственно, вот.





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