Про стадии рендера на почитать

В качестве наглядного пособия сколько всего происходит в графике за один кадр, можно изучить отличнейшую статью про стадии рендера в Grand Theft Auto V. 🚗
Хотя игра уже далеко не новая, в сегодняшних реалиях мало что поменялось в подходах рендеринга сцены с отложенным освещением/затенением и экранных эффектов.

#rdclr_frontend #WebGL #read

А вот все то же самое, только уже в виде видоса, с разделением по дроуколлам. 🛴

#rdclr_frontend #WebGL #read

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

🦚 На этой неделе мы с вами поговорим о дизайн-системах для фронтенда, обсудим Component Driven Development и заглянем в Storybook.

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

🕵🏻 Перейду сразу к примеру. (Все имена и персонажи выдуманы, любое сходство считать совпадением)

Представим, что разработчик Серёжа пишет приложение с нуля. Все кажется понятным и простым. Но со временем кодовая база разрастается, заказчик вносит правки, на которые Серёжа не рассчитывал, дизайнер переделал пару макетов, а дедлайн все ближе. Что происходит? «Быстрые» правки и костыли превращаются в снежный ком, который растет вместе с проектом. Проблема? Проблема.

🧑🏻‍🌾 Второй пример. Разработчик Ваня попал в проект, который писал Серёжа. Ваня долго вникает в исходники, пытается что-то изменить в подходе, но это трудно: система негибкая и зависимая. В результате Ваня вынужден подстраиваться под проект, чтобы ничего не сломалось. Работа идет медленнее, трудо- и времязатраты увеличиваются, количество багов растет. Проблема? Проблема.

Думаю, оба примера знакомы многим. Что делать?

🍅 1. Если заказчик дает добро, финансы и время, можно переписать проект. Но это очень редкий случай.
🍒 2. Можно нанять больше разработчиков, чтобы быстрее выполнить задачи. Но это дорого и неэффективно в долгосрочной перспективе.
🥝 3. Можно начать внедрять компонентный подход (CDD) и собирать дизайн-систему для UI — медленно, но верно.

🚀 Самый лучший вариант — использовать CDD с самого начала и стартануть проект с дизайн-системы.

Дальше расскажу, что дает Component Driven Development и как его использовать. Не переключайтесь.

📌 Итак, Component Driven Development

CDD в разработке интерфейсов — подход, в котором вы сначала создаете систему компонентов, а потом собираете из них UI, как конструктор Lego.

Компонент — независимая строительная единица интерфейса. Сам процесс разработки идет «снизу вверх»: от базовых элементов (компонентов) — к блокам (композиции из компонентов), а затем к страницам, из которых собирается проект.

Какие преимущества дает CDD?

✏️ Качество кода.
Подход предполагает фокусную разработку компонента. Вы концентрируетесь на определенном элементе, описываете его интерфейс, все состояния, пропсы, проверяете все сценарии использования.

✏️Простое тестирование.
Тестировать код на уровне компонента гораздо проще и эффективнее.

✏️Скорость разработки в долгосрочной перспективе.
Да, на начальном этапе разработка займет больше времени, в отличие, например, от Page-based development. Но если проект большой или его нужно масштабировать, это получится сделать гораздо быстрее и безопаснее за счет переиспользования компонентов.

✏️ Простота обучения команды.
Если к работе подключается новый разработчик, он быстрее разберется в коде и вольется в проект.

✏️Удобный рефакторинг.
Внося изменения в одни компоненты, вы не сломаете другие, потому что они изолированы.

В результате вы получаете собранный UI kit с чистым, читабельным кодом. Круто, но это все еще не дотягивает до конструктора Lego. Чего не хватает?

🍹Хороший UI — это результат плотной работы дизайнеров и разработчиков. Чтобы спроектировать такой интерфейс, нам нужно создать мост, который объединит усилия команд дизайна и разработки в единое целое. Этот мост — дизайн-система.

О ней я расскажу завтра. А вы пока подумайте, как начать разработку не с хедера или футера)
#rdclr_frontend #product

Дизайн-система для frontend-разработчика
Как будто что-то на дизайнерском. Но нет.

