Kaner: Exploratory testing better than scripted testing

Все, что касается проектирования тестов...

Модератор: YuriY

Kaner: Exploratory testing better than scripted testing

Сообщение YuriY » 18 авг 2008, 22:18

searchsoftwarequality.com // 05.08.2008

Exploratory testing is superior to scripted testing, resulting in better tests and better testers, noted tester Cem Kaner told attendees at the Conference of the Association for Software Testing (CAST). Kaner, a software engineering professor at the Florida Institute of Technology, advocated that testers use checklists rather than scripts in his keynote speech, "The Value of Checklists and the Danger of Scripts: What Legal Training Suggests for Testers."


Как я понял, товарищ Канер рекомендует работать с чек-листами, а не с тест-кейсами, написанными в расчете на то, что кроме них ничего не нужно будет выполнять в рамках тестирования.

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

А если приложение большое и бизнес-логика в нем сложная, можно ограничиться чек-листами?) Как вы думаете?
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Сообщение lesha » 19 авг 2008, 12:51

Мне кажется, что все зависит от особенностей функциональности, которую необходимо протестировать. Например, не могу представить как составить более менее нормальный чек-лист, который бы проверил, что при создании 2-го итема и переименовании 3-го итема, обновится 1-ый итем. Т.е. в проектах со сложной структурой и функционалом без сценариев (тест-кейсов) бедет возможно даже сложновато. В особенности при smoke и acceptance тестировании.

Сейчас работаю над проектом, в котором приходится комбинировать кейсы и чек-листы. Вполне хорошо даже получается. Так ведь можно делать? :)
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19

Re: Kaner: Exploratory testing better than scripted testing

Сообщение arvex » 01 сен 2008, 12:24

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

А если приложение большое и бизнес-логика в нем сложная, можно ограничиться чек-листами?) Как вы думаете?


Думаю, что на вопрос "можно ли ограничится" у каждого найдется свой ответ. Одни скажут, что можно, другие нет.

Мне кажется, чтобы ответить на этот вопрос "можно ли ограничиться чек-листами?" надо для начала определиться с тем, какие цели преследуются при выборе между чек-листами и тест-кейсами, какие у них преимущества и недостатки.

Выше были озвучены первые два фактора, при которых постает вопрос выбора "чеклисты или тест кейсы", а именно:

1) Экономия времени на написание (в пользу CheckLists);
2) Документирование сложной функциональности в больших проектах (в пользу Test Cases);

...добавлю пару своих:

3) Отсутствие необходимости в высокой квалификации тестеров, которые выполняют тесты (в пользу Test Cases);
4) Вероятность не покрытия функционала тестами (ошибки дизайнера) (в пользу CheckLists)

...продолжаем...
arvex
Admin
 
Сообщений: 44
Зарегистрирован: 29 янв 2008, 23:34
Откуда: Kharkov

Сообщение despair » 18 сен 2008, 12:12

Мое мнение такое.

Ограничиваться чек-листом никак нельзя, полное тестовое покрытие им (так же как и кейсами) не сделаешь.
Я вот веду довольно большой проект со сложной логикой. Скажу честно - сколько не пытался как-то прописать тест-кейсы или чек лист более-менее детализированный - упирался в стену (кейсы или лист требует начальник). Кейсы получаются очень большими, в чек-лист все вписать нереально (сложная логика), временные затраты немыслимые.

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

Если бы таки пришлось писать детализированный чек-лист либо покрывать кейсами - спалил бы моск наверно :)

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

ЗЫЖ я ярый противник тест-кейсов, считаю это пустой тратой времени, по крайнем мере в большинстве случаев. :twisted:
best regards,
Sergey
despair
Junior
 
Сообщений: 15
Зарегистрирован: 17 мар 2008, 11:41
Откуда: Харьков

Сообщение arvex » 25 сен 2008, 08:57

despair писал(а):Поэтому, мое мнение - чек-лист или кейсы для полной проверки ну никак не годятся, никогда ими не обеспечишь хорошее тестовое покрытие.

Но вопрос то остается: а чем все таки обеспечишь хорошее тестовое покрытие?
Я работал и сейчас работаю на больших Web-проектах, время разработки некоторых из них переваливает 15000 часов. Так вот когда уже в живой работающих проект вносятся какие-то "небольшие" изменения какой-то функциональности или новая функциональность, то допускать, цитирую:
как минимум неприятно-вредные ошибки.
совсем нельзя, т.к. иногда на первый взгляд незначительное изменение функциональности может повлечь большие проблемы в проекте.

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

Лично в своей практике для обеспечения максимальных результатов постоянно приходится сочетать: тест-кейсы + чек-листы + матрицы.
arvex
Admin
 
Сообщений: 44
Зарегистрирован: 29 янв 2008, 23:34
Откуда: Kharkov

Сообщение despair » 25 сен 2008, 18:49

100%-ное тестовое покрытие не обеспечить никак, увы.

У меня вот, например, тож есть такой проект - пишется уже очень долго, думаю там и за 15000 часов перевалило. (я его приводил в пример в первом посте). Как вышел я с ситуации - писал, но повторюсь :)

С меня требовали покрытие кейсами или чек-листами. Я уперся, потому что понимал, что покрыть кейсами никак нереально, затраты времени неописуемые(для полного покрыти нужно оченьмного времени потратить). Таки доказал, что это не возможно и оно того не стоит. Требовали дальше покрытие чек-листами. Я снова уперся, не захотел писать детализированный чек-лист (для нормального покрытия нужна хорошая детализация)- это тоже очень много времени потянуло бы. Я написал чек-лист с функционалом, который самый юзабельный, который пользователь 100% использует. А время, которое я потратил бы на написание детализированного чек-листа и прохождение его, я кинул на exploratory тестирование.
Выкатили нам билд с изменениями - мы тестим по чек-листу. Далее мы выполняем exploratory. Нада сказать, что качество проекта не страдает. Жалоб на него очень мало, хотя проект довольно таки сложный и логика запутанная, очень много разных прав в системе.
Поэтому: на моем примере, такой подход прошел. Да, у меня не описано все тест кейсами и чек-листами, ни матрицами, ничен не описано толком, но качество проекта приемливо и всех устраивает, а не к этому ли мы стремимся, коллеги? Поэтому, я считаю - что такой подход допустим.
Вот по сути и тестовое покрытие. Чек-лист + exploratory. :idea:
ЗЫ: изменения в проект вносятся постоянно. Проект давно в эксплуатации.
Замечу: у нас нет текучести кадров. Поэтому в проекте ориентируются все хорошо. Такой подход при частом смене штата может не пройти.


Ваша ситуация: вносятся изменения в проект...
Я бы поступал так в вашей ситуации:
1. Пинать прогеров, чтобы писали что могли задеть, когда вносили изменения. Тут 2 варианта есть дальше
а) Написали что могли сломать. Вы именно это все глядите (я бы тестировал, так как я описал выше, exploratory тут лучше всего годится по-моему). Если далее обнаружится ошибка в том, что прогеры не описали - их проблемы, их ответственность. Если в том что писали - тут да, проглядели :roll:
б) НЕ написали что могли сломать. Гадайте время на тестирование такое, чтобы хватило. Не дают это время - пожалуйста, техника risk based всегда рядом. Расписываем и пугаем начальство и заказчика если нада. Согласны на это - все, мы прикрылись. Не согласны - дискутируем и ищем решение.
Вот ответ на то, как быть с изменениями. Я бы поступал так.
best regards,
Sergey
despair
Junior
 
Сообщений: 15
Зарегистрирован: 17 мар 2008, 11:41
Откуда: Харьков

Сообщение arvex » 26 сен 2008, 09:45

Я не говорил о "100%-ном тестовом покрытии", я писал о "максимально-возможном тестовом покрытии" или "достаточном тестовом покрытии" и к этому нужно стремится.

А то, что было описано:
despair писал(а):Я написал чек-лист с функционалом, который самый юзабельный, который пользователь 100% использует. А время, которое я потратил бы на написание детализированного чек-листа и прохождение его, я кинул на exploratory тестирование.

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

На мой взгляд для выбора вашей стратегии необходимо, чтобы были удовлетворены следующие условия:

1) не целесообразность траты времени на разработку документации(т.е. цель не оправдывает средства - это бывает тогда, когда мы тратим уйму времени на описание работы "не сложной", и "не подверженой багам" функциональности);

2) команда разработчиков пишет более менее качественный код(имеется ввиду еще и то, что интуитивно можно предположить, где будет состедоточено максимальное количество багов, а где они "врятли" будут найдены; бывает так, что функциональность "влоб" работает, но "под углом" она не работает - разработчики просто забыли это реализовать, или реализовали, но "криво");

3) команда тестировщиков эфективно использует exploratory testing(здесь вы фактически зависите от уровня тех тестировщиков, которые проводят тестирование, и надеетесь на их компетентность).

Если хоть один из выше описанных пунктов не будет отвечать действительности, то врятли можно быть уверенным в успешности данного подхода. И я описал только 3 условия, а их может быть и больше.
arvex
Admin
 
Сообщений: 44
Зарегистрирован: 29 янв 2008, 23:34
Откуда: Kharkov

Re: Kaner: Exploratory testing better than scripted testing

Сообщение wishaway » 26 сен 2008, 11:50

yurock писал(а):searchsoftwarequality.com // 05.08.2008

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


Да, в основном на моей практике это из-за нехватки времени. Но работает это только в том случае, если тестировщик - профессионал. Иначе ни о каком exploratory речь идти не может. А чек-листы подразумевают именно exploratory.

А если приложение большое и бизнес-логика в нем сложная, можно ограничиться чек-листами?) Как вы думаете?


Теоретически можно. Все зависит опять таки от квалификации тестировщика. Неважно, какой проект - большой или маленький. У меня основной критерий - это сложность проекта.

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

Основной плюс чек-листа кроется в следующем:
1. Не нужно много писанины (начальное состояние, тестовые данные, куча шагов, ожидаемый результат)
2) Наглядно (в виде таблицы можно оформить)

В большинстве проектов чек-листами можно обойтись. Просто для разной сложности проекта будет разная детализация чек-листа.

Например, та же позиция в чек-листе "Проверить работу Pager-а" может быть описана более подробно:
"Проверить работу Pager-а при количестве страниц больше 100"
"Проверить работу Pager-а при использовании фильтра-поиска"
и т.п.

Глубиной детализации чек-листа можно добиться полного заменения тест-кейсов. В итогде - все равно будет меньше писанины (все по той же причине отсутствия инфы, которая обязательна для тест кейса)
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Re: Kaner: Exploratory testing better than scripted testing

Сообщение arvex » 26 сен 2008, 16:15

wishaway писал(а):Но работает это только в том случае, если тестировщик - профессионал. Иначе ни о каком exploratory речь идти не может.

...согласен с этим условием полностью :wink:
+ сложность проекта

Итак, получается, что выбор в пользу exploratory зависит от:
1) Квалификация тестировщика
2) Уровень сложности проекта
arvex
Admin
 
Сообщений: 44
Зарегистрирован: 29 янв 2008, 23:34
Откуда: Kharkov

Сообщение despair » 26 сен 2008, 16:29

Exploratory должно выполняться всегда. Нельзя его исключать.
Не зависимо от уровня сложности проекта и от квалификации тестера.
При этой технике находится очень много ошибок, которые ни чек-листом ни кейсами не найдешь.
best regards,
Sergey
despair
Junior
 
Сообщений: 15
Зарегистрирован: 17 мар 2008, 11:41
Откуда: Харьков

Re: Kaner: Exploratory testing better than scripted testing

Сообщение wishaway » 26 сен 2008, 16:32

arvex писал(а):
Итак, получается, что выбор в пользу exploratory зависит от:
1) Квалификация тестировщика
2) Уровень сложности проекта


Не соглашусь. Exploratory нужно делать всегда, в любом проекте. Это не я, это Канер рекомендует. А я ему верю :)

А эти два пункта - это не пользу exploratory, а в пользу чек-листа (по отношению к тест-кейсам)

То есть:
выбор в пользу чек-листа (а не тест кейсов) возможен, если:
1) Квалификация тестировщика позволяет (делать exploratory по чек-листу)
2) Уровень сложности проекта не слишком высокий

Если хотя бы одно из двух не выполняется - то без тест кейсов не обойтись...
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Re: Kaner: Exploratory testing better than scripted testing

Сообщение pl » 21 ноя 2009, 07:21

Exploratory testing is superior to scripted testing, resulting in better tests and better testers

Думаю, Канер здесь кривит душой, подменяя причину следствием. :? Exploratory не сделает из новичка профессионала... По крайней мере быстро.

Однако, Канер прав в-целом. Скрипт предполагает логическое движение в канале некоторого workflow. Эта специфика сужает внимание. При разработке чек-листа, работа ведется в плоскости покрытия - и это снимает проблему.

Скажу больше, существуют и другие подходы. Например, когда чек-лист и скрипт работают в паре. Чек-лист используется для отражения того, что должно быть проверено и ожидаемых результатов, а скрипт - для предоставления пошаговых инструкций, как это исполнять. (импровизация на тему стандарта IEEE-Std-829)
pl
Newcomer
 
Сообщений: 3
Зарегистрирован: 21 ноя 2009, 04:39


Вернуться в Проектирование тестов | Test Design

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron