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

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

откуда брать технические требования, описано в самом начале моей статьи про обеспечение качества на проекте и немного с другого ракурса - в статье "Стратегия тестирования". не смущайтесь, что там про игры, если у вас не игры. единственное важное отличие в этом плане - заказчиком задач и фич будет не геймдизайнер, а feature/prоduct оwner. и документы будут называться спецификациями, а не геймдизайн-документами.

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

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

кидать - сюда @qa_yashik_feedback_bot

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

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

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

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

"при нажатии кнопки Новая игра происходит запуск FTUE, начиная со стартового видео".

(FTUE - first time user experience, то, что игрок видит только однажды, при первом запуске)

🤔 где искать основной пользовательский сценарий?

обратить внимание на четыре вещи:

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

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

3) какие каналы монетизации у вас есть, их все нужно проверять особенно внимательно

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

после этого основные вопросы у вас должны отпасть 🌞

перерыв на мемасы

тема - бомба и пока практически не поднималась на этом канале. что вы знаете о внутренней кухне MMORPG?

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

встречаем 🦸‍♀️🧙🏻✨

нормально мы вчера разогнались в комментариях!

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

👫 наличие и стабильность интернет-соединения - важнее всего

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

🐘 много данных - нужна организация, хранение, и удобный доступ

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

🙈 хостинг серверов: выбор и поддержка

где ставить сами железки и кто их будет обслуживать? особо хардкорные ребята арендуют кусок дата-центра где-нибудь поближе к своим потенциальным клиентам-пользователям, или хотя бы в удобной зоне полёта пакета (не целлофанового). но чаще всего инфраструктурщики вдумчиво прокидывают трассировку до точки, высчитывают пинги, TTY, TTL, строят схемы и чешут черепушки. и... покупают хостинг у хостинг-провайдера! к счастью, сейчас их существует великое множество: Google, AWS, Azure, Bluemix, vultr.com, multiplay, i3d, gameservers.com, servers.com и так далее. что особо актуально для средних и небольших игр. да, это накладывает необходимость дополнительных коммуникаций, зато сильно упрощает обслуживание инфраструктуры - больше не нужно переживать за стабильность работы большей её части.

🐝  безопасность

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

хотите её больше погружения в тему - читайте эту серию статей Гленна Фидлера "интернет для игр".

но мы-то знаем, что вот так всё на самом деле выглядит ❤️

подборочка багов из новой Watch Dоgs: Legiоn

(спасибо за ссылку, Миша!)
https://youtu.be/yncmSQgy-k8

и последнее от меня про масштабные онлайн-игры (если вам мало, потыкайте кнопку внизу, — добавлю ещё):

👷🏻‍♀️ будучи лидом, да и "рядовым" тестировщиком на таком проекте, поначалу очень легко испугаться масштаба и ответственности за него. такие чувства полностью понятны, особенно если для вас это ново. но от лица выжившей (из ума) могу гарантировать, что бояться вам нечего - главное обратить внимание на количество выделяемых команде ресурсов - человеческих, денежных и других.

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

💁🏻‍♀️  спрашивайте подробнее про структуру руководства, сроки и распределение обязанностей, чтобы исключить ситуацию с множеством согласований и задержек.

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

а хороший онбординг — сила 🧠

маловато реакций, поэтому про онбординг расскажу.

как его организовывать? для онбординга нужна эмпатия. вспомните, как вы себя чувствуете первые дни на работе. даже если вы в своём деле 5, 10, 20 лет.

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

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

помню свою самую ужасную первую неделю: мне просто выдали пачку технических документов в Confluence без всякого направления и предложили их читать. голова моя кипела, приходилось несколько раз в день выходить проветриваться, а возражения и предложения не встречали понимания руководителя. вам так проще? сложно поверить, легко за вас порадоваться, поэтому так и сделаю 👌

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

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

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

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

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

а вы помните, что я провожу карьерные консультации для QA?

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

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

😐интересна вакансия, но непонятно, как к ней подступиться

вам - сюда!

