"Exploratory testing" практика
#1
Отправлено 17 декабря 2004 - 19:55
Т.е. это тестирование обратноя сторона тестирования по скриптам. В отличии от "Scripted testing" (написали скрипт - проверили), это "Exploratory testing" базируется на опыте самого тестировщика и работает по принципу подумали - протестировали, шаг влево, шаг вправо. (Это моё понимание в двух словах).
Интересны вот какие факты:
1. Как это тестирование звучит в русской терминалогии? Может есть какие-то статьи. Мне кажеться что все таки что-то есть, т.к. это тестирование очень хорошо вяжется с парным тестированием (тестирование в паре). Статьи по парному тестирование есть и на этом сайте. :-D. И кто сталкивался с XP, может применял? И возможно ли это в нормальном процессе разработки?
2. Интерес к данному тестированию, возник по причине, что приходиться вести проект с полным отсутствие документации. При этом невозможно составление данной по ряду причин (чтобы не говорили, что документацию нужно вести всегда - сам это прекрасно знаю).
Специфика:
- Outsourcing проект
- Начальство и в тем более заказчик (чисто бизнес взгляды, но задания дает сам) не будет тратить средства на составление подробной документации
- Гипердинамика изменения требований, т.е. несколько в день (на протяжении нескольких лет :blink: )
- Необходимость тестирования на лету! (приходит письмо в две-три строчки "что проверить", и нужно через 1-3 часа прислать ответ "хорошо проверили, вот дефекты"). Или же выполнение срочных прямыз заданий.
- Любая задержка ведет к "выяснению отношений"
- Большой плюс, что customer платит по повышенному рейту, но только за результат. :ph34r:
- Увы несостоявшаяся команда. Периодическая текучесть.
- Некоторые наборы тестов присутствуют, но ихнее покрытие не столь велико.
3. Так вот стоят задачи:
- Организовать максимально возможный процесс. И планировать работу хотя бы на день вперед.
- Обеспечить процесс обучения. (Фактически сейчас опыт и знание проекта передается как у ремеслеников)
А в общем у кого есть реальный опыт произведения подобного тестирования. Можете изложить в нескольких шагах? А также принцип внутреннего направления (исключив опыт самого тестировщика) - конечно если это вообще возможно...
А если уж тема не поимеет результатов, делитесь мыслями по такому особому тестированию.
#2
Отправлено 18 декабря 2004 - 09:33
#3
Отправлено 18 декабря 2004 - 10:20
Большое спасибо, но именно через гугл, я и смотрел. :Dвот что нашел google (это только первая ссылка)
Exploratory Testing Explained
Интересно именно реальный опыт и мысли тех кто с этим сталкивался на практике (вживую), т.е. какие-то дополнительные примеры, и оценка ожидаемых результатов с полученными. B)
#4
Отправлено 20 декабря 2004 - 06:04
Я пока не изучала ничего по exploratory testing, поэтому могу только подсказать идеи по организации тестирования исходя из своего опыта и поставленных вами, Dimon, проблем.
Могу рассказать как мы организовывали тестирование в отсутствие документации или при абсолютной нехватке времени на ее изучение.
Разработчик/проджект менеджер садился и рассказывал тестировщику о продукте: назначение, кто с ней будет работать, архитектура, используемые технологии разработки, возможные слабые места продукта (тестировщик сам должен это выспрашивать при надобности), приоритеты тестирования (в общем - по подсистемам/функциям и пр.).
Далее тестировщик садился и самостоятельно осваивал продукт в первом приближении, при этом рождаются идеи где что может сломаться (возможные проблемы), идеи записываются - как глобальный план тестирования в первом приближении (или не записываются если нет необходимости - если, например, надо протестировать только одну-две несложные функции и тестировать будет тот же тестировщик, которому объясняли как должен работать продукт.
Потом смотрим на план, подбираем методы тестирования и, собственно, тестируем - когда знаем что мы хотим выявить, тогда тесты на это направлены и не важно, каким образом мы проверим свою гипотезу.
Если у вас, как вы говорите, гипердинамика изменения требований, то нет смысла составлять подробную документацию (потому что, как я поняла, у вас нет циклов тестирования версий продукта, а сколь-нибудь подробная тестовая документация предназначена в первую очередь для воспроизводимости тестирования).
Но план тестирования всегда должен быть - он может представлять собой список функций, которые нужно протестировать (это те функции, которые были дописаны, те которые с ними взаимодействуют - как минимум).
Если ваш проект длиться уже несколько лет и о его закрытии даже в отдаленном будущем не идет речи, да при этом текучесть кадров, то вскоре может оказаться, что никто не будет знать, какие функции есть в продукте и как они работают, поэтому, как минимум вам необходимо составить список всех функций продукта (убедите ваше начальство в необходимости этого шага - ведь заказчик может в один момент сказать вам быстренько протестировать всю систему). В любои случае, напишите список всех подситем продукта, потом будете дописывать функции по подсистемам - в параллельном режиме с жизнью проекта.
Также есть идеи формализовать направление движения МЫСЛЕЙ тестировщика - то есть как рождаются тесты - в виде чек листов. Как это - у меня есть небольшой опыт, если интересно, могу поделиться.
#5
Отправлено 22 декабря 2004 - 18:04
Согласно книги Сема Кенера и сотоварищей "Lessons Learned in Software Testing: A Context-Driven Approach" exploratory testing означает ни что иное, как исследовательское тестирование, которое проводится в период ознакомления с тестируемой системой или программой. По мере знакомства exploratory testing вытесняется более осознанными тестами.Вот все чаше натыкаюсь на публикации (не всегда новые) связанные с подобным тестированием. (набрав в поиске ключевое слово eploratory - ничего не нашло :( )
Т.е. это тестирование обратноя сторона тестирования по скриптам. В отличии от "Scripted testing" (написали скрипт - проверили), это "Exploratory testing" базируется на опыте самого тестировщика и работает по принципу подумали - протестировали, шаг влево, шаг вправо. (Это моё понимание в двух словах).
Можно сказать, что exploratory testing вынужденная операция. По своей сути этот вид тестирования близок к "ad hoc testing". Различие лишь в том, что первый вид тестов проводится на незнакомой системе, а второй - на уже изученной, но спонтанным образом -"на удачу".
Никаких теоретических или системных особенностей эти два теста не имеют.
#6
Отправлено 23 декабря 2004 - 01:24
Вот их сайты:
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 ("исследовательское тестирование" - так переведем :)). Увы, не помню, какой.
#7
Отправлено 23 декабря 2004 - 12:24
Также есть идеи формализовать направление движения МЫСЛЕЙ тестировщика - то есть как рождаются тесты - в виде чек листов. Как это - у меня есть небольшой опыт, если интересно, могу поделиться
Yarilo, поделитесь, пожалуйста, мне тоже это интересно
#8
Отправлено 23 декабря 2004 - 14:45
Тема называется Unified Testing System: the solution.
#9
Отправлено 23 декабря 2004 - 14:49
Develop Unified Tests: the solution, Quick test design, document and testing
(перепутала :) )
#10
Отправлено 06 января 2005 - 12:52
То есть в рамках плана тестирования по каждому продукту выделяется время не только на системное тестирование, но и на случайное. Когда тестер берет изделие и начинает гонять не только все его стандартные функции, а еще и взаимодействие их. Конечно, у каждого своя специфика, нужны отдельные навыки для телефонов, компьютеров, КПК и т.д.
Около 3/4 из всех дефектов, найденных мной, приходятся на фазу Random Testing.
Конечно, позже приобретается опыт и становится даже очевидно где могут быть баги. И что интересно, обычное системное тестирование практически не покрывает некоторые области. И как раз там случайное тестирование более всего применимо.
Я лично считаю его самым перспективным видом. Конечно, если в ходе его все протоколировать, для процесса.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных