Yarilo

Привет!
Хочу поделиться идеей и предложениями по разработке и описанию унифицированной системы тестирования.

Постановка проблемы.

1)Ограниченное время (вплоть до его отсутствия) на проектирование и описание тестов.
2)Сжатые сроки выполнения тестирования.
3)Масштабная система на разработку тестов для которой требуется слишком много времени, которого не предоставляется.
3)Необходимость разработки минимальной документации для автоматизированного тестирования (правда, это только предложение, мной не опробовано).



Необходимые условия для применения решения.

Тестировщик должен знать как должна работать каждая из тестируемых функций системы. Должен быть список тестируемых функций продукта (может быть незадокументирован, может составляться налету с тестированием).


Решение.

Основная идея заключается в том, что необходимо один раз (конечно не за один раз, а итеративно дополняя от проекта к проекту или в течение жизненного цикла продукта) описать общую схему для тестирования программного продукта. Описать эту схему так, чтобы можно было ее использовать для тестирования ЛЮБОГО программного продукта - с небольшими дополнениями, минимальной модификацией схемы.

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

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

Чтобы составить схему системы тестов предлагается выписать все аспекты тестирования, к каждому аспекту составить список требований, которым должна удовлетворять система в отношении тестируемого аспекта. Также можно написать при надобности процедуры тестирования для каждого требования (по крайней мере, тестировщик должен знать каким образом возможно протестировать каждое требование). Оформить можно в Excell файле в виде таблички.

Замечание: см. пример.


При исполнении тестирования используется следующая последовательность действий:

1)Выбирается функция для тестирования.

2)К функции подбираются аспекты тестирования, которые будут к ней применяться (могут применяться не все аспекты).

3)Функция тестируется в отношении каждого из подобранных аспектов тестирования - проверяется выполнение требований к аспекту согласно процедуре тестирования.



Замечание:

можно каждому аспекту, требованию [, процедуре] сопоставить уникальный идентификатор и вести отчет о тестировании в виде чек листа (тест ID/ номер версии продукта/результат прохождения теста). Идентификатор теста будет состоять из набора идентификаторов аспекта, требования [, процедуры].

__________________________________________________________________
Пример:
аспекты:
Access to Features (для тестирования возможности правильного вызова тестируемой функции - например, возможно ли нажать на кнопку, которая должна быть enabled, нажатие на кнопку - это вызов функции feature),

Empty Database (для тестирования корректности работы системы на изначально пустой базе данных),
Save Object (для тестирования корректности сохранения бизнес-объектов в системе в различных ситуациях),

Creation of the System Object (для тестирования корректности создания различных бизнес-объектов в системе в различных условиях),

Modifying System Object (для тестирования корректности модификации различных бизнес-объектов в системе в различных условиях),

Duplicated Records (должна ли система допускать дублирующиеся экземпляры бизнес-объектов/записей),

Boundary Testing (тестирование вводов системы),

GUI (тестирование графического интерфейса),

Help/Hints (тестирование корректности системы подсказок и помощи)

и прочие - в зависимости от того, какие аспекты системы вам необходимо протестировать.



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

1)All controls/elements in the window/form are correctly displayed — all bounds of the controls are shown.

2)Each element on the window/form has a correct name (does not contain lexical errors, the first letter of each word of a name is uppercase).

3)There are no redundant GUI elements in the interface.

4)Tab order in the window/form is correct.

5)Labels do not intersect other controls (test on less monitor resolution 800/600).

6)Scrolling is everywhere if necessary. If possible, try to resize (deflate the width and height) the window and validate that all controls/elements of the window are still accessible to view.

7)Drag & Drop should not work in a Navigation Tree control.

И далее в таком же духе.
___________________________________________________________________

Жду ваших откликов! :)

Привет! :)

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

Чем отличается его работа от бизнес-аналитика?

Какие артифакты должен уметь создавать такой специалист?

Из каких специалистов (и с каким образованием) набирают людей на спец. по консалтингу?

Какие методы работы применяются?

В каких фирмах этот специалист требуется - только в специальных консалтинговых или в каких - то еще?

Если кто про это что-нибудь знает или знает соответствующие ресурсы, пожалуйста, откликнитесь!

Привет!

У меня такой вопрос - может быть кто-нибудь знает о стандартных концепциях (моделях) построения подсистемы управления правами в бизнес-приложениях? Также в моделях интересуют алгоритмы вычисления прав. Мне нужны сами документы или ссылки на источники.

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

Привет!

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

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

- затраты на тестирование, основанное на скриптах, при малейших изменениях функций системы будут расти в геометрической прогрессии => слишком дорого, чтобы применять в проектах с неводопадным жизненным циклом разработки;

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

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

В связи с этим у меня вопроы давно такие:

1.Для небольших проектов (4-5 разработчиков, 1-3 месяца работы) стоит ли автоматизировать тестирование, если стоит, то:

- какой тип тестирования нужно автоматизировать (модульное? системное?)?

- какой тип автоматизации использовать (скрипты для use cases? скрипты для функций имплементации самого нижнего уровня? тестирование на моделях - относительно use cases? тестирование на моделях - относительно функций имплементации самого нижнего уровня?)?

2.Какое должно быть соотношение тестировщиков по отношению к разработчикам чтобы можно было вообще думать о возможности автоматизации?

3.Обязательно ли начинать работы по подготовке и разработке автоматизированного тестирования с самого начало разработки самой системы? (если нет, то когда начинать)

4. Чего вы вообще автоматизируете?! (отчаянно) Имеется в виду, какие типы приложений (бизнес-приложения с клиент-серверной архитектурой, web-приложения с архитектурой клиент-web сервис..., сайты на PHP писанные и пр. виды).

Люди, пожалуйста, откликнетесь!!!!