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

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

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

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

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

Фирме в которой я работаю необходимо пройти сертификацию по ISO 9001:2000

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

Первым шагом видится прочитать документы по ISO 9001:2000,
тогда станет понятно, насколько фирма готова и чего ей не хватает, следовательно прояснятся задачи, из задач вытекает и время для подготовки :)

Вид описания варианта тестирования завист, кроме всего, от подхода к тестированию. Если вы хотите построить тестирование на основе моделей, то расписывать каждый конкретный flow не стоит.

Что ты имеешь в виду под тестированием на основе моделей?

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

Более подробно можешь поискать в инете, посмотри также подход UniTesK.

По-моему, тестер = тестировщик, только тестер - это русифицированный английский вариант слова tester. То есть, по английски tester, по русски тестировщик - это одно и то же. :)

Привет!
Мне было бы удобнее, если бы новостная рассылка выходила раз в неделю в рамках рассылки 'Тестирование и качество', т.к. я уже подписана на три рассылки по тестированию и качеству и, если честно, иногда в них путаюсь :huh:

Про формат публикации новостей:
Лучше 1-й вариант - он нагляднее (большие отступы между единицами контента), информативнее (есть дополнительные пояснения).
Из 2-го варианта я бы оставила символы жирной точки перед единицей контента, но и без них пойдет :)

Жаль, нельзя несколько галочек наставить. По жизни, приходится многим заниматься :).

Точно!

Может быть завести чек-боксы вместо радио-буттонов на форме голосования? :rolleyes:

4) Вся документация хранится в системе версионного контроля совместно с рабочими документами по разработке ПО

Храним как все остальные документы и файлы с кодом.

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

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

Интересно, а где это так доплачивают (ну хотя бы город скажите)? :rolleyes:

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

Привет!

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

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

Привет!

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

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

Привет!
В нашей компании мы после каждого проекта не проводим собраний, но когда ценная идея (или полезный опыт) возникает по организации работы, мы ее обсуждаем.

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

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

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

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.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это точно :)

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

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

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

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

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

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

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

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

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

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

Привет! :)

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

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

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

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

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

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

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

Спасибо, уважаемый Barancev (даже как-то неудобно по фамилии называть :unsure: ) за совет, я так и настраиваюсь на борьбу за качество, теперь изнутри команды, а не снаружи :)

Если я не ошибаюсь - то пора делать ноги.

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

Ну, скажем, стресс, мы переходим из инкубаторного состояния на рынок :rolleyes:
Мы (тестировщики) сейчас пробуем переквалифицироваться, получится (я надеюсь!) - будем девелоперы на все руки, не получится - сделаем ноги :D

Если начальство перевело всех тестировщиков в разработчики - ещё не всё потеряно. Можно жить и так. Оттого, что тестировщики не называются тестировщиками, они хуже не становятся и могут с успехом осуществлять свою профессиональную деятельность.

Я бы добавила, что если посмотреть на ситуацию из отдаленного будущего, то не только не все не потеряно, но даже такая ситуация полезна:

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

2)теперь тестировщики имеют шанс углубить свои знания в технологиях программирования, архитектурных вещях;

3)разработчики должны будут изменить подход к разработке, чтобы предупреждать ошибки;

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

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