Ну какая-нибудь страшная и злая рожица еще лучше с топающими ногами

P.S. Блин ну почему меня после отправки сообщения выкидывает в корень ветки форума в которой находится тема

Не, Саша., ты не понял. Не тебя донимать, а МЕНЯ - Галогена, то есть. Но читается да как тебя:)

P.S. Блин ну почему меня после отправки сообщения выкидывает в корень ветки форума в которой находится тема

Саша, в настройках полазь. Там можно настроить способ куда тебя отправлять после публикации заметки

Не, Саша., ты не понял. Не тебя донимать, а МЕНЯ - Галогена, то есть. Но читается да как тебя:)

Уважаемый , Галогеноджан!
Буду вас донимать. :-)
Возьмем ситуацию.Вам надо протестировать систему.
Например некоторую примочку , которая работает с 1С.
Предположим у вас работают профи тестировщик и новичок.
Кто-то из них работает удаленно а кто-то у заказчика.
Что им понадобиться для тестирования?
Какие документы?

Предположим у вас работают профи тестировщик и новичок.
Кто-то из них работает удаленно а кто-то у заказчика.
Что им понадобиться для тестирования?
Какие документы?

Как минимум им понадобится тестовый стенд.
Под "какие документы" понимаются входные или те, что они сами разрабатывать будут?

Под "какие документы" понимаются входные или те, что они сами разрабатывать будут?

конечно входные документы

Возьмем ситуацию.Вам надо протестировать систему.
Например некоторую примочку , которая работает с 1С.
Предположим у вас работают профи тестировщик и новичок.
Кто-то из них работает удаленно а кто-то у заказчика.
Что им понадобиться для тестирования?
Какие документы?

Я и сам большой новичок в этом деле.
Как учит нас литература от гуру - нужно иметь план тестирования, т.е. набор неких тестовых сценариев или может фичей которые следует тестировать (будет скорректировано после разъяснений alexlobach).
Эти фичи проранжированы, для них определены сроки и ресурсы тестирования.
По фичам наверное нужно разработать тестовые сценарии и подобрать данные и ожидамые результаты.
Ну а по сценариям формируем тестовые случая с использованием классов эквивалентности, например.

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

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

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

конечно входные документы

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

Эдуард, пожалуйста, не путай план тестирования и набор неких тестовых сценариев. Это абсолютно разные вещи

Эдуард, пожалуйста, не путай план тестирования и набор неких тестовых сценариев. Это абсолютно разные вещи

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

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

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

Какие вопросы я должен задавать?Чтобы расширить свое понимание о системе.

2 Эдуард
Тест-план (план тестирования) документ описывающий кто, что, когда и как тестирует, или не тестирует
Хотел написать ответ здесь, но понял что потом будет еще больше вопросов
Постараюсь в течение 2х-3х дней подготовить статью на эту тему, в смысле какая нужна документация

2 Андрей
порекомендую как и Эдуарду начать с описания Вариантов использования на основании тех знаний, которые вы можете получить у людей "которые  что-то знают"

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

Андрей, Вы не одиноки. Большинстов сталкивается с тем, что нет спек, ничего не известно. Но ведь есть программа:)

Для того чтобы погрузиться в процесс нужно:
1. изучить функциоанл программы
2. беседовать с аналитиками
3. беседовать с программерами
4. записать на форум по тестированию и активно его читать и общаться

Обещанная статья http://www.alexlobach.ru/2008/09/03/artefakty-neobxodimye-dlya-testirovaniya/

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

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

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

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

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

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

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

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