Сегодня рассказываю, как правильно тестировать код,  и делимся личным опытом. Да-да, ты все понял верно: при разработке мобильных приложений тестирование проводит не только QA-инженер, но и сам автор кода. Причем не только в самом конце, когда приложение почти готово, но и в процессе. Мы сегодня рассмотрим оба этапа. 

Chrome DevTools — это консоль разработчика, набор инструментов в браузере для создания и отладки сайтов и приложений. С их помощью можно в том числе тестировать уже разработанную функциональность.

В этой статье будет подборка полезных инструментов внутри DevTools, которые не очень распространены в QA, но при этом могут значительно упростить и ускорить тестирование сайтов и приложений. К каждому инструменту я сделал небольшой пошаговый туториал.

Отмечу, что говорить мы будем именно о Chrome DevTools, хотя и в других браузерах есть аналогичные консоли разработчиков. Сам их частенько использую — это удобно. Поскольку инструменты неочевидные, рекомендую заглянуть под кат и начинающим, и опытным тестировщикам — точно почерпнёте для себя что-то новое.

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

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

Итак, к делу.

Автор:

Test Replay приходит в Cypress

Возможно, вы слышали новости о Cypress. Версия 13, их крупнейший релиз, демонстрирует функцию Test Replay, позволяющую пройтись по прогону своих тестов. В ходе прогона все снимки DOM, сетевые вызовы и логи консоли будут записаны, позволяя глубоко анализировать прогон.

Cypress – решение с открытым исходным кодом, но за ним стоит компания. Премиум-сервис, который эта компания предлагает – это сервис Cypress Cloud, облегчающий параллелизацию тестов, тест-аналитика, а теперь еще и Test Replay.

 Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

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

Приступим!

Автор:

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

Чтобы грамотно обсудить, что значит «значимая», нам нужно рабочее определение. Не претендую на то, что мое определение «значимой автоматизации» исчерпывающе, но базировать свои мысли буду на нем. С этого и начнем:

Значимая автоматизация – это автоматизация, написанная для получения ценной информации о качестве нашего продукта (когда мы пишем проверки), или помогающая выявить эту информацию эффективнее (когда мы используем автоматизацию в иной форме).

Повторюсь, это, вероятно, не идеальное определение (но много ли вы видели идеальных?), но для начала сойдет. Разберемся с ним и детальнее взглянем на значимость автоматизации.

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

Начнем с определения — что такое CJM.

CJM (от англ. customer journey map) воспроизводит путь, который проходит клиент от осознания потребности в продукте до его покупки, а иногда и после неё. Всё это время он взаимодействует с продуктом и компанией и принимает решение на основе полученного опыта. Другими словами, это визуализация путешествия клиента по продукту

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

Пока искала работу знакомая QA Lead порекомендовала попробовать себя в сопровождении, сказала, что это будет полезно для развитии в тестировании. Стоит признаться, что изначально приняла это предложение скептически, но за неимением вариантов получше решила попробовать. Ниже, чтобы вы поняли, чем я занималась и поняли, насколько это будет вам полезно, распишу чем занималась и что мне это дало, а также какие препятствия мне встретились на этом пути.

Привет! Меня зовут Ирина Иванова, я работаю QA-инженером в команде разработки внутренних проектов в Учи.ру. Мы занимаемся такими сервисами, как виджет поддержки, личный кабинет сотрудников пользовательской поддержки, карьерный сайт и так далее. 

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

При автоматизации нагрузочных тестов специалисты рано или поздно приходят к мысли о том, как сравнивать результаты проводимых тестов. И не только сравнивать, но и демонстрировать результаты команде и бизнесу. Часто сравнение результатов нагрузочных тестов напоминает игру «найди 10 отличий» на почти одинаковых картинках. И если для специалистов в тестировании производительности это не проблема, то для коллег, не погруженных в теорию, это может стать таковой. Тут необходим какой-то простой и наглядный индикатор, который легко позволит определить — показатели стали лучше или хуже в процессе работы над проектом.