Никто не спорит с тем фактом, что в процессе разработки необходимо проводить качественное тестирование, которое обеспечит достаточное тестовое покрытие. Но какова область и цель тестов? В какой среде их нужно проводить и как быть с зависимостями? В статье мы постарались ответить на эти вопросы, рассматривая стратегию тестирования мобильных приложений.
С чем в свои рабочие будни приходится сталкиваться QA-лидам и другим причастным? Разбор некоторых частых организационных кейсов в работе тестировщика в нашей статье.
Всем добрый день!
Ранее я писал об опыте создания новых исследовательских сценариев в мире исследовательского тестирования. Начало вы можете прочитать вот здесь.
Ну что ж, давайте продолжать, ведь мне ещё есть чем с вами поделиться :)
Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам о простых QA метриках, помогающих отслеживать качество продукта.
Если мы вобьем в поисковой строке незамысловатое словосочетание “метрики QA”, то увидим, что почти все ссылки ведут на классические метрики: процент покрытия требований кейсами, коэффициент регрессии, скорость работы QA команды и т. д. Если вы их не видели — то можете легко найти. Большинство из них полезны, и некоторые будут использованы в статье, но немного в другом формате. Подобные метрики обычно выглядят как n/m, где n и m — количество какого-либо параметра. Например: количество переоткрытых дефектов, общее количество дефектов и время исправления найденных дефектов. Я же хочу рассказать о чуть более аналитической работе: мы будем смотреть не только сухие цифры, но и делать выводы о том, откуда эти цифры взялись. Ближе к концу статьи я поделюсь некоторыми идеями о том, как решать возникшие проблемы.
За последние десять лет индустрия программного обеспечения сильно изменилась. И хотя трудно точно предсказать, что принесет следующее десятилетие, оно, безусловно, поставит перед специалистами по тестированию и контролю качества целый ряд новых задач.
Во-первых, это искусственный интеллект и машинное обучение, которые давно прогнозировались как путь к тому, чтобы сделать тестирование программного обеспечения лучше, быстрее и дешевле.
Однако для того, чтобы к этому прийти, потребуется время. Одновременно с этим изменится тип требуемых навыков. Для работы, связанной с тестированием программного обеспечения, потребуется больше опыта работы с данными и аналитикой, поэтому образование в области науки о данных и глубокого обучения (deep learning) должно стать частью роли тестировщика программного обеспечения. Кроме того, поскольку все больше тестов автоматизируется, человеческое взаимодействие будет иметь реальную ценность при утверждении результатов тестирования и принятии соответствующих мер.
Несмотря на то, что специалисты по тестированию часто остаются невоспетыми героями, их работа получает все большее признание за ее вклад в DevOps. В то же время тестирование будет продолжать становиться неотъемлемой частью других частей жизненного цикла программного обеспечения, а быстро развивающиеся инструменты сделают тестирование доступным для большего числа членов команды.
Итак, что, как мы знаем или хотя бы подозреваем, повлияет на будущее тестирования программного обеспечения?
Искусственный интеллект (artificial intelligence) и машинное обучение (machine learning)
Добрый день! Меня зовут Александр, я старший специалист по тестированию в ГК Юзтех. В этой статье я постараюсь кратко рассказать историю создания новых исследовательских сценариев и поделиться с вами опытом их применения.
Перед началом прочтения сразу обозначу две концепции, которые лежат в основе статьи:
Привет, меня зовут Николай. Моя должность в Delivery Club — QA Automation Engineer в мобильной платформенной команде. Эта статья будет о том, как мы подменяем и храним ответы бэкенда при UI-автоматизации тестирования курьерского Android-приложения.
Представьте, что вы перевели свое приложение на английский. А что, если ваше приложение работает в 47 странах, большая часть из которых говорит на разных языках и диалектах? Возникает проблема выстраивания единого процесса локализации и проверки переводов в каждом конкретном случае.
Меня все еще зовут Андрей, я продакт-менеджер в inDrive и занимаюсь развитием пассажирского флоу — основного сервиса компании. В этой статье расскажу, как мы выстроили процесс локализации в компании через боль и ошибки.
Сначала расскажу о том, как мы эволюционировали в плане выбора инструментов для локализации. Затем поделюсь проблемами, которые возникли у нас при переводе приложения на арабский. И, наконец, покажу новую схему локализации в inDrive и ее успешное применение на примере казахского языка, которое мы осуществили в июне этого года.
Аудит качества помогает выяснить, следует ли команда бизнес-процессам. Кроме того, аудит качества позволяет поддерживать желаемые стандарты качества. Этот процесс гарантирует, что сотрудники следуют всем процессам и процедурам, а команда соответствует ожиданиям клиентов при предоставлении продуктов и услуг.
Составные части аудита качества:
• Текущее качество продукции.
• Качество тестирования.
• Качество разработки.
• Требования к качеству.
• Готовность к производству.
• Опасные области.
• Состояние процессов по проекту.
• Автоматизация + Рентабельность инвестиций.
• Удовлетворенность клиентов.
Когда:
• У вас нет четкой видимости качества программного обеспечения или узких мест в процессе работы.
• Рабочая нагрузка вашего проекта увеличивается, но ваш текущий процесс контроля качества не позволяет масштабировать ресурсы.
• Ваш текущий процесс контроля качества не позволяет вам перейти на другую методологию разработки, применить другой подход к управлению инфраструктурой или внедрить другие изменения в процессе.
• Вам необходимо пройти сертификацию продукта/процесса, и вы хотите убедиться, что ваш процесс контроля качества соответствует требованиям, установленным соответствующим стандартом.
• Качество продукта в вашем проекте низкое, и для этого нет очевидных причин, вы получаете много жалоб от конечных пользователей.
Для чего:
• Изучить, с чего начинается процесс, как он поддерживает развитие и где он эффективно заканчивается.
Разработчики и тестировщики заводят тест-кейсы в систему хранения тестов (TMS), но это долго и никому из них не нравится. При этом QA-инженеру нужно как-то отслеживать и подсчитывать для пирамиды тестирования unit-тесты, которые написаны в коде приложения. Решить эти задачи может одна система — кастомная TMS, она умеет выгружать все тесты из кода и визуализировать тестовое покрытие в понятные графики и числа.
Меня зовут Василий Юдин, я инженер в Авито и техлид команды, которая разрабатывает инструменты для тестирования. Рассказываю, как мы с командой создали хранилище тестов с выгрузкой из кода и как оно помогло нам в работе.
В этой статье я поделюсь своим опытом создания Telegram Bot-а для автоматизации тестирования.
Распространённая связка из JUnit5, Selenide и Allure для UI-автотестов работает стабильно и надёжно. Но до момента, пока тестов становится много, их длина увеличивается, а итоговые видеофайлы по результатам тестом превышают час. Главный инженер-тестировщик Группы «Иннотех» Александр Кочергин нашёл способ укрощения инструментария.
Когда мы слышим термин "Quality Gates" (QGS), мы склонны думать о них довольно недальновидно на уровне проекта как об этапах и предпосылках для перехода к следующему этапу реализации проекта. На проектах, особенно на тех, которые работают с использованием любой гибкой методологии, часто можно обнаружить что показатели качества более низкого уровня (например, критерии входа и выхода из теста, а также определение Definition of Done) часто обсуждаются/документируются, но затем упускаются из виду или вообще не используются.
QGS – это, по сути, очень хорошие чек-листы, подкрепленные простыми рабочими процессами. Они обеспечивают нам наглядность, уверенность и структурность того, что мы поставляем как результат процесса разработки, а также соответствие нашим установленным стандартам качества и ожиданиям. Для любой роли необходимо убедиться, что вы можете организовать список необходимых задач (чек-листов) и выполнить эти важные задачи. Этот процесс является ключом к предоставлению качественного программного обеспечения, когда команда поставляет продукт без спешки и потери качества.
Ниже приведены примеры использования QGS для различных ролей и областей в рамках цикла обеспечения качества и контроля качества. Они продемонстрируют, насколько они могут быть полезны для обеспечения структуры и качества команды и управления разработкой продукта. Несмотря на то, что мы используем QGS, которые визуально являются последовательными, задачи и действия, проходящие через них, могут выполняться параллельно или последовательно в зависимости от вашей методологии доставки (например, гибкая, водопадная и т.д.).
Всем привет!
Меня зовут Женя, и я люблю автотесты. Причем люблю так сильно, что даже стал соавтором Kaspresso, OpenSource библиотеки для написания автотестов под Android, и автором ряда докладов и статей про тесты (Kaspresso: фреймворк для автотестирования, который вы ждали, Автотесты на Android. Картина целиком, Kaspresso tutorials. Часть 1. Запуск первого теста, Дмитрий Мовчан, Евгений Мацюк — Как начать писать автотесты и не сойти с ума). Также со мной полюбил автотесты и мой товарищ, Сергей Ярцев, который является CTO в HintEd, и также вынужден трогать автотесты, причем под разные платформы.
В одной из своих статей (Автотесты на Android. Картина целиком) я описывал, что вообще в себя включают Автотесты под Android. Если кратко, то я выделял 4 большие области: Процесс написания автотестов, Runner, Инфраструктура и Остальное, которое включало в себя отчеты, интеграцию с CI/CD и тд. В свое время (2019-2020) когда мы делали Kaspresso, мы закрывали боль с написанием автотестов. Теперь разработчики и тестировщики могут писать красивый и понятный DSL и не думать про проблемы с флаканием, логами, скоростью и тд. По другим же областям были некоторые решения, но команды, выстраивающие весь процесс, должны были сами со всем этим разбираться и все это стыковать. Особенно больно было с Инфраструктурой, где приходится нырять в дивный мир DevOps и частично даже Highload.
Недавно мне стало интересно, а как сейчас обстоят дела у разных команд с автотестами. Для этого мы с Сергеем провели ряд интервью с более, чем 30 разными командами. Да, это далеко не вся выборка, и данное исследование точно не претендует на абсолютную истину. Но 30 больше, чем 1 или 2 или 5, и поэтому исследование точно может наводить на кое-какие мысли.
Конференция Heisenbug («по тестированию, но не только для тестировщиков») близится: программа уже готова, и пришло время поделиться с Хабром всеми подробностями.
Во-первых, напоминаем формат. Конференция будет проходить три дня. Первые два — полностью онлайновые. А вот в третий всё на выбор участников: можно приехать на конференцию в Москве, чтобы как следует пообщаться лично, или подключиться удалённо из любой точки планеты.
Во-вторых, публикуем полную программу. В ней не только доклады-монологи: будут и воркшопы с мастер-классами, где можно научиться чему-то на практике, и круглые столы с тематическими обсуждениями. Среди прочего будут звучать слова «SRE», «Kaspresso», «бенчмаркинг», «TestOps» и не только. Но обо всём по порядку.
Тёмная тема — уже не просто тренд в дизайне, а правило хорошего тона. Позаботьтесь о комфорте пользователя, если вы уважаете его желание провести ночь с вашим приложением, вместо того, чтобы хорошо выспаться.
Далеко не все пользуются тёмной темой, но однажды ослепнув от яркого монитора и обзаведясь очками, невольно переходишь на тёмную сторону. Так как же грамотно подойти к её созданию? Меня зовут Мария, я QA-инженер в ISPmanager и сегодня расскажу, как спроектировать и протестировать тёмную тему с учётом человеческой физиологии.
Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент.
