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

Фотография

Помогите


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

#1 NoName

NoName

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

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

Отправлено 20 февраля 2007 - 11:10

Здравствуйте! Я начинающий тестировщик, подскажите пожалуйста, как правильно составлять тест-кейсы??? очь прошу... заранее спасибо!
  • 0

#2 Tiana

Tiana

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

  • Members
  • PipPip
  • 81 сообщений
  • ФИО:Girnyk S. Tatyana
  • Город:Украина, Харьков

Отправлено 20 февраля 2007 - 11:15

вот так, к примеру.
  • 0

#3 NoName

NoName

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

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

Отправлено 20 февраля 2007 - 11:23

Спасибо!
  • 0

#4 NoName

NoName

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

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

Отправлено 20 февраля 2007 - 11:26

А если не сложно, не могли бы вы скинуть заполненный пример, какой нить простой программки, очень буду благодарен
  • 0

#5 Clauster

Clauster

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

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 20 февраля 2007 - 18:03

идите в раздел библиотека и читайте статьи
  • 0

#6 olya_A

olya_A

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

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

Отправлено 03 октября 2007 - 07:54

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

#7 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 03 октября 2007 - 11:12

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


Действительно, и зачем вы туда поперлись... Вообще, интересно, почему люди без опыта, когда приходят, не говорят "Научите меня, мне интересно" а сразу: "Да я всё умею! (ой что же делать что же делать...)"

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

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

Следующее упражнение. Никогда не слушайте, если вас просят "убедиться в том, что программа работает". Ваша цель как тестировщика - доказать, что программа не работает, или работает плохо, или просто она противная и бяка. Как это делается? Делается это просто: берется программа и ставится в неудобное положение. После этого её нужно пощекотать - баги сразу и посыплются. Подробнее этот случай описан в анекдоте про сибирских лесорубов и японскую пилу, а еще лучше поискать в google слова domain testing, boundary testing и далее по ссылкам.
*рука с волшебной палочкой начинает затекать*

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


А вообще, можно книжек каких-нибудь почитать. Только хороших.
  • 0

#8 atermath

atermath

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

  • Members
  • Pip
  • 30 сообщений
  • ФИО:Сикорский Андрей Анатольевич
  • Город:Москва

Отправлено 03 октября 2007 - 13:30

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


Было бы просто замечательно, чтобы разговор стал предметным - Вы ничего не рассказали о программе: что это такое, что делает, какая область применения (кстати, это тестовое задание для приема на работу? Или тестовое задание на испытательный срок?)

Выше уважаемый rlabs уже написал вам первые шаги - причем асболютно правильно.

а) ставите программу (на этом этапе отметьте для себя, что составило трудности при установке, какие ошибки возникли)
б) Используете эту программу, как и любую другую (желательно по назначению): если это текстовый редактор - набираете тексты, если это банковская программа - составляете сметы
в) в процессе использования смотрите, делает ли программа то, что должна делать(то, что она должна - можно узнать частично из руководства пользователя, вообще же есть такой документ, как требования)
г) если что-то идет неправильно (документ не создается, когда должен, шрифт не становится жирным, если должен, операционная система повисает, программа закрывается с сообщением об ошибке) - то пишете отчет. Формат отчета может быть разный, но самая важная часть у него всегда одна
  • Краткое описание проблемы (например, "Документ не сохраняется")
  • Полное описание проблемы(что именно вы сделали, чтобы добиться такого результата, что именно произошло в результате ваших действий
Там есть еще всякие приоритеты ошибок, версия программы в которой обнаружена ошибка - будет лучше, если вам на месте расскажут, какие поля есть в вашей баг-трекинг системе и что туда надо писать.

ну а о тест-кейсах, автоматизации, тест-планах - это когда минимум усвоится.
В заключение (не обижайтесь): тестировщик - это прежде всего исследователь. Исследуйте то, что вам надо сделать, как тестировщику. Книг много - в том же ОЗОНе есть неплохие. Из ссылок - смотрите инфу в этом форуме и, если с английским в ладах, то можно заглянуть на sqaforums.com, там есть и информация для новичков
  • 0
Андрей Сикорский
Тестировщик, математик

#9 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 03 октября 2007 - 14:20

Следующее упражнение. Никогда не слушайте, если вас просят "убедиться в том, что программа работает". Ваша цель как тестировщика - доказать, что программа не работает, или работает плохо, или просто она противная и бяка.


Ну вот Вы и наставляете человека на путь истинный. :focus:
Цель/задача тестировщика проверить программный продукт на соответствие требованиям. А уж что вы при этом доказываете, что она работает или не работает, вопрос лично каждого. :victory:
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#10 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 03 октября 2007 - 16:07

Ну вот Вы и наставляете человека на путь истинный. :focus:
Цель/задача тестировщика проверить программный продукт на соответствие требованиям. А уж что вы при этом доказываете, что она работает или не работает, вопрос лично каждого. :victory:


Вообще это не я, это почти дословная цитата из Канера.

Если вы используете только requirements-based тестирование, то можно либо а) позавидовать ("ура, у них есть спецификации!") либо б) посочувствовать ("если требованиями покрыто только 10% функционала и обновлялись они год назад -- что же протестировали все эти люди?")
  • 0

