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

SQA Days#15. День 1.

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

Затем было традиционное открытие конференции. ну и .. понеслась.
Прсыпающийся от обилия кофе мозг пошел усваивать доклады.

Елена Захарова.
Тестирование Ленты Активности. 
Хороший получился доклад, для расширения кругозора, а также для новичков. Доклад  также будет полезен для новичков, и тех, кто работает с пободными сервисами. У Лены довольно большой опыт, лента одноклассников -разумна, и все это из кучи обработки и фильтрации данных.

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

Юлия Горлова
Лайфхаки ручного тестирования на мобилках.

понедельник, 21 апреля 2014 г.

Встречи клуба (г. Москва) Читать обязательно!

Отвлекусь от отзыва об SQA на пост про Московский клуб тестировщиков.

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

- Почему так редки встречи?

* Нет докладчиков, нет площадок.
Проблема: за все нужно платить.

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

- Мы же в Москве, у нас Баранцев, Руколь и пр. пусть выступают!

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

- В Питере вот проводят даже видео записи.

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

Теперь о планах и хорошем


SQA Days# 15 Впечатления (общее)

Вот и отгремела самая общительная конференция тестировщиков SQA Days# 15!

Конференция для меня прошла в очень крутом драйве, подъеме и позитиве.

*  Организаторы превзошли снова сами себя
*  Было много хороших и очень хороших докладов (были и не очень, не без этого)
*  Ребята, которых я готовила выступили очень круто! (А Инна Смирнова даже заняла призовое место, как лучший докладчик)
* Я встретила старых и новых друзей/знакомых
* Услышала интересные для себя доклады

* Опробовала новый скил - выступление втроем
* У меня было день рождение

В целом, скажу откровенно, на SQA я не первый раз, и всегда мне эта конференция нравится, но такое ощущение конфы у меня было всего 2 раз. Такое было, когда я пришла 1 раз на нее в своей жизни, и вот в этот.

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

Конкретный разбор докладов и отзывы по ним я напишу позже.


Ах, да, слышала довольно приличное количество комментариев, что площадка маловата для такого количества народа.
Народу действительно было много. Более 700 человек!
После "Львов-Арены" места действительно казалось мало. В залы периодически было невозможно попасть, НО при этом было столько экранов, что можно было стоять у дверей, смотреть на экране презенташку и слышать докладчика.
А количество народа в зале - блин, я столько людей узнала)  В небольшом пространстве оказалось, вдруг, что многие люди смогли перезнакомится. В большом помещении проще было укрыться за столиком своей компашкой и никого не задевать. А тут "пришлось" и в конце второго дня многие это замечали и воспринимали площадку  по-другому. 

Как говорится, Все, что не делается - к лучшему !" )

А вот видео с афтепати для настроения! Позитифф в фб

четверг, 17 апреля 2014 г.

Тестировщик и техническая поддержка ( моя статья из журнала Tester's life Декабрь'12)

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

Кастинг «МОДЕЛЕЙ»


Размышляя над кандидатурами, обычно рассматривают: 
• Community manager.
• Специально выдрессированная обезьянка.
• Немногим реже — программист.
• С некоторой долей вероятности попадает ПМ.
• И чаще всего — тестировщик...
У многих возникает вопрос праведного гнева —почему и тут тестировщик?
Причин может быть несколько:
• «Тестировщик — всезнайка» — он знает больше всех о самом продукте и о его уязвимостях.
• «Тестировщик — винтик-шпунтик» — оперативно среагирует на озвученную проблему.
• «Тестировщик — сыщик» — он примет меры,дабы исправить эту проблему в кратчайшие
сроки, или найдет того, кто это сделает.
• «Тестировщик — проводник» — может разобраться и объяснить пользователю на
понятном для него языке, как исправить проблему, даже если она не на стороне продукта.
Рассмотрим вариант «Community manager» (он же СМ):
• «СМ — робот» — как правило, он ничего не знает о самом продукте, только общие понятия.
• «СМ — ответственный» — узнав о проблеме, он о ней кому-то, наверное, сообщит. Кому — потом можно искать долго и нудно.
• «СМ — злобный буратинка» — он не поможет пользователю решить его проблему, если
проблема на стороне пользователя. А иногда, даже если и поможет, то все может обернуться
еще хуже и уж лучше б не помогал.
Следующий вариант «Программист»:
• «Программист — обычный» — знает продукт только в части своего кода.
• «Программист — иностранец» — он не умеет говорить на языке обычных людей о продукте.
Если и объяснит что-то, пользователь не поймет.
• «Программист — вредитель» — узнав о проблеме, он может исправить ее молча; может передать другому программисту; может отправить тестировщику; может решить, что это
не проблема, и т.д.
Остальные кандидаты — конструктор из характеристик СМ-а и программиста. Небольшой опрос показывает, что в российских и украинских компаниях, тестировщик сам занимается
технической поддержкой или находится в тесном сотрудничестве с ней.
Где это не так — можно только посочувствовать или поставить памятник. На выбор...
Подводя небольшой итог, согласимся с тем, что кандидатура тестировщика является наиболее подходящей для выполнения роли технической поддержки. Теперь давайте рассмотрим, какие подводные камни его ждут на этом пути и какую пользу можно извлечь.

