Недавно у меня была итерация тестирования. Задача — проверить функционал, для которого нужно было создать 50+ сущностей. Однотипных, с разными названиями.
Обычно такое делаю через интерфейс. Открываю форму, заполняю поля, сохраняю. Потом ещё раз. И ещё. Пятьдесят раз. Я замерял: на одну сущность уходит примерно 20 секунд. Умножаем на 50 и получается больше 15 минут однотипных действий. А времени на итерации всегда мало.
Расскажу про свой опыт сдачи ISTQB CTFL 4.0 через индийского провайдера. Есть множество статей как сдавать, я не буду тут про это говорит. В статье описан только мой опыт сдачи через indian testing board.
Первое, что я сделала, промониторила цены у разных провайдеров, которые предоставляют сдачу онлайн на английском языке. Нашла самый выгодный вариант Indian testing board — 110$. Для индийцев экзамен вообще стоит 60$.
Провайдеров можно посмотреть тут.
Еще есть самый дешевый, что я находила — египетский провайдер SECCЧитать полностью »
Привет! Давайте знакомиться, меня зовут Мария. Год назад я впервые устроилась в банк и в одиночку начала автоматизировать фронтенд проекта. Мои розовые очки быстро разбились о суровую реальность банковской системы, а энтузиазм сменился на панику от количества проблем и вопросов. Я хочу рассказать о том, как можно сделать первые шаги в автоматизации, договариваться с командой и построить рабочий процесс.
Эта статья не для гуру автоматизации, она для тех, кто только начинает свой путь в AQA и очень переживает.
Для обзора хочу кратко обозначить мою начальную позицию и итоги спустя год.
Существует простое правило: чем раньше найден баг, тем он дешевле.
Представим проект, где тестирование есть только на production. Баг находят уже после релиза. Фича, которая приносит деньги, становится недоступна. Мы теряем прибыль, тратим время на дебаг, фикс и доставку — а вместе с тем время на post mortem и многочисленные созвоны по инциденту.
Привет! Сейчас покажу штуку, которую я довольно долго доводил до ума, и мне кажется, она может пригодиться не только мне.
Задача звучит скучно: нагенерировать тестовые карточки людей. Пол, имя, диагноз. Скучно ровно до того момента, пока не посмотришь, что получилось:
женский, Ольга, Аденома простатыФормально придраться не к чему. Пол настоящий, имя настоящее, диагноз из справочника. Просто вместе они дают человека, которого не бывает. Каждое поле правильное по отдельности — неправильно то, что вышло из них вместе.
Здравствуйте, дорогие друзья! Сегодня хочу поделиться опытом, который был получен за 2 часа изучения того, как развернуть Gitlab и подключить к нему Gitlab Runner из‑под Docker, и всё это на домашней Fedora 44.
Всё то, что было сделано, вызвано желанием немного потыкать и узнать, что из себя представляет Gitlab как для DevOps, так и для QA. При этом я не ограничивал себя в возможностях бесплатной удалённой версии от самого Gitlab.
Пару месяцев назад я попросил агента проверить форму обратной связи после рефакторинга. Через несколько минут получил отчёт: все проверки пройдены, форма работает корректно. Зелёные галочки, уверенный тон.
Я тогда только начинал отдавать тестирование агенту, поэтому работал по схеме «доверяй, но проверяй»: следом прошёл форму руками, с открытой вкладкой Network. Снаружи всё честно: валидация зелёная, кнопка активная, тост «Спасибо!» показывается, сервер отвечает 200. А в payload вместо темы обращения уходит строка [object Object]. Агент проверил всё, кроме того, что реально уходит на сервер.
Всем привет! Меня зовут Ксюша, и я backend QA-лид нескольких команд в EXANTE.
В начале этой истории я была обычным QA в команде, которая отвечает за ядро нашего backoffice.
Думаю, многие из вас знакомы со Scrum и его ивентами, но если нет — дальше речь пойдет о ретроспективе, одной из ключевых встреч этого фреймворка.
Вначале пути, вскоре после agile-трансформации, мы проводили ретроспективы, которые, в теории, должны были приносить пользу, а на практике ощущались бесполезными. В течение часа мы жаловались и выпускали пар, а через один спринт возвращались к тем же проблемам.