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

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

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

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

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

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

Странно, не вижу там слова 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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

Учиться надо ДО того как готовиться к экзамену, при подготовке надо повторять уже изученное. Или вы в институте не так делали? В противном случае получиться то, о чем говорит Case.
PS Самый клинический случай экзамена это вот такой.

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

где им уметь "уже изученное" если на работе они щелкают по кнопкам?

Повторюсь :) Учиться нужно, читать нужно. "Сдача экзамена + получение сертификата" не равно "учиться тестированию".

готовиться к экзамену = учиться

Надя, учить и учиться надо.

Вот только вопрос был не про обучение, а про сертификацию ISTQB, которая не имеет ценности в пределах СНГ.

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

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

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

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

скажем так, можно для всего этого не сдавать ISTQB. можно читать хорошие книги.

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

Даже если в Беларуси не значит, то заказчику из англии или германии затолкнуть подороже тестера получится

это что ситуация так поменялась и теперь белорусские аутсорсеры по разным расценкам продают тестеров с сертификатами или без них?
понимаю, что senior tester может по расценкам идти дороже, чем junior . но вот чтоб junior шел с сертификатом дороже, чем без...

наверное ситуация меняется, если это так..

к сожалению, пока беседы с некоторыми тестерами (совсем даже не начинающими) из Беларуси или Украини или России зачастую показывают поразительное отсутсвие знание основ тестирования. не все конечно. но многие.. вчастности те, кого продают аутсорсеры.

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

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

осмелюсь предложить свое видение переводов англ терминов:

1. Дефект – это ошибка в коде ПО.
Баг же может быть: неправильный цвет сообщения об ошибке.
Т.е. если говорит языком множеств: Баг больше или равно Defect

2. Действие человека, которое позволило ошибке в По проявиться – является an error.

3. Дефект (a fault) – проявление ошибки в ПО. Тестеры как правило ощут дефекты, допуская ошибки в действиях нарочно

Логическая цепочка такая:

Тестер допустил ошибку нарочно (an error) - > это вызвало падение системы или отклонение от ожидаемого поведения (a failure) , потому что в системе есть дефект (a fault)


Обнаружение бага (a bug) всегда является инсидентом (an incident), как уже сказали. Но баг не всегда вызывает отклонение от ожидаемого поведения (a failure).

Мы используем вместо «bug» “issue” когда найденный баг серьезно отразится на работе наших клиентов. Т.е. мы употребляем issue когда серьезные проблемы у клиентов могут возникнуть если мы срочно баг не исправим. Но Баг для нас это не issue


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

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

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

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

если ваш заказчик требует и вам ну никак не жить без этой работы - сдавайте.

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

зачем ругать то, что выполняет одну из целей своего существования?

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

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

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

Термин 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, можно и плохо изъяснилась), если вам позволяют ресурсы, время, и пр – лучше перепроверить и оттестировать старое окружение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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