Дизайн-система — это набор компонентов, правил и паттернов проектирования UI.
Это результат совместной работы дизайнеров и разработчиков, единый источник правды в процессе разработки проекта.

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

Что должно быть в дизайн-системе:
🌔 набор стилевых правил - цветовая палитра, шрифты, типографика;
🌓 набор компонентов и блоков интерфейса;
🌒 документация — для каждого элемента есть описание интерфейса, свойств и состояний;
🌑 иерархия — компоненты разделены по уровням.

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

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

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

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

#rdclr_frontend #product

Storybook
(ссылка в конце)

Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.

⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.

Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.

⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.

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

Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜

#rdclr_frontend #product

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

Для компутерщиков про компутерщиков, так сказать. Так что, если не знали, что посмотреть в выходные — теперь знаете. «SAO» мы сюда включать не стали!

— «BPS» или «Battle Programmer Shirase» — анимешка старая и больше для тех, кто с компьютером на «вы», но дух программирования передан неплохо.

— «Калигула» — действие происходит в месте под названием Мёбиус, где вы будете свободны от ужасов реальности, а любое желание будет исполнено. Управляет пространством виртуальный идол Мю, каким-то образом обретший сознание сознание. Она поет и заманивает людей в цифровой рай. Оттуда — нет выхода в реальность, там — нет понятия возраста и пола, ведь все равны.

— «Виртуальный спецназ» — пятеро опытных хакеров решают решают провернуть последнее совместное дело и разбежаться, однако все идет наперекосяк.

— «Нет игры — нет жизни» — История фокусируется на Соре и Сиро, брате и сестре, репутация которых как безупречных NEET, хикикомори и игроманов породила легенды по всему интернету. Вся их жизнь — очередная «отстойная игра».

Дополняйте список чем-нибудь, что считаете качественным.

Всем привет!
👋

Меня зовут Настя, я middle QA в компании Red Collar, и на этой неделе мы с вами поговорим о тестировании.

📌 Эвристики и мнемоники в тестировании: что это и как применять — первая тема

С самого детства все мы запоминали цвета радуги с помощью фразы «Каждый охотник желает знать, где сидит фазан». Как оказалось, это самая известная нам мнемоника. В тестировании они также применяются. Так что это такое: эвристика и мнемоника?

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

SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):
✌🏻 Structure — структура приложения, проверка составляющих его частей. На данном этапе разрабатываются тестовые идеи и сценарии, связанные со структурой приложения.
🖖🏻 Function — функциональность приложения, проверка того, что приложение делает. На этом этапе разрабатывается функциональное тестирование программного продукта.
🤜🏻 Data — работа с данными; проверка того, как приложение работает с данными. Тестировщики должны узнать, с какими данными работает система, и разработать тесты, проверяющие, как система получает, обрабатывает и выдает различные виды данных.
🤘🏻 Platform — платформа; проверка того, как приложение взаимодействует с платформой, на которой запущено. Тестировщики должны определить, на каких платформах выполнять ручное и автоматизированное тестирование.
👌🏻 Operations — использование, проверка сценариев использования приложения. В этом пункте тестировщики должны выяснить, кто конечные пользователи тестируемого программного продукта, для каких задач пользователи собираются его использовать.
🤏🏻 Time — время, проверка того, как приложение ведет себя в зависимости от времени.

Самая известная мнемоника для тестирования мобильных приложений — I SLICED UP FUN.
🕴🏻 Inputs — входные данные (вводимые с клавиатуры или набираемые пальцем).
👨🏼‍🦽 Store — Хранилище. Android Market, например.
🧍🏾‍♂️ Location — Расположение (ошибки гео-координат, движение, быстрая остановка).
🧑🏻‍🦯 Interactions/Interruptions — взаимодействие / прерывания. Сворачивание приложение, когда играет музыка, например.
🏃🏻 Communications — входящий звонок, смс, уведомление.
👬 Ergonomics — мелкие детали напрягают глаза, ищите такие проблемы.
🧍🏿‍♀️ Data — Данные. Все, что приложение обрабатывает.
🕺 Usability — удобство использования.
🧑🏽‍🦼 Platform — для каких платформ выпущено ПО, где будет работать.
🧎🏻‍♀️ Function — Функционал.
👯‍♀️ User Scenarioes — пользовательские сценарии.
🤳🏻 Network — сеть.

