Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

вот вы зря, на мой взгляд, говорите, что разработка вас не интересует.
попробую сейчас объяснить почему.
TDD может использоваться в методологих Agile. суть любой методологии Agile (их несколько) сводится к разработке ПО интерациями. Выглядит это примерно так (например): проект разбит на итерации. скажем, каждые 2 недели. в конце каждой второй недели заказчик должен получить ощутимый результат - продукт, с неработающими фичами, как правило, на начальных итерациях.
в понедельник все собрались, поняли что будет в сделано в новой итерации. и тут же все сели работать. разработчики- код писать (некоторые составляют decision table matrix), тестеры - писать скрипты (даже если они явно провалятся вначале) и т.д.

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

в каждой итерации идет component testing (unit testing), integration (который тестирование взаимодейтсвие компонентов - функций, процедур и тд) testing.
если UI тестируем, то можно проводить Exploratory testing. однако как правило в коротких итерациях не хватает времени для него и его откладывают до той итерации, когда Ui нормализуется. а на начальних занимаются boundary analysis например. тестируют функционал формальными методами.

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

Странно, не вижу там слова agile. Может это просто виды тестирования для итеративного тестирования (iterative testing) как там написано?

вот источник: http://www.io.com/~w..._challenges.pdf
сперва он дает краткие характеристики (однословными понятиями) Agile подхода (Incremental, Iterative, Adaptive), а потом объясняет каждое понятие в контексте методов тестирования.

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

ну вот не верю, что Agile обходится без итераций
вот смотрите: из Петтихорда:

What is Agile Development?
Incremental, Iterative, Adaptive

Incremental

•Build a system gradually
•See the system grow
•Demonstrating progress

Iterative
•Multiple releases or check points during a project, each closer to the target
•Iterations include requirements development and testing
•Typical iterations are two weeks long
•Plan as you go

Adaptive
•Goals change based on lessons from prior iterations, feedback and business opportunities

в прикрепленном документе рекомендуемые виды тестирования при Agile

ВСЕМ БОЛЬШОЕ СПАСИБО !!!
Ваши советы очень помогли мне принять решение !!!

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

Уважаемые участники форума.Хочу у начальника попросить повысить ЗП .
Я работаю на этой фирме 6 месяцев, и ЗП у мен 270$. Как по вашему, это нормальная ЗП для тестера.Это мое первое место работы.
И какие аргументы для повышения можно выдвенуть????????????????

Простите меня, пожалуйста. Выскажу сейчас своб личную точку зрения.

а не рано ли вам просить повышения? 6 месяцев это не очень то большой срок, если честно.

на первой работе работают (работали, наверное..) за гроши и получают опыт и знания. За 270 долларов не прожить, согласна. Поэтому если вы чувствуете, что стоите большего, это хорошо. Надо показать это. Возможно ваш начальник просто не видит, что вы стоите большего?

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

просить надо, но аккуратно.
Удачи вам! и правильно сказали - учитесь. не теряйте время!

Смотря , что включаете в "прогон одного цикла тестирования программного продукта". Планирование? Разработку тестов? Развертываение и поддержку тест окружения (простите, не знаю какой термин употребляется environment)? стресс тестинг включаете? объем тестинг включаете?

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

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

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

если юз-кейсов нет, используем разбивку функциональности на тест-объекты. уровень глубины определяем сами. мы не пользуемся Functional Point Analysis о котором писал Green как мне кажется.

Ошибаемся ли мы? да, но стараемся.

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

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

Любая матрица - это таблица. Traceability можно перевести как "отслеживание". В процессе тестирования (и разработки ПО в целом) очень важно отслеживать взаимосвязь понятий, утверждений, компонентов - entity одним словом. например, бизнес -требований и тест требований, или тест требований к тест кейсам и т.д. Отслеживать подобные связи надо на протяжении всего цикла разработки. на протяжении процесса пазработки ПО пободные связи меняются, пересматриваются, переделываются. Но в каждый момет и менеджер, и тестер и аналитик должны четко понять что с чем и как связано.

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

самая простая матрица связи выглядит как в приложенной картинке


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

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

