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.

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

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

1. Стратегию вы оформляете в виде отдельного артефакта/документа? Если да - то зачем или почему?
2. С кем согласовывается стратегия тестирования и почему?
3. Могли бы вы на примере виндового ноутпада показать где заканчивается стратегия и где начинается план тестирования?

Теперь по этим вопросам.

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

2. С кем согласовывается стратегия. Только руководителями департамента разработки. хотя каждый месяц мы рассказываем на внутренней конференции о стратегиях тестирования сейлам и консультантам.

3. уже ответила выше.

не все тестирование из Лондона уходит в Индию, Китай, Южную Африку, Россию и страны восточной европы. как и везде здесь есть люди, которые в тестировани уже не 3 года. Но как ни странно, даже опытные люди не пишут документов с нуля. многие вообще мало себе представляют, что они делают. Берется старый тест-план с другого проекта или какой-то пример из интернета и пишется документ. и так из проекта в проек. из года в год.
документы некоторые читать невозможно. для абсолютно всех багов в тест-планах иногда только дата меняется.

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

Автору топика -спасибо за хороший вопрос.

Case - спасибо за дискуссию.

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

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

Вам не нравится, как ISEB определяет стратегию? Никто не спорит. У ISEB много сторонников и противников. Я когда приводила пример только лишь хотела показать. что RUPом не надо ограничиваться в определениях.

Стратегия и план -документы разного уровня. Здесь принято определять полиси -> стратегию->план->фазный план. От общего к частному.

Будете смеяться, но каждому проекту у нас своя методология. и для каждой фазы может быть отдельная методология тестирования. мы сейчас выпускаем первый SP к 4 релизу. для всех SP у нас своя методология тестирования+учет специфики каждого Service pack.

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

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

что в себя включает план и чем он отличается о стратегии - расписывала выше. с момента публикации того сообщения мои взгляды не изменились :)

Надежда, да не буду я смеятся, что вы в самом деле...

Я понял что вас так учили, потому извинился за свои слова "попались!"!

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

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

меня никто этому не учил:) в ISEB я заглянула, когда поняла, что здесь без него просто на работу не берут.

у нас есть стратегия тестирования для процесса тестирования в целом. но мы это называем полиси. и у нас есть стратегия проектная - для конкретных проектов.

если говорить вашим языком, Case, то в нашей компании у нас есть стратегия процессная и проектная.

Galina,

все в точности, как ты описала.

Green, это вы про то, что вам тоже не приходилось писать методологии?? :)

Стоит только внести небольшую поправку. Методология - это действительно глобальная штука. Она не измеряется масштабами проекта. Как правило, ее применяют для решения задач в рамках проекта.

Следовательно, для тестирования проекта разрабатывается стратегия (в некоторой терминологии - план тестирования). которая строится на одной или нескольких методологиях.

Стратегия-это не план. Стратегия -это способ связи рисков и тестирования. И это надо понимать. У вас есть проектные риски. Вы дружно решаете, что надо снизить. Чтобы снизить отдельно взятый риск (можно с риском ничего и не делать, если он не критичен), надо выбрать правильный метод разработки и тестирования. Сюда я включаю также проектирование на разных уровнях и прочее.
Документ "Стратегия" (назовем его так) описывает риски и как вы собираетесь их снизить, какой метод тестирования вы выбираете. Вот когда мы доходим до слова "метод" - мы понимаем "методология". Стратегия НЕ СТРОИТСЯ на методологиях. Документ "Стратегия" говорит вам какую методологию надо использовать, чтобы снизить конкретные риски.

Стратегия говорит вам что планировать. План говорит вам - что и когда делать. Тут очень важно понять разницу.

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

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

Удачи вам!

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

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

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

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

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

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

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

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

Надя

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

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

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

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

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

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

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

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

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

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

Лично сдавала 110 фунто вроде бы. Что примерно 190 долларов. Кто сказал что 650 долларов стоит экзамен? Это с билетом Москва-Лондон и обратно??

Надежда 650$ стоит мой сертификат QuickTest Professional Specialist и кстати сдать его можно онлайн!

Простите, не прочитала внимательно. Признаюсь честно после работы с Test Partner уже не пойду сдавать QTP...

А кстати, расскажите как у вас с commitment to your employer после того, как вы наверное за его деньги сдали сертификат? от вас требуют прилежной работы в течение 2 лет, если экзамен оплачивает работодатель? или вы это сами так решили вложить деньги в знания?

У нас сейчас тоже можно пройти сертификацию.
Сдавать на английском конечно, тоже немецкая компания проводит сертификацию и книжка есть.

Нам вообще компания будет оплачивать сам сертификат, но скажите мне плиз, сколько он стоит и как обстоят дальше, не Foundation Level.

На чем построена сертификация - это вопрос ответ?
Что конкретно нужно.

Я тестер уже 4 года и материалов куча перелопатила в теории и практике, что нового дает этот сертификат Foundation?
И что интересного Надежда Вы нашли для себя при подготовки следующего?

Ой, если вы уже 4 года в тестировании, то зачем вам Foundation? Идите на Practitioner. Вот это будет вам реальный challenge. Там придется не знания по теории показывать, а практические навыки и опыт свой демонстрировать. Foundation хорош для тех кто от 1 года в тестировании. Для Practitioner надо как минимум 2. и то, если честно, не все тестеры за два года доходят до понятия рисков и оценки затрат.

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

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

читайте и применяйте. даже если только одну фразу

Коллеги, простите :)
А реально этот сертификат работодатели в глаза видели?

Работодатели видели. Российские коллеги трогали и тихо завидовали :)

Всем удачи на экзамене!!!!!!!

Сообщите потом результаты. Мы за вас порадуемся.

Лично сдавала 110 фунто вроде бы. Что примерно 190 долларов. Кто сказал что 650 долларов стоит экзамен? Это с билетом Москва-Лондон и обратно??

Нет работодатель от нас ничего не требует. Данный экзамен бесплатен в рамках партнерской программы и сдавать его или нет дело сугубо каждого.
По сути дела для меня было интересно подтвердить свои знания и в качестве бонуса получить данную бумажку. А на работу он абсолютно не влияет. :)
[/quote]

Вот здорово! Я это по поводу отсутсвия "отработки". А задания были по тестировочному продукту или по вашему? мне просто интересно как QTP можно "сдать".. были ли задания на обработку прерываний и exceptions? работата с dfs folders или надо просто проскочить по web элементам и кое где добавить loop?

просто интересно...

[quote]он ничего не стоит так как я и без данного сертификата должен являться специалистом в данном продукте [/quote]
ну и как, являетесь???

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

экзамен можно легко сдать, но понимание основ тестирования (ISEB Foundation- самый базовый сертификат в тестировании) не приходит порой с сертификатом. это важно понимать.

по своему опыту знаю, что понимание материала по Foundation пришло только при подготовке к Practitioner.

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

Если хотите знать, надо ли сдавать? надо. и в первую очередь, для себя.
все материалы очень легко купить на ebay. они стоят копейки. подготовиться очень просто. сдать - мне обошлось в 100 фунтов. наверное, в Москве чуть дешевле. моя дневная зарплата сейчас превышает затраты на материалы по ISEB, поэтому выгода затрат- очевидна.
но это все из личного опыта. не берусь судить тех, кто считает, что это пустая трата времени и денег.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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