Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приступим!

Автор: Евгений Гусинец, Middle QA Engineer, автор телеграмм канала QA❤️Life

Тестирование продуктов является неотъемлемой частью процесса разработки программного обеспечения. В его основе лежит создание и выполнение тест‑кейсов — документированных инструкций, определяющих шаги для проверки определенных функций или аспектов программы. Тест‑кейсы играют важную роль в обеспечении качества программного продукта. Они помогают не только выявить ошибки и дефекты, но и удостовериться в соответствии функциональности программы заявленным требованиям.

Каждый тест-кейс разрабатывается с целью проверить определенный аспект продукта, будь то функция, интерфейс или производительность. Ключевым элементом каждого тест-кейса являются предварительные условия, или Pre-conditions, которые определяют состояние системы перед началом тестирования.

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

Эта статья начиналась, как пост, отвечающий на этот опрос:

Поле ввода принимает годы рождения между 1900 и 2004. Каковы граничные значения для этого поля?

Оригинальная публикация
Автор: Логунова Маргарита 

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

Так какие особенности сопутствуют тестированию десктопных приложений?

Автор: Т. Ашок (T. Ashok)
Оригинал статьи: Tea-Time With Testers, #01/2021
Перевод: Ольга Алифанова

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

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

Автор: Маарет Пюхяярви (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

Сегодня я созванивалась с коллегой по профессии. Он отправил мне сообщение в LinkedIn, прося о разговоре про тест-покрытие – до этого мы не особенно-то переписывались. И, как я иногда делаю, я согласилась поговорить. Я благодарна, что этот созвон состоялся – как за осознание, что объясняю тест-покрытие через модель «1-2-3», так и за канал коммуникации, позволяющий мне приходить к пониманию, вне зависимости от того, кто где находится.