очень интересует как организовать этап тестирования GUI

M arilou

Модератор: вынес в отдельный топик из "Цикл разработки ПО"

Зависит от объема работ и цели тестирования.

1. Если цель - проверить гуй на корректность работы, а объем большой, рекомендую посмотреть в сторону средств автоматизации - к примеру, WinRunner
2. Если объем не большой или гуй меняется довольно часто, то лучше чтобы тестировщик работал. 
3. Если цель - гуй на юзабельность проверить, нужно привлекать специалиста по usability, или опытного тестировщика

Все баги и замечания должны где-то централизованно храниться.

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

некая последовательность действи которые должен проделать тестировщик что бы проверить все возможные режимы работы

Предположим по нажатию кнопки может выполнится действие А или действие Б, а то какое из этих действи выполнится зависит от условия V, получается что бы протестировать нажатие кнопки ее нелдостаточно нажать 1  раз.

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

Frees, пускай тестировщик берет Mercury Test Director, и занимается  написанием тест-кейсов на функциональность. Из тесткейсов можно собирать группы: smoke testing, regression testing, acceptance testing. 

А без бранных слов тестировщик не может написать план тестирования?

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

Mercury Test Director
тест-кейс
smoke testing
regression testing
acceptance testing

а также узнать ответ на вопрос: как же все-таки организовать этап тестирования этого самого интерфейса?
увидела пока только ответ на вопрос "кто должен этот интерфейс тестировать"
совершенно непонятно, что делать, если у вас нет этого самого Mercury Test Director

пока пишу сценарии тестирования ручками и рисую таблички типа CRUD (применительно к моей задаче) для разработчика.

Это сообщение отредактировал(а) ida - 30.6.2009, 12:56

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


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


полное тестирование всей функциональности


тестирование, по результатам которого принимается решения о приемке билда тестировщиками или клиентом


тест-кейс - это как use case, но для тестирования

1) список действий для проверки фичи
2) ожидаемый результат
3) полученный результат
4) статус: passed/failed


можно в экселе, просто ручной работы будет много


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

ну а вот собственно пример можно привести? КАК же все-таки написать план тестирования.

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

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

Зачем план? Тесткейсы изолированы друг от друга и нет никакой последовательности, в которой они должны выполняться.

Если нет плана действий, то проект никогда не будет завершен 

тест-план - это и есть наборы тест-кейсов для smoke, acceptance и regression тестов. одни и те же тест-кейсы могут одновременно находиться в нескольких категориях.