Форум Сообщества Аналитиков

Дисциплины => Тестирование => Тема начата: Виталий Григораш от 19 Июля 2007, 22:53:35

Название: Test Case & Test Analyst
Отправлено: Виталий Григораш от 19 Июля 2007, 22:53:35
Привет!
Мой вопрос может быть будет не совсем в тему, но я все же надеюсь, что есть люди, которые смогут мне помочь.
Проблема в том, что мне сейчас поставлена задача написания сценариев тестирования (test cases) по имеющимся вариантам использования (use cases). Я никогда такой работой не занимался и не совсем представляю с чего начать. В RUP есть роль Test Analyst, который отвечает за написание этих самых test cases по ВИ, но к сожалению нет шаблона документа с описанием этих самых ТС и очень мало информации по их написанию.
Если кто-то занимался подобной работой подскажите как лучше оформить данный документ. А может у кого то есть уже готовый шаблон? 8) Буду очень признателен.

Пока описываю по следующей схеме:
1. Test Case ID Название
2. Краткое описание
3. Предусловие
4. Шаги тестирования (что должен делать тестер)
4.1 Шаг 1
4.1.1 Описание
4.1.2 Входные значения (Например, ввести значение и нажать кнопку)
4.1.3 Выходные значения (что-то вроде ожидаемых результатов - например, окно с сообщением ошибки)
5. Постусловие

ЗЫ Обратился сюда так как считаю, что данную роль могут выполнять аналитики. Я сам писал когда-то ВИ, теперь вот надо написать по ним test cases.
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 20 Июля 2007, 10:31:52
Как тестер, могу сказать, что у аналитиков и тест-аналитиков часто бывает очень разный взгляд на одни и те же вещи. Думаю, по Вашему вопросу есть информация на сайте http://it4business.ru/category/software-testing/ (бывший software-testing.ru). Также вопрос можно задать там же на форуме.
Название: Re: Test Case & Test Analyst
Отправлено: bas от 20 Июля 2007, 11:26:51
Я пишу именно как у вас написано. Только весь 4ый п. я пишу в виде таблицы. И у меня нет 5ого пункта.
Вот что я нашел в инете: http://www.geocities.com/xtremetesting/TCtemplate.html
А вообще на гугле есть много интеерсного по словам:
test case sample
test case template

Присобачиваю, что я дела когда-то
Название: Re: Test Case & Test Analyst
Отправлено: bo от 27 Июля 2007, 23:50:48
привет.

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

по use cases-ам я не уверен, я пишу по srs.

во
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 29 Июля 2007, 01:14:54
по use cases-ам я не уверен, я пишу по srs.

А нельзя ли уважаемый, ВО (или bo), привести пример srs и теста, который для него?
Очень полезно знаете для прихожан :-) И я лично с удовольствием посмотрел бы.
Название: Re: Test Case & Test Analyst
Отправлено: bo от 01 Августа 2007, 01:21:48
доброй ночи.

обычно на подобные вопросы не отвечаю. :-)
извините. сошлюсь на "поправку к конституции". не могу. запрещено корпоративной политикой. тем более на публичном форуме.

...я бы тоже "с удовольствием посмотрел" в документацию любого из конкурентов или крупных партнеров. :-)

во
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 01 Августа 2007, 09:48:40
обычно на подобные вопросы не отвечаю. :-)
извините. сошлюсь на "поправку к конституции". не могу. запрещено корпоративной политикой. тем более на публичном форуме.
Вас никто не пытается заставить делится корпоративными секретами. Вамс просят поделится Вашим опытом. Опыт-то надеюсь Вам принадлежит?

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

Во-первых, я даже (слава Богу) не знаю в какой фирме ВЫ работаетет!
Во-вторых, "стихи не продаются, но можно рукопись продать"!
В-третьих, а что Вы тогда пытаетесь найти на форуме? Чужие секреты, чтобы сделать Вашу фирму конкурентноспособной?
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 27 Августа 2008, 11:49:18
Доброе время суток!

У меня тоже вопрос по Test  Case.
У меня на новой работе возник вопрос по тестовым сценариям.
Причем задав этот вопрос я увидел испуг в глазах. Сразу начинают говорить:”Это ни кому  не нужно. Это дорого поддерживать. Надо брать человека под это дело. И тд” Что это по вашему: Боязнь потерять свою значимость и следовательно сопротивление всему новому? Или в зрелости организации?
Помогите с аргументацией.
Например:
•    для чего нужны Test Case
•    кто должен разрабатывать
•   Полезность для обучения тестировщиков
•    какие сценарии пишутся (с точки зрения пользователя- вошел в систему -> поработал -> выход из системы ,для администратора и тп),
•   охват теста
•    стоимость разработки и поддержки теста
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 27 Августа 2008, 13:33:07
Цитировать
для чего нужны Test Case
Test Cases нужны для того чтобы знать что и как проверять и документирования что и как проверялось
Цитировать
кто должен разрабатывать
Тот кто умеет (тестировщик/тест-дизайнер)
Цитировать
Полезность для обучения тестировщиков
не понял вопроса (тестировщики умеют писать тесткейсы, если не умеют то какие ж это тестировщики)
Цитировать
какие сценарии пишутся (с точки зрения пользователя- вошел в систему -> поработал -> выход из системы ,для администратора и тп),
охват теста
стоимость разработки и поддержки теста
Зависит от ПО, квалификации отведенного времени
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 27 Августа 2008, 14:11:22
Test Cases нужны для того чтобы знать что и как проверять и документирования что и как проверялосьТот кто умеет (тестировщик/тест-дизайнер)не понял вопроса (тестировщики умеют писать тесткейсы, если не умеют то какие ж это тестировщики)Зависит от ПО, квалификации отведенного времени

