Home

Начинаем

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

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

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

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

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

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

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

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

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

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

Автор: Кирилл Корнаков

Если вы когда-нибудь сталкивались с автотестами, которые ломаются на ровном месте, не дают предсказуемых результатов или отнимают больше времени, чем ручное тестирование, — эта история для вас.

Наша команда столкнулась с похожей проблемой: тесты, которые должны были ускорять разработку, превращались в источник боли и хаоса. Мы больше не доверяли их результатам: красные прогоны стали «фоновым шумом», а зелёные — чем-то из области фантастики.

В этой статье я расскажу, как мы разбирались с нестабильностью, рассмотрев три разных подхода (быструю починку тестов, создание идеальной базы данных и генерацию тестовых данных), и выбрали тот, который позволил нам ускорить CI/CD и вернуть контроль над автотестами.

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

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

Профессиональная команда разработки отличается от любительской способностью справляться с такими ситуациями.

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

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

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

Опишу контекст, чтобы пояснить, что конкретно я имею в виду.

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

Вместо того, чтобы поделиться определениями тестов (в некоторых командах они даже не зафиксированы) и вникать в логику интеграционных и E2E-тестов, некоторые стремятся разработать автоматизированные проверки, верифицирующие, что все покрыто. Тут и начинается структурирование логических тестов: они хотят превратить логические тесты в структурные.

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

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

QA, QE и специалисты-тестировщики часто слышат одни и те же вопросы, особенно находясь на руководящей позиции. Например, это «сколько кейсов еще осталось», «сколько времени еще нужно тестированию», и «какой процент тестирования завершен».

Как руководители, мы часто должны отвечать прямо, линейно, исчислимо. Именно это, как правило, и нужно задающим вопросы – простой, удобоваримый кусок информации, на основе которого принимаются сложные бизнес-решения. Бизнес ожидает ответов вроде «Нам осталось выполнить 500 кейсов из 10000», «в среднем мы выполняем 50 кейсов в день, то есть дней 10», и «мы на 95% готовы».

Опытные люди, однако, знают, что эти ответы не всегда дают нужную информацию. Минусы соблазна «просто сказать им число»:

• Числа легко истолковать неверно.
• Числа не показывают всей картины.
• Они одномерны.
• Они отражают устаревшие данные.

Эффективный способ решить эту проблему – воспользоваться метрикой, разработанной одним из нас (это был Мас Коно). Он называет ее тест-пойнтами. По сути это взвешенный замер запуска планируемых кейсов.

Автор: Герасимов Сергей Сергеевич, Петрович-Тех, блог компании

Всем привет! Меня зовут Сергей, я – Senior Manual QA Engineer в "Петрович-Тех", и в этой статье я предлагаю разобрать граничные значения на практических кейсах.

Думаю, почти любой тестировщик вспоминает граничные значения первыми из всех техник тест-дизайна. Особенно на собеседовании. Граничные значения звучат просто и понятно, про них легко рассказать, потому что даже из названия ясно, где и как они применяются. 

Несмотря на то, что техника простая – она решает много проблем. Это не попарное тестирование, о котором я писал здесь, где есть куча инструментов на выбор, надо правильно составить входные данные, потом анализировать их и выдавать результат. Тут всё проще: мы руководствуемся чистой логикой. 

Разберем в статье конкретные примеры использования этой техники. Поехали!

Автор: Герасимов Сергей Сергеевич, Петрович-Тех, блог компании

Всем привет! Меня зовут Герасимов Сергей, я – Senior QA Manual Engineer (да, я хвастаюсь) в компании “Петрович-Тех”.

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

Звучит просто, но что кроется за ней?

В своей прошлой статье я рассказывал о тестировании оплат, техниках тест-дизайна, которые использовал, и всячески открещивался от попарного тестирования. Но вот злой рок дошел до меня, и сегодня я хочу рассказать о недавнем опыте использования “попарки” на практике. 

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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