#11 olya_A

olya_A

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

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

Отправлено 04 октября 2007 - 06:45

Было бы просто замечательно, чтобы разговор стал предметным - Вы ничего не рассказали о программе: что это такое, что делает, какая область применения (кстати, это тестовое задание для приема на работу? Или тестовое задание на испытательный срок?)


программа, для которой необходимо составить тест-кейсы, предназначена для автоматизации обработки и учета документов в ЗАГСе. данное задание является тестовым не для испытательного срока, а для приема на работу :)
задание звучит следующим образом:

Для приложения ZAGS разработать подмножество тестовых случаев (test cases), предназначенных для выполнения тестов функциональности.
Тест-кейсы следует писать по документам:
"Руководство по установке и удалению АС ЗАГС.doc"
"Руководство пользователя АС ЗАГС.doc"
То есть, программа должна вести себя так, как описано в данных документах.
Набор тестовых случаев должен быть основан на требованиях к приложению, изложенных ниже.

Требования к приложению:
1. Функциональность приложения должна соответствовать руководству пользователя.
a. Вся функциональность, описанная в руководстве пользователя, должна быть реализована
b. Приложение должно выполнять свои функции именно так, как описано в руководстве пользователя.
2. Если по какой-то функциональности недостаточно информации в руководстве пользователя, эта функциональность должна соответствовать здравому смыслу и общепринятым нормам.


ну вот пока и все:) вот установила я эту программку у себя, почитала документы, попыталась понять суть работы... пока на этом и застряла... :victory:
  • 0

#12 JimR

JimR

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

  • Members
  • PipPipPipPip
  • 253 сообщений
  • ФИО:Ручко Дмитрий Иванович
  • Город:Москва

Отправлено 04 октября 2007 - 08:22

...

ну вот пока и все:) вот установила я эту программку у себя, почитала документы, попыталась понять суть работы... пока на этом и застряла... :victory:


Оля, а понимаете ли Вы что есть тестовый случай и с чем его едят?

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

Как освоитесь - беритесь за тестовую программу для собеседования.

Продолжать же по этой теме ещё можно много и долго.
Но я бы предложил лучше подумать: "А действительно ли Вам хочется быь тестировщиком? Или просто показалось, что здесь проще работать?"
  • 0
Дмитрий Ручко
InfoTeCS

#13 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 04 октября 2007 - 08:45

Ну вот Вы и наставляете человека на путь истинный. :drinks:
Цель/задача тестировщика проверить программный продукт на соответствие требованиям. А уж что вы при этом доказываете, что она работает или не работает, вопрос лично каждого. :victory:


Вообще это не я, это почти дословная цитата из Канера.


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

Если вы используете только requirements-based тестирование, то можно либо а) позавидовать ("ура, у них есть спецификации!") либо б) посочувствовать ("если требованиями покрыто только 10% функционала и обновлялись они год назад -- что же протестировали все эти люди?")