Ладно пойдем другим путем.
Если посмотрите сюда: http://pankratov.org.ua/docs/ecmm4st.pdf
То что твориться в нашем отделе тестирования можно прировнять к уровеню 2.
Поэтому я справшиваю какие + и -  :-) в Test Case

Тут проблема во внедрении мне кажется. А про автоматизированное тестирование хорошего сказать не смогу :-(
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 27 Августа 2008, 14:33:25
Ну и смотрим то что Слава наваял
Вы на 2 (3-й нафиг не нужен)
Нужен 4-й его основа "Фокус тестирования смещен в сторону тест-дизайна и планирования"
Тест-дизайн это и есть написание эффективных программ тестирования на основании написания правильных тесткейсов
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 27 Августа 2008, 14:40:49
Нужен 4-й его основа "Фокус тестирования смещен в сторону тест-дизайна и планирования"
Тест-дизайн это и есть написание эффективных программ тестирования на основании написания правильных тесткейсов
По тест-дизайну посоветуй доки почитать.Или ссылки дай.
Спасибо
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 27 Августа 2008, 17:22:05
Вариант 1 смотрим любую из книг
Канер С., Фолк Дж., Енг Кек Нгуен. Тестирование программного обеспечения
Блэк Р. Ключевые процессы тестирования
Тамре Л. Введение в тестирование программного обеспечения
Савин Р. Тестирование Дот Ком

Вариант 2
Пошерстить ветку http://it4business.ru/forum/index.php?showforum=111

Вариант 3
Начать активно донимать galogena, ибо он теперь главный спец по тестированию (вернее учится)
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 27 Августа 2008, 17:48:16
Эдуард!!!

жаль набор смайликов в форуме очень ограничен

 :)
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 27 Августа 2008, 17:50:07
Эдуард!!!

жаль набор смайликов в форуме очень ограничен
Эд у нас спец по дониманию! А какой смайлик тебе был нужен?
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 27 Августа 2008, 17:54:31
Ну какая-нибудь страшная и злая рожица еще лучше с топающими ногами

P.S. Блин ну почему меня после отправки сообщения выкидывает в корень ветки форума в которой находится тема :(
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 27 Августа 2008, 18:05:04
Не, Саша., ты не понял. Не тебя донимать, а МЕНЯ - Галогена, то есть. Но читается да как тебя:)
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 27 Августа 2008, 18:07:11
P.S. Блин ну почему меня после отправки сообщения выкидывает в корень ветки форума в которой находится тема :(
Саша, в настройках полазь. Там можно настроить способ куда тебя отправлять после публикации заметки
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 01 Сентября 2008, 12:07:36
Не, Саша., ты не понял. Не тебя донимать, а МЕНЯ - Галогена, то есть. Но читается да как тебя:)
Уважаемый , Галогеноджан!
Буду вас донимать. :-)
Возьмем ситуацию.Вам надо протестировать систему.
Например некоторую примочку , которая работает с 1С.
Предположим у вас работают профи тестировщик и новичок.
Кто-то из них работает удаленно а кто-то у заказчика.
Что им понадобиться для тестирования?
Какие документы?




Название: Re: Test Case & Test Analyst
Отправлено: Irr от 01 Сентября 2008, 12:58:55
Предположим у вас работают профи тестировщик и новичок.
Кто-то из них работает удаленно а кто-то у заказчика.
Что им понадобиться для тестирования?
Какие документы?
Как минимум им понадобится тестовый стенд.
Под "какие документы" понимаются входные или те, что они сами разрабатывать будут?
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 01 Сентября 2008, 13:03:09
Под "какие документы" понимаются входные или те, что они сами разрабатывать будут?

конечно входные документы
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 01 Сентября 2008, 19:05:26
Возьмем ситуацию.Вам надо протестировать систему.
Например некоторую примочку , которая работает с 1С.
Предположим у вас работают профи тестировщик и новичок.
Кто-то из них работает удаленно а кто-то у заказчика.
Что им понадобиться для тестирования?
Какие документы?
Я и сам большой новичок в этом деле.
Как учит нас литература от гуру - нужно иметь план тестирования, т.е. набор неких тестовых сценариев или может фичей которые следует тестировать (будет скорректировано после разъяснений alexlobach).
Эти фичи проранжированы, для них определены сроки и ресурсы тестирования.
По фичам наверное нужно разработать тестовые сценарии и подобрать данные и ожидамые результаты.
Ну а по сценариям формируем тестовые случая с использованием классов эквивалентности, например.

Саша Лобач советовал мне действовать примерно так:
формируем вариант использования в стиле: шаг исполнения - действия пользователя по этому шагу - ожидаемый результат (отклик системы)
по каждому шагу где это кажется необходимым (особенно там где предполагается многозначность и альтернатива) формируются тестовые случая: по сути класс проверяемых данных с точно известным результатом исполнения

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

