Цель нашего обсуждения сегодня - разобрать процесс проведения тестирования проекта. Мы затронем следующие темы:
• Классический подход к тестированию
• Анализ успехов и неудач в ходе тестирования
• Проблема уменьшения покрытия(эрозии) тестирования
• Управление инцидентами в процессе тестирования
• Управление финальной игрой
Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA.
Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование.
Первый риск: Идея попадает к аналитику
Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде.
Второй риск: разработка по тех. требованиям
Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
Привет, Хабр! Меня зовут Вадим, я мобильный разработчик в СберМаркете. В этой статье расскажу, как провести профилирование (оно же измерение производительности или оценка перформанса) в react native приложениях: как выявить источник проблем и решить их. В русскоязычных источниках не так много информации по данной теме. Я потратил немало времени, чтобы со всем разобраться, поэтому попытаюсь восполнить этот пробел и для вас :)
UI-автотесты под Android — отличный инструмент, который позволяет кратно сократить время на проверку разрабатываемых фич и свести к минимуму участие в ручном регрессионном тестировании инженеров по обеспечению качества. Но работать с UI-тестами надо правильно — иначе все может прийти к ситуации, при которой автотесты становятся нестабильными, а их результаты не вызывают доверие.
Меня зовут Эмилия Куцарева. Я — руководитель команды автоматизации тестирования в Одноклассниках (VK). В этой статье я расскажу о нашем подходе к работе с Android UI-автотестами: как устроен запрет мерджа, как смогли стабилизировать тесты, как настроили параметризацию запуска.
В этой статье мы поговорим о том, что можно проверить у локатора (элемента) и какие вообще есть возможности проверок. Более того, в этой статье я описал упражнения, которые вы можете выполнить и отработать в качестве практики.
Обычно мои статьи были холиварными, а не техническими. Но в этот раз решила выложить что-то действительно техническое и полезное. Тестировщики, налетай! Очень хочу, чтобы опытные ребята, которые с playwright работают давно, поделиться своим мнением о примерах в тексте статьи. Достаточно ли они информативны.
Проверки локаторов
Это могут быть как интерактивные элементы (кнопки, поля ввода, чек-боксы, ...), так и статика (картинки, текст, иконки и т.д.).
Каждый элемент на странице может давать пользователю обратную связь: поле ввода подсвечивается красным, если вы ввели невалидные данные, иконка "Сохранить" неактивна, потому что вы еще не внесли изменения в документ, цвет всплывающего уведомления должен быть красным, потому что случилась ошибка. Чаще всего, нам нужно получить какое-то свойство элемента только для того, чтобы сразу же проверить его значение. Мы хотим проверить, что отображается правильный текст или элементу присвоен нужный CSS-класс.
С другой стороны, иногда нам нужно, все же, уметь получать свойства элементов для промежуточных действий. Например, мы хотим посмотреть, сколько сейчас строк в таблице, удалить одну и проверить, что строк стало меньше на одну. Для того, чтобы организовать такую проверку, нам нужно вычислить, сколько всего строк было до того, как мы удалили последнюю строчку. Если в таблице было X строк, то, после нажатия, должно быть X-1. Найдите икс, получается? И вот тут нам нужна "ручка", которую мы дернем и получим число, без всяких assert'ов.
Часто случается так что на необходимом сайте установлена защита от ботов. Например: QRATOR, Cloudflare, Akamai Bot Manager и пр. Можно потратить множество ресурсов на обход этих систем, но если у вашего ресурса есть мобильное приложение, то можно пойти другим путём. В подавляющем большинстве случаев мобильное приложение остается без защиты т.к. методы актуальные в браузерной разработке в мобильной не актуальны. В этой статье мы совершим атаку MITM на приложение [скрыто], узнаем эндпоинты по которым приложение получает данные и получим данные сами.
В своей книге "Методы тестирования программного обеспечения" Борис Бейзер описывает парадокс пестицидов. В контексте тестирования программного обеспечения - независимо от того, какой метод тестирования вы выберете, вы все равно пропустите более незаметных “вредителей”, то есть баги.
Объяснение Бейзера заключается в том, что со временем все меньше и меньше ошибок будут находиться в тех частях кода, которые были тщательно протестированы, а ошибки, которые обнаружат пользователи, будут в областях, которые были протестированы менее тщательно.
Как же с этим справиться? Расширить охват тестирования, добавив в свой процесс фаззинг.
Тестирование продуктов является неотъемлемой частью процесса разработки программного обеспечения. В его основе лежит создание и выполнение тест‑кейсов — документированных инструкций, определяющих шаги для проверки определенных функций или аспектов программы. Тест‑кейсы играют важную роль в обеспечении качества программного продукта. Они помогают не только выявить ошибки и дефекты, но и удостовериться в соответствии функциональности программы заявленным требованиям.
Каждый тест-кейс разрабатывается с целью проверить определенный аспект продукта, будь то функция, интерфейс или производительность. Ключевым элементом каждого тест-кейса являются предварительные условия, или Pre-conditions, которые определяют состояние системы перед началом тестирования.
Денис Веренцов, Android-инженер Авито, рассказал, как работает инструмент для параллельного запуска мобильных автотестов Emcee, как развернуть его на своей инфраструктуре, или запустить в облаке, чтобы прогонять тесты прямо в браузере.
Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.
На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.
В статье постараюсь простым языком рассказать о своем опыте работы с техниками тест-дизайна на примере проверки оплат – расскажу, как проверяю интеграционные сервисы и всё, что этого касается.
В известном смысле это основы тестирования, но по моему опыту как раз из-за этого (“это база, ну что там может быть такого”) о подобных вещах на практике забываешь чаще, чем хотелось бы. К тому же в любом домене есть свои тонкости, в случае проверки систем оплат – налоги, чеки, возвратные чеки, регионы, экономические зоны. Кажется, для насмотренности может быть полезно разобраться, как тест-дизайн адаптируется под эти нюансы.
Приступим!
Часто автотестирование кажется новичкам чем-то невероятно сложным и недостижимым. Многие думают, что для того, чтобы начать писать автотесты, необходимо сначала получить глубокие знания в программировании, разобраться во всех технических тонкостях ручного тестирования и только лишь потом пробовать писать автоматизированные тесты.
Это, конечно, не так. Я предлагаю вам познакомиться с Robot Framework — инструментом, который позволит писать автотесты, даже если у вас не было никакого опыта программирования.
Труднее всего тестировщику приходится в ситуациях, где даже не подозреваешь, что действуешь неправильно.
Сегодня я разберу 6 кейсов, с которыми время от времени сталкивается каждый QA, которые на первый взгляд кажутся не сложными, но потом становится ясно, что они приводят к неожиданным проблемам, незнание которых может сильно осложнить тестирование, а в худшем случае привести к проблемам релиза.
Привет, Хабр! Меня зовут Катерина. Недавно я опубликовала подборку ресурсов для питонистов и, поскольку ее неплохо приняли, решила поделиться еще и ресурсами для QA-специалистов. Я не систематизировала их по важности или популярности, просто разбила на статьи, YouTube- и Telegram-каналы.
Всем привет! Меня зовут Алексей Иванов, и я очень люблю тестирование.
Несколько месяцев назад я заметил, что в Москве не хватает митапов по тестированию. Да, есть митапы, которые иногда проводят ребята из Альфа-банка, Озона, X5, но все они исходят от компаний, а не от сообщества как такового. И мы с небольшой командой организовали сообщество MoscowQA и провели первый митап в МТС AI.
29 февраля наш митап пройдет при поддержки компании Самолет.
В программе доклады инженеров из Самолета, Flipper Devices и moretv.
Современные приложения становятся все более сложными и потребность в актуальном и эффективном тестировании растет. Ручное создание тест-кейсов может занять много времени, поэтому применение генерации тестов на основе ИИ может сделать этот процесс более эффективным.
По мере того, как растет потребность в более быстрых циклах разработки и повышении качества программного обеспечения, генерация тест-кейсов на основе ИИ выступает в роли силы, которая способствует преобразованиям в тестировании. В этой статье мы изучим революционный концепт создания тест-кейсов с использованием ИИ, и покажем его потенциал в изменении парадигм тестирования ПО за счет повышения эффективности, покрытия и точности.
С использованием стабильных и точных методов поиска элементов в Appium, вы снизите вероятность нестабильности тестов и повысите надежность мобильных приложений.
Платформа 1C:Enterprise — самый простой способ перейти в сферу мобильной разработки. Научиться писать приложения на 1С проще, чем освоить Swift, Java или Kotlin. Обучение займёт всего пару месяцев. При этом специалист с такими знаниями всегда будет востребован на рынке благодаря популярности программ 1С. Освоить разработку мобильных приложений на базе 1C:Enterprise можно с начальными навыками программирования на 1С, Python, SQL, Java, C++, C#. В статье мы рассказали, какие задачи решает 1С-программист и насколько перспективна мобильная разработка на встроенном языке.
В данной статье мы рассмотрим следующие темы вопросов по Appium на собеседовании:
• Основы Appium
• Концепции автоматизации Appium
• Продвинутые возможности Appium
• Устранение неполадок и лучшие практики
В нашем мире, где каждый релиз готовится в спешке, а сами релизы выходят на регулярной основе, что вы делаете, чтобы защитить своё программное обеспечение? Что вы можете сделать, какие вообще есть варианты?
С точки зрения того, что именно представляет собой CI/CD: непрерывная интеграция программного обеспечения — это процесс, целью которого является максимально проверенный дистрибутив.
Хотя характеристику «максимально проверенный» можно интерпретировать по-разному, я полагаю, что это сводится к использованию такого количества тестов, которое позволяет бюджет, а бюджет — это деньги и время.
Если есть тест, который добавит вам уверенности и который вы можете себе позволить — он должен стать частью вашей стратегии.
