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

Caliber в этом плане больше подходит? Вы его используете?

Caliber - удобный инструмент для управления требованиями, мне в нем больше всего пригодились функции группировки требований, представление требований в виде дерева и подсистема публикации - можно настроить Word - шаблон и на его основе сделать экспорт требований в формате Word - документа.

Привет!

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

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

--таким образом нельзя провести smoke test

Вот это я не поняла - что значит нельзя провести smoke test? По какой причине нельзя провести?

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

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

От этого и хотели уйти - от описания конкретного поведения системы. Задача - описать требования в отношении каждого аспекта тестирования.

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


p.s. поздно заметила ответы в теме - прошу прощения за запоздалый ответ :)

Кажется я поняла :rolleyes:

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

Я описала только подход к планированию и документации тестирования - минимальная документация при ОПРЕДЕЛЕННЫХ условиях (которые для некоторых проектов и, возможно даже, компаний не соблюдаются).

Видимо все недоразумения из-за этого :huh:

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

Я не предлагаю в чек листе писать "что именно это должно произойти", чек лист лишь предъявляет требование, которое должно быть КАКИМ-ЛИБО образом протестировано (для разных проектов по-разному). А как именно протестировано - вот это "что именно это должно произойти", и это тестировщик сам определяет как тестировать (для этого необходимым условием является знание тестировщиком корректного поведения системы, что и было оговорено :) ). При наличии времени на описание можно написать как тестировать каждое требование из чек листа для конкретного проекта (это уже будет тест процедура).

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

p.s. поздно заметила ответы в теме - прошу прощения за запоздалый ответ :)

Обычное дело :)

Пыталась как-то недавно внедрить данный принцип работы с чек-листами. Стандартные, часто тестируемые функции описаны отдельно. При тестировании указывается ссылка на чек-лист. Но на практике получилось так:
--всех реально тестируемых функций не охватишь - будет очень большая таблица
--таким способом можно описать лишь ОСНОВНЫЕ, часто встречаемые аспекты
--и они (часто встречаемые аспекты) иногда в соответствии со спецификацией продукта довольно изменчивы
--таким образом нельзя провести smoke test
--неудобно хранить инфу о прохождении тестов - надо постоянно переключаться на другой файл для просмотра что же мы тестировали
--функциональность продукта (работа по назначению)- описать таким способом не получится.

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

Попробовать внедрить все равно стоит -на разных предпрятиях по разному процессы уживаются.

Привет! Немного комментариев для Doveangel :)

--таким способом можно описать лишь ОСНОВНЫЕ, часто встречаемые аспекты

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

--и они (часто встречаемые аспекты) иногда в соответствии со спецификацией продукта довольно изменчивы

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

--таким образом нельзя провести smoke test

Вот это я не поняла - что значит нельзя провести smoke test? По какой причине нельзя провести?

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

Это точно :)

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

От этого и хотели уйти - от описания конкретного поведения системы. Задача - описать требования в отношении каждого аспекта тестирования.

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

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

"... а еще мне петь охота.
За кружок по рисованию
тоже все голосовали."

Doveangel,
Вам повезло в одном - Вы получите представление о всех перечисленных Вами видах деятельности.

Green, вы не могли бы пояснить, что вы хотели сказать этим постом?

Да, впечатляет! :)

Тема называется так:
Develop Unified Tests: the solution, Quick test design, document and testing

(перепутала :) )

Я создала новую тему в разделе Тестирование и качество, т.к. статейка вышла универсальная, к сожалению не знаю как сюда ссылку вставить.
Тема называется Unified Testing System: the solution.

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

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

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.

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

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