По результатам тестов будет составлен отчет и сделаны метрики: скажем отношение пройденных тестов к общему их числу. Если вы делаете несколько циклов тестирования, то данный показатель может быть индикатором прогресса или регресса, т.е. будет показывать тренд...
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 01 Сентября 2008, 22:04:58
конечно входные документы
Ну, если входные, то желательно документ, по которому будет осуществляться приемка продукта заказчиком (это бывает техническое задание, а в некоторых случаях программа приемо-сдаточных испытаний - но такой шик бывает очень редко). Ну или хотя бы постановку задания, по которой писали разработчики, или документацию для пользователя.
А вообще, теоретически, это зависит от вида тестов. Для модульных тестов - нужна архитектура и ТЗ, для тестов функционала в целом - ТЗ и результаты бизнес-анализа, если он был (что также бывает очень редко).
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 01 Сентября 2008, 22:08:18
Эдуард, пожалуйста, не путай план тестирования и набор неких тестовых сценариев. Это абсолютно разные вещи
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 01 Сентября 2008, 22:27:52
Эдуард, пожалуйста, не путай план тестирования и набор неких тестовых сценариев. Это абсолютно разные вещи
Александр, я постараюсь. Тем более, если у тебя найдется время доходчиво пояснить что такое план тестирования. Действительно, читая книги, я так до конца и не понял что же это такое. То ли это план выполнения работ по тестированию на определенный период с распределением времени, ресурсов и форм отчетности. Или же это также и набор этих самих тестовых сценариев.  Во всех книгах точно есть - это план-график работ по тестированию...
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 02 Сентября 2008, 11:26:15
техническое задание, программа приемо-сдаточных испытаний , постановку задания,  документация для пользователя.
Представьте ситуацию , что всего этого нет.А есть только люди , которые  что-то знают.
Исходя из того что я понимаю о системе , то и делаю.Те  пока в состоянии обнаружить очевидные ошибки, ошибки в пользовательском интерфейсе.

Какие вопросы я должен задавать?Чтобы расширить свое понимание о системе.
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 02 Сентября 2008, 12:17:23
2 Эдуард
Тест-план (план тестирования) документ описывающий кто, что, когда и как тестирует, или не тестирует
Хотел написать ответ здесь, но понял что потом будет еще больше вопросов :)
Постараюсь в течение 2х-3х дней подготовить статью на эту тему, в смысле какая нужна документация

2 Андрей
порекомендую как и Эдуарду начать с описания Вариантов использования на основании тех знаний, которые вы можете получить у людей "которые  что-то знают"
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 02 Сентября 2008, 14:49:47
Представьте ситуацию , что всего этого нет.А есть только люди , которые  что-то знают.
Исходя из того что я понимаю о системе , то и делаю.Те  пока в состоянии обнаружить очевидные ошибки, ошибки в пользовательском интерфейсе.
Андрей, Вы не одиноки. Большинстов сталкивается с тем, что нет спек, ничего не известно. Но ведь есть программа:)

Для того чтобы погрузиться в процесс нужно:
1. изучить функциоанл программы
2. беседовать с аналитиками
3. беседовать с программерами
4. записать на форум по тестированию и активно его читать и общаться
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 03 Сентября 2008, 16:51:48
Обещанная статья http://www.alexlobach.ru/2008/09/03/artefakty-neobxodimye-dlya-testirovaniya/
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 03 Сентября 2008, 18:25:16
Александр, очень интересно понять процесс формирования тестовых случаев.

В книге "Быстрое тестирование" в целом это описано достаточно понятно, но...

Интересно обсудить-понять стиль написания ВИ для тестового применения. Как корректно создавать тестовые случая?

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

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

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

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

Понимаю, что последний вариант более подходит для автоматизации. Т.е. если что-то поменяется, то изменению подлежат только часть тестовых случаев.
В первом случае правда достаточно изменить сам конечный документ. Правда в этом случае ошибка будет интегральная и причину ее будет сложнее установить...
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 17 Сентября 2008, 22:52:00
порекомендую как и Эдуарду начать с описания Вариантов использования на основании тех знаний, которые вы можете получить у людей "которые  что-то знают"
Александр, и возможно другие ценители искусства тестирования.
Нельзя ли привести пусть наброски примеров написания вариантов тестирования для целей тестирования - хоть на примере NotePad и последовательной цепочки рассуждений, приводящих к тестовым случаям и их форме.

Будет ли форма тестового случая = форме варианта использования с нанизанными на нее тестовыми данными и ожидаемыми результатами
или
она совершенно не будет равна и будет иметь другое формообразование?

