Сообщений в теме: 8

[limerik]

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

[Dmitry_NJ]

Чтобы научиться делать что-то (неважно что - писать тестовые процедуры или заниматься любовью) надо пробовать это делать.

[Rost]

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

Добрый день.
Могу посоветовать такой алгоритм:
1. Понять что это;
2. Узнать как это сделать;
3. Проанализировать, только честно, способны ли вы на такое?
4. Принять решение и выполнять его.

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

[DNA]

Согласен с Дмитрием. Лучший способ научиться что-то делать - начать это что-то делать.

Лирическое отсутпление.
Есть еще вторая ступень знания. Чтобы что-но научиться делать действительно хорошо - нужно научить это делать другого.

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

[Kaluga]

Друзья,
Ну вы и намудрили :) Целая философия.

3. Проанализировать, только честно, способны ли вы на такое?
4. Принять решение и выполнять его.

Надеюсь, что все же это стеб ;)

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

[Kammi]

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

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

[d4lt]

Вспоминаются времена написания моих первых тестовых процедур...
Тогда я пришел к выводу, что актуальные тестовые процедуры никуда не годяться, отстали от времени, в достаточной степени не охватывают требования к безопасности и т.д.. В результате, после недели креатива по 16 часов в день, было рождено ОНО, тогда еще в очаровательном формате Excel :) Мне казалось, что это практически "идеал" для процедур: их было относительно немного (около 3000), они были логически скомпонованы, документ имел более понятный дизайн, дополнительные макросы позволяли собирать больше метрик и выбирать регрессионные кейсы для будущих тестовых циклов на основе введенных результатов и предполагаемого количества циклов. В общем, я был доволен. До пробного старта.
Моя же Муза посмеялась над моей наивностью и невежеством, это было ужасно. ЗАЧЕМ я ЭТО написал? Большая часть тестов никуда не годилась! Все чаще приходило понимание нормальности прошлой версии процедур :) На исправление ушли еще 5 дней, 10 литров кофе и 50 листов, испещренных схемами и графиками поведения программы.
Я считаю, что для меня это был один из самых ценных уроков по тестированию, приведшему к нескольким простым правилам написания процедур.

Итак, что нужно для достижения приемлемого результата:
1. Просмотреть примеры процедур, изучить достоинства и недостатки прошлых версий (если есть);
2. Постараться написать первый набросок исходя из use-case'ов, а затем добавить недостающие тесты для покрытия требований;
2.1. Постараться избежать точных указаний действий, так как структура приложения может измениться, но не обязательно при этом менять все тесты :)
2.2. Проставить для кейсов ссылки на пункты в спецификации, чтобы после можно было бы проверить степень ее покрытия;
2.3. Желательно сделать каждый тест независимым от остальных, т.к. тесты будут гоняться разными людьми, и будет неприятно, если для прогона одного теста нужно прогнать еще и предыдущий, который уже сделал другой тестировщик час назад;
3. Дополнить сценарными тестами;
4. Разбить кейсы на группы, при этом постараться, чтобы требования для первого теста были близки ко второму, и т.д.. Время цикла будет быстрее, если тестировщик в одном тесте будет заполнять файловую систему и проверять первый запуск приложения, а в следующем совершать действия опять же с полной файловой системой (нужно учесть п. 2.3).
5. Отревьюировать документ. Пригласить нескольких тестировщиков, пусть они дополнят кейсы :)
6. Прогнать пробный тестовый цикл + немного потестить, не опираясь на сами процедуры;
7. Изменить документ в соответствии с найденными проблемами;
(8). Изменять и дополнять процедуры после каждого тестового цикла в соответствии с найденными дефектами, - это значительно облегчит задачу выбора регрессии.

P.S.: Прошу простить за мой русский, пишу в пятницу вечером :)

[greesha]

Разрабатывать тесты на основе use-case это хорошо, даже замечательно, при одном условии: они у вас есть и соответствуют живой версии софта. :) Мне до сих пор в этом случае не везло: о use case я читал только в книгах, сейчас пытаюсь хотя бы объяснить программистам, что это такое. Только в этом году удалось убедить руководство, что в команде нужен отдельный аналитик, но его, конечно, сразу бросили на новые проекты, а все требования к существующим приложениям так и содержатся в головах программистов.


А что в данном случае понимается под тестовой процедурой? Процедура - это такое слово, многозначное...
И вообще, limerik сюда вернётся, интересно?

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

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

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

При выполнении тестового случая выполняется набор проверок, представляющих собой вопросы с вариантами ответа "да" или "нет" (как правило.

Пример, из самого свежего. Клиент обнаружил, что очередная версия скрипта создания базы данных завершается с ошибкой (Создаваемое VIEW1 ссылается на VIEW2, которое на этот момент ещё не создано). Скрипт тупо генерируется MS SQL 2000 командой "Generate SQL Script", и до сих пор таких проблем не возникало. Тут же пришлось добавить дополнительный тест в план выпуска релиза.

ТЕСТ
Название теста: Создание новой базы с помощью SQL скрипта
Цель теста: Убедиться, что поставляемый скрипт корректно создаёт все объекты базы данных.
Подготовка к тесту: Предполагается, что на компьютере тестировщика установлены MS SQL Server и тестируемая версия XXX
Описание теста:
В состав поставляемой программы входит скрипт XXX_MS_SQL.sql для создания объектов базы данных. Этот скрипт генерируется средствами MS SQL Server.
После генерации скрипта он должен быть отредактирован программистом вручную.
Последовательность операторов в скрипте может быть неверной, и в результате выполнения скрипта может завершиться ошибкой, при этом некоторые объекты БД не будут созданы.
Кроме того, MS SQL Server 2000 при генерации скрипта использует языковые настройки по умолчанию, в частности, добавляет параметр Collate в команды создания объектов базы данных. У клиента, использующего другие языковые настройки, этот параметр приводит к неправильной кодировке данных и потери части информации.

ТЕСТОВЫЕ СЛУЧАИ
Порядковый номер: 1
Цель: Убедиться, что скрипт создания БД выполняется без ошибок и не содержит параметров collate.
Последовательность действий:
1. Создать новую, пустую базу данных с помощью Enterprise Manager.
2. Подключиться к новой базе из Query Analyzer.
3. Загрузить скрипт ХХХ_MS_SQL.sql из каталога установки программы
4. При активном окне, содержащем скрипт, выполнить поиск строки Collate (для открытия диалога поиска нажать Ctrl-F).
5. Выполнить скрипт (нажать F5)

ПРОВЕРКИ
Порядковый номер: 1
Скрипт не содержит параметров collate? Да/Нет
Порядковый номер: 2
Выполнение скрипта завершилось без ошибок? Да/Нет


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

[limerik]

Спецификация...тесты,use-casЫ....
Оказалось,что под этими громкими словами "Тестовая поцедура" понималось сочинение "Как я провел лето...", точнее, чтобы я сделала, если Б! была спецификация или уже были частичные готовые разработки !
Спасибо всем, кто отвечал, может быть, у кого-то еще появляться какие-нить предложения на эту тему...