Тег: exploratory testing

4

Автор Опубликовано 4 комментария

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

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

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

5

Автор Опубликовано 5 комментариев

Такой возник диспут.

"Тестировщик никогда не додумывает. Лучше задать вопрос. Вот этому стараюсь учить, да" (с)

Говорят нам преподаватели тестирования.

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

Даже сильнее скажу, то что я додумываю, считаю своим огромным конкурентным преимуществом перед теми тестировщиками, которые не додумывают.

Что я делаю не так?
И что я делаю так?

Прошу мнений в комменты.

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

2

Автор Опубликовано 2 комментария

Коллеги и все, кто в теме.
Почему считается, что тестировщики ищут как сломать программу?

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

Исключения, конечно тоже есть - тестирование безопасности (например penetration testing), но я им не занимаюсь практически.
А вы, тестировщики, ищете как сломать?

5

Автор Опубликовано 5 комментариев

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

Теперь про анализ. У меня такое замечание/дополнение по процедуре анализа ошибок найденных исследовательским тестированием, да и другими методами тестирования тоже. Я очень понимаю желание проанализировать ошибку до нахождения точных границ фейла ("когда ввожу число 500  - работает, 501 - уже нет"), но со временем пришел к выводу, что обычно этого делать не надо. Достаточно зафиксировать входные параметры, при которых ошибка возникает ("ввел число 650 - не работает") и продолжать поиск других ошибок.

Аргументы такие: ...читать далее Анализ багов при исследовательском тестировании