спасибо
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 22 Сентября 2008, 13:42:55
Нельзя ли привести пусть наброски примеров написания вариантов тестирования для целей тестирования - хоть на примере NotePad и последовательной цепочки рассуждений, приводящих к тестовым случаям и их форме.
Эд, сейчас не готова, как только будет похожая задача, тебе кину.
Будет ли форма тестового случая = форме варианта использования с нанизанными на нее тестовыми данными и ожидаемыми результатами или она совершенно не будет равна и будет иметь другое формообразование?
По моему опыту бывает и так, и эдак. Зависит от качества модели вариантов использования. Ну и от того, насколько образ мышления автора модели вариантов использования сходится с образом мышления автора модели тест-сценариев.
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 22 Сентября 2008, 17:46:49
По моему опыту бывает и так, и эдак. Зависит от качества модели вариантов использования. Ну и от того, насколько образ мышления автора модели вариантов использования сходится с образом мышления автора модели тест-сценариев.
Давайте подумаем немного.
Ситуации бывают такие:
1. Грамотно организованный процесс рзработки, где в основу положен ВИ. ВИ здесь и фрейм предметной области и промежуточный продукт для получения других: постановки задачи на проектирование, написания инструкций по использованию, разработке тестовых случаев
2. Нет ничего подобного пункту 1. В этом случае ВИ скорее получают из того как работает система глазами пользователя, те.е ВИ = инструкции того как использовать систему, чтобы получить то что желательно.
В этом случае мне думается пробем понимания вообще не будет. Все же видят систему и более менее знают как с ней работать, только такое описание дает более четкое представления.
Т.е. по сути я пишу ВИ с точки зрения реального интерфейса. Есть бизнес-задача - например оформление документов по коммерческой поставке, и я составляю описание того как это делается. По сути я описываю некоторый сценарий - скорее всего типичный и любые альтернативные, указывая где и какие кнопочки нажимать. Единственное что, я не указываю какие данные при этом выбирать. А вот когда указываю эти данные то получается по сути тестовый сценарий.
Хотя в стандарте IEEE нет понятия сценария.
Насколько я понимаю тестовый случай - это по возможности нечто атомарное - например: проверить что сумма счета при создании счета выставляется корректно.
Я из описания ВИ знаю какие действия я делаю, чтобы получить этот самый счет,в нем возможно отражены правила, которые влияют на эту сумму счета, зная которые я подбираю данные. Причем если внимательно подумать, то по сути целью будет не просто проверка суммы счета, а влияние некоторых параметров (количества товаров, цены на текующую дату, скидки и т.п.) на конечную сумму счета.
При этом у меня есть несколько возможностей:
1. сформировать влияющие правила последовательно и посмотреть как формируется счет
2. найти клиента с некоторым набором нужных мне правил - и создать счет и убедиться, что сумма корректна
В зависисмости от возможности - я могу организовать два разных сценария: один будет например таков - выбрать
1.создать-выбрать клиента , задать ему такие-то правла, сформировать счет и убедится или не убедится что сумма корректна
или
2.клиента № такойто(и я заранее знаю его набор правил), сформировать счет и сравнить с ожидаемым


При наличии исходных данных 2 сценарий проще и быстрее - он легче и программируется, да и в ручную меньше манипуляций.

Хотя в 1 случае мы еще можем проверить и сам факт установки и применимости этих правил

Вообще м дело творческое и сильно зависит от ситуации.
В любом случае ВИ являясь некоторой законченной целостной функциональностью, дает больше возможностей для выделения тестовых случаев.

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

