Привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот так, два ответа в совокупности дали ясную реалистичную картину из мира автоматизированного тестирования и прояснили мои догадки и вопросы.

Спасибо, Darkus, за подробный ответ и, в особенности, за пример!

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

Да уж, точно не играют!

У нас в компании в некоторых проектах сами разработчики пишут автоматизированные тесты для конкретных функций кода (unit-тестирование), а тестирование как процесс заключается в прогоне системы по вариантам использования (иногда нигде не документированным) с различными тестовыми данными вручную, причем регрессионное - большая редкость, т.к. жизнь проекта - от 2-х недель до 3-4-х месяцев.... А теперь и вообще, отмирает тестирование :( - говорят и без него жить можно.

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

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

Вот это да!!!
Вот так Dmitry_NJ!
Спасибо за ваш развернутый ответ!!!

Теперь у меня нету сомнений в том, что автоматизация тестирования GUI систем в нашей компании в текущей ситуации - несбыточная мечта (и можно спокойно принять этот факт :) )!

Привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет! :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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? По какой причине нельзя провести?

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

Это точно :)

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

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

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

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

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

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

Привет!

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

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

Привет!

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

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

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

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

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

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

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

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