Российский магазин приложений RuStore начинает серию дайджестов о рынке мобильной разработки. Каждый месяц мы будем собирать самые интересные и важные новости, которые вы могли пропустить.
Ultron — самый простой фреймворк для разработки UI тестов Android.
В данной статье я познакомлю вас с малоизвестным фреймворком, который позволит вам облегчить android ui тестирование.
QA инженер имеет внушительный арсенал техник тест-дизайна: классы эквивалентности, граничные значения, попарное тестирование, диаграммы состояний и переходов, таблицы принятия решений, сценарии использования и альтернативные сценарии, перебор комбинаций, деревья решений ...эмм, это все что я помню, если что-то забыл, поправьте.
Так вот, сценарии использования и альтернативные сценарии, мы обычно получаем от аналитиков из спецификации.. таблицы, деревья и диаграммы мало кто чертит, так как это занимает много времени (при дефиците ресурсов). Как правило, в ходу две популярные техники: классы эквивалентности и граничные значения, и только отдельные умнички используют pairwise ( попарное тестирование ).
Думайте иначе и будете вознаграждены.
Как думаете, кто способен лучше всех оценить качество работы вашего приложения? Подсказка: в команде разработки такого специалиста нет. Возможно, такого специалиста нет даже во всей вашей компании. Лучшими специалистами и экспертами будут настоящие пользователи приложения. Они смогут оценить его качество, лишь когда установят приложение на свои устройства, однако к этому моменту уже важно иметь понимание того, соответствует ли продукт ожиданиям пользователей или нет.
Крупнейшие и наиболее успешные ИТ‑компании привлекают
реальных пользователей на каждом этапе разработки ПО от его концепции до релиза.
Но большинству компаний есть к чему стремиться в области качества из‑за
нескольких популярных заблуждений, лежащих в основе QA‑процессов.
Построив карьеру тестировщика ПО и открыв собственную компанию по тестированию,
автор статьи обнаружила, что стоит думать по‑другому, когда речь идет об
улучшении качества продукта.
Сейчас на слуху переход на IPv6 и связанные с ним проблемы. Мы в РНКБ недавно испытали это на себе – внедряли IPv6 для мобильных приложений. Задача оказалась нетривиальная, поэтому мы решили рассказать и другим хабравчанам, почему у нас не всё пошло гладко и с чем мы столкнулись. В других банках РФ, в т. ч. из топ-10, по нашим сведениям, IPv6 пока не поддерживается.
Тестирование, вероятно, является одной из самых горячих тем в разработке программного обеспечения. Все согласны с необходимостью качественного тестирования и определенного количества тестов (или покрытия кода). Но каков масштаб, цель и задача ваших тестов? В какой среде вы должны их запускать и как управлять зависимостями?
Ниже представлены некоторые из вопросов, на которые мы попытались ответить, предоставив стратегию тестирования для наших мобильных приложений.
Проблематика: работа с контекстом и зависимостями
Определение точного объёма и среды для ваших тестов должно быть первым шагом в этом процессе. Представьте, что вы тестируете свое приложение электронной коммерции вручную. Вы хотите протестировать процесс заказа, включая услугу оплаты, предоставляемую сторонней компанией? Или вы хотите сосредоточиться только на коде, разработанном вашей командой, исключая сам платежный сервис?
Однозначно правильного ответа нет. Но эти два идентифицированных теста не должны происходить одновременно и определенно не будут стоить одинаковых затрат (с точки зрения реализации и удобства обслуживания).
Всем привет!
И снова с вами я, Юрий Шабалин, ведущий архитектор Swordfish Security и генеральный директор Стингрей Технолоджиз. Как вы помните, мы разрабатываем систему автоматизированного анализа защищенности мобильных приложений, о которой я рассказывал в прошлых статьях.
Сегодня мне хотелось бы отступить от привычных технических тем и поговорить о том, зачем вообще проверять и защищать мобильные приложения. С этим вопросом я часто сталкиваюсь в своей работе. Ведь по мнению большинства, мобильный продукт — это всего лишь клиент, фронт для серверной части, ничего ценного для злоумышленников здесь нет и вектор атаки у него узкий. Ниже мы приведем список мифов о безопасности мобильных приложений и вместе разберемся с каждым из них.
В этом году спектр тем для обсуждения в секции Тестирования — от техно-хардкора про нагрузочные тесты до философии проведения собеседований. Своими взглядами на лучшие практики поделятся работники из крупнейших компаний российского IT.
На собеседовании тестировщиков я обычно задаю вопрос, делают ли в команде ревью. И часто слышу в ответ разные вариации “нет”: разработчики делают, но я не вникал; нам не надо, мы много общаемся; никто не знает питон, а тесты написаны на нём. Так что, неужели ревью подходит только разработчикам?
Давайте начнем с ручного тестирования. Надеюсь, никого не удивлю тем, что ревью относится не только к коду. Все давно слышали про shift left, ревью аналитики и прототипов, ревью тест-кейсов. Слышали, конечно, но не внедряли, потому что а) нам не надо, у нас работают хорошие специалисты, или б) у нас нет времени (ага, всё занято полезными встречами, понимаю).
Я искренне считаю, что в обоих пунктах происходит рационализация одного и того же страха. Нам страшно показывать свою работу другим. Страшно обнаружить пробелы в знаниях и проиграть в сравнении. Узнали себя? Тогда вам в помощь культура ревью.
В 2022 году мы запустили новое мобильное приложение для iOS и Android, встроив в него дополнительные сервисы: «Медиа», «Трекер активности», «Live-трансляции», «Онлайн-тренировки» и другие. Они закрывают потребности наших клиентов, не связанные с покупками. Например, помогают следить за спортивными новостями, поддерживать физическую активность и быть частью сообщества единомышленников.
Однако некоторые клиенты мало заходили в дополнительные сервисы, так как всё ещё воспринимали нас как магазин товаров для спорта. Чтобы познакомить покупателей с новыми возможностями приложения и увеличить число активных пользователей, было решено запустить геймификацию. Меня зовут Сергей Вылекжанин, я начальник отдела «Сервисы Спортмастера», и в этом посте расскажу, как всё было.
Компании активно используют геймификацию в бизнес-целях: для привлечения и удержания клиентов, стимулирования покупок, продвижения новых сервисов и услуг. Спортмастер — не исключение. При запуске игры мы придерживались двух принципов:
Первый — клиентоориентированность. Мы провели исследование пользователей и учли их интересы в концепции игры, чтобы сделать геймификацию вовлекающей.
Второй — коммерческая эффективность. Мы отказались от аренды готовых решений и разработали собственную информационную систему, которая поможет нам многократно перезапускать игру без дополнительных вложений.
В конечном итоге этот подход себя полностью оправдал.
Внедрение автоматизированных тестов, которые тестируют всё приложение, является сложной задачей. От выбора уровней для проверки (API, UI или оба) до управления тестовыми данными и подбора подходящей библиотеки для работы. Основываясь на своем опыте, я подготовил руководство по внедрению автоматизации в ваш проект.
Рано или поздно большой продукт сталкивается с проблемой количества тестов, а точнее с тем, сколько времени нужно, чтобы их прогнать. При этом не все команды готовы тратить кучу сил на оптимизацию этого процесса. Гораздо проще решить проблему с помощью большого количества эмуляторов или ресурсов на CI.
В этой простыне текста хочу рассказать про то, как мы уменьшили время прогона UI-тестов на мерж-реквесте с 4 часов до 30 минут, какие есть подходы к решению проблемы и как сделать свой Test Impact Analysis.
Добро пожаловать, новички в тестировании! Вы, вероятно, только начали свой путь в этом увлекательном мире, но не беспокойтесь, мы здесь, чтобы помочь вам разобраться в различных типах тестирования, которые используются в современной практике. Независимо от того, какой уровень опыта вы имеете в тестировании, этот материал будет полезным для вас, чтобы расширить свои знания и умения.
Типы тестирования
Существует множество различных типов тестирования, каждый из которых имеет свои особенности и преимущества. Рассмотрим некоторые из наиболее распространенных типов тестирования.
Это мой первый пост, прошу сильно не пинать. Для начала немного расскажу, кто такой тестировщик. Это специалист, который отлавливает ошибки на всех этапах разработки проекта. Работа рутинная, но ответственная. Получают тестировщики на 20-30% меньше, чем программисты: от 30 000 руб. и выше, всё зависит от опыта.
Становление тестировщиком – самый простой путь старта в IT, есть куда расти (тест-менеджмент, веб-дизайн, чистая разработка).
Эту информацию я почерпнул из открытых источников и подумал, что вот, я не умею программировать, а получать астрономическую зарплату работать в IT – хочется. Думал, что начну с ручного тестирования, устроюсь на работу – а дальше, как пойдёт.
Но на практике оказалось не всё так просто. Кругом полно таких же людей, который думают точно также же, и такие специалисты маловостребованы. Для чего вообще берут на работу стажёров? Работодатель ожидает, что в ближайшем будущем навыки стажёра охрененно вырастут и он будет приносить огромную пользу фирме с дальнейшим повышением зарплаты (но не всегда таким, какую ожидает стажёр). Поэтому чаще всего стажёры, получив опыт, либо настаивают на значительном повышении з/п или уходят к конкурентам.
Несмотря на грустные мысли, я поставил цель – изучить навыки тестирования на Python хотя бы на уровне продвинутого стажёра.
Ближайшая конференция Heisenbug будет больше обычного: целых четыре дня (два онлайновых и два в Москве с возможностью удалённого подключения). А значит, и докладов тоже будет много. И сейчас, когда программа готова, пришло время показать Хабру их описания.
Как водится на Heisenbug, освещены будут очень разные стороны тестирования, от мобильного до нагрузочного: можно в оглавлении этого поста найти интересующий блок и перейти сразу к нему.
И ещё, как водится на Heisenbug, вместо «болтологии» — техническая конкретика. Как тестировать Flutter-приложения? Как ускорить прогон тестов в многомодульном проекте Maven? Даже хайповый ChatGPT тут будет не в очередных абстрактных рассуждениях «уволят ли нас всех через пять лет», а в конкретном «сравним на практике ChatGPT со статическим анализатором кода».
Представьте, что вы из большой компании впервые пришли на проект единственным тестировщиком и чувствуете себя совершенно беспомощным. В этой статье хочу затронуть некоторые неочевидные нюансы организации тестирования в небольшой команде.
Часто при разработке собственных фреймворков (или для проверки соответствия кода требованиям организации) возникает необходимость реализовать сложные проверки корректности использования в коде приложения. Это может быть реализовано через расширение возможностей линтера, который используется в Android Studio. В этой статье мы рассмотрим общие подходы к созданию таких расширений для Android-приложений и несколько примеров для проверки названий функций и наличия аннотаций.
Всем привет! Меня зовут Стас, и я Senior QA в компании inDrive и наставник на курсе «Инженер по тестированию» в Яндекс Практикуме. Ещё веду телеграм-канал «Тестировщики нужны».
Многие начинающие автоматизаторы задаются вопросом: «Как же написать свой первый автотест на мобильное приложение?». В данной статье я и хотел бы ответить на этот вопрос. На самом деле, статей на эту тему написано довольно большое количество. Подробно рассказывается применение паттерна PageObject в написании тестов и многое другое. Но наша с вами задача — написать наш первый простенький тест на экран авторизации на языке Java. Поэтому давайте решим эту задачу вместе!
Привет, Хабр! Меня зовут Ира, я SRE в команде Samokat.tech. В этом посте хочу поделиться подходом в тестировании, которым мы пользуемся сами. Если вам при подготовке тестов часто приходится писать похожие друг на друга как две капли воды заглушки (или, как их ещё называют, «моки»), а затем заботиться о том, чтобы их развернуть, то вам может понравиться наше решение. Освободившись от части рутинных забот, вы можете уделить больше времени чему-то более важному.
Разношёрстные и хаотично развёрнутые в окружении заглушки – дорогие и неэффективные. В каждой отдельной заглушке разбирается в лучшем случае только одна команда, чаще только один человек. Со временем при накоплении критической массы они становятся фактически неподдерживаемыми.
Такие заглушки редко переиспользуются и что важнее, никто ими не делится, так как они либо тривиальны, либо написаны не самым лучшим способом (могут оказаться слишком сложными или неоптимальными).
Сложно представить тестировщика в роли доброго самаритянина, раздающего коллегам свои заглушки. Его к этому вряд ли что-то мотивирует, да и работы у него всегда прилично. Некогда отвлекаться! Так, давайте разгрузим немного нашего трудягу.
Если вы хотите добиться успеха в быстро изменяющемся мире современных технологий, то необходимо постоянно повышать узнаваемость своего бизнеса. Целевая аудитория в наше время в равной мере пользуется как веб-приложениями, так и мобильными устройствами, а потому вопрос предоставления высококачественных программных продуктов для обеих групп пользователей является жизненно важным для любой компании.
Для создания безупречных программных приложений требуется хорошо спланированный процесс тестирования мобильных и веб-приложений. С изменением мышления клиентов и их переходом к использованию мобильных приложений возрастает и роль мобильного тестирования. Решающим элементом такого процесса является круглосуточный доступ к лаборатории тестирования. Тестировщики, обладающие постоянным доступом к облачным сервисам, могут использовать набор портативных и мобильных устройств для повышения эффективности, масштабирования и общего улучшения процесса тестирования. В то же время при всей схожести процесса сохраняется различие между тестированием мобильных и веб-приложений.