М-да... :-)
а) Если у вас нет требований, что же вы тогда проверяете? Точнее откуда вы знаете, что правильно, а что нет?
б) год назад надо было спрашивать разработчиков, а что они, собственно делают? Неубедительно. :beach:

А в данном случае требованиями есть "документация - рук-во пользователя и по установке и удалению программы". Чем не требования к тестированию? Все остальное - это домысел как должно работать или предложения, как сделать по другому, но никак не ошибка. Ровно потому что вы не знаете как оно должно быть на самом деле.
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#14 olya_A

olya_A

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

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

Отправлено 04 октября 2007 - 09:44

можно конечно методом научного тыка исследовать программку. но дело в том, что я не хочу изначально неправильно делать. к тому же я плохо понимаю сам процесс, если он не систематизирован в моей голове. поэтому я конечно почитала некоторые статейки про тест-кейсы. вот например есть три шаблона или вида: step-by-step, matrix и automated test-cases. полагаю, что в моем случае проще начать со step-by-step? тогда возникает другой вопрос: список действий и результатов получиться просто огромный!? ибудет выглядеть так: 1. в поле "номер бланка" вводим слово "кошка" -> результат символы не печатаются -> fail/pass? и так далее...так или не так. не понимаю....
  • 0

#15 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 04 октября 2007 - 10:20

полагаю, что в моем случае проще начать со step-by-step? тогда возникает другой вопрос: список действий и результатов получиться просто огромный!? ибудет выглядеть так: 1. в поле "номер бланка" вводим слово "кошка" -> результат символы не печатаются -> fail/pass? и так далее...так или не так. не понимаю....


Введите в свой словарный запас еще понятия "позитивный" и "негативный" тест. В двух словах, "позитивный" тест - это тест при котором система себя ведет так, как описано в требованиях/мануале/guide и т.п., что у вас есть. Негативный, это тест, который проверяет работу системы при неверном ее использовании (например в числовое поле попытаться вставить букву).
1. Если у Вас намечается оооочень много тестовых вариантов использования, а времени не много, сперва пишите и проверяйте только позитивные. Это покажет Вам, правильно ли работает программа, как то описано в требованиях/мануале/guide и т.п., что у вас есть.
2. Если есть время на небольшую часть негативных тестов, тогда добавляйте по одному негативному тесту к каждому варианту использования.
3. Если много времени, то делайте полное позитивное и негативное тестирование.

Надо оговорить, что в п.2. стоит сперва выбрать критические части ПО и проверять там негативные тесты в первую очередь. Если на остальные нехватит времени, не так критично.

Не забывайте перед реализацией того или иного пункта обсудить его с руководителем и дать свою оценку по времени. Что-то типа: ожидается около N тестов, время на их написание Т1, время на ревью и корректировку Т2, время на прохождение Т3 (тут прохождение + фиксировнаие результатов + тестовые репорты), время на работу с ошибками в течении полного жизненного цикла ошибки Т4. Итого закончим тогда-то.

Конечно, Вам будет трудно определиться с датами в первые разы. Но за Вас этого никто не сделает. Попробуйте накидывать по 15% времени к каждой фазе. Ну и включайте здравый смысл. :victory:
Это если в двух словах. :-)
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#16 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 04 октября 2007 - 10:59

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

It would be a mistake to redefine your mission more positively, as someone who verifies that the program works. Even if "verify that the program works" is handled to you as your mission, advise your client that such verification is impossible. It's hideously expensive. Unless you run every possible test, you can't prove the product works. The best you could say is "For the tests I performed, I didn't notice that the product didn't work". The opposite, however, is marvelously economical: With as little as one test, you can shown that the product doesn't work.

Cem Kaner, in the "Lessons Learned in Software Testing"

Если вы используете только requirements-based тестирование, то можно либо а) позавидовать ("ура, у них есть спецификации!") либо б) посочувствовать ("если требованиями покрыто только 10% функционала и обновлялись они год назад -- что же протестировали все эти люди?")

М-да... :-)
а) Если у вас нет требований, что же вы тогда проверяете? Точнее откуда вы знаете, что правильно, а что нет?
б) год назад надо было спрашивать разработчиков, а что они, собственно делают? Неубедительно. :acute:

