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

И еще вопрос.

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

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

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

Надя

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

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

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

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

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

Надя

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

А вот кстати, про уход к конкурентам. у меня в контракте прописано, что не могу уйти к конкурентам в течение 5 лет после прерывания данного контракта. Интересно, в России тоже есть похожие условия в контрактах?

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

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

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

Я спрашиваю: что же так не понравилось , что он даже не стал дальше его читать.

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

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

Что скажете?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

Удачи вам!

Galina,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фазы тестирования представлены следующим набором:
1. модульное тестирование (тестирование модулей, функций и пр.)
2. тестирование интергрированных модулей
все не перечисляю и так все знают..

5. Фаза приема- примемочное тестирование.
вот список существующих видов приемочного тестирования
а) user acceptance testing - т.е. либо наемные люди на стороне заказчика выполняют тесты, которые им вздумаются, либо сам заказчик.
b) contract acceptance testing - вы, как исполнитель демоснстрируете, что все условия контркта выполнены. этот вид тестирования может быть отдан кому угодно, даже в третьи руки.
c) alpha testing & beta testingю... не стану расписывать, думаю, и так знаете.

ну вот и смотрите.. user acceptance testing and contract acceptance testing в качестве одной из техник тестирования могут исользовать smoke testing.. но это вовсе не обязательно..

надеюсь, наглядно объяснила :)
удачи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вообще тут не подняли тему о том, что CMMI "чтит" процессы, и не "думает" о людях. Никто не сказал о том, что такие компании как Borland по рейтингу CMMI имеют 1 уровень и по всем "классификациям" СММI, уже должна была давно кануть в Лету.

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

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

СMMI ведет вас к чему-то. он дает вам надежду - из непонятно чего сделать что-то. но что?? что-то предсказуемое и управляемое. но не факт, что это будет успех. CMMI придуман для руководителей, которые, глядя на все, что творится в разработке, хотят как-то с этим справится.. Иллюзия контроля, как сказал Бах в одной из своих статей.

с уважением,
Надя

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

http://www.citforum....th_per_project/
http://www.software-...really-need.htm
http://www.software-...lin/gone-if.htm

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

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

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

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

все высказанное является моей точкой зрения.

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

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

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

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

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

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

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

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

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

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

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

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