Название: Re: Test Case & Test Analyst
Отправлено: Irr от 22 Сентября 2008, 21:31:48
1. сформировать влияющие правила последовательно и посмотреть как формируется счет
2. найти клиента с некоторым набором нужных мне правил - и создать счет и убедиться, что сумма корректна
Эд, это зависит от цели тестирования + изменений, которые случились+времени, выделенного на тестирование. Если визуалка ввода правил для клиента не менялась, а менялся алгоритм начисления суммы, я бы выбрала 2 вариант.
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 22 Сентября 2008, 21:45:47
Ниже идут мои практические наработки, не претендующие на научность выводов:
Ввод клиентов и изменение у них правил наверняка реже используемая и менее критичная функция, чем расчет суммы/формирование счета. Поэтому вперед стоит смотреть именно формирование счета, как критичное и часто используемое, т.к. если не успеть проверить это, могут быть проблемы гораздо серьезней, чем от ошибки в другом функционале. И в таком случае тест-сценарии будут формироваться не с т.з. последовательного покрытия системы списком юзкейсов, а от покрытия самых критичных мест. И вот эти критичные функции могут не совпадать сценарно с юзкейсами. Такая же ситуация может выйти, когда архитектурно система реализована так, когда функции системы не раскладываются/не мапятся на юзкейсы. В таком случае, если цель тестирования проверить некий механизм/функционал, то пойду от функций, и мне будет по фигу на юзкейсы. В общем, идти надо от цели тестирования (привет товарищу Boatman'у)
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 22 Сентября 2008, 21:54:33
1. Грамотно организованный процесс рзработки, где в основу положен ВИ. ВИ здесь и фрейм предметной области и промежуточный продукт для получения других: постановки задачи на проектирование, написания инструкций по использованию, разработке тестовых случаев
Я бы не сказала, что Грамотно организованный процесс разработки это обязательно процесс разработки, где в основу положен ВИ. Имхо, это еще надо доказать, для меня это не аксиома.
В любом случае ВИ являясь некоторой законченной целостной функциональностью, дает больше возможностей для выделения тестовых случаев.
ВИ отражает динамику системы, а у системы есть и статика, так что я не согласна с тем, что ВИ является законченной целостной функциональностью, достаточной для проведения тестирования.
(ну все, сейчас меня побьют ногами юзкейсшаманы и прочие апологеты религии "юзкейсы это наше все")
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 22 Сентября 2008, 22:28:31
Я бы не сказала, что Грамотно организованный процесс разработки это обязательно процесс разработки, где в основу положен ВИ. Имхо, это еще надо доказать, для меня это не аксиома.ВИ отражает динамику системы, а у системы есть и статика, так что я не согласна с тем, что ВИ является законченной целостной функциональностью, достаточной для проведения тестирования.
В данном случае я имел в виду случай, когда юзкейсы рулят. У нас интерактивная система, построенная по сути на сценариях ее использования. И хотя в основе разработки совершенно не используются юзкейсы, более того они сознательно игнорируются и даже нет никакого стремления их использовать. Тем неменее предложенная мною форма описывания уже имеющейся функциональности через юзкейсы встретила понимание и одобрение. Более того такая форма оказалась понятной и быстро воспринимаемой теми людьми с которыми я начал работать.

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

Цитировать
(ну все, сейчас меня побьют ногами юзкейсшаманы и прочие апологеты религии "юзкейсы это наше все")

Никто тебя не будет пинать. Просто в нашем случае нет ни того, ни другого. Нет не вариантов использования, нет и списка требований по задачам. Есть лишь знания предметки у аналитиков. Есть работающая система. Потому одной из первичной задач было описать функциональность системы, и я избрал форму ВИ.

Цитировать
В таком случае, если цель тестирования проверить некий механизм/функционал, то пойду от функций, и мне будет по фигу на юзкейсы. В общем, идти надо от цели тестирования (привет товарищу Boatman'у)
Я не противоречу тебе. Просто что значит я пойду от функции, а как ты о ней узнаешь? Потыкаешься в системе и поймешь - согласен. Но если у меня будет некий сценарий (ВИ или что-то иное, просто последовательность нажатия клавиш), то это уже дает мне много интересной информации.

1. анализируя каждый шаг - действия пользователя - отклик системы - я могу создать как минимум один тестовый случай, а если на шаге возможны вариации - уже больше
2. каждый ВИ я прошу описывать так - предусловие и возможные состояния в которые перейдет система - опять есть информация для анализа - проверить эти возможные состояния
3. анализа разных Ви позволяет выделить очень похожие шаги в них - аргумент в пользу скриптования таких похожих шагов в виде процедур и функций или скажем так библиотечных элементарных шагов. Это можно вторично использовать при разработке тестовых сценариев просто ссылаясть на эти процедуры или включать их как элементы сценария не вдаваясь в их структуру и анализируя их работу
4. при желании каждая такая процедура может быть сформирована как отдельный тестовый случай - стимул - ожидаемая или неожидаемая реакция

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

5. как уже показал анализ написанных ВИ - проверка их работоспособности часто покрывается одинаковыми тестовыми скриптами. Скажем в случа оформления коммерческой поставки - через исполнение биллинга проверяется влияние схемы поставки.

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

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

А зато я пачками обнаруживаю ошибки юзабилити, например. Правда это следствие постоянной изменчивости системы и отсутствие стабилизированного релиза. Работа по стабилизации которого сейчас активно ведется.
Название: Re: Test Case & Test Analyst
Отправлено: Сергей Атрощенков от 25 Сентября 2008, 19:11:19
Еще замечу - цель тестирования однозначна - обнаружить ошибки, чем больше, тем лучше. Другое дело какие ошибки, вот тут уже начинается по-моему стратегия. В моем случае как я понимаю в первую очередь нужно обнаружить функциональные.
Эдуард, не был бы так категоричен в определении именно цели тестирования. На мой взгляд - цель тестирования - обеспечить наиболее стабильную, удобную и достаточно функциональную информационную систему у конечного пользователя, путем поиска ошибок в программе.

Но что самое прикольное, особых ошибок мне вытащить пока не удается, поскольку так сложилось в проекте, что лучшие выявители ошибок сами пользователи - слава Богу их не мало.
Это с одной стороны хорошо - можно анализировать то, почему ошибки были пропущены, и дополнять тестовые наборы.
А с другой, существуют проекты, которые были в итоге похоронены из-за этого (множество мелких фирм-проектов точно, ну и, на мой взгляд, один из проектов от MS)
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 25 Сентября 2008, 20:48:34
Здравствуйте. Спасибо за интерес к теме.

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

Цитировать
Это с одной стороны хорошо - можно анализировать то, почему ошибки были пропущены, и дополнять тестовые наборы.
А с другой, существуют проекты, которые были в итоге похоронены из-за этого (множество мелких фирм-проектов точно, ну и, на мой взгляд, один из проектов от MS)
Нет я, конечно же, не говорил об этом серьезно. Такой подход наверное вполне подходящий к проектам Open Source, где продукт бесплатен. А когда ты продаешь за серьезные деньги продукт, то пользователь ожидает, что он может выполнять свои задачи, а не задачи разработчика по тестированию :) Более того я в шутке скрываю свое сожаление по этому поводу.
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 08 Декабря 2008, 11:08:56
Вопрос.
Какова стоимость или время разработки Test Case?
Каковы должны быть причины , чтобы не разрабатывались Test Case в компании?
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 08 Декабря 2008, 11:34:27
Вопрос.
Какова стоимость или время разработки Test Case?
Не зная контекста задачи, сказать очень сложно. Это все равно, что вопрос "А сколько будет стоить написать ТЗ?" без указания конкретики о системе.
Каковы должны быть причины , чтобы не разрабатывались Test Case в компании?
Хм. обычно такой вопрос не возникает, так как исторически ситуация складывается наоборот. Если без тескейзов жили и программа продавалась, зачем начинать их писать? Это ж в любом случае затраты.
В такой ситуации вопрос будет звучать так: "Каковы должны быть причины, чтоб начинать разрабатывать Test Case?"
Или это какая-то совершенно другая ситуация?
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 08 Декабря 2008, 11:39:31
Вопрос иначе задам.
Да правильно заметили, если успешно все продавалось , то зачем их писать.
Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?


Название: Re: Test Case & Test Analyst
Отправлено: Григорий Печенкин от 08 Декабря 2008, 12:39:51
Вопрос иначе задам.
Да правильно заметили, если успешно все продавалось , то зачем их писать.
Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?

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

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


В конечном итоге разработка тест-кейсов позволяет экономить главный ресурс - время. Без них просто неизбежны потери времени на повторное  тестирование и доработки уже выпущенной версии. Важно ещё то, что разработка тест-кейсов и проверка по ним включается в план работ и позволяет более-менее адекватно оценивать свои возможности. А авральные переделки и перетестирования всегда оказываются внеплановыми, выполняются за счёт каких-то других (плановых) действий и с большой эмоциональной перегрузкой ("как же достал этот бардак!") и обычно вызывают появление новых ошибок.
Название: Re: Test Case & Test Analyst
Отправлено: Виталий Григораш от 08 Декабря 2008, 17:02:08
....Зачем Test Case нужны?Вот какая польза?Вообще для чего они изобретены?
Так как часто тест кейсы разрабатываются на основе ВИ, то очень удобно проверять систему по этим самым ВИ. Например, разрабатываем мы систему из 10 ВИ, и по каждому написали несколько тест кейсов. В процессе разработки ПО реализация ВИ будет последовательной, инкрементной. Пусть мы реализовали 2 ВИ - прогнали по ним тест кейсы и убедились, что ошибок нет. Далее добавили еще 2 ВИ, которые могли затронуть предыдущие. Прогоняем тест кейсы по новым и старым ВИ, дабы удостоверится, что ошибок в старых нет, те программисты ничего не сломали при добавлении новой функциональности.
Отсюда видно назначение тест кейсов, особенно для автоматизированного тестирования. Мы на практике так делали - работает здорово.
Название: Re: Test Case & Test Analyst
Отправлено: Александр Лобач от 08 Декабря 2008, 17:04:18
Первая жизненно важная функция тест кейсов - документирование нашего знания о желаемом поведении продукта. Тест кейс - это ведь не только что мы хотим сделать руками. Это и что мы ожидаем, и как мы конкретно удостоверимся в получении правильного результата.

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

Третье - документирование того что будет проверяться/проверялось во время тестирования.

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

Название: Re: Test Case & Test Analyst
Отправлено: Григорий Печенкин от 08 Декабря 2008, 17:15:07
Вот и наметилась основа для семинара "Нафига нужны тесткейсы". :) Осталось только под шаблон подогнать.
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 08 Декабря 2008, 17:35:37
Первая жизненно важная функция тест кейсов - документирование нашего знания о желаемом поведении продукта. Тест кейс - это ведь не только что мы хотим сделать руками. Это и что мы ожидаем, и как мы конкретно удостоверимся в получении правильного результата.

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

