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

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

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

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

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

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

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

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

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

Вступление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Павел Саман (Pavel Saman)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Валери Роле (Valery Raulet)
Оригинал статьи
Перевод: Ольга Алифанова

 С того момента, как Тим Бернерс Ли изобрел "Всемирную паутину" в 1989, браузер довольно серьезно изменился. Теперь он может запускать веб-приложения, используя технологию, которая исходно вообще для этого не предназначена. Язык HTML был создан для того, чтобы исследователи могли сотрудничать и делиться информацией.

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