Exploratory testing - это один из видов деятельностей (как сейчас модно говорить, "активностей" ) тестировщиков. Идет перед собственно тестировнием. Часто идет перед написанием тест кейсов. По сути это знакомство с программой, которое приходится делать ввиду отсутствия документации хоть сколько нибудь приемлемого качества.

PS. Никто не мешает использовать TDD при разработке ПО по RUP или по ГОСТ.

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

Однозначно, нет. Никто не мешает вести адаптивный (agile) проект чистым водопадом, без всяких итераций. Но это оффтопик.

а можно пример? или вы имеете в виду , что внутри каждой итерации тестирование проходит по каскадной модели?

Основное преимущество TDD значительно улучшенное качество кода.Не думаю.

что по вашему есть преимущество TDD тогда?

итак, пытаюсь подытожить то, что было сказано по теме


TDD - это это метод разработки ПО.

TDD часто используется в Agile методологиях. Под Agile мы здесь понимали класс методологий разработки (куда входят Scrum, XP, Agile etc.)

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

Основное преимущество TDD значительно улучшенное качество кода.

сказали, что TDD можно использовать при RUP (но надо поискать больше информации)

методы: в зависимости от рисков и требований к качеству ПО.


я выбрала неправильно слово "рефакторинг" и дискуссии ушли в другом направлении. прошу за это прощение.

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

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

Уважаемые участники форума.Хочу у начальника попросить повысить ЗП .
Я работаю на этой фирме 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. вот только сейчас посмотрела на дату поста, наверное вы уже нашли все ответы :)