Автор: Т. Ашок (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)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Тестирование – проблема выборки. И именно в выборках мы делаем очень существенные ошибки.

Ошибка в выборке компьютера разработчика ведет к печально знаменитым фразам вроде "на моей машине все работает" и "мы не релизим твою машину".

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

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

Автор: Смирнов Дмитрий

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

Большинство тестировщиков знакомы с такими техниками тест-дизайна, как разбиение на эквивалентные классы и анализ граничных значений.

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

В двух словах напомню.