Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.

В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.

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

Под катом — разбор тестирования первого из этой тройки, GraphQL. Все примеры в посте я делал с помощью Postman, он достаточно популярен и доступен, чтобы вы при желании могли всё быстро в нём повторить.

18 месяцев.

400 развернутых интервью с "входящими в IT".

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

~30 курсов, на первые занятия которых автор ходил или общался с организаторами (7-8 курсов предложили полностью бесплатное обучение).

10 Хабр-статей, включая эту (набравшие более 300'000 просмотров).

В результате:

• Получен ответ на главный вопрос жизни, Вселенной и всего такого: "Какой процент студентов QA-курсов после выпуска в действительности начинает работать тестировщиком?"

• На основании собранной статистики выявлен список худших QA-курсов в обитаемой части галактики с точки зрения самого объективного параметра. А именно - способности выпускников трудоустроиться.

• Составлен гайд “Как способным войти в IT с гарантией трудоустройства” (но он не всем понравится)

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

Начнем с самого начала: что такое «тестирование программного обеспечения»? Мы изучим основные концепции тестирования программного обеспечения, которые сформируют ваше мышление по мере приближения к искусству качественного инжиниринга. 

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

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

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

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

Здесь я объясню, как определить стратегию тестирования, которая заложит основу для надежного и гибкого процесса тестирования, подходящего для любой методологии разработки, используемой вашей командой. Я раскрою:

— Что такое стратегия тестирования?

— Структура стратегии тестирования

Данная статья является продолжением рассмотра основ GLTF и GLB форматов. Вы можете найти первую часть статьи здесь. В первой части мы рассмотрели с вами зачем изначально планировался формат, а также такие артефакты и их атрибуты GLTF формата как Scene, Node, Buffer, BufferView, Accessor и Mesh. В данной же статье мы рассмотрим Material, Texture, Animations, Skin, Camera, а также закончим формировать минимальный валидный GLTF файл.

Material и Texture

С мешем неразрывно связаны материалы и текстуры. При необходимости меш может быть анимирован. Материал хранит информацию о том, как модель будет отрендерена движком. GLTF определяет материалы, используя общий набор параметров, которые основаны на Physical-Based Rendering (PBR). PBR модель позволяет создавать “физически корректное” отображение объекта в разных световых условиях благодаря тому, что шейдинговая модель должна работать с “физическими” свойствами поверхности. Есть несколько способов описания PBR. Самая распространенная модель — это metallic-roughness model, которая и используется по умолчанию в GLTF. Также можно использовать и specular-glosiness модель, но только при помощи отдельного расширения (extenstion). Основные атрибуты материала следующие:

1. name — имя меша.
2. baseColorFactor/baseColorTexture — хранит инфомрацию о цвете. В случае атрибута Factor информация хранится в числовом значении для RGBA, в случае Texture — хранится ссылка на текстуру в объекте textures.
3. metallicFactor — хранит информцию о Metallic
4. roughnessFactor — хранит информцию об Roughness
5. doubleSided — имеет значение true либо false (значение по умолчанию) и указывает на то, будет ли меш рендериться с обоих сторон или только с "лицевой" стороны.

Что такое GLTF и GLB?

GLTF (GL Transmission Format) — это формат файла для хранения 3Д сцен и моделей, который является крайне простым в понимании (структура записана в стандарте JSON), расширяемым и легко взаимодействующим с современными веб-технологиями. Данный формат хорошо сжимает трёхмерные сцены и минимизирует обработку во время выполнения приложений, использующих WebGL и другие API. GLTF сейчас активно продвигается Khronos Group как JPEG от мира 3D. На сегодняшний день используется GLTF версии 2.0. Существует и бинарная версия данного формата, которая называется GLB, единственное различие которого в том, что все хранится в одном файле с расширением GLB.

Эта статья — 1 часть из 2х. В ней мы с вами рассмотрим такие артефакты формата и их атрибуты, как Scene, Node, Buffer, BufferView, Accessor и Mesh. А во второй статье мы рассмотрим оставшиеся: Material, Texture, Animations, Skin и Camera. Больше общей информации о формате можно найти здесь.
Если в процессе просмотра статьи захочется лично поработать с данным форматом, то можете скачать модели GLTF 2.0 с официального репозитория Khronos на GitHub

Проблематика и её решение

Изначально GLTF формат был задуман Khronos Group как решение для передачи 3D контента по интернету и был призван минимизировать количество импортеров и конвертеров, разные виды которых создаются при работе с графическими API.

На текущий момент GLTF и его бинарный брат GLB используются как унифицированные форматы и в CAD программах (Autodesk Maya, Blender и т. д.), в игровых движках (Unreal Engine, Unity и прочих), AR/VR приложениях, соц. сетях и т.д.

Было бы странно, если в такой комплексной системе как видео игры не было багов. Они есть, встречаются часто и этот бестиарий здесь крайне разнообразен. Ознакомившись с вышеприведёнными видами тестирования для игр, думаю вы догадываетесь, что и баги в видео играх встречаются далеко не только "404 not found" и "game crashed". Давайте же пробежимся по самым часто встречающимся из них в игровой индустрии!

В первых 2х статьях (раз и два) мы с вами уже взглянули на виды тестирования, применяемые в геймдеве и примеры багов, часто (и не очень) встречаемых в играх. Но в воздухе остался неозвученный вопрос: "Каким образом всё это тестировать?" В этой главе поделюсь подходами и инструментами, которые я использую для тестирования тех или иных игр, включая игры с большими картами (к примеру в жанре Battle Royal) или же что-то более локальное, такое как спортивный симулятор.

Задачи стали проходить тестирование быстрее. Я просто добавил на сервер...

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