Мы тоже иногда внедряем ошибки и называем такое тестирование Robustness (помехоустойчивость?). Обычно это попытки сымитировать какие-нибудь внешнее ошибки (типа специфических сбоев сети). Основная цель - узнать не впадает ли программа в ступор или кору (hang или crash); и может ли адекватно среагировать на ошибку (правильно отрепортить ее). Дополнительно проверяется и тест - а попадает ли он в "больное" место.

Алексей, проверка устойчивости системы в случае выключения электричества - это немного другое.

1. В каких целях\областях он используется?
2. Насколько полезно такое тестирование? Реально ли можно найти ошибки, которые иначе найти затруднительно?
3. Как планируется тестирование для данного вида?
4. На каких этапах разработки ПО применяется?
3. Ну и какие инструменты используются? Хотя уже и есть такая тема, но она без ответа :(

1. В основном используется при тестировании компонентов. Причем не только их изолированное тестирование, а часто при их интеграции. Знаю, что компании , поставляющие на рынок например RAD контроллы, используют этот метод.

цель упрощенная: посмотреть, как компонент "реагирует" на ошибки. способен ли он вернуться к рабочему состоянию

механизм: внедряется ошибка (создается или вызывается) в процессе тестирования и анализируется, как компонент реагирует на эту ошибку.

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

3. планируется как и все остальные виды тестирования. ничего специального не видела никогда.


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

+1 за Баха

Не ругайте, что открыла тему в этом подразделе. Тут были темы про ISEB Foundation, поэтому открываю здесь.

Наверное, многие уже знают, что с марта 2008 года экзамен ISEB Practitioner разбивается на 2 экзамена: ISEB Practitioner in tets Analiysis и ISEB Practitioner in Test Management. Кроме того, чтобы иметь возможность сдавать любой из этих экзаменов, необходимо иметь сдать ISEB Intermediate экзамен и иметь на руках сертификат.

Чтобы иметь возможность сдавать ISEb Intermediate, надо иметь на руках ISEB Foundation.

Вот такие новости.
Источник: официальный сайт BSC http://www.bcs.org/s...00101000200301t

Простите, если не поняла правильно вопрос. Но мне кажется, что уместно будет рассказать, как мы сейчас используем Test Partner.
У нас два десктопных приложения (веб интерфейс к ним пока не в счет): - клиент и консоль управления. Они оба работают с одной БД.
Мы создали свой фреймворк, который позволяет очень быстро создавать новые автоматизированные тесты путем изменения нескольких параметров.

Тест БД хранится на отдельном сервере. Все всходящие параметры для автом тестов хранятся в ней. так называемые "ожидаемые результаты" хранятся там же.

В ходе выполнения скрипта (авт теста) данные считываются с окна приложений, записываются в БД. затем данные сверяются: то, что записали с тем, что ожидаем. В конечном счете у нас есть 2 результата:
1. результат выполдения авт теста: успешно или неуспешно
2. так называемый лог файл - где мы видим результаты сверки ожидаемых результатов с теми, что у нас на экране..

До перехода в эту компанию я никогда не видела такого подхода. Но он идеально вписывается в наш процесс тестирования. Может, и вам подойдет.

Надя

какого рода письмо?

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

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

Из своего опыта: постеснялась дважды просить больше. но поговорила с агентом. в последний раз он выбил еще 5К в год.
Зареклась в следующий раз попробовать самой написать такое письмо :)

Может, кому то это поможет!

The Art of Software Testing, Second Edition by Glenford J. Myers

может и я кому то смогу поспособствовать...
глава 4 касается только тест проектирования. много примеров. написана неплохо.

И еще вопрос.

Кто знает где можно скачать пробную версиюTestPartner и докумнетацию.

Обращался в RedRoxx ответа нет:(

Вот тут http://software-test...?showtopic=9427 я описывала кратко наш подход к тестированию десктопных приложений, используя Test Partner. там совсен кратко, но если есть еще вопросы - напиши, я постараюсь ответить более подробно..

Надя

P.S. вот только сейчас посмотрела на дату поста, наверное вы уже нашли все ответы :)