RCRCRC — эвристика, применяемая для регрессионного тестирования.
👕 Recent — какие новые функции были добавлены в текущей итерации, что было изменено из уже существующего функционала.
🩱 Core — основные сценарии. Что должно всегда работать.
🥼 Risk — какой функционал имеет максимальные риски — его и проверяем.
👘 Configuration — на каких окружениях и в каких конфигурация должно работать.
👞 Repaired — какой функционал мы чинили в релизе. Ретест багов, как минимум самых важных.
🧣 Chronic — регрессия областей с хроническими болезнями (где чаще всего находились баги ранее).

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

#rdclr_QA

📎 В первой статье (VPN) вы прочитаете более подробно о преимуществах и недостатках тестовых эвристик, об «оракуле» — дополнительном эвристическом механизме.
Во второй — расшифровку самых известных мнемоник и эвристик и их описание.

Как писать хорошие тест-кейсы?

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

1️⃣ Один тест-кейс — одна проверка
Следи, чтобы в тест-кейсе был только один ожидаемый результат. Это поможет не запутаться — по крайней мере, пока ты учишься. Когда станешь опытнее, сможешь сочетать несколько проверок в одном тест-кейсе, но пока лучше следовать этому правилу.

2️⃣ Один тест-кейс — одни тестовые данные
Тестовые данные — данные, которые понадобятся тебе для тестирования. Например, ты проверяешь, что в поле можно ввести текст от 2 до 10 символов. Символы, которые ты вводишь в поле для проверки, — тестовые данные. В одном тест-кейсе используй одни тестовые данные. Например, если нужно протестировать поле с коротким и длинным именем, составь два разных тест-кейса.

3️⃣ Уникальный ID
ID тест-кейса не должен повторять другие. Если будет два одинаковых, команда запутается. Иногда ID для тест-кейсов задаёт система, в которой работает тестировщик. Если такого нет, следует уточнить у коллег какая система учет принята в команде.

4️⃣ Уникальный и полный заголовок
Хороший заголовок не повторяет заголовки других тест-кейсов, чтобы не запутаться. Он конкретный и отвечает на вопрос: «Что я проверяю?» или «Что? Где? Когда?».

5️⃣ Лаконичные и чёткие шаги
Когда описываешь шаги: не расписывай их чересчур подробно: включай в них только необходимую информацию: следи, чтобы каждый шаг отвечал на вопрос «Что нужно сделать?».

6️⃣ Если для проверки нужны особые настройки, укажи предусловие
Предусловие — всё, что нужно сделать до того, как приступать к основным шагам тест-кейса. Например, зайти в приложение под определённым логином или включить какие-то настройки.

7️⃣ Если после проверки нужно дополнительно проверить изменившиеся состояние, укажи постусловие
Постусловие — всё, что нужно сделать после того, как были выполнены основные шаги тест-кейса или вернуть систему в исходное состояние (выйти из профиля пользователя, удалить сохраненные данные).

8️⃣ Словарный запас
Избегай использование в тест-кейсе слов:
человек —> пользователь
есть —> находится, отображается
посмотреть —> проверить
как на макете —> согласно макету
Замени их на предложенные (—>)

И самое главное — соблюдай правила орфографии! 🌺

#rdclr_QA

Введение в тест-анализ #1: декомпозиция, визуализация, поиск серых зон

🍼 Тест-анализ (test analysis) — один из этапов тестирования, направленный на изучение требований и макетов. Когда будешь изучать, постарайся ответить на вопрос: что именно предстоит тестировать? Так ты составишь список объектов тестирования.

Объекты тестирования (test objects) — части приложения, которые нужно проверить. Например, компания сделала почтовый клиент — приложение, в котором можно обмениваться электронными письмами. В последнем обновлении разработчики добавили фичу: теперь приложение определяет спам и сохраняет его в отдельной папке.

Попробуй определить, что именно предстоит протестировать? Тестировщик будет проверять не всё приложение целиком, а определённую функциональность — работу со спамом. Но сначала нужно получить требования: с этого начинается вход в тест-анализ.