А в данном случае требованиями есть "документация - рук-во пользователя и по установке и удалению программы". Чем не требования к тестированию? Все остальное - это домысел как должно работать или предложения, как сделать по другому, но никак не ошибка. Ровно потому что вы не знаете как оно должно быть на самом деле.

Мы сейчас рискуем свалиться в рассуждения о философии тестирования. Попробую ограничиться лишь следующим:
  • пример "требований" из 2 пунктов приведен двумя комментариями выше (и, кстати, там есть отличное требование,упминающее некий "здравый смыл" - то есть те самые "домыслы")
  • как правило, документация пишется по уже готовому продукту, и соответствует его поведению независимо от того, правильно он был реализован или нет
  • не секрет, что спецификация часто пишется апостериори, уже после реализации функциональности, и отражает то, что получилось - а это может не совпадать с тем, что задумывалось.
Возможно, в НАСА работают по-другому; но в любом случае тестировщик, не выходящий за рамки спецификации - не очень хороший тестировщик.
  • 0

#17 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 04 октября 2007 - 11:45

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

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

вот например есть три шаблона или вида: step-by-step, matrix и automated test-cases. полагаю, что в моем случае проще начать со step-by-step? тогда возникает другой вопрос: список действий и результатов получиться просто огромный!?

Когдав дело касается оформления, всегда следует прежде спросить себя (а работая в команде - еще и окружающих): "Зачем?" (это вообще очень хороший вопрос, универсальный такой)
Список тестов - это просто список тестов. Каждый тест - это всего лишь набор из начального условия, самого теста, и ожидаемого "правильного" поведения. Например, вот вам один из положительных тестов для процедуры инсталяции: Проверить, что программа устанавливается в каталог, указанный пользователем, а не в каталог "по умолчанию." Ожидаемый результат: устанавливается как надо, и после этого её можно запустить. Всё, один тест готов. Его можно расписать на 5-10 шагов, только надо ли? Хватит списка самих тестов.
Далее посмотрим, какой получается ответ на наш мега-вопрос применительно к вышеуказанным шаблонам:
  • Пошаговая инструкция: как правило, нужна для того, чтобы отдать готовые тесты на исполнение студентам или роботам (или студентам-роботам). В вашем случае, не нужно.
  • Матрица: для удобства, когда у нас есть много-много объектов, к которым нужно применить одни и те же тесты. Тупой пример: хочется проверить, а работают ли на каждом экране инсталятора кнопки "Вперед", "Назад" и "Отмена" (ну или еще какие-то общие вещи, вроде синтиксической корректности текстов). Делаем матрицу, в которой пересекаем тестируемые объекты с тестами. Удобно составлять, удобно выполнять, удобно отчитываться (а еще красиво - когда клетки заштрихованы зелененьким и красненьким фломастерами). Другой пример - ввод слов "кошка", "собачка" и "экскаватор" в каждое поле на какой-нибудь большой форме.
Автоматические тесты лучше оставить на потом.

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

Если вернуться к тестированию инсталяции. стартовая точка: читаем в документации "Для установки программы запустите файл ... и следуйте инструкциям". Первый тест - установка программы со всеми значениями по умолчанию. Читаем дальше: "... можно указать путь для инсталяции". А что, если указать другой путь? А что, если указать неправильный путь? А что, если вообще не указывать путь? А что, если указать путь, а потом вернуться и указать другой? На все эти вопросы программа должна иметь ответ, отличный от "падения" или жалобного бормотания.

ибудет выглядеть так: 1. в поле "номер бланка" вводим слово "кошка" -> результат символы не печатаются -> fail/pass? и так далее...так или не так. не понимаю....

Хотелось бы отметить, что тесты не стоит конкретизировать. В переводе на язык тестов ваш пример будет выглядеть как "ввести нецифровые символы в поле "номер бланка", допускающее ввод только чисел. Ожидаемый результат: нецифровые символы не вводятся".


Ну и так далее.
  • 0

#18 Rost

Rost

    Постоянный участник

  • Members
  • PipPipPip
  • 241 сообщений
  • ФИО:Rostyslav Boruk
  • Город:Украина, Киев

