Это вторая книга из трилогии Ольги Назиной по тестированию ПО. Про первую книгу автор рассказала в своем блоге на Хабре, третью мы осветили в предыдущем посте. Мультяшный авторский стиль изложения с сотнями картинок-комиксов необычен для компьютерной литературы, но почему бы и нет? Книга легка в восприятии и помогает грамотно использовать техники проектирования тестов, знакомит с границами их применимости.
Когда-то давно наш далёкий предок вылез из мирового океана и начал эволюционировать. Встал на четвереньки, потом на две ноги, взял палку — слово за слово, и вот вы получили персональный ноутбук, должность QA-лида и отправились работать на удалёнку в распределённой команде.
Ольга Назина — признанный автор книг и учебных курсов по тестированию ПО. Удивительный мультяшный стиль изложения с сотнями картинок‑комиксов помогает легко воспринимать сложные темы, постигать азы и развиваться в профессии специалиста по QA. Новая книга, вышедшая в 2024 году, знакомит с тонкостями регистрации и отслеживания статуса багов в процессе разработки приложений. Будет безусловно полезна начинающим тестерам, слушателям ИТ‑курсов, а также всем, кто интересуется системным подходом к тестированию ПО.
Профессия тестировщика для многих служит "входным билетом" в IT. На что же может надеяться начинающий специалист?
До конференции по тестированию Heisenbug всего ничего, её программа уже известна, и пришло время рассказать о ней Хабру.
Каждый раз в Heisenbug есть и то, за что его знают и любят, и новое.
Что уже знакомо? Снова будут привычные тематические блоки: «инструменты и фреймворки», «мобильное тестирование», «нагрузочное» и так далее. Снова будут некоторые спикеры, полюбившиеся многим по предыдущим Heisenbug: Артём Ерошенко (поговорит о том, умерло ли тестирование), Дмитрий Тучс (продолжение темы JUnit extensions), Константин Волков (всегда что-то интересное про Flipper Zero). Снова будет формат «хоть приходите на конференцию ногами, хоть смотрите в онлайне».
А что будет нового? Конкретные темы докладов — они-то всегда свежие. И рассказываем Хабру, какие именно в этот раз:
Статья от тестировщика "ITQ Group" Леонида Галочкина.
Понимание принципов работы activity помогает понять логику работу мобильных приложений, разрабатывать тест-кейсы разного уровня, готовить тестовую документацию. Принципы activity можно игнорировать, например, при тестировании UI приложения или при e2e-тестировании, но для полного тестирования МП знать их необходимо.
Растут или снижаются зарплаты в тестировании? Какие скилы наиболее востребованы? Сколько вакансий для джунов? Узнали у экспертов, как изменился рынок в 2023 году и какие тренды сохраняются в 2024.
Автор: Роман Горбунов, руководитель QA-проектов в «Точка качества».
Тестирование — неотъемлемая часть разработки, так как оно обеспечивает надёжность, качество и функциональность программного обеспечения. Однако, чтобы действительно быть эффективным, тестирование должно быть систематическим, планируемым и охватывать все аспекты разрабатываемого бизнес-продукта. Важным аспектом тестирования является уровень тестового покрытия, который определяет, насколько хорошо тесты охватывают функциональность и код ПО.
В этой статье мы остановимся на определении тестового покрытия, рассмотрим важность для проверки качества бизнес-продукта и определим критерии его выбора.
Что такое тестовое покрытие
Тестовое покрытие — это метрика, которая показывает плотность покрытия тестами кода или требований. Если требования отсутствуют, то тестовое покрытие может отражать степень покрытия логической структуры приложения. Тестовое покрытие можно представить в виде сочетания глубины и ширины тестирования.
Ширина тестирования отражает какая функциональность затрагивалась тестированием (модули/функции).
Глубина тестирования отражает вид проверок, которые производились для модуля/функции (например, позитивность/негативность сценариев).
Уровни тестового покрытия по ширине:
Цель нашего обсуждения сегодня - разобрать процесс проведения тестирования проекта. Мы затронем следующие темы:
• Классический подход к тестированию
• Анализ успехов и неудач в ходе тестирования
• Проблема уменьшения покрытия(эрозии) тестирования
• Управление инцидентами в процессе тестирования
• Управление финальной игрой
Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от 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 — инструментом, который позволит писать автотесты, даже если у вас не было никакого опыта программирования.