ТЕСТИРОВЩИК — ОН ЖЕ ТЕХНИЧЕСКАЯ ПОДДЕРЖКА

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

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

Список может пополняться и варьироваться, но это основа того, с чем вы можете столкнуться.

Бочка пользы

Казалось бы, да к черту такие танцы с бубном, на кой оно бедному тестеровщику, когда работы по горло! А полезно это может быть по нескольким причинам:
• Оперативная реакция — если пользователям что-то создает дискомфорт, они мгновенно
поднимут бурю негодования, что позволит вам локализовать и устранить проблему в
кратчайшие сроки.
• Баг-халява — нет таких программ, где не существует бага/уязвимости, которая приносит
пользователю радость и халяву, а тестировщику бессонную ночь и валерьянку. Будет здорово,
если о таком виде «жука-уникального-с-планеты-Халявного-Зла» сообщит честный
пользователь.
• Баги-собственники — привязываются аки верный питомец исключительно к своему
персональному пользователю-хозяину. Найти баг можно в тот момент, когда ваше созвездие
сменило галактику в 45-й день месяца, совпавшего с лунным затмением, которое
бывает раз в 130 лет и... И счастье, если его сдаст пользователь.

ТЕСТИРОВЩИК И ТЕХНИЧЕСКАЯ ПОДДЕРЖКА — ВМЕСТЕ НА ВЕК!

 

Допустим, все-таки есть «СМ-уникум», который знает продукт, может ответить и помочь пользователю, а всю полученную информацию передает вам лично.
Идеальная схема.
Или нет...?

мая твая не панимает
Главная проблема всех времен и народов — коммуникация, игра в испорченный телефон.
Вот посадим мы их всех на лавочку, как в детстве играли, и посмотрим, что получится.
По порядку рассчитайсь!
1. Пользователь1.
2. СМ.
3. Тестировщик.
4. «Человек-исправлятор».
Допустим, Пользователь1 передает проблему СМ-у, тот — дальше по цепочке. До тестировщика дойдет наиболее полная информация, а к человеку-исправлятору попадет
уже локализованная проблема. Такую схему можно использовать только при условии, что пользователи идеальные, формулируют проблемы четко, а СМ не растеряется, когда вместо Пользователь1 — появится Пользователь 2, 5, 250, 1032, и т.д.
Усложним задачку, посадим вместо Пользователя1 — Скромняжку.

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

Что в сухом остатке?


Тестировщик = техподдержка — идеал для небольших и средних компаний. В больших возникнут проблемы, там лучше набирать уже специально обученных людей. Идеальной схемы не существует, и как бы мы ни пытались охватить все проблемы, каждому необходимо
собрать свой конструктор из подходов и методик. Ведь каждая компания и ее продукты уникальны, и вряд ли кто- то знает, что подходит именно вам.
Ну и помните, талантливый человек талантлив во всем, неважно, тестировщик он, программист, специально обученная личность, ПМ или community manager.

четверг, 10 апреля 2014 г.

Игровой сленг. Или "Разговорный гайд для нубов"


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

Данная проблема действительно существует.

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

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

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

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

Например - когда вы разбираете ТЗ  и что-то переспрашиваете  - отдел ГД в 90% случае ответит вам что-то типа :

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


И это будет обьяснение " на русском".

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

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

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


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

Или вот мой знакомый говорит - купил  подруге обвес на 8 марта.  (Это значит, что купил какое -то украшение, цепочку или браслетик и прочее)


Вобщем, удачи вам в изучении нового языка! Качайте скилы!  И велком в виртуальный мир!