Сообщений в теме: 104

[Case]

Аргументируйте?

[Strogoff]

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

[SALar]

Вернитесь к этой теме лет через 7-8.

Совершенно верно. У Демарко приведен хороший расчет. Если человек работает в IT 40 лет (до выхода на пенсию), а через пять лет становится руководителем, то мы получаем пирамиду с очень узким фундаментом. Работать становится просто некому. Все руководят.

А специалистами они становятся от полу года до года, если за год он не стал Инженером то "ф топку" такого специалиста. 

"Не верю!" (с) Станиславский. Или у вас критерий оценки "специалиста" очень низкий.

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

Но, на мой взгляд, во всем, что связано с IT, нельзя говорить о человеке с 2-летним стажем, что он начинающий по определению.
Во-первых, появляются новые и совершенствуются старые технологии. И их нужно изучать иногда с нуля. Совсем не факт, что человек с 10-летним опытом использования DOS, не будет,по сравнению со студентом, выглядеть стажером сидя за машиной под Win Vista.
...

Отвечу всем сразу.

Знание технологий, таких как JScript или VBScript для оценки ведущего вторичны или третичны. Это уровень начинающего кодера. Стажера.

Для ведущего характерен набор знаний другого рода.
1. Знание набора приемлемых решений для огромного количества ситуаций и трансформации потребностей пользователя в продукт на уровне рефлексов.

2. Знание нескольких предметных областей. Так если человек автоматизировал бухгалтерию, то он должен знать:
* Что такое сторно, и как его принято обозначать в журнале.
* Какие существуют типы амортизации и какие типы уже устарели
* Каковы правила списания на МБП
* Какие проводки порождает начисление зарплаты
ну и т.д.

Если вы являетесь ведущим тестировщиком, то на уровне рефлекса должны преобразовывать прецедент "Редактирование элемента справочника" в набор тест кейсов типа такого:
================================
9.1.3.1 Простой тест
1. Сгенерировать уникальную ФС
2. Положить в БД
3. Получить из БД идентификатор
4. Сгенерировать вторую уникальную ФС
5. Отдать WS (команда «изменение») вторую ФС с идентификатором первой
6. Проверить в БД что есть вторая с идентификатором первой.
7. Проверить в БД что вторая одна.
8. Проверить в БД что первой нет.
9. Почистить БД

9.1.3.2 Тест нарушения уникальности
1. Сгенерировать уникальную ФС и Положить в БД
2. Получить из БД идентификатор
3. Сгенерировать вторую уникальную ФС и Положить в БД
4. Отдать WS (команда «изменение») вторую ФС с идентификатором первой
5. Проверить возвращаемый код ошибки
6. Проверить в БД что есть вторая с идентификатором первой.
7. Проверить в БД что вторая есть и она одна.
8. Проверить в БД что первая есть и она одна.
9. Почистить БД

9.1.3.3 Попытка сохранения пустой ФС
1. Сгенерировать уникальную ФС
2. Положить в БД
3. Получить из БД идентификатор
4. Отдать WS (команда «изменение») пустую ФС с идентификатором
5. Проверить возвращаемый код ошибки
6. Проверить в БД что есть первоначальная ФС и она одна.
7. Почистить БД

9.1.3.4 Сохранение ФС, которая была удалена другим пользователем
Кстати, а что здесь должно быть? А в каких случаях это неприменимо?
============================================
И уж совершенно точно, что "ведущий" должен знать для какой архитектуры и какого варианта ответственности компонент эти сценарии подойдут, а для каких будут мусором.

И плюс к этому еще куча всего. Например:
"Какие артефакты вам нужны для тестирования прототипов интерфейса?"
"В чем разница между атрибутивным набором дефекта для команды в 3 человека и команды в 300?"
"Какие методы обеспечения бездефектности используются в XP?"

=============================================
Но как говорится, будьте спокойны. Эти вопросы будут задавать только при более менее развитой области. А сейчас, сейчас время "ведущих" и "ПМ" с трехмесячным опытом.

[ss12]

Совершенно верно. У Демарко приведен хороший расчет. Если человек работает в IT 40 лет (до выхода на пенсию), а через пять лет становится руководителем, то мы получаем пирамиду с очень узким фундаментом. Работать становится просто некому. Все руководят.

Отвечу всем сразу.

Знание технологий, таких как JScript или VBScript для оценки ведущего вторичны или третичны. Это уровень начинающего кодера. Стажера.

Для ведущего характерен набор знаний другого рода.
1. Знание набора приемлемых решений для огромного количества ситуаций и трансформации потребностей пользователя в продукт на уровне рефлексов.

Возможно, это был не совсем удачный пример. Но я не представляю как можно тестировать, например, Java приложения без знаний основ Java, как тестировать 64-битные приложения без понимания, что это такое и т.д. Хотя нет... представляю как... но это будет уровень далеко не ведущего тестера.
Кроме того, согласитесь, что знание нескольких предметных областей, большого количества стандартных ситуаций без знания того же VBScript - есть, если следовать Демарко, пирамида с не менее узким фундаментом. ;)

2. Знание нескольких предметных областей. Так если человек автоматизировал бухгалтерию, то он должен знать:
* Что такое сторно, и как его принято обозначать в журнале.
* Какие существуют типы амортизации и какие типы уже устарели
* Каковы правила списания на МБП
* Какие проводки порождает начисление зарплаты
ну и т.д.

Если вы являетесь ведущим тестировщиком, то на уровне рефлекса должны преобразовывать прецедент "Редактирование элемента справочника" в набор тест кейсов типа такого:

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

И плюс к этому еще куча всего. Например:
"Какие артефакты вам нужны для тестирования прототипов интерфейса?"
"В чем разница между атрибутивным набором дефекта для команды в 3 человека и команды в 300?"
"Какие методы обеспечения бездефектности используются в XP?"

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

[yamayka80]

и кстати....
цитаты:
до 2ух лет - стажёр (это чему же 2 года стажироваться надо)
от 2 до 5 лет - начинающий (ну госпада, если так долго начинать.... мобильнее надо быть)

+1