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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

+1 за Баха

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

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

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

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

Надя

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

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

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

Термин 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 и пр.. ваш регрешн сюит даже может не запуститься на новом оборудовании

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

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

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

не благодарное ето дело manual testing

Ира, да что вы такое говорите? вы уверены, что выжимаете из ручного тестирования все, что можно? может, мы понимаем разные вещи под ручным тестирование??

Ваша фраза напомнила фразу о том, что многие считают black box testing бесполезным занятием. Глупость. и только.

Все выше сказанное - моя точка зрения.

Нет black box testing не бесполезным занятие, а наоборот необходимое ...а не благодарное дело это потому как нечего показать кроме как результата (нормально работающего продукта), а главное что меня беспокоит что все-таки чтоб команда ..как бы правильнее высказаться .. прогрессировала хотелось бы внедрить хотя бы "чуточку" автоматизации..не не во вред срокам, дополнительным деньгам, и ресурсам...
Спасибо.

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

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

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

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

про black box testing это совсем было не к вам :) no personal offence.
сам факт, что вы думаете о развитии тестеров - уже большое дело. удачи вам!

Автоматизация тестирования - это прежде всего поиск выгоды (т.е. экономии затрат).

Прежде чем убеждать клиентов, подумайте и убедите себя. сейчас вам надо 200 рублей на ручной тест низкой сложности, автоматизировать его вам будет стоить 2000 рублей. плюс на переделку и отдалку понадобится еще 2000 рублей, так как первые тесты никогда не бывают удачными.
итого, 4000 рублей на автоматизацию одного простого теста. т.е. 20 тестов ручных за это время можно было бы прогнать. автоматизация одного теста стоит пропущенных 19 тестов и багов вместе с ними?

посчитайте свои потери, перед тем как начнете все автоматизировать.

автоматизировать надо так, чтобы тесты находили баги. на дизайн такого теста и его автоматизацию требуется больше ресурсов, чем 1:10.
действительно ли это выгодно вам и вашим клиентам?

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

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

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

удачи вам в любом случае!

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

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

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

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

за комментарий- спасибо :)

Мне нравится спрашивать, есть ли разница между тест-архитектором и тестером, тест- аналитиком и специалистом по тест-автоматизации.

Как ни странно, но есть соискатели, которые не видят разницы в этих направлениях деятельности тестера.

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

Эх, не по теме.. но душа утром проснулась и улыбнулась. Дожди в Лондоне закончились. на целую неделю обещают солнце. И долгожданный отпуск... ура! Лечу в Беларусь, потом Питер и в Прагу. не спустить бы сейчас все деньги на распродажах :) я не заядлый шопер, но ведь первый день отпуска! вот вернусь и с новыми силами перебираюсь в Сити, а сейчас просто лето...

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

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

модераторы, если сочтете это сообщение флудом - удаляйте :) я не обижусь

всем солнца, света и хорошего дня!

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

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

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

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

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

"Хороший", "Инициативный" - вещи весьма субъективные. Да, есть риск выбрать не того или не выбрать того, кто нужен. Но опять же, выбирают те, кто имеет представление о том, каким должен быть кандидат на ту или иную должность.

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

про "а вы уверены?" - согласна. самой пришлось учиться проходить такие вопросы.

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

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

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

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

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

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

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

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

было очень забавно уже после этого на него смотреть.

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

наглая ли я? нет, я очень friendly. но уверенность во мне есть. а желание "расшатать" цепь рассуждений соискателя приводит чаще к негативному отношению с его стороны к потенциальному работодателю. и кто при этом больше теряет?? :)

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

скажем, если человек знает, чем отличается left join от right join. можно спросить, что происходит, когда в коде он встречает left outer join или что происходит, когда в коде он видет просто join.

если соискатель знает разницу и понимает, что в каких ситуациях применять, то он ответит очень уверенно.

хорошего дня!

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

даже в Лондоне, куда стекается огромный поток людей и, в частности, ИТ специалистов, хорошего тестера найти трудно.

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

Артем, я не проснулась в одно утром с понимаем, как надо организовать тестирование в нашей компании. Думаете, нам легко было пробивать стену
руководства, которое считает, что надо запретить людям есть утром на работе мюсли с молоком. потому как это лишних £ 5.2 в день. сколько было проведено переговоров, сколько предложений было внесено, и 99% из всего это так и не внедрили. без прибавки к зарплате начали сами что-то делать, потому как стыдно было перед людьми, которых мы наняли, за поведение компании.

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

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

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

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

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

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

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

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

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

ISEB Practitioner Course , page 66
Привожу целым обзацем.