Отправлено 04 октября 2007 - 13:31

It would be a mistake to redefine your mission more positively, as someone who verifies that the program works. Even if "verify that the program works" is handled to you as your mission, advise your client that such verification is impossible. It's hideously expensive. Unless you run every possible test, you can't prove the product works. The best you could say is "For the tests I performed, I didn't notice that the product didn't work". The opposite, however, is marvelously economical: With as little as one test, you can shown that the product doesn't work.

Cem Kaner, in the "Lessons Learned in Software Testing"


Спасибо за цитату. Теперь нехватает только определения самого Канера, что есть целью тестирования. :-) Думаю Ольге очень познавательно читать и думать над такими вот абзацами.
А почему Вы сделали вывод из этого абзаца, что "Ваша цель как тестировщика - доказать, что программа не работает, или работает плохо, или просто она противная и бяка." Нет, я понимаю Вашу цель - доступно донести до начинающих специалистов светлую мысль. Но вот почему именно такая суть, не понимаю.
Я полностью согласен с Канером, что проверять работоспособность системы это безыдейное занятие, тем более в разрезе "run every possible test" и без упоминания о проверке некорректной работы.
Замечу только, что это никак не расходится с тем, что я написал "Цель/задача тестировщика проверить программный продукт на соответствие требованиям". Как вы это делаете, запускаете только позитивные тесты, запускаете только негативные либо и те и те, все возможные или достаточные для заключении о готовности ПО к запуску в продакшн, повторюсь "вопрос лично каждого".

Мы сейчас рискуем свалиться в рассуждения о философии тестирования. Попробую ограничиться лишь следующим:

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


Не, думаю что мы дойдем до рассуждений о философии. :-)
А чем отличается п. 2 от п. 3? ИМХО по сути ничем, только по форме изложения. И я таки с Вами соглашусь. Пока что я не совсем понимаю, почему Вы так привязались к слову требования. Для меня и user guide - требования к продукту если нет ничего больше. И по этим "требованиям" я буду работать, если ничего больше нет. Именно это я и пытаюсь донести до Ольги, что есть программа, есть описание того, как она работает. Вот по описанию и пишите тестовые случаи. Что не понятно спрашиваете у разработчиков.

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


Абсолютно с Вами согласен (я не про НАСА :-)). Надо думать, особенно если на входе только руководство пользователю. Оттуда можно взять поведение, а все остальное необходимо предполагать и интересоваться у ответственных лиц, правильно ли ты предполагаешь. Можно еще посоветовать попросить ПМ'а провести ряд презентаций самого продукта для тестировщиков. Можно даже спонтанных. Цель - донести до тестировщиков поведение системы и ответить на вопросы.

Алексей, я не говорю о конкретной модели тестирования. Я говорю о миссии/цели тестирования. Что, в конечном счете, необходимо проверить все ли правильно реализовано, а не доказывать что что-то не работает. И очень похоже, что мы подразумеваем одно и то же, а говорим разными словами. :-)
  • 0
Ростислав Борук,
Консультант по процессам тестирования

#19 olya_A

olya_A

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

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

Отправлено 05 октября 2007 - 14:14

хотела еще спросить... а вот как нужно фиксировать результаты тестирования? ведь если я устанавливаю программу это и есть позитивное тестирование, но при этом я выполняю большое количество действий. как ничего не пропустить? какими инструментами нужно пользоваться при этом? или методиками?
  • 0

#20 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 07 октября 2007 - 10:57

Следующее упражнение. Никогда не слушайте, если вас просят "убедиться в том, что программа работает". Ваша цель как тестировщика - доказать, что программа не работает, или работает плохо, или просто она противная и бяка.

Тут я тоже подключусь, с вашего позволения.

Используя этот подход прошу вас набросать тесты для проверки следующей функциональности:
  • Форма проверки валидности введённого в editbox значения
  • Валидные значения от 0 до 9 целочисленные, включительно
  • Проверка только этого одного условия

  • 0
Слава Панкратов
Редактор портала www.it4business.ru


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

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