Начинаем

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Что мы имеем? Сложную предметную область, высокую вариативность сценариев и потенциально огромные риски от ошибок с одной стороны, и короткие итерации разработки и частые циклы доставки с другой. Я расскажу о том, как на данный момент при таких вводных выглядят процессы обеспечения качества множества сервисов, которые поставляют всю необходимую информацию нашим торговым терминалам.

Я начал свой путь в компании в конце 2017 года с должности специалиста технической поддержки, некоторое время поддерживал скрипты на python, а затем в мае 2019 года стал тестировщиком.

Здесь и далее я буду употреблять именно слово “тестировщик”, так как согласен с мнением, высказанным в книге “Agile Testing”, что в попытке называть специалистов QС или QA больше желания уйти от негативных ассоциаций низкоквалифицированной должности, чем реальных расширений компетенций. Тем не менее тестировщик в agile, как правило, более t-shaped и оказывает влияние на весь процесс разработки ПО. О выделенных ролях QC и QA, не занимающихся непосредственно тестированием, речи мы не ведем.

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

Автор: Валентин Агапитов (Valentin Agapitov)
Оригинал статьи
Перевод: Ольга Алифанова

Всем привет. Хочу рассказать об отличных способах применения ИИ в вашей IDE.

Сейчас диалоговые ИИ вроде ChatGPT напрямую встраиваются в наиболее популярные IDE – например, в Visual Studio Code, Visual Code, и семейство IDE от JetBrains.

Для начала я проведу обзор вариантов использования, в которых ИИ пригодился мне для создания кода тест-автоматизации. Затем – предложу ряд ИИ-инструментов, которые могут вам помочь.

Автор: Денис Федоров

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

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

Автор: Фернандо Тейшера (Fernando Teixeira)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое простота разработки?

Простота разработки, также известная как опыт разработчика или DX (developer experience) – тема, быстро набирающая популярность в области ИТ. Однако появилась она не вчера. Первые упоминания о ней относятся к ранним 2010-м, и в последнее время в сообществах разработчиков ей уделяется все больше внимания.

Простота разработки связана с вопросом, насколько легко или сложно разработчику выполнять задачи, необходимые для процесса разработки. Положительный опыт разработчика означает, что эти задачи довольно легко выполнимы командой, потому что для поддержки процесса разработки существуют необходимые системы, технологии, процессы и культура. Короче говоря, хороший DX важен, так как позволяет разработчиком писать код с уверенностью, приносить больше пользы и повышать производительность, затрачивая меньше сил.

Когда мы говорим о «разработчиках», это включает любого вовлеченного в процесс разработки инженера, включая инженеров по обеспечению качества (QA) и тестировщиков, работающих над качеством ПО, а также любую иную техническую роль в тех же процессах.

У некоторых компаний целые отделы занимаются поиском способов улучшить опыт разработчика. Крупнейшие ИТ-компании вроде Spotify даже создали специализированные инструменты, цель которых - улучшить опыт внутренней разработки – например, Backstage, помогающий создавать порталы для разработчиков, где централизованно располагаются все инструменты, ресурсы и документация компании.

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

Меня зовут Алексей Борискин, и на два дня я стал курьером.

Я системный аналитик в компании «Автомакон», где занимаюсь разработкой мобильного приложения «ВкусВилл:Курьер». Но почему я решил на время сменить профессию? Мне нужно было понять, как работает наш продукт в реальной жизни — не через отчёты или звонки с курьерами, а своими руками, ногами и велосипедом.

Это история о том, как я погрузился в наш продукт, нашел баги, замерзал, боролся с ветром, но в итоге спас сотни заказов. Я применил философию гемба, чтобы увидеть мир глазами тех, для кого мы создаём свои решения.

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Представьте на минутку, что вы тест-робот, задача которого – тщательно следовать тест-скрипту. Ваша ключевая проблема – это выполнить текстовую инструкцию в графическом интерфейсе пользователя. Если вы тестируете веб-приложения, то ваши инструкции могут выглядеть, как строка CSS – нечто вроде ".posts:n-th(3) button:has(.pencil)." Это можно интерпретировать, как кнопку редактирования третьей записи, но в структуре приложения зависимость более глубокая.

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

Самый простой способ показать, чего вы ожидаете от приложения – это скриншот. Это позволит быстро верифицировать тестируемую фичу. Сообщения об ошибке будут сразу считываться как две различающиеся картинки. Отчеты о падениях будут выглядеть, как зримые артефакты – тестировщики смогут взглянуть на них и исправить, даже не зная внутренней структуры. Вы получите то, что на экране. Поэтому давайте взглянем на тестирование UI на основе графики.

Статья предоставлена сайтом qarocks.ru

Страница регистрации – это не просто форма для создания учетной записи пользователя. Это тщательно продуманный процесс, который обеспечивает защиту бекэнда, соответствие стандартам конфиденциальности и безопасности, а также проводит проверку пользователей перед предоставлением определенных прав доступа к сервисам. Если вам нужно протестировать страницу регистрации, но вы не знаете с чего начать, ознакомьтесь с нашим руководством, в котором вы найдете более 100 тест-кейсов для страницы регистрации с подробным описанием.  

В этой статье мы перечислим наиболее распространенные и важные тест-кейсы и распределим их по группам.  

Автор: Мэг МакКей (Meg MacKay)
Оригинал статьи
Перевод: Ольга Алифанова

Переход от «рассмотрения» к «уточнению» багов

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

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

Ранее у нас были регулярные встречи по рассмотрению багов, но по различным причинам никто не стремился их воскресить. Я, однако, заметила, что команда считает, что встречи по грумингу фич помогают нам повысить качество кода юзер-стори. Поэтому мы решили применить тот же подход к рассмотрению багов. И так родились сессии по уточнению багов!