4

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

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

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

Наконец опубликовано видео с моего доклада на SQA Days 16. Хотите сделать ваше ручное тестирование быстрее и гибче? Обязательно посмотрите 🙂

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

Если у вас есть свои вопросы - задавайте, постараюсь ответить. В конце поста добавлю и пример с решением, который описывал в докладе.

Видео:

Слайды:

...читать далее No-Test-Cases: избавьтесь от тест-кейсов в ручном тестировании

6

В очередной раз имеем ситуацию, когда один человек дизайнит тейст-кейсы, а совсем уже второй человек их выполняет. Или автоматизирует (проблема та же самая).
Так вот, в процессе выполнения (или автоматизирования) за первым "дизайнером" приходится некисло исправлять. Более того, часто (да почти всегда), чтобы исправлять за дизайнером, надо самому въезжать в предметную область и требования. Иначе как ты поймешь, что надо исправлять и на что?
В одном из докладов советовали такое: на позицию тест-дизайнера нужно брать самого умного-благоразумного тестировщика. И тогда мол, выполнять тесты сможет любой студент с улицы. Немножко за кадром остался ответ на вопрос - выполняет ли свои тесты тест-дизайнер сам или только "студент".
На мой взгляд в этой конструкции есть проблема. Если тест-дизайнер не выполнит и не отладит (а часто это можно сделать, в отличии от написания тест-кейсов только в конечной стадии разрабоки, когда ПО близко к состоянию "готово").
А заменять фазу отладку тест-кейсов усилением на фазе дизайна, это все равно что использовать пару гуру-студент для программирования - гуру пишет код, а студент компилирует, дебажит, исправляет найденные ошибки. Такая связка, конечно работать не будет.
Выводы.
1. Отлаживать и исправлять тест-кейсы при выполнении должен квалифицированный тестировщик (например, сам же тест-дизайнер).
2. Если при ручном тестировании пользоваться вместо тест-кейсов - ноу-тест-кейсами, то как и предыдущем пункте, без квалифицированного тестировщика при выполнении не обойтись, зато затраты на "отладку" и "исправления" сократятся в десятки раз.

А что вы думаете по этому поводу?