🌽 1. Декомпозиция
Декомпозиция — разделение целого на части. На этом этапе тебе предстоит разбить крупные объекты тестирования на более мелкие. Так с ними удобнее работать. Например, функциональность работы со спамом можно разбить на два объекта: определение спама и сохранение в отдельной папке

🍫 2. Визуализация
Когда декомпозируешь требования, попробуй их визуализировать. Визуализация — создание наглядной схемы всех объектов тестирования. Так проще воспринимать и структурировать информацию. Если поймёшь, что на схеме чего-то не хватает, уточни требования. Визуализировать можно с помощью mind-карт и блок-схем.

🍾 3. Поиск серых зон
Когда декомпозируешь и визуализируешь требования, сможешь увидеть в них несостыковки, противоречия и пропуски — серые зоны. В этом случае обращайся к менеджеру, он поможет разобраться. Иногда приходится искать серые зоны повторно. Например, тебе удалось заметить неявные требования, доуточнить их и дополнить схему. Но оказалось, что в ней всё ещё есть слепые зоны. Их тоже нужно уточнить, декомпозировать и визуализировать: так ты получишь полное представление о том, что предстоит тестировать.

Следом я расскажу о проблемах с поиском серых зон.
#rdclr_QA

Введение в тест-анализ #2: проблемы с поиском серых зон

🍩 неуточнённые и неполные требования
С первого раза их не заметить. Например, как должно выглядеть сообщение «Заказ оформлен»? Отдельное всплывающее окно? А какого цвета должен быть текст сообщения? Ещё одна серая зона: почему поле «Отчество» обязательное? Что делать, если его нет?

🍩 скрытые требования
Авторы документации не всегда включают требования, которые кажутся им очевидными. Например, логотип состоит из двух слов и должен быть кликабельным: только первое слово при нажатии ведёт на главную страницу, а второе — на каталог товаров.
макеты и требования расходятся. На макетах есть нижний блок со ссылками, но в требованиях его функциональность не описана. Другой пример: на макете поле называется «Email», а в требованиях — «Электронный адрес».

🍩 требований нет.
Такое тоже бывает)

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

Советую на почитать:
1. Как находить ошибки в бизнес-логике фичей
2. Зачем проводить декомпозицию требований
3. Mind Map в помощь тестировщику

#rdclr_QA #read

Тестирование API: на что обратить внимание

API (Application Programming Interface — программный интерфейс приложения) — интерфейс, который помогает приложениям взаимодействовать.

Приложения тоже могут отправлять команды, и другие приложения будут их выполнять. API помогает сервисам «общаться» и обмениваться информацией друг с другом.

🧐 На что обратить внимание при тестировании АПИ?
🦴 1. В первую очередь на URL, т. к. вы указываете куда идти за ресурсом. Неверный URL запроса вернет вам ошибку Couldn’t not send request, вы просто не сможете отправить запрос.
🦴 2. Method, чтобы понимать что с ресурсом надо сделать.
🦴 3. Тело запроса также важно проверять, так как в теле вы передаете информацию или обновляете существующую. Например, если неверно указать id — вернется ошибка 400 Bad Request.
🦴 4. В теле ответа также следует быть внимательным, создалось ли то, что мы хотели; какие значения в наших полях.
🦴 5. Формат передаваемых данных (json/xml). Если сервис принимает запросы только в джейсон, то при отправке другого формата вы получите ошибку 415 Unsupported Media Type.
🦴 6. Перестановка мест параметров не должна вызывать ошибку, так как от перестановки слагаемых... дальше мы знаем :).
🦴 7. Статус-код показывает успешен или нет наш запрос, а текст ошибки поможет понять, где мы допустили ошибку. Так как только наше АПИ будут использовать другие разработчики при интеграции первое с чем они столкнутся — это с ошибками. Они могут забыть указать заголовок или опечататься, поэтому сообщение об ошибки должно быть понятным.
🦴 8. Регистронезависимость заголовков: вне зависимости от написания они все должны передаваться.

🤬 При тестировании API негативные тесты очень важны! Например:
1. Что будет, если какой-либо из заголовков не передать?
2. Что будет, если передать неправильно и какой текст об ошибке мы увидим?

Позитивные тесты мы проводим по документации (все ли вернулось?). Проверяем это независимо от метода. Различие лишь в том, есть ли тело у метода или нет.