Третье - документирование того что будет проверяться/проверялось во время тестирования.

Четвертое - Тест кейсы совершенно незаменимы там, где пишутся автоматизированные тесты. Как бы хорошо Вы ни знали Силк или ВинРаннер, надо знать что с этим тулом делать в конкретной ситуации. Автоматизация тестирования без наличия добротных тест кейсов превращается в профанацию и только дискредитирует идею автоматического тестирования как таковую.
Рад что наши мнения совпадают.
А вот руководитель мой считает иначе. :-(
Название: Re: Test Case & Test Analyst
Отправлено: bas от 08 Декабря 2008, 17:49:54
Вот и наметилась основа для семинара "Нафига нужны тесткейсы". :) Осталось только под шаблон подогнать.
Ага, будет хорошим продолжением семинара в Спб. Наши коллеги из другого лагеря (Саша и Сергей) не хотят провести такой семинар?? ;)
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 08 Декабря 2008, 18:18:02
Можно я тоже выскажусь.

Сейчас в компании, в которой я работаю, я как раз отвечаю за это самое тестирование.

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

Такой процесс не дает никакой реальной пользы. Почему?
1. выявить все ошибки не возможно
2. человек даже самый аккуратный не в силах методично и систематически проверять систему (тем более без всякого плана)
3. просто физически аналитик не в состоянии прогнать даже все тесты, которые у него сидять в голове, а следовательно его выводам мало доверия

Простой пример: у меня сейчас сделано не так много тестов, но некоторые направления более или менее покрыты. Например нужно посмотреть работает биллинг или нет. Как обычно поступает аналитик(он же по совместительству тестер). Запускает билинг, выбирает каких-то двух трех клиентов и смотри - о все окей.
Как я поступил - во-первых я выбрал 50 разных клиентов (т.е. с разными начальными условиями). Я написал ОДНУ процедуру проверки и запустил ВСЕХ 50 клиентов на проверку. Из них 10 клиентов не прошли.Причем как выяснилось проблема не в алгоритме биллинга, а некоторых предварительных действиях. Вот этих 10 клиентов при старом подходе мы бы пропустили, а так удалось найти ошибки совершенно другого характера.

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

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

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

