SALar

Не все баги, не все баги... В нормальной банковской системе сотни тысяч багов. И поможет ли тут Чак Норрис это еще вопрос.

Чтобы приоритизировать баги нужен опыт. Серьезный опыт. Скажем тысяч десять проанализированных дефектов. И несколько тысяч занесенных самостоятельно. Иначе вам будет сложно понять, почему jira-1330 очень серьезный архитектурный баг, стоивший фирме несколько сотен тысяч (а может и миллионов) долларов.

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

1. Почему решили сменить работу?
а) А кто сказал, что решил? Финансовый директор украл оборотные средства и свалил на Бали. А фирма померла.
б) Офис перенесли с метро Менделеевская в Кубинку. Сэкономить хотели. Ага. А мне теперь до них 4 часа ездить.
в) Кинули с премией. Ушла вся команда. А менеджера маленько побили.
Но ответят:
* Хочу развиваться.

2. Почему выбрали нашу фирму?
а) Кто сказал что выбрал? Вы что, IBM? Я и название то только сейчас на визитке прочитал. И кроме вашего у меня уже 5 предложений и еще 7 собеседований впереди.
б) Домой обедать уходить буду. Дом в пятистах метрах. А зарплата примерно как везде.
в) С чего вы решили, что я выбираю фирму? Я выбираю с кем работать. С Архипенковым или с Александровым (кстати реальный выбор одного моего знакомого).

3. Кем вы видите себя у нас через пять лет.
а) Никем не вижу. К этому времени или вы развалитесь, или зарплату забудете повысить, или... Так что через 2-3 года я уйду на 2х зарплату.
б) Генеральным директором. Что, место уже занято? Какая жалость.

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

Совершенно правильно делаете.

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

Э-э-э..... С матриц и начинают. Первые или одни из первых матриц:
1. Заинтересованные лица и их интересы.
2. Заинтересованные лица и их отношение к проекту.

Если не удается составить первую матрицу, то грамотные люди просто сворачивают проект.
Если не удается составить вторую матрицу, то проектные риски становятся неприлично высоки.

Большое спасибо.
Вот с перекрестными ссылками-то у меня и проблема. В моем инструменте есть 2 понятия: Процессы и Функции. Функции ведутся в древовидной структуре, с возможностью прикреплять к ним ER-ки (а еще операции и тесты - что для меня особо привлекательно), кроме как древовидностью структуры функции у меня никак не взаимосвязаны. У Процессов нет возможности визуализации, зато есть возможность указать Предшествующие процессы и просмотреть список процессов, использующих данный (т.е. последующих). В компании разные команды пользуются разной частью интрумента: кто ведет процессы, кому удобнее функции. Мне не удобно ни то, ни другое. Правильно ли я оцениваю ситуацию?
просто предложенное вами решение у меня никак не ложится на мои инструменты...

Есть разные виды атомарных элементов требований.

Для всяких КИС и АСУ удобно пользовать набор:
* [не]действующее лицо
* юзкейс
* объект
* печатная форма
* алгоритм
* нефункциональные требования в разрезе ГОСТ ИСО/МЭК 9126
* Диаграммы анализа - термин Вигерса, все виды диаграмм

Дополнительно можно в качестве требований приводить:
* ссылки на стандарты и законодательные акты
* протоколы сторонних систем (это требования, а не элемент проектирования)
* ...

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

Но поскольку, в РФ аналитиков исчезающе мало, думать на таком уровне декомпозиции в фирмах, как правило, даже не пробуют. И используют усеченные варианты.

Вы правильно понимаете. Те типы элементов, которые у вас ведут - не слишком удобны.

PS. Вам на конфу аналитиков сходить надо. На ЛАФ-2013 идите.

К тому же она получается очень общей и в нашей системе нет возможности взаимосвязи (к примеру, есть функция "Ведение списка пользователей" и есть отдельная функция "Управление ролями и доступом"), если только дублировать (Управление правами доступа и ролоями пользователей) = нагрузка очень большая. Разве что разработчки пропишут списки объектов метаданных по функциям? А можно про использование функциональной карты как планом и отчетом подробнее?

* Пользователь
* Роль
* Связь пользователя и роли
* Связь роли и группы функций
Это отдельные объекты. С линками друг на друга. ER-диаграмма ваш друг.

PS. Я занимаюсьпохожей задачей, что и вы, просто у меня система побольше. Я вынужден печатать ER-ки и работать с распечатками, т.к. пока это самый эффективный способ.
PSS. Если что Visual Paradigm - вполне приличная программа для рисования (и не только). Visio - даже не пробуйте - не пойдет.

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

RUP, например. Еще можете Коберна почитать.
Если нужен пример, то на русском был пример Вигерса и мой: http://blog.shumoos.com/archives/144

И вам сюда: uml2.ru

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

Мы склонны принимать нерациональные решения. За это открытие в 2002 году была вручена нобелевская премия.
Достаточно сказать, что на присуждении Нобелевской премии по экономике психологу, один из членов Нобелевского комитета сказал историческую фразу, которая звучит примерно так: "Под давлением Ваших аргументов мы вынуждены признать, что со времен Адама Смита мы парили человечеству мозги".

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

