Автор: Евгений Гусинец, 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», так и за канал коммуникации, позволяющий мне приходить к пониманию, вне зависимости от того, кто где находится.

Оригинальная публикация

Когда я был молодым…

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

Барак Обама, Джордж Буш и другие регистрировались в сервисе кастинга голосовых актеров, проводили сессии голосовых записей, исправно платили по счетам и выполняли прочие бизнес-действия. Через некоторое время об этом узнал наш ПМ, который попросил отказаться от практики привлечения политиков в ряды наших тестовых пользователей, т.к. правила компании предполагают использование нейтральных тестовых данных. Передо мной встал выбор: пользоваться случайным набором букв или придумать некий шаблон, который я буду использовать в своих кейсах. Я выбрал второй вариант.

Автор: Александр Копылов
Оригинал статьи размещен в блоге компании "Аурига" на сайте Хабр

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

В статье будем отталкиваться от функционального тестирования методом черного ящика.

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

Итак, начнем!

Автор: Саймон Томс (Simon Tomes)
Оригинал статьи
Перевод: Ольга Алифанова

Хорошее исследовательское тестирование требует хорошего навыка ведения заметок. Возможно, достаточным будет “выглядит неплохо” и “я нашел этот баг”. Но что вы упускаете, не ведя заметки, поддерживающие такое резюме? Какая информация останется в тени? Что вы заметили, но не задокументировали? Чем не поделились?

Автор: Егор Романов (telegram)

Yet another метод для разработки функциональных тест кейсов. Что будет, если отталкиваться от архитектурных схем тестируемой системы.

Вступление

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

На одном из собеседований мне задали довольно обыкновенный для области вопрос: «как ты пишешь тест кейсы, то есть какая у тебя методика по разработке тестов, покрывающих функциональность продукта?». Удивительно, но он поставил меня в тупик. Я читал и о традиционных подходах, и об интересном варианте из книги «Как тестируют в Google», но они не применялись мной в полной мере.

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

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Конфликт, возникающий при рассказе о проблемах исследовательского тестирования

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