И еще вопрос.

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

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

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

Надя

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

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

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

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

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

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

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

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

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

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

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

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

Надя

Не ругайте, что открыла тему в этом подразделе. Тут были темы про 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

+1 за Баха

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли 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 и другие виды нефунк. тестирования, посколько это позволяет быстро отловить проблемы в коде, связанные с этим. иначе в конце рефакторинг кода приводит к новым ошибкам

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


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

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

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

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

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

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


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

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

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

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

ну вот не верю, что 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

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

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

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

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

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

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

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

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

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

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

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

тест кейсы расписываются в тест планах низкого уровня.

и еще: не держите планы и тест кейсы в секрете! люди должны их видеть обсуждать и использовать.

Здравствуйте. Хотелось бы получить совет, а может узнать что-то новое.

Предметом интереса стал стандарт 829(Test Documentation). Уверен, что тема обсуждалась не раз, но если есть возможность - давайте еще раз поговорим.

1. Сам стандарт. Четкость его соблюдения. Действительно ли дают ощутимые преимущества? (уровень размаха системы, а также необходимые параметры могу в общих словах сказать)

а вы его читали? или просто спрашиваете?

во первых надо понять одну простую вещь:
этот стандарт не определяет строгий список необходимых документов.
он определят только ФОРМУ и СОДЕРЖАНИЕ ОТДЕЛЬНЫХ документов.

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

Я бы начала с:
1. Full Regression Testing
2. Critical parts/path Testing
3. Exploratory Testing
По результатам более глубое тестирование частей...

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

Как то вот так...

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

Вы по результатам эксплорер тестинга собираетесь проводить глубокое тестирование частей?
и что такое "глубокое тестирование частей"?

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

с уважением и небольшим недоумением,
Надя

Уточняю, имелось в виду, что
1. Тестирование использовалось только ручное.
2. Функциональность перенесена полностью.
3. Тестирование, естественно, на новом окружение. Как работает старое мы и так знаем.
4. По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности.
5. Полный цикл - это то, как мы тестировали выводя в жизнь ту, милую, работающую версию с учётом полученного опыта. Что именно и как именно тестировалось - надо узнать у автора.
6. Что касаемо автоматизации и автотестов - это отдельная песня. Всё-таки автоматизация - это помощь в тестирование, а не полная замена.

Надеюсь, удалось рассеять Ваше недоумение! Если нет - могу попробовать ещё.

Галина, читайте по строкам:
Вопрос 1: вы действительно бы тестировали старый функционал на новом окружении в таком порядке как вы описали?
Вопрос 2: вы считаете что старое окружение теперь тестировать не надо?
Вопрос 3: "По результатам 1, 2, 3 (предыдущего моего поста) -> "глубокое тестирование частей". Под глобоким тестирование понимается - выолнение всех тест-кейзов, которые мы имеем для данной функциональности." - после (по результатам )регрессионного тестирования, критикал пас и эксплоритори тестирования вы собираетесь еще гонять все тесты которые у вас были?
Вопрос 4: полный цикл - это то, как вы тестировали? т.е. цикл тестирования для вас - это "как я тестировала" ?
Вопрос 5: об автоматизации речь не идет. идет речь о подходе к тестированию старого функционала на новой платформе - т.е. многим известный maintenance testing.

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

Можно просто Надя.
Сейчас попытаюсь на все ответить. Если что-то пропущу - напишите.


Вот что в моей компании понимают под термином maintenance testing: это тип выполняемой тестерами работы, которая производится каждый раз при внесении каких либо изменений в саму систему ( например, после change requests) либо при изменении окружения, в котором работает эта система.

Вот пример:
Мы поставляем клиентам продукт, который отслеживает изменения в Excel файлах. До марта 2007 года продукт работал только c обрабатываемыми Excel 2003 файловыми форматами. Вышел новый 2007 офис. Наша задача: проверить, как работает наш продукт с xlsx, xlsm,xlsb и пр.форматами поддерживаемыми Excel 2007. Плюс у нас есть заказчик, который работает на Citrix. Готовим к выходу новый релиз

Итак, есть изменения в окружении и есть изменения в системе (так как понадобилось доработать систему )

То, чем тестеры занимаются в этом случае – есть maintenance testing. Можно оспорить термин. Более того, в других компаниях возможно это называют по-другому.

Алгоритм действий (грубый):

1. Анализ изменений в Excel 2007 по сравнению с предыдущими версиями. Анализ принципа работы Сitrix окружения

2. Анализ «затронутых» изменениями в Excel 2007 функциональностей в нашей системе. Сitrix пока пропустим

3. Полный цикл тестирования не поддерживаемых ранее функциональностей. Например, таблицы (не путайте со сводными). Их не было до 2007 офиса. Если система не обрабатывает некоторые фичи нового офиса , например, игнорирует сводные таблицы – убедиться в том, что система их по прежнему игнорирует

4. Проверить удаленные и не поддерживаемые в новой версии офиса функциональности (например, не поддерживаемые старые форматы).

5. Протестировать основную фукциональность. Не только использовать critical path.

6. Протестировать процесс апгрейда системы (если предполагается), установки системы на новое окружение и пр.

6. Протестировать наличие обоих версий систем и обоих версий офиса на одной машине одновременно (если такое поддерживается)

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

8. нефункцильнальное тестирование

9. Полный регрессионый тестинг.

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

Как вы будете тестировать, кто будет тестировать и сколько вы будете тестировать – это все зависит от продукта, рисков, сложности , ресурсов и пр. факторов.

Цикл тестирования – это последовательность этапов тестирования (вкл. Анализ, проектирование и пр). Не важно где цикл описывается, главное, какие этапы в него входят и чем занимаются люди на этих этапах. И цели, которые преследуют люди, проводя тот или иной вид тестирования.

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

Галина, я не пыталась на вас наезжать. Я просто спросила, действительно ли вы в таком порядке хотите проводть тестирования. Я нигде не сказала , это хорошо или плохо. Я нигде не критиковала вас. Иногда люди перечисляют что бы то ни было в разной последовательности. Ваша последовательность видов тестирования показалась мне интересной. Я попросила вас подтвердить. И только лишь. Не ищите подвоха.

По поводу того, надо ли тестированить старое окружение.
Но где-то было это написано. Если в случае рождения ребенка в семье, в системе поле «число детей» должно увеличиться на количество рожденных деток, обычный тестер проверит – выросло ли количество детей на 1 после того, как он «добавил» одного ребенка. Но хороший тестер проверит, не «уменьшилось» ли при этом количество детей в другом месте. Поэтому мы всегда тестируем и старое окружение. Это не обязательно, наверное. Но мы так делаем. Прежде чем выпустить релиз или хотфикс мы проверяем все предыдущие версии.

Учитывая количество ошибок, которое возникает в коде при любой его поправке и сколько по статистике ошибок возникает в процессе управления кодом (имею в виду source control, можно и плохо изъяснилась), если вам позволяют ресурсы, время, и пр – лучше перепроверить и оттестировать старое окружение.

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

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

Надеюсь, ответила на все вопросы

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

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

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

Термин Maintenance testing не переводится как тестирование поддержки. А скорее "поддержательное" тестирование, если вам так будет легче понять. Он может проводиться с использованием люмых методов тестирования, но проводится он после релиза, обеспечивая поддержку продукта.