The test strategy document is high level and defines the test phases to be performed and the
testing within those phases for a programme (one of more projects)/. Based on a policy
towards testing, a strategy towards testing can be developed. A strategy can be for the whole
organisation, generic for each project, or can be developed separately for each project that
the organisation undertakes. A test strategy describes in detail the approach that will be taken
towards the testing including a description of the different testing phases and how the testing
will mitigate the risks involved. It can also be seen to be a description of what testing work will
be planned and how the testing work will be plan.

The project test plan document defines the test phases to be performed and the testing within
those phases for a particular project. If the test strategy is what to plan and how to plan it;
then the test plan is what to do and when to do it. It is the description of how and what to do to
implement the test strategy and will either confirm compliance, or explain non-compliance
with the test strategy. The test plan will have information on the time scales, costs and major
milestones that relate to the overall project plan.

“A test strategy tells you what to plan and how to plan it, the plan tells you what to do
and when to do it” (James Lyndsay)

Теперь смотрим пример:
Нам надо разработать редактор notepad. Тест стратегия будет определять :
1. Фазы (этапы) тестирования
2. Риски (продукт не поддерживает кодировки, не прочитывает XML файлы, не работает под Вистой, не выходит в срок и далее по списку)
3. Как снизить каждый риск: провести тестирование с максимальной выборкой кодировок, провести тестирование на различных платформах и т.д.
4. Далее документ «тест-стратегия» определяет что планировать – какой из выбранных видов тестирование должен быть спланирован в плане (простите за повторение) и как оно должно быть спланировано . Но стратегия не содержит этот план. Она только указывает, что будет и как будет спланировано. Стратегия направляет читателей к плану!
5. здесь же определяется будет ли тестирование автоматизировано. Если да, то какое. в каком соотношении к ручному (80% автоматизировнных тестов для регрессивного тестирования, 20%- ручные тесты)

Смотрим теперь план: мы уже знаем , какие виды тестирования мы должны спланировать. Осталось только расписать это. Пишем конкретно для каждого вида тестирования:

1. Фаза: Нагрузочное тестирование
2. Входные условия: функциональное тестирование должно быть успешно завершено; Тест среда готова к использованию; тестеры владеют методикой нагрузочного тестирования и пр
3. Выходные условия: ни одного серьезного сбоя в системе не зафиксировано в течение 10 часов с нагрузкой в 1000 пользователей в минуту, уровень производительности постоянно находился на уровне определенном требованиями заказчика и т.д.
4. Участники и их роли: участник А : роль: тест –архитектор; участник Б: роль-архитектор БД; Участник С: тестер
5. Период тестирования: 1-4.09.2007
6. Используемая методика создания тестов и тестирования
7. Стандарт, в соответствии с которым необходимо провести тестирование и т.д
8. автоматизация

Все приведенное выше является упрощенным примером.

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

Надя, ну попались, так и скажите :) Зачем огород городить?

Сейчас вы сказали следующее:
"Мне всё равно что написано в РУП, я им не пользуюсь и другим не советую". Но не сказали ничего другого по сути моего замечания.

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

Ну ничего себе...

Во-первых, я высказала свои мысли по поводу того, что тест-стратегия это не тест план. И я готова вам привести пример из того же ISEB Practitioner Syllabus, чтобы показать, что для людей составляющих такие документы стратегия - это не план.
Читайте Канера, Баха и Петихорда, чтобы узнать, что эти люди говорят о стратегии и планах.

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

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

Я еще раз готова повторить, тест-стратегия- это не тест-план. Это способ связи рисков с тест-деятельностью.

Автор, когда вы видите слово методология попробуйте заменить его на слово "набор методов". Метод - это описание того, как вы собираетесь что-то делать.
Если вам надо описать методологию тестирования - опишите методы тестирования, которые вы будете использовать, на основании рисков в вашем проекте.

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

Удачи вам!

есть кое что отметить:

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

Когда я говорю о тестировании я не беру определения из RUP или Prrince2. Я использую и очень рекомендую тестерам смотреть определения вне RUPа.

"Если у вас risk-based test strategy то вы базируясь на рисках будете выбирать приоритеты задач, а подходы и инструменты врядли сильно качнутся из стороны в сторону."

не только то тестирование, которое базируется на рисках, подразумевает расстановку приоритетов.
Приоритеты выбираются, когда есть ограничения. Приоритет может быть распеделен и в black box techniques. не надо сужать: раз риск -значит сразу приоритеты ставить. Да, реальность такова, что нам всегда надо много времени, а его нет. поэтому мы вынуждены выставлять приоритеты. но это не значит, что only risk based approach deals with priorities.

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