Я много раз встречала понятие "исследовательское тестирование" ("exploratory testing") и интуитивно понимала, что это - именно то, чем я в значительной степени занимаюсь на протяжении лет. Однако это понятие упоминалось в тех же книгах обычно вскользь, как просто один из существующих подходов; но как основной подход, принятый в качестве стандарта, неизменно описывалось тестирование по предварительно написанным тест кейсам.
И вдруг я прочитала статью Джеймса Баха (James Bach) "Exploratory Testing Explained". Мне сложно передать всю ту гамму чувств, которую я испытала! Вот оно - вот описание и обоснование того, к чему я когда-то сама пришла. Вот тот человек, который осмелился заявить во всеуслышание, что такой подход не просто имеет право на существование, но ещё и разумен и эффективен.
О, как долго книги и люди пытались внушить мне, что так работать неправильно. И какое счастье почувствовать, что ты не одинок, и что есть те, кто думает подобно тебе. Спасибо, Джеймс Бах и люди вроде Вас, за то, что вы ведёте эту борьбу и заставляете исследовательское тестирование заявить о себе!
У меня всегда вызывало искреннее недоумение стремление написать заранее все необходимые тест кейсы и тестировать строго по ним. Конечно, в определённой степени предварительное написание тест кейсов уместно, но разве могут проверки по ним полностью заменить и сравниться с гибкостью и адаптивностью исследовательского тестирования, выполняемого умелым тестером, который вкладывает в это все свои опыт, знания, инстинкты и вдохновение?!
Не надо относиться свысока и считать ущербными исследовательское тестирование и тестеров, которые его практикуют, только потому, что при этом порождается меньшее количество документов, столь любезных сердцам многих.
И я хочу верить, что каждый тестер, который действительно любит свою работу и считает тестирование своим призванием, хотя бы в глубине души понимает и осознаёт, что именно исследовательское тестирование - это квинтэссенция нашей работы.
P.S. Испытывая столь значительный эмоциональный подъём, я даже решилась написать Джеймсу Баху письмо, что для такого несмелого и нерешительного человека как я практически невообразимо. Написать - чтобы как минимум действительно сказать ему спасибо, а как максимум - уточнить у него, правильно ли я в принципе понимаю суть исследовательского тестирования. Каковы же были мои удивление и радость, когда на следующий же день я получила ответ! В целом, Джеймс Бах подтвердил, что я на правильном пути. Конечно, теперь мне ещё предстоит очень многое прочитать, узнать, осмыслить и, вероятно, многому научиться. Но направление теперь понятно; и известно, где искать помощь и совет в случае необходимости.
Бах - крут.
ОтветитьУдалитьПротивопоставление "тест кейсы и тестировать строго по ним" и "гибкостью и адаптивностью исследовательского тестирования, выполняемого умелым тестером, который вкладывает в это все свои опыт, знания, инстинкты и вдохновение" - зло.
Читать его книгу про школяра-буканира - надо.
У меня файл с книгой - есть.
Алексей, если можете поделиться книгой - буду признательна, т.к. как раз пытаюсь её найти.
ОтветитьУдалитьНасчёт противопоставления, которое зло, - можете поподробнее, пожалуйста?
Лупан - поэт :)
ОтветитьУдалитьЛена, дальше Вам сюда: http://www.developsense.com/resources.html
ОтветитьУдалитьК сожалению, уже не могу пригласить на тренинг "Rapid Software Testing" в исполнении Майкла Болтона, который буквально пару недель тому назад прошёл в Москве. Придётся ждать следующего :)
Но зато могу нескромно пригласить на свои тренинги по тестированию методом свободного поиска :)
Алексей, спасибо за ресурс. И спасибо за приглашение на тренинг. Но надеюсь, что это не заденет Вас, если я для начала позволю себе как можно больше поизучать первоисточник, т.е. всё, что найду на сайте и в блоге Джеймса Баха, а также то, что он мне рекомендовал изучить?
ОтветитьУдалитьРазумеется, это обязательно нужно сделать! Тем более, что значительная часть ссылок с указанной выше странички ведёт именно на сайт Баха http://www.satisfice.com/
ОтветитьУдалитьНадеюсь, Вы не откажетесь принять приглашение, если в следующий раз тренинг приедет провести Джеймс? ;)
:) Безусловно, к Джеймсу Баху я бы очень постаралась попасть. Пока же, если я правильно поняла, он предложил возможность общения с ним (и обучения у него) по скайпу, что меня безумно радует, но чем я очень боюсь злоупотреблять.
ОтветитьУдалитьПока Алексей Лупан не расшифровал детальнее, что именно он посчитал злом и почему, обосную немного высказанные в моём посте мысли.
ОтветитьУдалитьВо-первых, если уж подходить формально, то чистое скриптовое тестирование (использую кальку с английского «scripted testing», т.к. приходящие мне на ум варианты перевода слишком неудобны) и чистое исследовательское тестирование - это именно противоположности друг друга.
Во-вторых, я не отрицаю скриптовое тестирование как таковое (см. исходный пост); для себя лично я считаю оптимальным комбинирование двух подходов - скриптового и исследовательского. Предпочитаю при этом перекос в сторону исследовательского, но признаю, что степень исследовательского очень может зависеть от конкретных целей и задач.
В-третьих, я действительно считаю скриптовый подход менее эффективным и менее гибким, чем исследовательский. Как минимум потому, что вы никогда не сможете втиснуть в рамки сколь угодно многочисленных предварительно написанных тест кейсов все необходимые тесты. Если же всё-таки попытаться, то боюсь, что в результате получится огромный объём тест кейсов, которые как минимум будет очень сложно поддерживать, не говоря уж об их применимости. Скриптовый подход достаточно тяжёлый и неповоротливый, раз уж надо сперва описать, а потом проверить. Исследовательский же подход гораздо более гибкий, ведь тесты придумываются и выполняются в режиме реального времени в зависимости от реакции приложения, от контекста и т.п.
Прошу заметить, что я говорю о чистых скриптовом и исследовательском подходах. И полагаю, что когда люди защищают скриптовый подход, они скорее всего имеют в виду всё-таки какую-то комбинацию с исследовательским подходом.
А вот что я считаю злом - это насаждение скриптового подхода и отрицание исследовательского. Как можно низводить тестирование до рамок «написал инструкцию - выполнил инструкцию», когда на самом деле тестирование - это захватывающий интеллектуальный процесс?! Сама природа тестирования - исследовательская…
1) см. емайл.
ОтветитьУдалить2) Бояться злоупотреблять Бахом не следует - он сам народонаселению предложил общаться с ним в скайпе, и получает от этого полезный фан.
3) Я начну издалека и потом тоже уйду вдалёко, но таким образом я полностью объяснюсь.
Крепитесь :)
"Тестирование по скриптам" и "тестирование методом свободного поиска" - это тотальные противоположности.
Не следует их противопоставлять друг другу, и обсуждать их достоинства и недостатки по отдельности. Их следует комбинировать.
Как не следует противопоставлять пехоту и авиацию - грамотные полководцы используют их и одновременно, и поочередно - с одинаковой эффективностью для победы.
Дурак тот, кто будет делать упор только на один род войск в ущерб всему делу.
В неумелых руках меч самурая может стать даже причиной пожара. А в умелых руках им можно резать даже баклажаны. Но это не значит, что НАДО резать баклажаны мечом - не для того его ковали. У него есть своё предназначение и область применения.
Каждый тестировщик со временем приходит к пониманию того, что тест-кейсы (скрипты, если угодно) писать надо, даже если очень не хочется и скучно.
Скрипты - основа регрессионного тестирования. В этой области свободный поиск меня когда-то подвел, и пришлось быстро прозревать.
Вы никогда не найдете "волшебную методику тестирования", которая с блеском позволит всё и вся протестировать. Вам придется комбинировать существующие методики.
Так дети учатся в школе рисовать идиотские палочки и загогулинки (я в детстве ОЧЕНЬ не понимал, зачем это все нужно). Но после загогулинок начинаешь рисовать отдельные буквы. А буквы складываются в слова.
Владеющий техникой комбинирования слов уже может делать всё, что угодно. Буквально всё, что угодно. Слово становится оружием, а не набором загогулинок и "попиндикулярных палочек".
Цитата: "У меня всегда вызывало искреннее недоумение стремление написать заранее все необходимые тест кейсы и тестировать строго по ним".
А представьте себе себя менеджером тестировщиков. А меня - клиентом. Я спрашиваю: "Лена Первая, не ишпортилься ли осноффной функсиональ посля измененьий, который фнесли наши слаффные багосоздатели в наш слаффный продакт?"
Чтобы ответить на этот важный вопрос, надо иметь список того, что мы ОБА подразумеваем под основным функционалом. А чтобы оба подразумевали, что и как в этом функционале работает, мы должны иметь список требований. А чтобы мы оба подразумевали, что проверка этого функционала подразумевает проверку того-то и
этого-то таким-то образом, надо надо положить на стол тест-кейсы. Тест-скрипт. Must have.
Иначе всегда будут вопросы вроде "почему тут не проверили?" и "почему проверяли сопутствующий функционал в то время, как мы требуем проверить только основной?" Причин может быть много. Банальная: например, клиент платит ТОЛЬКО за проверку этой области, и все, что мы найдем в соседней, он просто не примет во внимание...
Поэтому не удивляйтесь, если от вас требуют заранее все написать и тестировать строго по этому.
Другое дело, если вы столкнулись с манагерами, которые не понимают силу исследовательского тестирования. Ну... Бахом это точно не лечится. Кто такой Бах?
Вы можете использовать свободный поиск даже в те моменты, когда вас никто не видит. Если найдете что-то серьезное, и доложите об этом - тогда слово "Бах" начнет звучать для упомянутых манагеров более весомо.
Кстати, процесс написания тест-кейсов - очень увлекательная мозговая работа. Скука - эти кейсы проходить в сотый раз...
И кстати: у тестирования методом свободного поиска есть существенный недостаток: ознакомление с программой в ходе ее исследования не поможет прояснить, были ли программистами правильно воплощены те задачи, которые перед ними кто-то когда-то поставил.
ОтветитьУдалитьНапример, открываю тестируемый сайт, и вижу черный текст на белом фоне. Нормально же? А если я вам скажу, что на исходном дизайне фон должен был быть зеленым, и то, что я вижу - несомненный баг (не подгрузился файл со стилями). А я не увидел баг, не понял, что это баг - просто потому, что не знал. Ибо не посмотрел на требования, которые, как мне сказали, есть на внутренней вики, но они давно устарели :)
Вот в таких местах поиск ничем не поможет.
Цитата: "Исследовательский же подход гораздо более гибкий, ведь тесты придумываются и выполняются в режиме реального времени в зависимости от реакции приложения, от контекста и т.п."
Не придумываются на ходу :) Они придумываются заранее, исходя из цели, которую надо достичь, и корректируются на ходу.
Тесты придумываются заранее, но их использование - целиком на усмотрение тестировщика.
Например, грозит нам поход в магазин. Жена записала: взять
- колбасу "Молочная",
- яйца,
- лук.
А если не будет в магазине колбасы "Молочная", но будет "Краковская". Что делать? Звонить жене и сказать, что есть "Краковская"? Или попытаться взять, не спрашивая, рискуя дома получить нагоняй? Или вернуться к жене ни с чем, и спросить, зачем ей нужен такой странный набор продуктов, и на основе этого выяснить, можно ли взять эту колбасу вместо другой. И, кстати, сколько яиц надо взять? И сколько лука? И какого именно лука? А почему? А когда ужин?
Вон сколько вопросов, которые надо продумать ДО ТОГО, как начинается исследовательское тестирование. Это не совсем то, что подразумевается под "придумывать на ходу".
В общем, читайте внимательно книгу Баха. Для этого понадобится один свободный день, или два, потому что текст не переведен на русский - увы.
После книги рекомендую паузу для осмысления, а затем тематический сеанс Баранцева (реверансы) на эту тему - недорого, грамотно, и по-русски.
Например, он внятно объясняет разницу между исследовательским тестированием и тестированием методом свободного поиска - до этого не каждый бахо-адепт додумается. Затем объясняет, почему это не универсальная техника тестирования. После этого становится понятно, что это весьма универсальная, но местами ограниченная техника :)
Всё.
Алексей, во-первых, спасибо большое за книгу.
ОтветитьУдалитьВо-вторых, спасибо за подробное объяснение своей точки зрения. Но, честно говоря, я не вижу в Вашей точке зрения таких уж принципиальных расхождений с тем, что высказала я. Как я говорила в предыдущем комментарии (и изначально), я сама считаю оптимальным комбинирование этих двух подходов. И, кстати, если бы меня спросили, для чего именно в моих глазах в первую очередь уместен скриптовый подход, то я бы сразу сказала, что для регрессионного тестирования - к этому я тоже не один год назад уже пришла.
Насчёт моей цитаты, которая так Вам не нравится ("У меня всегда вызывало искреннее недоумение стремление написать заранее все необходимые тест кейсы и тестировать строго по ним"): ключевое слово тут «все». Я не понимаю стремление описать каждый чих, каждую пару перебираемых значений, каждое шевеление мыши. Это просто бессмысленно в конце концов. Лично моё мнение на данный момент - тест кейсы должны покрывать основной функционал, основные требования, основные моменты позитивных и негативных тестов. И, кстати, наличие тест кейсов - ещё не означает, что при тестировании я в первую очередь буду опираться на них. Да, в конечном итоге они будут проверены, и будут перепроверяться снова, но при тестировании мои глаза изначально не будут зашорены этими самыми тест кейсами. Возможно, что эти тест кейсы будут даже созданы после начала тестирования.
Насчёт «придумывать на ходу» - пожалуй, само слово не слишком удачное. Но «продумывать заранее» - это тоже не то. Продумывается заранее какой-то общий план, генеральная линия тестирования, но конкретные тесты, которые выполняются - они всё-таки создаются в процессе. Допустим, я выполняю какой-то тест и наталкиваюсь на непредвиденное поведение. Разумеется, я начну исследовать, что же это за непредвиденность такая - т.е. по сути начну генерировать и выполнять новые тесты. Могла я ИХ продумать заранее? Вот это вряд ли, не правда ли? Поэтому всё-таки мы говорим о дизайне тестов на ходу.
Насчёт ознакомления с программой в ходе тестирования - вот это пока открытый для меня вопрос в подходе Баха. Я глубоко убеждена, что тестер должен знать, как должно работать приложение. И на текущий момент моё виденье примерно таково: тестер знает заранее в общих чертах требования к приложению (знать досконально всё равно вряд ли возможно, если приложение не слишком примитивно), начинает своё исследование-тестирование, изучает приложение таким образом, но параллельно же и начинает всё больше углубляться в требования к нему. Я думаю, что слово «обучение» в определении исследовательского тестирования - оно более широкое, чем просто ознакомление с полностью неизвестным доселе приложением. В эту сторону я хочу ещё покопаться и подумать.
И всё-таки ещё раз хочу пояснить, откуда столько радости и боли в моём посте. Мне ужасно видеть, когда тестирование преподносится только как написание и проверка тест кейсов. Когда считается нормальным, что тестер действует строго в рамках написанного. Когда тестеры становятся уже неспособными сделать шаг вправо-шаг влево от того, что написано. Когда тестирование после написания тест кейсов сводится только к их проверкам, только это планируется, только на это закладывается время и в общем-то только это от тестеров и ожидается. И когда вместо действительно тестирования, начинается погрязание в бесконечно дописываемых тест кейсах, их актуализации и попытках проверить всё ту их гору, которая образовывается.
И, кстати, не надо считать меня бахо-адептом, как Вы выразились. Это не мой случай, что я нашла его статью и открыла для себя исследовательский подход. Исследовательский подход - это то, к чему я сама шла и пришла, и своё виденье вырабатывала сама. Я была рада узнать, что есть в мире Джеймс Бах, проповедующий исследовательский подход. Я хочу досконально узнать, что именно преподаёт и предлагает его подход. Я хочу узнать, что я смогу добавить или улучшить в своём видении. Но если что-то из его подхода будет сильно противоречить моим убеждениям, и я не смогу с ним согласиться - я не слепой котёнок.
Я не считаю вас бахо-адептом. Сам я - бахо-адепт. Приходите в нашу бахо-церковь на бахо-служение бахо-подходу к тестированию :)
ОтветитьУдалитьЦитата: "Я не понимаю стремление описать каждый чих [...] Это просто бессмысленно в конце концов."
А я понимаю. Это ПОЛНОСТЬЮ зависит от контекста.
Трабла в том, что мы сейчас говорим общими словами про общий подход. Это все равно, что спорить о применении карри в кулинарии. Есть кухни, которые без карри не обойдутся. И наоборот. Поэтому говорить о тестировании ВООБЩЕ - сложно и муторно.
Насчёт описания "каждого чиха" - могу это понять разве что в контексте каких-либо исключительно высокорисковых приложений, типа медицинских или космических.
ОтветитьУдалитьВ целом же про спор - пожалуй, согласна.
Этот комментарий был удален автором.
ОтветитьУдалитьСразу оговорюсь, что я адепт тесткейсописания. :)
ОтветитьУдалитьЛена, есть определение такого рода деятельности как тестирование программного обеспечения - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. (IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004).
Основной упор делается на "проверка ... осуществляемая на конечном наборе тестов, выбранном определенным образом". Так что Вам не надо описывать каждый "чих", Вам надо выбрать только те "чихи", которых будет достаточно для получения необходимой информации о качестве реализации той или иной функции или приложения в целом. Для этого пишутся тест кейсы. Не волнуйтесь, все тестовые случаи Вам не описать - это не возможно из определения, но минимальный набор у вас должен быть. Пройдя все написанные кейсы, вы можете дальше развлекаться с Exploratory/Ad Hoc/Freestyle testing. В любом случае в этом бесконечно увлекательном процессе, вы будете ограничены такой мелочью, как бюджет проекта. Поэтому у вас может просто не хватить времени на проведение обширного исследовательского тестирования. Да и если вы напишите слишком много тест кейсов, вам тоже придется втиснуться в узкие временные рамки фазы тестирования. Поэтому надо просто понимать и знать, важность и приоритеты функций приложения. От этого будет зависеть сколько времени вы сможете потратить на её тестирование.
В конце хочу добавить, что "Серебряной пули" не существует.
Этот комментарий был удален автором.
ОтветитьУдалитьКак так - нет серебряной пули?
ОтветитьУдалитьА с чего я тогда сыкался в детстве, глядя на мерцающий экран с воющими оборотнями и глупыми людишками, которые лезут невооруженные в чащу темного леса?
Вот же "Серебряная пуля"!
Она есть!
;)
Потрясающе, комментарии в этот мой пост, кроме меня, пишут исключительно Алексеи! :)
ОтветитьУдалитьАлексей (который Булат), спасибо за высказанное мнение. На самом деле очень интересный вопрос - это как раз соотношение скриптового и исследовательского в тестировании каждого отдельно взятого проекта. Кстати, при ограниченных сроках (бюджете), если основной целью является именно качество, то исследовательский подход (в хорошем его исполнении) имеет высокие шансы быть более эффективным.
Кстати, насчёт приведённой Вами цитаты («Основной упор делается на "проверка ... осуществляемая на конечном наборе тестов, выбранном определенным образом"»): замечательно, но кто сказал, что это обязательно предварительно описанные тесты? :)
А вот с такой постановкой вопроса - «Пройдя все написанные кейсы, вы можете дальше развлекаться с Exploratory/Ad Hoc/Freestyle testing» - позволю себе категорически не согласиться. Исследовательское тестирование - это не игрушка на подхвате, когда делать нечего. Это мощный и эффективный подход сам по себе, а не вспомогательное средство к скриптовому подходу.
Лена, разделю ответ на несколько блоков!
ОтветитьУдалитьБЛОК 1.
1. сколько у вас человек в команде тестирования?
2. размеры проекта?
3. длительность проекта (уже прошло времени с начала и сколько планируется в будущем)?
--------------------
1.
- если вы одна тестируете приложение - забейте на тест кейсы, делайте как вам удобнее. Главное, следите, чтобы проектная документация, на основании которой вы проводите тестирование, находилась в надлежащем состоянии.
- если у Вас команда, то извините - шарить знания и контролировать процесс тестирования просто придется, а без кейсов это сделать очень сложно.
2.
- Если проект - 10 страниц и 5 форм ввода, т.е. мелкий - забейте на кейсы, напишите простые чеклисты.
- Если проект средний, то тут я бы порекомендовал вам писать кейсы, хотя, чеклистами тоже могут сработать.
- Если проект большой, то тут, мне кажется,без кейсов не обойтись.
и т.д.
3.
- Если до конца проекта осталось не много времени (1-2 месяца), а прошло уже пол года-год, то смысла начинать их писать нет.
- Если проект только начался и рассчитан на срок более полугода, то лучше писать тест кейсы.
и т.д.
--------------------
БЛОК 2.
Предусловие - вы используете ЕТ.
1. у вас спросили, за сколько вы протестируете форму логин на сайте mail.ru? - дайте точное кол-во дней, часов, минут.
2. на основании чего вы сделали свои оценки времени?
3. вы уверены, что из версии к версии вы будете проверять одни и те же правила и ничего не упустите?
4. на основании чего вы будете делать оценку качества реализации формы логин?
идем дальше... вы уволились, на ваше место пришел другой, не такой опытный как вы работник...
- что ему после Вас останется?
- вы уверены, что он будет тестировать также хорошо как и вы?
- кто пострадает, если он окажется менее изощренным "исследователем" чем вы?
-------------------
Алексей, не хочу повторять то, что уже было написано в комментах выше, поэтому кратко - мы тут уже говорили на тему того, что лучше всего 2 подхода каким-то образом комбинировать. Так что мы всё-таки не говорим о ситуации полного отсутствия описанных тест кейсов.
ОтветитьУдалитьНасчёт восприятия тесткейсов как отправной точки для проверок - я бы слегка возразила. Если я приду как новый тестер на какой-то проект, то скорее всего я не буду воспринимать старые тесткейсы как однозначную основу для своего тестирования. Тесткейсы писались людьми, в них тоже могут быть ошибки. Так что в смысле «наследства» меня лично гораздо больше интересует наличие нормальной документации по проекту. Хотя признаю - определённый смысл в передаче знаний через тест кейсы есть. Правда вот только что ещё пришла в голову мысль: раз уж приходит новый человек на проект, то это же возможность получить свежий взгляд на наши старые проблемы! Дадим ему старые тест кейсы - и толку от этого свежего взгляда. Пусть лучше покопается в документации и приложении, и с большой вероятностью увидит то, чем люди до него не видели.
Что касается ваших вопросов по поводу величины проекта, то скажу так: мой опыт более всего связан с проектом очень большим и очень продолжительным, как раз по мелким проектам опыта у меня не слишком много. Так что я являюсь сторонницей исследовательского подхода не потому, что я работаю в основном с мелкими проектами. Но может как раз потому, что с мелкими почти и не работаю :)
Извините, за настойчивость, не нашел ответы на вот эти вопросы:
ОтветитьУдалитьПредусловие - вы используете ЕТ.
1. у вас спросили, за сколько вы протестируете форму логин на сайте mail.ru? - дайте точное кол-во дней, часов, минут.
2. на основании чего вы сделали свои оценки времени?
3. вы уверены, что из версии к версии вы будете проверять одни и те же правила и ничего не упустите?
4. на основании чего вы будете делать оценку качества реализации формы логин?
Эх, и хотелось убежать от этих вопросов, да не удалось…
ОтветитьУдалитьХорошо, понятия не имею, за сколько я протестирую эту форму, хотя бы потому, что не знаю требований к ней и не имею практически ни малейшего опыта в тестировании подобных форм (но догадываюсь, что формы логина, да ещё и на веб-странице - штука весьма специфическая для тестирования).
Если бы я действительно взялась за такую работу, то думаю, что для начала выяснила бы все требования к этой форме и заказываемому тестированию, а также порылась бы основательно по всем доступным источникам, чтобы выяснить, на что стоит обращать внимание при тестировании подобных вещей. И моя оценка, уж коли бы я могла её дать, базировалась бы на полученной информации.
Отлично, вы запинали меня ногами и доказали, что я не могу ответить на ваши вопросы. Так что расскажите, пожалуйста, к чему были ваши вопросы об оценке времени?
Так, дальше. Хорошо, ещё раз повторю, что не проповедую чистый ЕТ подход, поэтому признаю использование тест кейсов как раз в первую очередь для регрессионного тестирования (см. комментарии выше). Поэтому по п.3 для регрессионного тестирования я бы либо использовала действительно написанные тест кейсы, либо какой-то контрольный лист с теми пунктами, которые необходимо проверять - это зависит от длительности проекта и от требований, предъявляемых как к самому проекту, так и к его тестированию. Думаю, что в данном случае я бы предпочла какой-то контрольный список для проведения своих тестов, если бы не выяснились какие-то очень сложные ситуации для проверки, которые было бы целесообразно подробно описать в тест кейсах.
Оценку качества я бы давала на основании соответствия тем требованиям, которые бы я выяснила. А соответствие бы я выясняла на основании тестов, которые бы я посчитала целесообразным проводить для проверки этих самых требований.
Теперь можете меня добивать :)
Лена, никто не пытается вас сбить и добить...
ОтветитьУдалить(сорри за интервенцию)
Алексей, спасибо за интервенцию :)
ОтветитьУдалитьНаверное, это только из-за моего чересчур живого воображения мне показалось, что Алексей Булат устроил мне допрос с пристрастием, позвякивая виртуальными инквизиторскими инструментами... %)
Лена, я не в коем случае не пытался вас добить или обидеть. Своими вопросами, я хотел показать, что при использовании чистого ET очень сложно давать какие-то оценки, будь то времени, будь то качества. Все будет базироваться лишь на субъективном мнении исполнителя. А для управления процессом тестирования - это ЗЛО.
ОтветитьУдалить---------------------
Как бы ответил на вопросы я (я не говорю, что так надо, я говорю, что я бы так делал)
1. у вас спросили, за сколько вы протестируете форму логин на сайте mail.ru? - дайте точное кол-во дней, часов, минут.
- анализ требований (если они есть).
- немного подумав оценил бы кол-во тест кейсов для прохождения, (допустим 20)
- предположим, из расчета 5 минут на тест кейс получим 5*20 = 100 минут чистого времени.
- добавил бы 30 минут на написание баг репортов
- итого ~130 минут - грубая оценка времени чисто на тестирование без подготовки данных
2. на основании чего вы сделали свои оценки времени?
- на основании тестовых случаев.
3. вы уверены, что из версии к версии вы будете проверять одни и те же правила и ничего не упустите?
- при использовании тест кейсов - ДА
4. на основании чего вы будете делать оценку качества реализации формы логин?
- на основании сформулированных критериев качества, где результаты прогона тест кейсов являются одним из ключевых параметров.
---------------------
Лена, можете сформулировать критерии качества продукта, который вы тестируете?
Алексей, такая уверенность в том, что совершенно ничего не будет упущено при дизайне тестов до начала тестирования - это просто поразительно. Создаётся впечатление, что вы полностью уверены в том, что вы способны предусмотреть абсолютно всё заранее. Нет никаких рисков и никаких непредвиденных ситуаций. И в результате получение абсолютно чётких инструкций с запланированным временем, просчитанным до минут. Просто потрясающе.
ОтветитьУдалитьПроблема только в том, что весь мой опыт говорит о том, что таких идеальных ситуаций просто не бывает (если не говорить об очень примитивных случаях, о которых я знаю очень мало). А полное предусматривание всего заранее - это просто фантастика, если не обладать настоящим даром предвиденья.
Вы говорите о тест кейсах как об одном из ключевых параметров при оценке качества. Наверное, это очень удобно. Но если все тест кейсы успешно пройдены, а вылезли другие ошибки (допустим. в результате эксплуатации) - то разве это качество? Если в критериях качества определено, допустим, дополнительно отсутствие ошибок высоких приоритетов, то как написанные заранее тест кейсы гарантируют отсутствие этих самых ошибок?
Думаю, что качество - это не договорное понятие. И боюсь, что никакое тестирование не может гарантировать стопроцентное качество.
Скорее можно вести речь о критериях приёмки тестирования и продукта, как раз и закреплённых какими-то договорными обязательствами.
Те критерии качества, о которых вы спрашиваете (если я правильно понимаю), я могу сформулировать только в достаточно упрощённом виде, от которого я могу отталкиваться в своей работе - это соответствие приложения предъявляемым к нему требованиям. И проверка этого соответствия - это для меня гораздо больше, чем следование единожды написанным инструкциям.
Боюсь высказать крамольную мысль, за которую меня точно по головке не погладят, но тем не менее: я опасаюсь, что базирование тестирования исключительно на тест кейсах - это в большой степени способ снятия с себя ответственности и способ угождения существующей схеме руководства, и в гораздо меньшей степени - забота о действительном качестве продукта.
Молодец, Лена! :)
ОтветитьУдалитьАлексей, видеть от вас похвалу, безусловно, очень приятно. Знать бы ещё, чем именно я её заслужила :)
ОтветитьУдалитьКрамольной мыслью в последнем абзаце :)
ОтветитьУдалитьОтвечу Лупану, потому что с Булатом Лена пока сама замечательно справляется :)
ОтветитьУдалитьПричём ответ будет немножко в стиле "бей своих чтоб чужие боялись" :)
1. Алексей, в твоих словах содержится противоречие.
Вот первая цитата:
>> "Каждый тестировщик со временем приходит к пониманию того, что тест-кейсы (скрипты, если угодно) писать надо, даже если очень не хочется и скучно."
А вот вторая:
>> "Так дети учатся в школе рисовать идиотские палочки и загогулинки (я в детстве ОЧЕНЬ не понимал, зачем это все нужно). Но после загогулинок начинаешь рисовать отдельные буквы. А буквы складываются в слова. Владеющий техникой комбинирования слов уже может делать всё, что угодно."
Думаю, что ты сам его видишь.
2. Цитата:
>> "Чтобы ответить на этот важный вопрос [не ишпортилься ли осноффной функсиональ посля измененьий], надо иметь список того, что мы ОБА подразумеваем под основным функционалом. А чтобы оба подразумевали, что и как в этом функционале работает, мы должны иметь список требований. А чтобы мы оба подразумевали, что проверка этого функционала подразумевает проверку того-то и этого-то таким-то образом, надо надо положить на стол тест-кейсы. Тест-скрипт. Must have."
Это не является цепочкой логических следствий.
Чтобы иметь единое представление о том, что такое основной функционал, не обязательно иметь список, но допустим это в качестве посылки. Чтобы понимать, как и что в этом функционале работает, тоже не обязательно иметь список требований, но допустим и это тоже в качестве посылки.
А вот дальше логика нарушена -- тест-кейсы или скрипты, оставшиеся с прошлого раза, могут оказаться совершенно бесполезны, если не принимать во внимание того, какие именно изменения внесены. А если принимаем во внимание -- начинается тест-дизайн, мы строим новые тесты с учётом новой информации. Ну или как минимум готовим новые тестовые данные, что тоже тест-дизайн в не меньшей степени.
Давайте рассмотрим пример -- текстовый редактор, аля Блокнот. Есть функционал открытия файла. Приходит релиз -- в нём по заявлению разработчиков произведена оптимизация, ускорена загрузка файлов. Какие тесты надо сделать? Попробовать загружать файлы разного размера, с разных файловых систем, в разной кодировке и т.п. Следующий релиз -- улучшили юзабилити, добавили шорткаты. Выполняем тот же сценарий, но открываем один и тот же файл, обращая внимание на то, есть ли на всех кнопочках и менюшках шорткаты.
Вопрос -- что из этого должно было быть записано заранее, до появления обоих этих релизов? И что из этого окажется полезным, когда придёт следующий релиз, в котором будет реализовано пока неизвестно что?
Резко поворачивается к Лене и образует с ней подпольную, противоречивую, но действующую коалицию супротив
ОтветитьУдалить- приходящих,
- бьющих,
- пинающих,
- а затем - подпрыгивающих на поверженных супостатах...
>> А я не увидел баг, не понял, что это баг - просто потому, что не знал. Ибо не посмотрел на требования, которые, как мне сказали, есть на внутренней вики, но они давно устарели :)
ОтветитьУдалитьЧто значит не посмотрел на требования? Это тебя Бах научил, что НЕ НАДО СМОТРЕТЬ НА ТРЕБОВАНИЯ? Наоборот! Это те, кто рекомендует тестировать по заранее заготовленным скриптам, часто говорят, что достаточно смотреть на эти скрипты и всё. Ну и если там ничего не написано про зелёный фон -- виноват будет не тестировщик, а тот, кто утвержил когда-то давно эти скрипты. Очень удобно, ага.
>> Не придумываются на ходу :) Они придумываются заранее, исходя из цели, которую надо достичь, и корректируются на ходу.
Тесты именно придумываются на ходу. Вот цели -- да, цели придумываются заранее. Тесты придумываются на ходу, и по мере выполнения каким-то образом результаты фиксируются. А затем определяется, удалось ли достичь поставленных целей.
>> Например, грозит нам поход в магазин. Жена записала: взять
ОтветитьУдалить- колбасу "Молочная",
- яйца,
- лук.
>> А если не будет в магазине колбасы "Молочная", но будет "Краковская". Что делать? Звонить жене и сказать, что есть "Краковская"?
ДА!!!! :)
Отличный пример, давайте его разберём, потому что тут замечательно можно увидеть распределение ролей.
Давайте попробуем спроектировать ЗАРАНЕЕ свои действия по походу в магазин.
1) Всё есть -- покупаем, возвращаемся домой.
2) Нет "Молочной", но есть "Докторская" -- покупаем её взамен, возвращаемся домой
3) Нет "Молочной", но есть "Краковская" -- ??? (спросить жену, брать или нет, и если не брать, то что делать)
4) Нет "Молочной", но может быть есть в другом магазине -- ??? (спросить жену, сходить в другой магазин или нет)
5) С колбасой порядок, но нет лука -- ??? (спросить жену, можно ли обойтись без лука)
6) Всё есть, но лук только зелёный, репчатого нет -- ??? (спросить жену, годится ли на замену)
7) ...
Так... Мы всё ещё в магазин не ушли, сидим и пишем возможные варианты развития событий. Жена говорит -- эй, давай, пора уже идти. Но нельзя! Мы идём к ней и начинаем спрашивать по списку -- что делать в том или ином варианте. Что она скажет? Двигай уже в магазин, там на месте разберёшься, если чего-то нет -- позвони! Ей не нужна гипотетическая информация, ей нужна реальная колбаса или реальная информация о том, что её нет, и реальная информация -- а что есть? На основании этой информации она сможет принять решение -- вплоть до "забей на колбасу, бери курицу и возвращайся домой". Вот уж этого вы точно заранее не предскажете! Потому что у неё есть цель -- приготовить ужин, и планируя разные действия, связанные с рисками возможного отсутствия колбасы вы занимались ерундой, вместо того, чтобы просто пойти в магазин и посмотреть, есть она или нет.
Ох и спасибо за поддержку!.. А то, кажется, я уже начинала выдыхаться... :)
ОтветитьУдалитьС удовольствием прочитал все обсуждение.
ОтветитьУдалитьИ все-таки из анализа куда-то делся такой интересный аргумент как планирование. Ведь у тесткейсописательства и у всей остальной бюрократии ноги растут именно оттуда.
> Вы говорите о тест кейсах как об одном из ключевых параметров при оценке качества.
ОтветитьУдалить- Лена, давайте читать внимательно: "на основании сформулированных критериев качества, где результаты прогона тест кейсов являются одним из ключевых параметров." Не тест кейсы - параметры, а результаты их выполнения.
> Если в критериях качества определено, допустим, дополнительно отсутствие ошибок высоких приоритетов, то как написанные заранее тест кейсы гарантируют отсутствие этих самых ошибок?
- Тест кейсы не панацея от всех болезней. Все не протестируешь, все баги не найдешь. Тест кейсы должны покрывать основаную функциональность, т.у. ту, которая 100% обязана работать. Все остальное - это полет фантазии тестировщика, т.е. ET. Именно поэтому мы и имеем в рузультате не 100 кейсов для формы из 5-ти полей, а всего 5-10.
--------
В компании, где я раньше работал было правило "нашел багу по время свободного тестирования - напиши и баг репорт и тест кейс". Таким образом увеличивался набор регрессионных тест кейсов и контролировалось появление старых дефектов.
--------
А вообще, Лена, у меня складывается такое чувство, что мы с Вами говорим на разных языках. Вы говорите как исполнитель - тестировщик, я как руководитель. Мне от вас нужны цифры: время для планирования, и результаты (сколько тест кейсов пройдено, сколько passed, сколько failed, кол-во багов) для того, чтобы сделать выводы. А все что вы мне сможете конкретно сказать - это кол-во найденных багов, а этой информации мне просто не достаточно.
И еще, вы писали "тестирование - это захватывающий интеллектуальный процесс?! " - Согласен с каждым словом, но вот только в этом всем есть своя лока дегтя - тестирвоание это рутина, от которой не уйти, и написание и прохождение тест кейсов - одна из таковых.
"Кончаю! Страшно перечесть...
Стыдом и страхом замираю...
Но мне порукой ваша честь,
И смело ей себя вверяю... " А.С. Пушкин
Uladzimir, +1
ОтветитьУдалитьВ одном из своих постов (23 марта 2010 г. 18:13) я пытался затронуть эту тему, но видимо ораторского искусства не хватило поставить акцент!
Алексей (Булат), насчёт Вашего уточнения («Не тест кейсы - параметры, а результаты их выполнения.»): да, я поняла суть, просто выразилась не совсем корректно, прошу прощения. Однако суть моего комментария это не меняет.
ОтветитьУдалитьТеперь что касается нашего расхождения во взглядах, в смысле точек зрения исполнителя и руководителя. Снова возражу по поводу того, что после исследовательского тестирования остаются только отчёты о найденных ошибках. Хороший тестер способен чётко обрисовать, что именно он тестировал, протестировал, каковы результаты его тестирования, а также то, что ему ещё предстоит протестировать. Целесообразную отчётность ещё никто не отменял. И не считаю, что это вариант хуже, чем название тест кейса, возле которого будет стоять резолюция «ок» или «не ок».
Владимир, добро пожаловать, вы первый НЕ Алексей в этом обсуждении (кроме меня) :)
ОтветитьУдалитьПо поводу планирования тут всё в общем-то крутилось, только может конкретно слово «планирование» не называлось.
Если не повторять всего того, что уже было сказано выше, то выдам ещё одну крамольную мысль (продолжение той, что была уже высказана): может быть, стоит смысл задуматься о том, чтобы поменять отношение к планированию и саму форму планирования, если эффективное тестирование в него так плохо вписывается? :)
А ещё позволю себе привести вольный перевод слов Джеймса Баха, которые он написал во время моей с ним короткой переписки:
«Много критики исследовательского тестирования на самом деле исходит от людей, которые по каким-то причинам не видят плохое тестирование в скриптовом подходе, который они так любят»
По-моему, это мысль, о которой стоит задуматься.
Лена, трудно с вами не согласиться, так как тайм-матириал проекты и есть такой "альтернативный подход" к планированию. Однако, не секрет, что такие проекты не поддаются оценке, так как в начале проекта имеется только общее представление о конечных результатах и весьма общее - о конечной стоимости. К сожалению, не все заказчики достигли такой же степени просветления сознания и продолжают задавать вопросы о конечной стоимости в начале проекта. :)
ОтветитьУдалитьПростите, в своем последнем наезде черт попутал:
ОтветитьУдалить"In freestyle exploratory testing, the only official result that comes from a session of ET is a set of bug reports.", тогда как при "Session-Based Test Management" все намного формализованнее. :) Век живи век учись...
Вообще я хотел спросить у Вас, Лена:
вы пишите, что "для себя лично я считаю оптимальным комбинирование двух подходов", однако в штыки воспринимаете любую фразу о пользе тест кейсов. (по крайней мере мне так показалось и немного возмутило, видимо из-за этого я насел на Вас с глупыми вопросами) Может вам следует все таки сказать вслух - что вы приверженец именно Исследовательского тестирования?
Алексей, мне жаль, если Вам показалось, что я вообще в штыки воспринимаю идею использования тесткейсов. Даже в исходном посте я писала: "Конечно, в определённой степени предварительное написание тест кейсов уместно..."
ОтветитьУдалитьВ штыки я воспринимаю идею работать ТОЛЬКО по ним, а также плохо реагирую на идею не воспринимать всерьёз исследовательское тестирование, т.е. рассматривать его как что-то вспомогательное, когда делать больше нечего :)
А так - я не отрицаю пользу от написанных тест кейсов, я даже совсем не отрицаю использование автоматизации тестирования (отдельная для меня тема), я просто очень хочу, чтобы исследовательский подход занял своё достойное место под солнцем :) Я знаю, что он очень эффективен. Я в значительной степени работала и работаю так. Как тестера, меня интересует качество, и поверьте - исследовательский подход может быть очень хорош в этом.
Владимир, и мне трудно с вами не согласиться :)
ОтветитьУдалитьНа самом деле я ведь отлично понимаю, что существует огромное количество вопросов, на которые на данный момент я лично ответов не знаю. Именно поэтому я сейчас стараюсь изучить то, что наработал Джеймс Бах и его единомышленники, в надежде, что какие-то ответы можно найти там. Ну и, разумеется, пытаюсь и сама для себя что-то решить, понять, обдумать и свести концы с концами.
Кстати, я очень признательна всем, кто принимал участие в этой дискуссии - за то, что поднимались неудобные вопросы, потому что это всё - направления, в которых надо копать и думать.
Но в чём я твёрдо уверена - это в том, что исследовательский подход имеет свои огромные плюсы, и не стоит отмахиваться от него просто потому, что он не вписывается сейчас в какие-то привычные схемы. Возможно, надо действительно поменять всю культуру тестирования и разработки ПО, чтобы исследовательское тестирование было действительно признано, и с большой вероятностью это может быть изменением к лучшему.
Сегодня ехал на работу и задумался над соотношением тестирования по кейсам и исследовательским... Со мной все ясно, я ЕТ рассматриваю как вспомогательный подход, у Вас все наоборот.
ОтветитьУдалитьНе могли бы вы поделиться Вашим видением комбинирования при использования тест кейсов и ЕТ?
P.S. мой "наставник" по тестированию учил меня "Всегда и во всем сомневайся. Верить нельзя никому, только себе. Доверяй, но проверяй." И я честно выучил эти уроки. Теперь, когда моя команда пишет тест кейсы, для меня все предельно просто - сделал ревью, нашел, что забыли или пропустили, добавили кейсы. Таким образом я отслеживаю, что было пропущено. При исследовательском тестировании, я честно не знаю как проконтролировать, что было проверено, что не было. Если же во время ЕТ вести лог проведенным тестам, то вы результате можно будет посмотреть, что было упущено из виду. НО - это уже будет ПОСЛЕ проведенного тестирования. Я же считаю, что багу надо найти как можно раньше. Для этого и пишу кейсы. (на P.S. можно не отвечать, я всего навсего раскрыл карты...)
Лена, спасибо Вам за пост. Я также рад найти единомышленников :)
ОтветитьУдалитьСчитаю, что метод исследовательского тестирования просто необходим, как и тестирование по тест кейсам. Разделять их ни в коем случае нельзя (как и было озвучено ранее в этой дискуссии).
Тестирование по тест кейсам необходимо как основа. Оно позволит дать информацию о стабильности системы, необходимо в тестировании на регрессии, поможет в планировании тестов.
Скриптовое тестирование - это своего рода костяк, который необходим. К тому же его тестирование можно автоматизировать!
Естественно, что всего не покроешь тест кейсами. И здесь как раз необходимо исследовательское тестирование. Вопрос в том как их сочетать? Либо проводить отдельной таской после основного теста (по тест кейсам), либо сочетать с ним. Т.е. в процессе прогона тест кейсов, мне могут в голову прийти идеи, как еще "сломать систему" - здесь я или запишу эту идею на бумажку и проверю потом, или проверю в рамках основного теста (в таком случае нужно планировать время соответственно).
PS) очень интересно было бы почитать о планировании времени на тесты ;). Как оно проводится, какие подводные камни и т.д.
Надеюсь, что те, кто тут писал о том, что они умеют планировать время на тестирование, читали вот эту статью:
ОтветитьУдалитьhttp://software-testing.ru/library/testing/general-testing/911-why-is-testing-taking-so-long
(безумный день - поздние комменты, сорри)
ОтветитьУдалитьАлексей (Булат), моё виденье в общих чертах примерно такое: тестирование начинается и в основном ведётся именно как ЕТ; тест кейсы же используются в основном как контрольные тесты для нужд регрессионного тестирования; причём не обязательно, как я говорила раньше, что они пишутся именно заранее, поскольку после реального знакомства с приложением (т.е. не только по документации) тесты могут быть описаны более адекватно. Причём понятно, что во время тестирования ЕТ всё равно проверяется весь основной функционал, который описывается в тест кейсах.
И всё-таки небольшой комментарий по поводу Вашего постскриптума - по поводу доверия (хоть может и чуть в другую степь). Как я Вас понимаю! :) Но вот что я вроде как для себя поняла, это то, что я либо человеку доверяю, либо не доверяю. И вот если НЕ доверяю, то у меня нет никакой уверенности в том, что тест выполнен хорошо, пусть он хоть трижды описан. Так что тут лично для меня есть ещё большой вопрос выбора «правильных» людей, но это отдельная большая тема.
И вот ещё какой момент: когда речь идёт о большом проекте типа моего, когда знать его в принципе весь невозможно в деталях, вопрос контроля становится вообще очень сложным.
SpooNesT, спасибо за комментарий. Своё виденье в общих чертах я описала в предыдущем комментарии - в ответе Алексею.
ОтветитьУдалитьНасчёт планирования: честно - мне тоже очень интересно про это почитать :) Для меня это сложная тема (как и очень многие другие). Для меня она сложная даже в том случае, если говорить про чистый скриптовый подход. Я даже хронометражем баловалась, чтоб выяснить, сколько надо времени на прогон этих самых тест кейсов, только это всё равно не слишком сильно помогает. Я надеюсь ещё как-нибудь поднять тему планирования, чтобы люди, опытные в этом деле, что разумное подсказали (вообще у меня большой список того, с чем я ещё хочу разобраться :) ).
А пока я собираюсь как минимум прочитать ту статью про время на тестирование, которую подбросил Алексей Баранцев, за что ему, кстати, большое спасибо :)
Похоже, я один придерживаюсь радикальной точки зрения, что заранее писать тестовые сценарии нет смысла. Впрочем, задним числом тоже нет смысла писать.
ОтветитьУдалитьДаже товарищи, признающиеся в бахо-адепстве не рискуют полностью отказаться от этого пагубного пристрастия, а? ;)
Ну, наверное, я трусиха - чтобы признаться :)
ОтветитьУдалитьНа самом деле я всё-таки вижу какой-то смысл в написанных тест кейсах, именно для проверки основных моментов при проведении регрессионного тестирования (особенно для сложных расчётных случаев), и как основу для автоматизации. Последнее - это скорее моя мечта, потому как пока что достаточно успешных опытов не было. Но на данный момент я считаю, что именно для целей автоматизации, чётко описанные тестовые сценарии необходимы.
я считаю, что именно для целей автоматизации, чётко описанные тестовые сценарии необходимы
ОтветитьУдалитьДа, это одно из заблуждений, присущее тем, кто приходит в автотестирование из ручного тестирования, но зато ему практически не подвержены автотестеры, пришедшие из программистов.
Автотест -- это программа. В наши дни никто не пишет программы, сначала описывая на бумаге алгоритм или какие-то отдельные фрагменты -- сценарии работы программы. Ну или если даже и описывает, то чисто для себя, как черновик -- почеркалн на бумажке, понял, как это программировать, и выкинул бумажку.
Потому что проще это сразу написать в коде. Потому что всё равно это будет делать один и тот же человек, нет как раньше разделения на алгоритмистов и кодеров. Потому что архитектура важнее отдельно взятого сценария.
На самом деле я всё-таки вижу какой-то смысл в написанных тест кейсах, именно для проверки основных моментов при проведении регрессионного тестирования (особенно для сложных расчётных случаев)
ОтветитьУдалитьСложные случаи должны быть где-то описаны, согласен. Но почему в тестовых сценариях? Почему не в каком-либо документе, который используется совместно аналитиками, разработчиками, тестировщиками и всеми прочими. Неужели только тестировщикам это важно?
А если это описано, скажем, в спецификации или техническом задании -- зачем это переписывать ещё раз в тестовых сценариях?
Насчёт автоматизации:
ОтветитьУдалитьТут и спорить не возьмусь, потому как в данной области у меня в основном только теоретические предположения. Из своего бедного опыта только такой пример приведу в защиту того, что я высказала: было время, когда на проект нам выделили программиста, чтобы он автоматизировал то, что мы (тестеры) сочтём необходимым. Так вот, мы ему предоставляли чёткий сценарий - что должно быть сделано. А он только программировал. Так, вероятно, сейчас тоже работать не принято? :)
Насчёт сложных расчётов:
В спецификациях и т.п. у нас на проекте - расписаны только алгоритмы расчётов. Сразу оговорюсь, что это не просто расчёты множества чисел, это ещё и очень сложная бизнес-логика. В тест кейсах же - конкретные проработанные примеры, по которым можно выполнять проверки, не надрываясь снова на всех сложностях расчётов. Вот при всей моей нелюбви к тест кейсам - это те случаи, когда я действительно выполняю проверки по ним. Конечно, приходится и тут временами что-то перепроверять и надрываться. Но при отсутствии изменений именно в этих областях приложения перед выпуском очередного релиза - можно себе позволить проверять именно по этим тест кейсам (именно эти расчёты).
Кстати, что касается общедоступности подобных примеров - у нас на проекте тест кейсы именно общедоступны: для аналитиков, для тестеров, для программистов (если бы последние захотели туда полезть).
P.S. Алексей, что Вы со мной сделали? Я защищаю написание тест кейсов?! :)
Алексей, вопрос к вам - как вы представляете себе тестирование без предварительных сценариев на проекте с не очень опытной командой тестировщиков, которые еще не умеют компилировать спецификацию в тесты "на лету", добавляя по вкусу современных подходов и методик? Это реальная ситуация с которой мне приходилось сталкиваться, и, боюсь, я в этом не одинок. Есть конечно очевидные варианты: обучать - но это займет время и не позволит быстро сделать проект, либо нанимать только профессионалов - но это не всегда возможно и сильно поднимает конечную стоимость проекта.
ОтветитьУдалитьЗаранее придуманные сценарии позволяют быть более-менее уверенным, что человек по крайней мере проверит все было описано в сценарии.
ОтветитьУдалитьИ еще чуть-чуть уточню свою позицию: я не пытаюсь сказать что подход без тестовых сценариев неприменим, я хочу сказать что это просто еще один метод, который имеет смысл использовать если он будет эффективен в конкретных условиях проекта. Т.е. я не буду называть себя ни адептом, ни приверженцем чего-либо.
ОтветитьУдалитьПрофессиональный плотник не будет доказывать что рубанок лучше стамески. Он знает что этими инструментами можно и нужно делать разные вещи. Хотя они и взаимозаменяемы в определенных случаях :)
Владимир, а вот тут я возражу Вам: на мой проект постоянно брались люди вообще без какого бы то ни было представления о тестировании. И поверьте, при правильном объяснении сути тестирования (громко сказано, но тем не менее) - они отлично начинают работать по требованиям с приложением. Мне кажется, что лучше сразу учить думать, чем подсовывать готовые тест кейсы.
ОтветитьУдалитькак вы представляете себе тестирование без предварительных сценариев на проекте с не очень опытной командой тестировщиков
ОтветитьУдалитьДавайте предположим, что у нас есть:
1) один опытный тестировщик Джон, который с одной стороны знает продукт, а с другой стороны умеет проектировать тесты,
2) несколько (трое) человек, которые обладают достаточной компетенцией, чтобы выполнить подготовленный кем-то другим сценарий.
Предположим, что выполнение типового сценария у не записывая занимает у Джона 1 минуту, а чтобы записать этот сценарий с нужной степенью подробности у него уходит 5 минут. Его (гм...) коллеги способны выполнить созданный им сценарий за 2 минуты.
Джон начинает работать. За час он может написать 12 сценариев и отдать их выполнять другим -- втроём они сделают это за 8 минут, а потом будут страдать ерундой, потому что сценарии кончились. Либо за тот же час он может выполнить 60 тестов самостоятельно. Разница -- в пять раз.
Выполняя тесты сам, Джон замечает разные странности, потому что он знает продукт, и фиксирует баги, придумывает новые тесты, уточняет своё понимание сути вещей. Трое его (гм...) коллег ничего этого не замечают, не предоставляют ему эту информацию -- в итоге никто не заводит баги, не придумывает новые тесты, не развивается. Баги уходят в продуктив (в том числе те, которые он мог бы найти, выполняя дополнительные 48 тестов).
Иными словами, на первой итерации эти трое только мешают Джону тестировать, а вовсе не помогают. Их производительность вчетвером в пять раз ниже, чем у Джона, если бы он работал один и выполнял тесты вместо того, чтобы их писать! Не хотите обучать этих троих -- ну так увольте их, пусть не мешают работать.
А, ну да, через пять-шесть, ну максимум десять итераций затраты на разработку сценариев окупятся. Может быть. Но примерно через столько же итераций окупаются расходы на автоматизацию. И инструмент будет работать быстрее и надёжнее этих трёх бездельников. Опять же уволить -- ведь программировать они поди-ка тоже не умеют?
Биороботы -- дорогое удовольствие.
Лена, это один из двух ответов, которые я ожидал услышать. Вы действительно можете гордиться таким проектом, и благодарить тех, кто подбирал вам кандидатов.
ОтветитьУдалитьНо давать оценку всем существующим проектам исходя из такого опыта я бы не стал, как я уже писал есть и другие примеры.
Алексей, это второй очевидный ответ :)
ОтветитьУдалитьЯ могу долго обсуждать границы применимости автоматизации тестирования, так как вплотную занимаюсь ей последние годы и - да, я с вами полностью согласен насчет этого подхода, но есть деталь, оставшаяся за кадром - это еще один Джон который пишет автотесты, назовем его Билли. А его найти еще сложнее чем Джона-2 в помощь Джону. И стоить он будет дороже :)
Ох, Владимир, было бы чем гордиться… И людей я в последнее время подбирала себе сама, и это ещё та проблема. Проблема в том, что те, кто смог работать, как я описала, - они как угодно могут работать. А те, кто не смог (а были и такие, что скрывать-то) - они не могут и по тест кейсам толково работать.
ОтветитьУдалитьВы знаете, я даже Джеймсу Баху сама высказывала эту мысль - мол, такой подход в тестировании подходит не всем, и что некоторым, кажется, любая степень свободы вредит. Но он возразил мне, и я вынуждена была с ним согласиться, потому что это на самом деле это то, что я сама чувствую и думаю: а действительно ли тестеры те, кто не может работать не по написанному? И дело тут не в опыте.
Если знаете ответы -- зачем спрашивать :)
ОтветитьУдалитьЯ не считаю, что автоматизатора найти сложно, на рынке полно вполне приличных программистов.
Повторю вкратце суть.
1) Человек думает существенно быстрее, чем пишет. Поэтому искусственно органичивать скорость тех немногих людей, которые умеют думать, заставляя их писать тесты -- это крайне неэффективный способ их использования.
2) Медленные мешают работать быстрым. Ещё Брукс писал в мифическом человеко-месяце, что увеличение размера команды как правило приводит не к ускорению, а к замедлению. Вы заставляете эффективных работников обслуживать неэффективных, вместо того, чтобы напрямую получать от них результат.
Лена, я полностью согласен с вами на счет людей которые могут и не могут тестировать. Но вот так вот просто списывать со счетов опыт я бы не стал :) Это фактически ставит на один уровень человека, который прочитал книгу и человека у которого есть реальная практика работы. Я бы взял на работу последнего, а вы?
ОтветитьУдалитьНу и еще момент - вы же не станете утверждать, что после "объяснении сути тестирования" человек без опыта поднялся на ваш уровень и ему можно доверить все что угодно? ;)
Алексей, спасибо. Вашу точку зрения я понял :)
ОтветитьУдалитьвы же не станете утверждать, что после "объяснении сути тестирования" человек без опыта поднялся на ваш уровень и ему можно доверить все что угодно? ;)
ОтветитьУдалитьНадо доверять. Но надо и проверять. То есть -- контролировать результат и корректировать его в нужном направлении, а не пытаться выдать заранее заданные чёткие инструкции.
Коллеги, не забывайте, что тестирование методом свободного поиска -- это НЕ анархия, там тоже всё подчинено строгой дисциплине, контроль и учёт, а как же!
А вот не поверите, Владимир, - я иногда предпочту человека без опыта.
ОтветитьУдалитьКстати, если неопытный кандидат по своей воле книгу прочитал - значит, ему самому интересно. Хотя и если не читал книгу - это тоже ещё ничего не значит.
Да я вообще при оценке кандидата, наверное, ненормально пытаюсь его оценить.
Я давно поняла, что мне лично почти безразлично, знает ли он теорию какую-то, и в общем-то мне лично не слишком нравятся все эти подходы типа «протестируйте яичницу». Мне очень хочется понять, насколько человек способен работать без принуждения, насколько у него есть ответственность, насколько он способен думать самостоятельно - вот только как это оценить? У меня больше вопросов…
А сам опыт я ни в коем случае со счетов не сбрасываю, надо ж мне хоть какое-то основание, чтобы о себе как о тестере неплохо думать… :)
Лена, иногда и я предпочту. Но при прочих равных - возьму человека с опытом. Просто потому что это тупо сэкономит мне время на объяснение общих вещей в сотый раз, а также даст возможность обмена опытом. Я понимаю что вы тестировщик и ищете недосказанности и неточности, но попытайтесь увидеть проблему целиком - проекты и ситуации бывают разные.
ОтветитьУдалитьВыбирая один стандартизированный подход вы тем самым лишаете себя возможности получать преимущества остальных подходов. Алексей пытается доказать что есть "серебряная пуля", т.е. универсальный подход. А я - что есть здравый смысл. Т.е. всегда имеет смысл вначале подумать - а подходит ли та или иная методика к проекту, к заказчику, к модели разработки, имеет ли смысл выбрать что-то другое? Какие есть преимущества и недостатки? Что перевешивает? И логика и здравый смысл - именно ВАША логика и ВАШ здравый смысл - ключевые факторы в принятии решения.
Хочу согласиться с Владимиром, всему свое время или "каждой двери свой ключ".
ОтветитьУдалитьВы проповедуете такой гибкий подход, как ЕТ, но сами не можете принять, что гибкость именно в том, чтобы в нужный момент применить более эффективный метод.
Алексей пытается доказать что есть "серебряная пуля", т.е. универсальный подход.
ОтветитьУдалитьЭто где я предложил универсальный подход? И в чём он состоит?
Я сказал, что есть некоторые вещи, которые с моей точки зрения делать нет смысла. И попытался показать, что отказ от них приведёт к ускорению тестирования. Согласитесь, это ещё не тянет на "подход", и тем более на универсальный :)
Личные выпады про мою недостаточную гибкость пропустим. Потому что я-то как раз бывал и в той, и в другой ситуации, жизнь аутсорсера интересна и разнообразна, у каждого заказчика свои правила игры. Поэтому я могу сравнивать.
Я готов рассмотреть ситуацию, в которой написание тестовых сценариев для ручного выполнения ЗАРАНЕЕ, до начала тестирования, можно было бы считать более эффективным способом, чем не делать этого.
Дисклеймер. Алексей (Булат), Владимир, я не буду продолжать спор о том, лучше ET других подходов или хуже. Зато объясню, почему я начал с ответа Лупану, а не с возражений и объяснений, что ET это круто.
ОтветитьУдалитьУ меня нет цели и желания "обращать кого бы то ни было в свою веру". Я хочу помочь тем, кто сам стремится понять, в чём тут фишка и как это позволяет повысить скорость и эффективность тестирования. Я не буду стататься убедить вас, что надо срочно начать практиковать ET. Не хотите -- не надо. Но если захотите -- вэлкам, вот тогда я постараюсь помочь.
Честно говоря, не совсем понимаю, чем же заслужено обвинение в НЕгибкости. По-моему, все мои высказывания должны были говорить о том, что я именно стараюсь в любой ситуации исходить из контекста. Ну, если этого не заметно, то не представляю, как я могу оправдаться. Поэтому и не буду :)
ОтветитьУдалитьВладимир, про отсутствие опыта я ответила Вам именно так не потому, что везде ищу неточности как тестер. А потому, что я обжигалась на приёме на работу тестеров с опытом, и при этом получала часто потрясающие результаты от приёма на работу людей без опыта вообще. Я не пытаюсь противоречить только для того, чтобы противоречить. Я просто говорю про то, что получается из моего опыта. И я отлично понимаю, что универсальных рецептов нет.
ОтветитьУдалитьАлесей (Баранцев), пожалуй, Вы правы в том, что бесполезно пытаться «обращать кого-то в свою веру». Хотя временами очень хочется :) Я лично хочу хотя бы надеяться на то, что можно добиться, чтобы люди относились к ЕТ серьёзно.
ОтветитьУдалитьСудя по всему, что тут было высказано, мне ещё надо во многом разобраться с самой собой - во что я верю, во что я не верю, во что я боюсь признаться, что действительно верю :) И ещё пытаться разобраться с кучей вопросов - своих изначальных и в этой теме поднятых. Надеюсь, будет шанс ещё что-то обсудить.
Оформил свои размышления навеянные этой дискуссией у себя в блоге http://softqa.posterous.com/-vs-97
ОтветитьУдалитьС огромным удовольствием прочитал сию дискуссию, и просто хочется сказать спасибо всем участникам и Лене в особенности, как топик-стартеру.
ОтветитьУдалитьКачественная пища для размышлений...
:)
Алексей, большое спасибо за комментарий. Очень приятно знать, что поднятая тема (и дискуссия вокруг неё) кому-то оказалась интересной и заставила задуматься :)
ОтветитьУдалитьAlexei Barantsev комментирует...
ОтветитьУдалитьПохоже, я один придерживаюсь радикальной точки зрения, что заранее писать тестовые сценарии нет смысла.
25 марта 2010 г. 22:25
****************************
Нет, не один :) Ох, какой холивар я пропустил!
Жаль, что Вас тут не было :) Чем больше людей, тем больше мнений и интереснее дискуссия...
ОтветитьУдалитьЯ, кстати, никуда не ушел :)
ОтветитьУдалитьАлексей (Булат), я что-то почувствовала себя плохой хозяйкой, которая оставила в одиночестве пришедшего гостя :) Но мне показалось, что дискуссия сошла на нет.
ОтветитьУдалитьПоследние обвинения в негибкости меня действительно удивили, потому что отталкивание от контекста - оно действительно основополагающее в ET (насколько я понимаю), и в моей практике тоже. В собственной практике, кстати, может даже слишком много гибкости временами, которая порой больше прогибание в плохом смысле, что явно не является предметом моей гордости. Но если вы под отсутствием гибкости подразумеваете нежелание согласиться с тем, что в некоторых случаях чистый скриптовый подход будет наиболее эффективным (с точки зрения качества, а не с точки зрения менеджмента), то мне, пожалуй, придётся признаться в подобной негибкости :) Потому что действительно не могу себе представить на текущий момент подобные случаи.
Если вы хотите продолжить дискуссию, то я совершенно не против, просто действительно не представляю в данный момент, в каком именно русле она может быть далее продолжена. Если есть что-то конкретное, что вы хотите ещё обсудить в рамках этого поста, то говорите.
Правда хочу заметить, что в данный момент я занялась более ли менее основательным изучением первоисточников, чтобы найти ответы на вопросы как изначальные собственные, так и поднятые этой дискуссией. Так что через какое-то время я надеюсь стать более «качественной» собеседницей на тему ЕТ, чем таковой являюсь сейчас :)
Я уверена, что это не последний мой пост на тему ЕТ, и буду рада и в дальнейшем вашим комментариям, т.к. они, в частности, мне самой помогают с чем-то лучше разобраться и что-то расставить по местам :)
Хотя с последней записи прошло много времени, очень хочется оставить комментария :)
ОтветитьУдалитьТак вышло, что я работала в проекте, где исследовательское тестирование было невозможно.
Да да, именно невозможно, позже расскажу почему.
Мое мнение, для каждого конкретного проекта нужно выбирать свой подход. Он очень много от чего зависит: от размера приложения, команды, по какому процессу разрабатывается приложение, кто заказчик, каковы критерии качества продукта, ну и т.д.
Если приложение небольшое, его функционал можно изучить целиком за короткий срок, его тестируют профессионалы, способные выполнять интеллектуально любое задание, детектить и оформлять баги, составлять понятные и не отнимающие много времени отчеты о проделанной работе, то нафиг тесткейсы, их написание обойдется дороже, чем исследовательское тестирование!
И все было бы очень хорошо и просто, если бы все приложения были именно такими, никиких тесткейсов никто и никогда не изобрел бы, не родилась бы система CMMI, в ней просто не было бы необходимости.
Но все это родилось, потому что есть проекты, где приложения огромны и очень сложны, над их частями работают не просто разные команды, а, к примеру, разные страны. Проекты длятся несколько лет и за это время пару раз успевает полностью смениться команда тестеров. Как такие приложения тестировать исследовательски?
Я работала в проекте, где тестировалась подобная программа. Это было что то вроде операционной системы для сотовых сетей. Понять ее интуитивно было невозможно, поскольку мало чей жизненный опыт может подсказать как на самом деле работает ваш сотовый. И интерфейс ее ничего общего с оконным интерфейсом винды не имел. На изучение программы и прочтение всей документации к ней по моим подсчетам ушло бы не менее полугода. Полугодовое обучение нового сотрудника - штука очень накладная. Запустить программу на реальной сети и проверить работу тоже возможности не было, потому что любой баг вызвал бы колоссальные финансовые потери (минута простоя какой нибудь сотовой сети по стране обходится в миллионы баксов).
По моему мнению, система тесткейсов была придумана именно для таких вот случаев, потому что иначе этот процесс просто не управляем.
То, что нельзя составить кейсы так, чтоб покрывался весь функционал - это миф. Наша система покрывала все (но надо сказать, что писалась она не один месяц и дополнялась в течении всего проекта).
Вот такой вот пример об идеальности кейсов и невозможности исследовательского тестирования :)
Кейсы и ИТ для меня противопоставлением не являются, просто они применяются для решения совершенно разных задач. Оба подхода, на мой взгляд, одинаково хороши, если они к месту.
Создание тестового покрытия штука затратная, оно оправдано только тогда, когда сильно упрощает жизнь в будущем.
Спасибо за комментарий и за высказанное мнение.
ОтветитьУдалитьНе хочу сейчас разворачивать длинные споры, просто скажу, что примерно поняла вашу точку зрения, однако со многим из высказанного я лично не слишком согласна. Конечно, бывают проекты критичные, например, касающиеся жизни и здоровья людей, там без тесткейсов просто нельзя, насколько я понимаю. Но что касается размеров и сложности проекта, то я как раз очень долго и работала на очень большом и не самом простом проекте, который разрабатывался годами - и исследовательское тестирование было там весьма уместно.
Что же касается "мифа" о том, что нельзя тесткейсами покрыть всё, то тем более не согласна. Конечно, можно на каждое требование написать тесткейс, и даже 10 тесткейсов, и даже штук сто, но даже это не будет гарантией, что тесткейсами будет покрыта любая возможность взаимодействия с приложением. Ну вот даже такой простой пример, что пользователь может с каким-то приложением работать мышью, а может с помощью меню, а может с помощью горячих клавиш, при этом работать может очень быстро или очень медленно и т.п. - это всё может иметь значение, и я не представляю, чтобы всё это и для всего приложения было предусмотрено тесткейсами; а это ведь всего лишь маленький пример.
В целом же, пожалуй, моя точка зрения была высказана более ли менее полно во множестве комментариев выше, поэтому просто не хочу повторяться, описывая своё мнение заново.
Если хотите продолжить разговор на эту тему, то обязательно его поддержу, только, к сожалению, сейчас не могу обещать быстрое реагирование.
Спасибо! Мне, как начинающему тестеровщику, эта дискуссия была КРАЙНЕ полезна!!!
ОтветитьУдалитьОчень радостно, если развёрнутая дискуссия была кому-то полезна :) Успехов в вашей работе!
ОтветитьУдалитьСпасибо за интересную дискуссию. И за блог целиком. Очень вдохновляет в начале пути!
ОтветитьУдалитьОльга, спасибо на добром слове :) Очень приятно, если мой блог оказывается полезным О-)
ОтветитьУдалитьА вам больших успехов!
Спасибо за пожелание)
ОтветитьУдалитьПока смотрю на тестирование со стороны технической поддержки и "исследовательское тестирование" в таком случае действительно эффективнее, как мне кажется.
:) ну, что и мне так кажется - я в рамках этой темы уже многократно повторяла.
ОтветитьУдалитьПравда мне недавно напомнили, что что будет эффективно в рамках одного проекта - может быть не слишком эффективным в рамках другого. В частности, называли очень большие проекты и проекты, критичные для жизни и здоровья людей. Не имея опыта в подобных проектах, спорить с такими высказываниями мне сложно... Полагаю, что где-то скриптовый подход будет считаться единственно возможным для максимального контроля и порядка.
Но я всё равно больше верю в исследовательский подход :)
Исследовательское тестирование по впечатлениям лучше использует знание человека о программе и его представление о том, как конечный пользователь с ней работает. Когда часть тестирования отдается технической поддержке - не использовать этот ресурс странно.
ОтветитьУдалитьБуду думать на эту тему)
Кстати, действительно очень интересный вариант - выполнять тестирование работникам тех. поддержки, ведь именно эти люди получаются информацию о _реальном_ использовании продукта...
ОтветитьУдалитьСкажу честно - никогда о таком не слышала, но я вообще с тех. поддержкой никогда не встречалась в реальности :-<
В любом случае это интересная информация для обдумывания, так что и вам спасибо! :)
В Agile-методологии есть вариант, когда помимо тестеровщика в команде существует внешнее приемочное тестирование. И как раз тут полезно применение тех.поддержки и исследовательского тестирования)
ОтветитьУдалитьВообще-то я всегда считала, что внешнее приёмочное тестирование - это тестирование на стороне заказчика или типа того. Но, возможно, есть варианты...
ОтветитьУдалитьНу да. В нашем случае заказчику отдают на тестирование - но это скорее на уровне "попробовать поработать".
ОтветитьУдалитьВпрочем - это уже вбоквел от темы)
Странные завихрения вселенной отправили меня именно на этот ресурс. Искал информацию об Исследовательском тестировании...не мог оторваться..читал и читал, читал! Спасибо Вам огромное за столь детальное обсуждение! выпил все залпом)
ОтветитьУдалить:) могу только порадоваться, что наша горячая дискуссия оказалась интересной
УдалитьЭтот комментарий был удален администратором блога.
УдалитьПроверяйте почту
УдалитьСлучайно к вам попал, но начал читать и затянуло, очень интересно...
ОтветитьУдалитьЗдравствуйте, Антон! Спасибо на добром слове, очень приятно такое читать :) Жаль, что я свой блог позабросила по разным причинам, но даже благодаря одному такому отзыву может найду в себе силы снова его возродить со временем... Надеюсь, вы найдёте здесь хоть что-либо полезное :)
УдалитьБлагодарю всех участников дискуссии! Данная ветка обсуждения помогла определиться с подходящими источниками обучения и добавила крайне познавательный багаж в копилку знаний.
ОтветитьУдалитьДа, знатная была дискуссия... :) Искренне рада, если она оказалась полезной, успехов вам!
УдалитьПоэтому ключевой момент — это избрать темы продвижение лучшими статьями, коие используют поисковым спросом, другими люди задают вопросы в поисковую систему. Собрать список этих запросов — значит собрать семантическое ядро.
ОтветитьУдалить