Перейти к содержимому

Фотография

"Exploratory testing" практика


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 9

#1 Dimon

Dimon

    Активный участник

  • Members
  • PipPip
  • 110 сообщений
  • ФИО:Dimon Makhno
  • Город:Украина, Харьков


Отправлено 17 декабря 2004 - 19:55

Вот все чаше натыкаюсь на публикации (не всегда новые) связанные с подобным тестированием. (набрав в поиске ключевое слово eploratory - ничего не нашло :( )
Т.е. это тестирование обратноя сторона тестирования по скриптам. В отличии от "Scripted testing" (написали скрипт - проверили), это "Exploratory testing" базируется на опыте самого тестировщика и работает по принципу подумали - протестировали, шаг влево, шаг вправо. (Это моё понимание в двух словах).

Интересны вот какие факты:
1. Как это тестирование звучит в русской терминалогии? Может есть какие-то статьи. Мне кажеться что все таки что-то есть, т.к. это тестирование очень хорошо вяжется с парным тестированием (тестирование в паре). Статьи по парному тестирование есть и на этом сайте. :-D. И кто сталкивался с XP, может применял? И возможно ли это в нормальном процессе разработки?

2. Интерес к данному тестированию, возник по причине, что приходиться вести проект с полным отсутствие документации. При этом невозможно составление данной по ряду причин (чтобы не говорили, что документацию нужно вести всегда - сам это прекрасно знаю).
Специфика:
- Outsourcing проект
- Начальство и в тем более заказчик (чисто бизнес взгляды, но задания дает сам) не будет тратить средства на составление подробной документации
- Гипердинамика изменения требований, т.е. несколько в день (на протяжении нескольких лет :blink: )
- Необходимость тестирования на лету! (приходит письмо в две-три строчки "что проверить", и нужно через 1-3 часа прислать ответ "хорошо проверили, вот дефекты"). Или же выполнение срочных прямыз заданий.
- Любая задержка ведет к "выяснению отношений"
- Большой плюс, что customer платит по повышенному рейту, но только за результат. :ph34r:
- Увы несостоявшаяся команда. Периодическая текучесть.
- Некоторые наборы тестов присутствуют, но ихнее покрытие не столь велико.

3. Так вот стоят задачи:
- Организовать максимально возможный процесс. И планировать работу хотя бы на день вперед.
- Обеспечить процесс обучения. (Фактически сейчас опыт и знание проекта передается как у ремеслеников)


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

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

#2 Petr

Petr

    Опытный участник

  • Members
  • PipPipPipPip
  • 317 сообщений
  • ФИО:Можаев Петр
  • Город:Москва

Отправлено 18 декабря 2004 - 09:33

вот что нашел google (это только первая ссылка)
Exploratory Testing Explained
  • 0

#3 Dimon

Dimon

    Активный участник

  • Members
  • PipPip
  • 110 сообщений
  • ФИО:Dimon Makhno
  • Город:Украина, Харьков


Отправлено 18 декабря 2004 - 10:20

вот что нашел google (это только первая ссылка)
Exploratory Testing Explained

Большое спасибо, но именно через гугл, я и смотрел. :D
Интересно именно реальный опыт и мысли тех кто с этим сталкивался на практике (вживую), т.е. какие-то дополнительные примеры, и оценка ожидаемых результатов с полученными. B)
  • 0
Граммотность - то качество, которым я не обладаю.

#4 Yarilo

Yarilo

    Новый участник

  • Members
  • Pip
  • 59 сообщений
  • Город:г. Барнаул, Алтайский край

Отправлено 20 декабря 2004 - 06:04

Привет!

Я пока не изучала ничего по exploratory testing, поэтому могу только подсказать идеи по организации тестирования исходя из своего опыта и поставленных вами, Dimon, проблем.

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

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

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

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

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

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

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

Также есть идеи формализовать направление движения МЫСЛЕЙ тестировщика - то есть как рождаются тесты - в виде чек листов. Как это - у меня есть небольшой опыт, если интересно, могу поделиться.
  • 0

#5 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 22 декабря 2004 - 18:04

Вот все чаше натыкаюсь на публикации (не всегда новые) связанные с подобным тестированием. (набрав в поиске ключевое слово eploratory -  ничего не нашло :( )
Т.е. это тестирование обратноя сторона тестирования по скриптам. В отличии от "Scripted testing" (написали скрипт - проверили), это "Exploratory testing" базируется на опыте самого тестировщика и работает по принципу подумали - протестировали, шаг влево, шаг вправо. (Это моё понимание в двух словах).

Согласно книги Сема Кенера и сотоварищей "Lessons Learned in Software Testing: A Context-Driven Approach" exploratory testing означает ни что иное, как исследовательское тестирование, которое проводится в период ознакомления с тестируемой системой или программой. По мере знакомства exploratory testing вытесняется более осознанными тестами.

Можно сказать, что exploratory testing вынужденная операция. По своей сути этот вид тестирования близок к "ad hoc testing". Различие лишь в том, что первый вид тестов проводится на незнакомой системе, а второй - на уже изученной, но спонтанным образом -"на удачу".

Никаких теоретических или системных особенностей эти два теста не имеют.
  • 0
Гринкевич Сергей

#6 Stasde

Stasde

    Новый участник

  • Members
  • Pip
  • 71 сообщений

Отправлено 23 декабря 2004 - 01:24

Ищите статьи Sem Kener, James Bach, Bret Pettichord. Там немало об этом типе тестирования.
Вот их сайты:

Sem Kener: http://www.testinged...cles/index.html

James Bach: http://www.satisfice.../articles.shtml
http://blackbox.cs.fit.edu/blog/james/

Bret Pettichord: http://www.pettichord.com/
http://www.io.com/~wazmo/qa/

Да, кстати, встречал сайт, где предлагали тул для exploratory testing ("исследовательское тестирование" - так переведем :)). Увы, не помню, какой.
  • 0

#7 Tester

Tester

    Новый участник

  • Members
  • Pip
  • 73 сообщений

Отправлено 23 декабря 2004 - 12:24

Также есть идеи формализовать направление движения МЫСЛЕЙ тестировщика - то есть как рождаются тесты - в виде чек листов. Как это - у меня есть небольшой опыт, если интересно, могу поделиться


Yarilo, поделитесь, пожалуйста, мне тоже это интересно
  • 0

#8 Yarilo

Yarilo

    Новый участник

  • Members
  • Pip
  • 59 сообщений
  • Город:г. Барнаул, Алтайский край

Отправлено 23 декабря 2004 - 14:45

Я создала новую тему в разделе Тестирование и качество, т.к. статейка вышла универсальная, к сожалению не знаю как сюда ссылку вставить.
Тема называется Unified Testing System: the solution.
  • 0

#9 Yarilo

Yarilo

    Новый участник

  • Members
  • Pip
  • 59 сообщений
  • Город:г. Барнаул, Алтайский край

Отправлено 23 декабря 2004 - 14:49

Тема называется так:
Develop Unified Tests: the solution, Quick test design, document and testing

(перепутала :) )
  • 0

#10 baldr

baldr

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • Город:СПб

Отправлено 06 января 2005 - 12:52

У нас в организации под Exploratory Testing (он же Random Testing) понимается так называемое "Случайное тестирование".
То есть в рамках плана тестирования по каждому продукту выделяется время не только на системное тестирование, но и на случайное. Когда тестер берет изделие и начинает гонять не только все его стандартные функции, а еще и взаимодействие их. Конечно, у каждого своя специфика, нужны отдельные навыки для телефонов, компьютеров, КПК и т.д.
Около 3/4 из всех дефектов, найденных мной, приходятся на фазу Random Testing.
Конечно, позже приобретается опыт и становится даже очевидно где могут быть баги. И что интересно, обычное системное тестирование практически не покрывает некоторые области. И как раз там случайное тестирование более всего применимо.
Я лично считаю его самым перспективным видом. Конечно, если в ходе его все протоколировать, для процесса.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных