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

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

Решение — под катом.

Поскольку карандаши — вообще замечательнейшая и любимая тема, я получил несказанное удовольствие от этого задания. В процессе размышления и поиска информации открыто много нового и интересного, о чем раньше я и не подозревал…

Итак, имеем карандаш:

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

Что такое тест-кейс?

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

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

Зачем нужны тест-кейсы?

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

Ответ на топик «Распространенные ошибки при составлении баг-репортов».

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

Если кратко, то хороший баг-репорт позволяет:
1. воспроизвести проблему (это не всегда возможно, но надо стремиться).
2. понять, в чем проблема и какова ее важность.

Как написать хороший баг-репорт?
Для начала надо подготовиться. Если вы обнаружили баг, не стоит моментально бежать в баг-трекер и писать «ничего не работает!». Воспроизведите ошибку. Воспроизвелась? Отлично. Не воспроизвелась? Значит, что-то вы не учли. Вспоминайте, что делали.

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

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.