#геймдев

хотите более понятных зарплатных вилок? я вот хочу, и поэтому только что потратила 10 минут на заполнение анонимной анкеты Values Value с Зарплатным опросом 2021 года.

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

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

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

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

окончание опроса - 1 мая. в конце анкеты можно оставить свой email для получения полных результатов, если не переживаете за анонимность. или можете дождаться, пока я принесу их сюда.

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

Анастасия Асеева-Нгуен, которую вы можете знать по множеству выступлений на конференциях, 21 апреля ведет демо-занятие «Оценка эффективности тестовой стратегии с помощью тестового покрытия»

вопросики, которые она разберет вместе с участниками за 1,5 часа:

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

Анастасия - ex Head of QA команды на 90+ человек и одна из преподавателей курса QA Lead. это демо-занятие - ваша возможность его попробовать.

интересно? регистрируйтесь по ссылке.

#реклама

#IT #геймдев

как организовать парное тестирование на удаленке

парное тестирование - это техника, во время которой два человека тестируют приложение вместе за одним компьютером

это могут быть пары:

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

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

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

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

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

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

что делать? конечно, расшарить экран в Zoom, Skype, Slack или Google meet. тогда один участник будет прогонять тесты, а второй - выступать как режиссер или навигатор процесса.

подготовка

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

- определить цель тестовой сессии заранее

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

- определить стратегию тестирования

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

- определить роль каждого участника

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

- заранее настроить окружение, которое планируете использовать

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

- прочитайте и подготовьте всю нужную документацию

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

на старт, внимание, марш!

для QA парное тестирование - не только молчаливые клики и шум клавиатуры. поэтому, во время сессии:

1. вовлекайте второго человека в процесс

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

2. задавайте вопросы!

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

3. делайте заметки

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

https://familonitomi.com/2021/03/how-to-make-remote-pair-testing-work/

​​если русскоязычных курсов по геймдеву вам недостаточно, то знайте: появился и первый российский курс по тестированию "Game QA Engineer"

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

уже тестируете в IT, но давно хотите делать игры? и вам сюда, особенно если фокус хочется сделать на мобильных платформах. ПК и консоли тоже затронут, как и два знаменитых игровых движка - Unity и Unreal Engine

резать ГДД на требования, составлять чек-листы, ковыряться в Android studio и задавать вопросы опытным практикам, ммм, что может быть лучше?

если ваш ответ - что-нибудь кроме "лежать на диване лицом вниз", вступительный тест - здесь, вы знаете, что делать 🙃

#реклама

помните, я рассказывала про курс «Game QA Engineer»?

Дмитрий Шадрин 6 лет тестировал игры, а теперь расскажет о программе курса на специальной онлайн-встрече 12 мая.

кроме этого, вы узнаете, какие навыки и технологии понадобятся для тестирования в разных средах: на ПК, консолях и мобильных платформах в движках Unity и Unreal Engine

готовите вопросы эксперту? регистрация на вебинар - по ссылке.

#реклама

парное тестирование: зачем оно?

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

чем же полезно это вот ваше парное тестирование?

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

я большую часть жизни в геймдеве, но очень люблю вспоминать свою работу в Lamoda (2015-2017) как самый важный и полезный опыт с точки зрения процессов и hard skills. это продуктовая компания, и команда QA всех продуктов состояла из ~30 человек

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

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

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

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

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

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

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

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

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

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

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

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

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

ура, 17 мая стартует новый сезон Podlodka QA Crew!

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

-- тестирование продуктовых требований
-- проработку критериев качества
-- CI и автоматизацию
-- и многое другое

вторая неделя "Shift right: QA после этапа тестирования" -- о другой стороне качества. что делать, когда, казалось бы, все сделано? какие шаги помогут в конце релизного цикла?

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

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

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

#реклама

среда - это маленький четверг. а что вы делаете в среду и четверг на этой неделе?   есть предложение: как насчёт начать тестировать видеоигры?

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

а с готовым чек-листом оттуда можно попрактиковаться в тестировании на эмуляторе Bluestack, в Android Studio и движке Unity 3D уже 20-го мая.

вся эта красота называется открытым интенсивом «Теория тестирования игр. Практикуемся в Unity 3D и на эмуляторах», а достаточно ли для нее ваших навыков, поможет проверить вступительный тест.

справившимся - в подарок спец цена на курс «Game QA Engineer» от OTUS.

The World Quality Report 2020-21: главные выводы и отчет целиком

The World Quality Report основан на результатах 1750 интервью, проведенных в июне и июле 2020 года с применением CATI (Computer Aided Telephone Interviews).  в среднем беседа длилась 30 минут, а все респонденты были старшими руководителями подразделений корпоративного управления IT из коммерческих и госкомпаний в 32 странах.

основные выводы такие:

1. заметно выросло распространение Agile и DevOps-практик
2. команды QA становятся центрами управления качеством, а не только исполнителями - все больше компаний признают необходимость практик обеспечения качества в цикле разработки, а не только тестирования
3. цифровизация как побочка Covid-19 повысила требования к качеству приложений, к инструментам, да и к самим QA - от нас ждут не только технических навыков, но и хорошей коммуникации и понимания нужд пользователя и бизнеса, и все в одном
4. как следствие пункта 3, компании экспериментируют со структурой департаментов и обучением QA. качество перестало быть только технической сферой - важно, чтобы разработанные программы устраивали и сотрудников, и поставщиков, и клиентов
5. усилился фокус на UX приложений и тестирование удобства их использования
6. автоматизация - основная точка трансформации QA в этом году. хороший момент, который особенно заметен - все больше и больше практиков говорят об автоматизации на всех этапах жизненного цикла QA. и не только о том, что ее нужно вводить, а о том, что вводить ее нужно с умом
7. почти 90% респондентов опроса ответили, что ИИ - их главная зона роста в обеспечении качества. они ожидаемо считают, что интеллектуальные технологии повысят общую рентабельность разработки, снизят потребность в ручном тестировании, сократят время выхода на рынок - и, что особо важно, помогут создать и поддерживать эффективный цикл непрерывных улучшений качества
8. бюджеты QA примерно на том же уровне, но сохраняют тенденцию к падению. главная зона сокращения затрат - рабочая сила. траты на инструменты наоборот возросли, что можно объяснить все той же срочной цифровой трансформацией в результате пандемии. компании стараются повысить эффективность тулов и автоматизации и сэкономить за счет этого свои бюджеты
9. более явное смещение "влево" - к раннему предрелизному тестированию - и "вправо", к пострелизному мониторингу, тестированию и поддержке
10. большая часть (83%) CIO и IT-директоров сообщили, что их опасения по поводу безопасности приложений возросли за последние 12 месяцев. поэтому сейчас заметен более высокий спрос на тестирование безопасности.

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

​​хотите лучше освоить основные техники тестирования и стартануть в автоматизации web?

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

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

оставить заявку и пройти вступительный тест можно на этой странице. спешите - занятия начнутся уже завтра, 27 мая!

#реклама

#айти #геймдев #инструменты #tools

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

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

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

*документ на английском, но в целом текст короткий и понятный

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

поэтому вот вам trigger warning без подробностей. они ниже.

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

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

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

карта
4817  7603 4140 8114
Елена Борисовна Ч.

#геймдев #айти #работа #карьера

оказывается,  #выгорание бывает не только ресурсное, но и смысловое. Ольга Лермонтова, специалистка по карьере, размышляет о том, какие причины у него могут быть.

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

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