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

[OVA]

Ведь в крупных компаниях не даром существует две линейки карьерного роста: техническая и руководящая. Можно расти в сеньера, консультанта и так далее, а можно в тим лида, менеджера и т.п.

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

[Фрося]

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

Если провести абстрактное деление тестировщиков на бизнес-ориентированных и ГИКов, то ключевые отличия где-то здесь:

Гик проверяет на соответствие стандартам и требованиям ВСЁ. Гику важны способы реализации. Гик приоритезирует дефекты и тесты на основании субъективных "хорошо" и "плохо". Гик больше внимания уделяет деталям. Гик реально заводит больше дефектов :)

Бизнес-ориентированный тестировщик не лезет в реализацию и детали. БО-тестировщик создаёт ментальную модель пользователя. БО-тестировщик приоритезирует тесты и дефекты исходя из значимости функционала для пользователя и регулярности использования. БО-тестировщик заводит МЕНЬШЕ дефектов, но именно те, на которые бы пожаловались пользователи.

И лично мне на самом деле всё равно, о каком продукте речь: система пожарной безопасности или браузерная игрушка. БО умеет определять важность функционала исходя из требований ПОЛЬЗОВАТЕЛЯ, а не АНАЛИТИКА. БО валидирует больше, чем верифицирует. И уж явно БО вникает в особенности использования СПБ, так что мне, как пользователю, должно быть не страшно :)

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

Уф... ну давайте по порядку -- сразу ответить не успею.

ГК занимается созданием/конструированием системы исходя из требований заказчика (в случае инициативной разработки - из требований конечного пользователя.)
По-другому сейчас никак - спроса на сферических коней нету!

ГК могут интересовать детали реализации - поскольку сделать систему ему надо минимизируя затраты. В том числе - (как пример) - и на покупных изделиях.

ГК вникает в особенности использования СПБ (пусть пока этот абстрактный пример будет - на мой взгляд он показателен. В силу большой разницы между браузерной игрушкой и пожарной системой!).
Но вникает несколько шире, чем конечный пользователь.
Пользователю СПБ что надо? Чтоб пожара не было! Все!
А вот как СПБ себя поведет в неотапливаемом коттедже/ при бросках электропитания на даче / в сверхжаркое лето - пользователь и в голову не берет.
ГК берет. Возьмет ли в голову БО - не знаю, и будет ли вообще проверять....

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

ПС.
Видимо - что есть Главный Конструктор из технарей - у нас у всех разное впечатление.
Но вот на "субъективное хорошо и плохо" - он точно не будет ориентироваться.
И команда вокруг него сплотится, и работать он будет на конечный результат.

[OVA]

Боюсь в такой постановке ГК совсем не обязательно должен быть менеджером. А желательно вообще им быть не должен. Нефиг ему ерундой заниматься.

[Фрося]

Пост касался тех, кого нелегкая (рука директора) сделала в один миг руководителем в незнакомой области. Это мой личный опыт, и я им делюсь.
.........................................
Дело не в системе, она не изменилась, дело в отношении к ней. Например, железячники искренне считали, что контора продает железо, а софт идет к нему нагрузкой, ибо на это железо теоретически можно было поставить и сторонний софт. Программисты смеялись над железячниками и прописывали в систему сторонние устройства. Всё это хозяйство делалось под заказ из проектного отдела, который в визио состыковывал кубики стрелками, и думал, что это может работать, а точнее должно работать, потому что продажники уже это продали. Комплексным взглядом на систему не обладал никто.
........................
Это была когнитивная катастрофа для неокрепшего менеджера. Я решил подойти с той стороны, которая мне была лучше всего известна - от конечного пользователя. Как я писал выше - их чаяния я знал лучше чем кто либо.
..................................
Хотел поначалу ответить на язвительные замечания от Фроси, но передумал, срач в комментах мне не интересен, тем более на столь уважаемом мною форуме.

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

А по делу.
(ИМХО личного опыта)
1. Почему возникают трения между программистами и железячниками мне стало понятно, когда посмотрела конструкторскую документацию (железячники-то как-то свое железо ведь фиксируют? и как-то связка с софтом прописывается?), поинтересовалась - как железо проверяют.
После чего - и комплексный взгляд стал появляться, и новые вопросы возникать.

2. Тестирование датчиков.
Для датчиков тестирования МАЛО. Написала выше - холодный дом, перерывы питания и прочая. Это уже испытания.
Если датчики покупные - то почему б не попросить предоставить ТУ на эти датчики? Вполне возможно - что проверок по ТУ окажется достаточно, чтобы убедиться, что датчики работают правильно.

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

[Фрося]

Уф.. про комплектность- то забыла..
Скорее всего - Комплектность указана в паспорте на изделие, или в этикетке на изделие.

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

[VikaCP]

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

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

[Natalya Rukol]

Я вот, например, работаю периодически с Kaspersky, у них, по-моему, достаточно грамотно все организовано.

Не везде, к сожалению, но во многих департаментах в Касперском есть возможность расти как в экспертизу, так и вертикально. Выбирает сотрудник.

А вот в Intel, к примеру, с этим проблемы. Хороший спец? Расти в начальники! Плохой начальник? Значит ты плохой спец!

Т.е. нет понимания, насколько это вообще разный рост.

[Фрося]

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

тут попалось - может Вам пригодится?
Во всяком случае -какой-никакой а КОМПЛЕКСНЫЙ подход.
И широкий взгляд.
Ежели ГОСТ не устраивает --- то по-крайней мере принципы понятны.

http://author-it.ru/...php?f=22&t=1114

[OVA]

А вот в Intel, к примеру, с этим проблемы. Хороший спец? Расти в начальники! Плохой начальник? Значит ты плохой спец!

В Intel это от офиса к офису может отличаться.
К тому же есть волшебный фактор "не повезло с начальником".

[Natalya Rukol]

В Intel это от офиса к офису может отличаться.
К тому же есть волшебный фактор "не повезло с начальником".

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

[OVA]

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

Позиции типа Principal Software Engineer и прочих Software Architect там есть, туда можно попасть и пять лет назад интернам в картинках в местном офисе такое кино показывали.