Что еще почитать по теме:
- Различия в тестировании REST и SOAP
- Быстро про API

#rdclr_QA #read

Всем привет и хорошего начала недели! Написала так много, что побуду с вами чуть подльше. 😺 Продолжаем тему тестирования, и кто не знаком, — дежурю я, Настя, middle QA. ✌🏻

Web-приложения и особенности их тестирования

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

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

Есть три основных шаблона построения сайтов:
🥘 MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие.
🍔 SPA (single-page application): одностраничное приложение, содержащее HTML-страницу,которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки.
🧅 PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.

Компоненты веб приложения:
🫖 UI — интерфейс пользователя. Реализуется через браузер в виде Web страниц. Написание на HTML, CSS, JavaScript.
🍵 Серверная часть. Языки программирования PHP, Perl, C/C++, Java, Python, Ruby, NodeJS.

Что тестировать? 🌅
1. Дефекты могут находиться как на клиентской, так и на серверной стороне.
2. Отображение клиента — кроссбраузерность.
3. Тестирование форм и ролевых моделей.
4. Тестирование установки веб-приложения.
5. Тестирование базы данных.
6. Тестирование передачи данных.
7. Безопасность, нагрузка.

Можно еще почитать о распространенных багах на веб.
#rdclr_QA #read

Библиотека: Все необходимое для ручного тестирования Web-приложений

🫁 Теория:
- Чек-лист тестирования WEB приложений
- Особенности тестирования веб-приложений
- Виды тестирования веб-приложений — как выбрать нужный?
- Основы тестирования и отладки Веб-приложений
- Web Application Testing: Step by Step Process to make it Right
- Frameworks
- Все про HTML и CSS
- Все про JavaScript
- Domain, Host, DNS: google support | статья
- Браузеры и движки: статья | Blink | Gecko | WebKit

🫀 Названия элементов UI:
- Гайдлайны платформ
- Статья с примерами и названиями элементов
- User Interface Elements
- UI Docs
- UI Kit Rambler

🧠 Статистика и аналитика:
- Яндекс.Радар
- gs.statcounter.com

👋🏻 Инструменты:
- extensions: Web Developer | EditThisCookie
- Chrome DevTools: Documentation | статья | breakpoints
- Responsive design testing tool
- Xenu's Link Sleuth (check broken links)
- Валидаторы данных: Валидатор JSON | Валидатор XML
- JSON encode/decode: json_encode | json_decode
- Fiddler: Fiddler | статья
- Charles: Charles Proxy | статья

🦷 Облачные платформы для кросс-браузерного тестирования:
Browserstack | CrossBrowser Testing | Browser Ling | Lambdatest | Sauce Labs | TestingBot | Comparium | Browseemall | Multibrowser | Digital.ai | Ranorex | TestComplete

#rdclr_QA #product #read

Типы мобильных приложений и как их тестировать

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

🌂 Чаще всего приложения для мобильных телефонов загружают на таких площадках, как Google Play или AppStore. Разработчики создают приложение либо под конкретную платформу, либо сразу для нескольких. Наиболее популярные операционные системы, для которых выпускаются новинки — это iOS, Android, Windows Phone.

🧚🏿‍♂️ Нативные приложения — это приложение, разработанное специально для одной платформы и на родном (с англ. native — родной) для определённой платформы языке программирования. Для Android этим языком является Java, тогда как для iOS — objective-С или Swift.

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

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

🥵 Как тестировать мобильные приложения? 🥶
Любое приложение на Android, Windows Phone или iOS делится на важные блоки: front- и back-end. В первый входят элементы, которые использует пользователь, а второй является скрытой частью, с которой работают исключительно программисты, применяя для этого серверный софт. Таким образом эта система работает в совокупности, но с чётким разделением функционала и задач. Как тестировать?

1. Тестирование на различных платформах, версиях ОС, моделях устройств.
2. Использование эмуляторов или реальных устройств.
3. Работа с разными видами интернет-подключений (Wi-Fi, 4G, 3G, отсутствие связи).
4. Переход в фоновый режим при поступлении звонков и sms, срабатывании будильника.
5. Процесс переустановки и обновления приложения до новой версии.

#rdclr_QA