Не знаю как в других системах, но в TestComplete есть так называемые сценарии ручного тестирования, которые можно просто понимать как мастера освоения работы с системой :)

Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 09 Декабря 2008, 11:23:08
А есть утилитки которые могут помочь в генерации Test Case?
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 09 Декабря 2008, 18:29:12
А есть утилитки которые могут помочь в генерации Test Case?
Андрей, что значит утилитки? И что значет помочь в генерации?

Тестовый случай разрабатываете вы сами. Опять же на каком уровне. На уровне тестирования классов, функций или процедур - тут одно и средства такие есть насколько мне известно.

Если на уровне тестирования интерфейса, функционального тестирования черного ящика, то есть множестов систем захвата и воспроизводства. В частности Test Complete (http://automatedqa.com).
Он помогает записывать ваши действия с тестируемым приложением. Обычно потребуется некоторая правка полученного макроса.
В TestComplete входят типа утилит программы рекодеры, но только в профессиональной редакции.
Название: Re: Test Case & Test Analyst
Отправлено: Григорий Печенкин от 10 Декабря 2008, 20:05:08
Хорошая статья "TOP 13 ошибок тестировщиков".
Первая часть как раз, главным образом, о тест-кейсах (и немного о требованиях).

http://www.software-testing.ru/library/5-testing/66-top-13----i----

Название: Re: Test Case & Test Analyst
Отправлено: Григорий Печенкин от 10 Декабря 2008, 20:09:21
Для тех, кого заинтересовала статья, продолжение здесь (в первой части я не нашёл ссылки на продолжение):

http://www.software-testing.ru/library/testing/bug-tracking/65-top-13-ii-
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 11 Декабря 2008, 16:11:50
Спасибо за ссылки статей. Довольно интересно
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 12 Декабря 2008, 10:16:45
Спасибо за статью.Хорошо описан пример.Увидел что часть документации у нас написано с ошибками.
Примерно так:

Шаги:
1. Действие 1
2. Действие 2
3. Действие 3
4. Действие 4

Ожидаемые результаты:
1. Результат 1
2. Результат 2
3. Результат 3
4. Результат 4

А для чего нужны Test Plan(тестовые планы)?
Покажите примерчик плиз
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 12 Декабря 2008, 12:53:58
Вопрос по Test Case
Какой вариант более правильнее в написании.Вернее сказать более распространен.
Вариант 1
Название теста
1 Шаг №
2 Описание действий
3 Описание ожидаемого результата
4 Результат

Вариант 2 (См вложение)
Название теста
1 Шаг №
2 Описание действий
3 Скриншот ожидаемого действия
4 Результат
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 12 Декабря 2008, 13:10:31
Вопрос по Test Case
Какой вариант более правильнее в написании.Вернее сказать более распространен.
Вариант 1
3 Описание ожидаемого результата

Вариант 2 (См вложение)
3 Скриншот ожидаемого действия
4 Результат
Более правильный тот вариант, который удобней и понятней в использовании в конкретной задаче конкретным людям. Если результатом должен быть вывод какой-то визуальной информации, то обычно удобней скриншот, если какие-то изменения в данных, еще где-то или скриншота еще физически не существует, то описание.
Это не догма, здесь все подбирается под конкретную задачу. Если некий вариант решает задачу, поставленную перед ним, значит, он и есть правильный.
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 12 Декабря 2008, 13:22:18
А какова в среднеем время изготовления одного Test Case?
И каково в среднем их колличество(10 , 50,100 шт)?
Название: Re: Test Case & Test Analyst
Отправлено: Irr от 12 Декабря 2008, 15:28:40
А какова в среднеем время изготовления одного Test Case?
И каково в среднем их колличество(10 , 50,100 шт)?
Ну как можно ответить на эти вопросы, не зная конкретики системы и квалификации писателя?!
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 12 Декабря 2008, 17:42:08
Андрей, описание тестовго случая должно быть конкретным до мелочей. Будете ли Вы иметь такое описание в виде текста или возможно у Вас будет сразу тестовый скрипт, зависит от того, как организована работа у Вас.

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

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

Вы задаете вопрос лучше описание результата или скриншот: сильно зависит от ситуации. Однако представьте что вы выкладываете скриншот печатной формы документа. Проверять все? Тяжелая работа да иногда и не очень корректная.

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

Количество тестов в минимуме должно соотвествовать количеству требований к системе. Но это недостижимый идеал. Причем ведь надо еще подумать как о положительном тесте, так и отрицательным.

Потому нужно определится со стратегией: как что когда зачем.

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

Время затрат на разработку теста весьма различно. Простой тест - если описание разработать можно очень быстро. Даже если писать скрипт, то тоже не слишком долго, пр определенном навыке. Больше времени уходит на объединение, оптимизацию и интеграцию. Но в среднем удается сделать 4 теста, или меньше (правда я беру только 4-5 часов)
Название: Re: Test Case & Test Analyst
Отправлено: Сергей Атрощенков от 13 Декабря 2008, 18:01:26
А для чего нужны Test Plan(тестовые планы)?
Покажите примерчик плиз

Андрей, рекомендую посмотреть:
http://www.protesting.ru/testing/plan.html
там же два шаблона тестового плана: RUP и IEEE 829
Название: Re: Test Case & Test Analyst
Отправлено: Григорий Печенкин от 14 Декабря 2008, 18:42:10
Андрей, описание тестовго случая должно быть конкретным до мелочей.

Я вот в этом не уверен. Всё зависит от того, для кого описание предназначено.

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

Но я не гарантирую, что это моё окончательное мнение. :)
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 14 Декабря 2008, 19:50:22
Я тоже сначала представлял себе идеальный testcase в виде детальной пошаговой процедуры с исчерпывающим списком проверок (условий прохождения теста). Но постепенно пришёл к выводу, что в небольшой команде, если предполагается, что у пользователя тестового случая заведомо высокая квалификация, оно может быть простым и коротким. Иначе эти тесткейсы окаызвается очень накладно сопровождать (в реальной жизни - они складируются в дальнем углу файл-сервера и никогда повторно не используются).
Может ты и прав. Но моя практика показывает, что тестовый случай должен быть максимально конкретен ( с учетом твоих пожеланий ).

