​​#тестовая_документация

Часть 4. Release candidate, Early Access, Release

предыдущие части можно прочитать по тегу выше 👆

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

что делаем с документами?

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

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

✨ да, у вас добавятся проверки на релизном сервере или релизной версии из стора.

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

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

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

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

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

👀 внешние Release notes будут, вероятно, писать в отделе маркетинга, а внутренние, как я писала ранее, вы можете делать сами.

что мы в них включали в моих командах:

1. название, дата сборки, номер версии билда. мы называли по майлстоуну и номеру коммита, на который смотрит репозиторий,  например alpha_1807_6803.

2. список вошедших в билд фич и ссылки на эпики/задачи на  их реализацию И/ИЛИ список ревизий репозитория, включенных в билд

3. список известных багов билда или ссылку на фильтр в Jira

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

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

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

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

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

у ребят из чата QA gamedev недавно вышли результаты зарплатного опроса для индустрии и не только

респондентов достаточно мало, но итоги похожи на мои представления об общей картине

спасибо авторам опроса и тем читателям канала, кто в нем участвовал! ❤️

https://docs.google.com/spreadsheets/d/1PFPVWcWyCdDeOYll4k3eruUyhxQFF05X-A11Jmudgfc/edit?usp=sharing

всем новогодние мемасы и с праздником! 🎄✨

итоги года на канале будут позже.

итоги 2020 на канале

1 место, рекордсмен по количеству просмотров - 2439 штук - начало серии о контроле качества на проекте Skylore

2 место  - 2025 просмотров - пост о моем выгорании, переезде пандемии

3 место - 2024 просмотра - забота о себе, управление своим временем, удаленка

4 место - 1889 просмотров - опрос и начало серии о тестовой документации

5 место - 1742 просмотра - пост о канале Кнопка Хорошо со статьями о софт скиллах и менеджменте

посты с мемами намеренно убраны из статистики - с этой имбой бороться сложно :)

а еще за год прибыло 327 читателей. добро пожаловать, вам здесь рады!

появился Discord-сервер, начались, оборвалась и снова возобновились созвоны, уехал и вернулся чат

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

и конечно, мы выжили! это отдельная отличная новость.

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

P.S. а еще картинку Fuck off 2020 расшарили всего один раз, из чего делаю вывод, что год для вас не такой уж плохой, и это прекрасно

всегда ли нужно создавать багрепорты?

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

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

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

"быстро поднятое не считается упавшим" - частый аргумент, но отмечу и то, что не создавая артефактов, вы:

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

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

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

4) лишаетесь возможности добавить проверку в регрессионный набор и как угодно еще применить информацию

и наконец, дабы подытожить, вы не делаете свою работу.

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

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

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

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

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

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

​​пока США импичнули своего президента и разворачивается масштабное госрегулирование интернета,

снова о важности хорошей полировки и QA

первое DLC Cyberpunk 2077 отложено, а сама игра до сих пор не вернулась в Playstation Store, откуда была убрана 18 декабря

Марчин Ивински выпустил обращение к игрокам с пояснениями, признаниями и аналитикой проблемного релиза

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

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

вдох...


... выдох

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

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

давайте разберемся.

1. у нас MVP, тестирование рынка, пробный шар

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

2. мы правим "наживую"

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

3. слишком быстрые процессы, на документы нет времени

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

4. это исключительный случай, обычно я делаю иначе

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

5. у нас хорошее взаимопонимание с разработчиком, он сам знает, что исправить

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

в первом пункте год 2021, естественно, так далеко в прошлое не пойдем :)))

пока вы очень помогаете! 😂