Хочу предложить вашему вниманию несколько сайтов по рациональному мышлению:

• http://hpmor.ru/ - фанфик по вселенной Роулинг "Гарри Поттер и методы рационального мышления". И, на мой взгляд, гораздо лучше исходного произведения. Зацепит - зацепит, не зацепит - не зацепит. В конце концов не вселюбят фанфики.
• http://lesswrong.ru/ - статьи по рациональному мышлению. Здесь описание в концетрированном виде. И в этом смысле этот сайт лучше.

Если предпочтете начать с фанфика, активно смотрите в энциклопедию (в туже википедию).
На английском статей Элиезера Юдковского больше, но начать вполне можно с русского.

1.Как определить, что является дефектом ПО, а что не является?(ответ нашёл,но верный ли он? - В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект — это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.

2.На что Вы бы обратили внимание в первую очередь при тестировании социальной сети?

3.Опишите основные виды тестирования.(правильно ли было б к этому вопросу отнести функциональные, нефункциональные и связанные с изменениями?!)

Помогите пожалуйста кто знает:)

1. http://blog.shumoos.com/archives/106
2. На артефакт "заинтересованные лица и их интересы". Без него стратегию тестирования написать сложно.
3. Году кажется в 2003 я привел на этом форуме классификацию по различным семантическим признакам. Сейчас, похоже она стала стандартом дефакто. Кто-то из сообщества даже поместил ее сюда: http://ru.wikipedia....ого_обеспечения
Классификацию давно пора переделать, но пока пользуйтесь тем, что есть.

А что это за "главная задача операционного менеджмента" ?

PS. Вопрос продиктован любопытством.

Концепция№1. Улучшение потока (сокращение времени цикла) - основная цель операционного менеджмента.

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

Я так понимаю, что взять справочник и посмотреть рекомендации - религия не позволяет. Так Евгений?
http://www.labirint.ru/books/138619/

А, забить на мандельбагу и хрен с ней.

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

Как выявлять мандельбаги? Вот такой вопрос. Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?

Заранее: Развивать наблюдательность и память.
Если случилось: лечь на диван и подумать как такое вообще могло случиться. Вот вам два примера разбора одной и той же редкой ошибки:

• э-э-э... ищите в панбагоне
• http://blog.shumoos.com/archives/247

ИМХО: из кого угодно, может получитсья кто угодно, при наличии физической возможности, и приложении к переходу максимума усилий...

Мне тоже нравится такой посыл. Но Адизес говорит, что не все так просто. Хотя может я просто его не дочитал? Кому интересно посмотрите http://www.ozon.ru/c...ail/id/5136706/

Но его модель PAEI не имеет никакого отношения к тому тестировщик или не тестировщик. А так же технический писатель, проектировщик GUI, ДБА, ...

Были случаи, когда тестировщик становился PM'ом? Это ровно тот же вопрос
"Зачем у хвоста кошка?" или "Чем тестирование по вторникам отличается от тестирования в agile?"
Да ничем не отличается. Бредовый вопрос. Нет "тестирования в agile". Есть просто тестирование. И уже сама формулировка, как правило, говорит о слабой подготовке докладчика. Или если хотите, это: "Намеренное введение в заблуждение, с целью получения profit". Кстати, я не сильно против. Пусть люди сходят хоть на такой доклад, чем вообще никуда не пойдут. Только переучивать их потом приходится...

Найдите мой доклад (видео) на ЛАФ-2011. Там довольно подробно рассмотрено множество методов.
Искать умеете?

походу не умею. не смог найти.

Для приоритезации багов тоже подходит.

Сделайте призы как на SQA Days 10 - красивые такие статуэтки :)

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

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

Когда я говорил, что нельзя всех подряд называть «синьорами», вы продолжали их создавать. Теперь у нас куча 23-летних синьоров и все равно никто его знает, чем абстрактный класс отличается от интерфейса.

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

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

Когда вы говорите, что программисты зажрались, то вы правы – ведь вы сделали все правильно!

...
Хорошо бы, но в управлениии конфигурацициями я не силен.

По управлению конфигурациями вы как минимум должны сказать: "Уровень процесса тестирования не может быть выше уровня процесса КУ. Без развития КУ внедрение тестирования бесполезно. Или вредно."

Точно так же как и ПМИ по 19 ГОСТ-у --- тоже тестировщик скорей всего будет писать

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


ГОСТ-ы:

• ГОСТ Р ИСО'МЭК 9126-93 - совершенно обязательно. Не знание этого ГОСТ-а для тестировщика, это как не знание PMIBOK для менеджера. Т.е. если даже название не слышали, то все очень запущено.
• ГОСТ 28195 - не показался, но почитать можно.
• 34.602 раздел 6 или 34.603
• Р 50779.42-99 - совершенно напрасно неиспользуется в QA и QC
• ГОСТ Р ИСО МЭК 12207-2010 и 34.601 - для вводной лекции пойдут

Ну и хватит для начала.