я постоянно повышаю свои навыки - для вас и потому, что для меня самой это важно.

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

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

новая цена - 5000р/час.

что вы получите за эту сумму? информация здесь. приходите, я уверена, вы не будете разочарованы 🌟

для записи пишите в лс @br0wnale

UPD: первый слот занят, действует новая цена

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

нужно оценить по приоритетности баги, которые уже есть в билде. жанр игры - Battle Rоyale.

1. в игре не работает функция перехода в полноэкранный режим. при клике на кнопку ничего не происходит.

2. в результате матчмейкинга игроки с одинаковым "обвесом" спавнятся в одной точке на карте. время от времени это мешает начать матч из-за проблем с коллизиями. воспроизводимость - 1 раз на 5 пар таких игроков.

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

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

5. в игре prоduct placement от Cоca Cоla: время от времени самолёты сбрасывают ящики с игровыми бонусами. на ящике логотип компании, а в логотипе - опечатка. например, Caca Cоla.

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

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

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

присылайте ответы в @qa_yashik_feedback_bot до завтра 💫

UPD: ребят, внимание. приоритет 1 - самый высокий. 6 - низкий. присылаете номер пункта и его приоритет, и так по каждому пункту.

итоги конкурса по приоритетам багов

я предполагала, что результаты будут субъективными, но итог всё равно удивил: ни один ответ не совпал между собой! в том числе, и с моим вариантом 🙈😀

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

а теперь разберу свой вариант.

👺 самый высокий приоритет - 1 - получила интеграция с Cоca Cоla, баг №5. функционально опечатка - самая простая в исправлении ошибка с низким severity, зато политические и бизнесовые риски максимальны:  ящики с логотипом содержат игровые бонусы, и опечатку увидит очень много игроков, на ящики откроется охота. и это точно не ускользнёт от внимания партнёра, что грозит компании разрывом сотрудничества.

😈 высокий приоритет - 2 - получает голый мужик, выпадающий из самолёта, баг №6. несмотря на небольшую воспроизводимость, политические риски самые высокие, даже возрастном при рейтинге 18+. согласитесь, даже если разработчик планировал взрослый контент, то всё равно важны условия и обстоятельства, просто делать голыми всех подряд - не выход, здесь нам не порномультик :)

😥 средний приоритет - 3 - получает баг №4, ошибка в туторе. он не блокирует игроков, что снижает бизнесовые риски - не все пользователи откажутся играть. они остаются высокими, но за счёт низких политических и технических рисков, смело оставляю им это место. скорее всего, и само исправление будет простым и быстрым (фикс ассетов на клиенте).

😔 приоритет ниже среднего - 4 - получает баг №3, бесконечный матчмейкинг для 1/500 игроков. да, баг не такой частый, но игроки вообще не могут начать матч, блокируются. во-первых, им нужно настолько хотеть играть, чтобы ради этого куда-то дополнительно обращаться, а значит не все воспользуются техподдержкой. а во-вторых, для компании техподдержка тоже не бесплатна. а значит у нас не только упущенная выгода, но и денежные издержки. притом, технические риски низкие, а источник бага непонятен, что может засунуть его по приоритету ещё ниже - нужно закладывать время на исследование.

🤔 низкий приоритет - 5 - получает баг №1, полноэкранный режим. им в онлайн-играх мало кто пользуется, а правка, скорее всего, будет очень простой. все виды рисков низкие.

🥱 очень низкий приоритет - 6 - получает баг №2. начнём с того, что предусловие "одинаковый обвес" будет выполняться не всегда, а как часто, мы не знаем. частота воспроизведения - 20% игроков с таким обвесом. но при этом, проблема ещё и не всегда мешает начать матч, а если мешает - матчмейкинг просто можно запустить заново. только бизнесовые риски здесь имеют значение. ну и снова, нужно будет исследование, почему возникает баг.

спасибо за ваши мощные ответы ❤️ радуюсь, что вы практикуетесь и задание вам так понравилось!

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

мемасы? мемасы!