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

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

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

Всем привет!

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

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

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

Именно этой теме мы посвятили встречу Android-разработчиков и мобильных тестировщиков на митапе Android Paranoid и обсудили:

• Как разработчику с помощью тестирования привести проект к стабильности?
• Чем разработчик может помочь тестировщику?
• Как выбрать лучший инструмент для повышения качества разработки?

Таймкоды проставлены, добро пожаловать под кат.

Приветствую тебя, мой читатель! Надеюсь, что предыдущие части (первая и вторая) из цикла статей про Nethuter тебе понравились. Сегодня мы сосредоточим внимание на атаках, когда сам атакующий имеет непосредственный (физический) доступ к компьютеру жертвы. Итак, поехали.

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


В компании поменьше, оказавшись в начале пути перед выбором реальным, а не теоретическим, будет заметно сложнее. На практике все не так просто как в теории. Но и не совсем страшно.
Дорогу осилит идущий: анализировать, искать, думать, записывать.

DINS Hiring Day — это возможность для талантливого QA Automation инженера получить оффер всего за один день. Весь процесс займет минимум усилий: нужно выполнить тестовое задание и принять участие в онлайн-собеседованиях 31 июля.

Подробности под катом.

Burp Suite – это платформа для выполнения тестирования по безопасности веб-приложений. В этой заметке я поделюсь несколькими приёмами, как использовать данный инструмент более эффективно.

Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно — это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё…

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



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

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

Содержание

• 1. Границы на клиенте
  
  • Maxlength
  • Ошибки в консоли JS
  • Изменение поведения
  • Итого по границе на клиенте
• 2. Границы на сервере
• 3. Границы в БД
• Итого: чек-лист поиска границ

Лето красное продолжается, как и онлайновые встречи Яндекс.Денег. 16 июля в 18:00 приглашаем всех причастных к разработке и тестированию под Android на Zoom-митап Android Paranoid. Доклады спикеров будут посвящены таким актуальным вопросам:

• Как разработчикам с помощью тестирования привести проект к стабильности?
• Как разработчик может упростить жизнь мобильному тестировщику?
• Как выбрать лучший инструмент для повышения качества разработки?

А перерывы между докладами обещают быть не менее интересными: вместе с коллегами из Яндекс.Денег, Авито, Ситимобила и Revolut устроим тематические дискуссии. Будет жарко!

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

Привет, Хабр. Меня зовут Сергей Вертепов, я senior backend инженер. Это небольшая обзорная статья о том, как мы тестировали монолитное приложение Авито, и что изменилось с переходом на микросервисную архитектуру.

Данная статья написана специально для OTUS преподавателем курса «QA Lead» — Анастасией Шариковой.

---

Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.

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

Привет, меня зовут Сергей, и я тестирую iOS приложения в Exness. В конце июня 2020 г. закончилась очередная WWDC. Давайте разберемся, что же она принесла нового в мир тестирования iOS приложений.

Всем привет! Меня зовут Михаил Булгаков (нет, не родственник), я работаю релиз-инженером в Badoo. Пять лет назад я занялся автоматизацией релизов iOS-приложений, о чём подробно рассказывал в этой статье. А после взялся и за Android-приложения.

Сегодня я подведу некоторые итоги: расскажу, к чему мы пришли за это время. Long story short: любой причастный к процессу сотрудник может зарелизить хоть все наши приложения на обеих платформах в несколько кликов — без головной боли, больших затрат времени, регистрации и СМС. Так, наш отдел релиз-инженеров за 2019 год сэкономил около 830 часов.

За подробностями — добро пожаловать под кат!

Многим кажется, что WWDC — праздник только для разработчиков, и если ты дизайнер или маркетолог, то тебе там нечего ловить. На самом деле это не совсем так. Действительно, большая часть будет актуальна только разработчикам, но многое будет полезно не только им.

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

Перевод статьи подготовлен в преддверии старта нового курса от OTUS — «Нагрузочное тестирование».

---

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

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

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

Привет, Хабр!

Меня зовут Сэм, я разработчик в сервисе Qonversion. В этой статье описаны новые возможности для тестирования подписок, представленные Apple во время сессии Introducing StoreKit Testing in Xcode на WWDC 2020.

Рынок подписок в мобильных приложениях быстро растет, но набор инструментов тестирования до iOS 14 был скудным. Вдобавок всё усложнялось нестабильностью песочницы Apple.
Нововведения в Xcode 12 и iOS 14 сильно меняют ситуацию.

Салют, хабровчане. Сегодня мы продолжаем серию переводов, приуроченных к запуску курса «Java QA Engineer».

---

Эпизод 3 — isDisplayed

В результате диалога, произошедшего в последние выходные января 2020 года, который был посвящен одной из проблем в Selenium, где кто-то сказал мне «почему ты просто не сделаешь так…» в ответ на объяснение проблемы, я решил написать серию статей, объясняющих команды в Selenium WebDriver и почему мы в итоге пришли к дизайну, который имеем сегодня.

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

В этом эпизоде ​​мы рассмотрим значительную часть механизмов, заложенных в isDisplayed(). Эти же механизмы используются в командах взаимодействия, поэтому будет полезно понять, как они работают, и как другие команды могут их использовать. С технической точки зрения это моя любимая команда (из-за того как она работает).

Перевод статьи подготовлен в преддверии старта курса «Python QA Engineer».

---

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

Самое плохое в визуальных ошибках это то, что их нельзя «поймать» с помощью обычного автоматизированного тестирования. Так происходит потому, что большинство инструментов автоматизированного тестирования сверяются с DOM (document object model), чтобы сообщить о состоянии приложения.

«Я делаю то, за что мне платят» — стандартный капиталистический подход к работе «на дядю» в Западной части нашего мира. В момент свет гаснет, станки останавливаются и все расходятся по своим делам. Интересно, что методологи в стиле Скрам и Канбан, которые говорят о командной работе, также жестко проводят черту между ролями и тем, кто, что и когда делает. Но это там! А у нас? А у нас роль в команде (буду говорить о тестировщиках (QA)) коррелирует со знаниями из разных сфер, важностью морального и душевного равновесия в коллективе и ответственностью за проделанную работу. Все это адаптирует методологии в командах немного под другим углом, отличным от запада.

В автоматизации тестирования существует много разных подходов, решений и способов. Самый распространенный и незаменимый —  паттерн Page Object (Screen Object). Я столкнулась с двумя подходами при работе с этим паттерном: c фабрикой для своих page object-ов и без нее. В этой статье на примере наших автотестов сравним оба подхода, их плюсы и минусы. Покажу, как выглядит наша фабрика page object-ов. Также расскажу о проблемах, с которыми мы столкнулись в автотестах с фабрикой и как их решили.

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