Ситуация:
Тестовый случай - создание счета на поставку по схеме А
Если написать просто: выберите клиента 1, создайте счет на поставку по схеме А. Результат счет создан.

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

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

Кроме того, хорошо созданый тестовый случай может быть полезен во многих случаях (каламбур). Хотя согласен сопровождать сложно
Название: Re: Test Case & Test Analyst
Отправлено: AndreyB от 28 Января 2009, 10:40:58
Андрей, рекомендую посмотреть:
http://www.protesting.ru/testing/plan.html
там же два шаблона тестового плана: RUP и IEEE 829

Спасибо за ссылку и за помощь.
Разработал тест-план и тест-кейсы.
Отдал результаты.
В ответ тишина.

Пользуется кто результатами я не знаю.
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 28 Января 2009, 12:14:57
Разработал тест-план и тест-кейсы.
Отдал результаты.
В ответ тишина.
Пользуется кто результатами я не знаю.
Вообще у меня отчет по результатм генерируется автоматически ежедневно по трем стендам
Всего тестов уже более 200
ПМ меня ежедневно опрашивает по результатам, частенько ругает, никогда не хвалит, много требует

Сейчас прихожу к выводу, что мне нужна система для управления тест-кейсами, присматриваюсь к testlink
Название: Re: Test Case & Test Analyst
Отправлено: Galogen от 11 Марта 2009, 08:01:04
А вот как протестировать веб-сайт?...
Как тестировать такие вещи?
1. Проблема тестирования - проблема разрботчика.
2. Ваша задача проверить соответствие разработке функциям в ТЗ, т.е. Вы сами должны ясно и четко представлять, а чего Вы хотели и действительно сумели донести это до разработчика.
3. Вы всегда сможете проверить работоспособность
  - а локально на некотором собственном стенде
  - б удаленно на хостинге, привлекая для этого кого-то
4. ВИ совокупность сценариев использования имеющих либо положительный либо отрицательный результат - так что по сути уже тест
5. Каждое требование, если оно сформулировано атомарно и однозначно проверяется на соответствие: как минимум тест на прохождение и тест исключения. Типа пароль должен быть не менее 6 символов. ВВодим 6 и более символов. Все ОК. ВВели 5 символов - появлется пердупреждение, страница обновляется. Если это проходит - гуд
6. Вы имеете право потребовать от разработчика (если такова была договоренность) предоставить Вам приемочный план тестирования и сами тесты
Название: Re: Test Case & Test Analyst
Отправлено: bustor от 11 Марта 2009, 09:07:09
Я правильно поняла, что можно для начала записать все функции в виде ВИ (и прогонять их в процессе тестирования)?

Насколько я помню теорию тестирования, бывают разные типы тестирования. То, что приведено в цитате - функциональное тестирование.

Но есть такие вещи, которые к ВИ не относятся - типа какая-нибудь маленькая настройка, и их немало.

Еще бывает:

Думаю, стОит понять, какие виды тестирования вам необходимо провести и почитать про них что-нибудь интересненькое.
Название: Re: Test Case & Test Analyst
Отправлено: Григорий Печенкин от 11 Марта 2009, 10:18:15
Сколько тут много всего интересного понаписано...
А вот как протестировать веб-сайт?...
Столкнулась с такой задачей.
Написала ТЗ, отдала разработчикам. Они там у себя как-то будут тестировать во время разработки, 2-й этап - тестирование на хостинге. Так вот как раз мне нужно придумать, что и как тестировать на хостинге (т.е. как мне проверить, что все, что они сделали, работает как надо).
Я правильно поняла, что можно для начала записать все функции в виде ВИ (и прогонять их в процессе тестирования)?
Но есть такие вещи, которые к ВИ не относятся - типа какая-нибудь маленькая настройка, и их немало.
Как тестировать такие вещи?

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

Тестировщики, в основном, тусуются на форуме it4business.ru (http://it4business.ru/forum), можно там поискать.
Возможно, есть статьи на software-testing.ru (http://software-testing.ru)