Кому нибудь знакомо ощущение ужасной беспомощности когда не можешь чего-то понять? :(

Я за то, чтобы понимать - за русский!

Что верно - то верно
:D

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

Привет!

У меня вопрос - в экстремальном программировании применяется только unit-тестирование или еще какие-нибудь типы применяются?

Привет!

Я пока не изучала ничего по exploratory testing, поэтому могу только подсказать идеи по организации тестирования исходя из своего опыта и поставленных вами, Dimon, проблем.

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

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

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

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

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

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

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

Также есть идеи формализовать направление движения МЫСЛЕЙ тестировщика - то есть как рождаются тесты - в виде чек листов. Как это - у меня есть небольшой опыт, если интересно, могу поделиться.

Здравствуйте :)

Если вы новичок вообще в тестировании, а не только в автоматизированном тестировании, то рекомендую почитать книгу:
"Тестирование программного обеспечения" Сэм Канер, Джек Фолк, Енг Кек Нгуен.
В частности, там рассматриваются вопросы какие тесты стоит автоматизировать в первую очередь. Описана методология разработки и проведения тестирования.

Чтобы что-то автоматизировать, нужно знать что это и ЗАЧЕМ - с какой целью, и стоит ли это автоматизировать. Это первые вопросы, на которые стоит найти ответы.

Про вопросы актуальности внедрения автоматизированного тестирования читайте на этом же форуме:
Automated Testing: Actuality Issues

Если вы хотите использовать UML для описания test cases, то подойдут диаграммы последовательности действий (sequence) или диаграммы деятельности (activity). Правда, зачем вам такое тяжеловесное (на мой взгляд) описание, не знаю.

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

Несомненно полезна! :)

Спасибо за ответ!

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

Как мне видится решение задачи, которую Serega обозначил:

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

2.Составить список контролов для каждого из типов. (Это можно сделать по-разному, наверное и скорее всего, можно автоматически).

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

4.Разработать главную процедуру, запускающую перебор контролов и вызывающую соответствующую процедуру сравнения с эталоном. (Тоже решается по-разному).

Это зависит от того, что понимать под ящиком :) Если ящиком является функция (в смысле программного кода), то все так и есть. Если же ящиком является GUI, с которым пользователь работает, то тут все несколько иначе.

Согласна :)

Нам Serega не сказал, как именно он хочет автоматизировать - копаться в исходном коде или работать исключительно с GUI :)

Тема вызвала бурные обсуждения, с огромным интересом слежу

2Yarilo не сдавайся, твой ход:))

Serega, а тебе действительно все еще надо эти private поля "доставать"? :D

Какой же это "черный ящик", когда вы точно знаете какой метод должен отработать? :)

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

Вообще все эти статьи - о тестировании на уровне кода, что не имеет ничего общего с тестированием "черного ящика", для чего собственно Robot и предназначен.

Я не очень поняла, что Вы имеете в виду под тестированием на уровне кода.... Конечно, при автоматизации придется возиться с исх. кодом проекта (если не написать своего обнаружителя объектов :) )

Статья про тестирование GUI - автоматизируется как раз тестирование по типу черного ящика: автор предлагает только ПОДХОД к тому как имитировать действия пользователя с GUI и сравнивать реакцию системы с ожидаемой.

Может быть я Вас не правильно поняла, тогда поправьте меня :)

Привет! :)

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

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

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

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

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

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

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

По поводу Робота под .NET, не знаю как сейчас, но в его версии до 2000 года под .NET он у меня все время падал и мы оставили идею с Роботом; может быть сейчас что-то изменилось...

Если вы решили автоматизировать тестирование под .NET, то рекомендую ознакомиться со статьями James McCaffrey, они доступны, например по ссылке
http://msdn.microsof.....mes McCaffrey

В частности, статья по автоматизации GUI в Visual Studio .NET доступна по ссылке
http://msdn.microsof...TestAutomation/
Знать C#, конечно, нужно обязательно, чтобы этот способ использовать.
Предложенным способом можно добыть любые поля типа и их значения, даже private (используется библиотека System.Reflection, метод Type.GetField).

В статьях есть прямо отрывки кода для реализации, что делает статьи еще полезнее и понятнее :)

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