Вы так же общаетесь с пользователями своих програмных продуктов?
Я потратила на билеты+проживание+ питание — это не бесплатно, это раз. Два — на фоне этих трат
Между прочим, выступить на такую аудиторию сложно, и делать это должны люди подготовленные, одного желания мало, нужен опыт.
Таки да, уехала домой «в восторге» от конференции
Тут во всем лучше чем в Киеве, Днепропетровске, Харькове и Львове вместе взятых. Тут есть внутренний рынок и тут всем рады
Та шо вы говорите? А вы там были, чтобы хаять? Не стоит первым кидать какашку, ато ж может и вернуться, да по-больше и по-жирнее ;)
Ну к такому положению вещей с едой в нашей конторе не привыкать . Все выметается секунд за 5.
У вас работают за еду? Вам мало платят? Откуда такое жлобство?
>>Make sure that you have done as deep investigation as possible (if the bug is not SAO) and have found the real cause of the bug.
С одной стороны вроде оно так, но junior специалистам такое советовать не стоит, они просто могуть закапаться и не выкопаться ;)
>>Look through other bugs in BB, making sure the steps you are going to write are similar to those that exist, so that the same actions are described similarly.Вот, как раз то, что я советую начинающим QC: будьте проще, используйте простые предложения. Чего советую и автору ;)
>>Build sentences correctly, basically the sentence structure looks like this: subject, predicate, objects.А не проще сказать,что предложения должны бать согласно грамматике английского язика Не стоит использовать грамматические структуры, которые не знаете.
>>Bug summaries should be as accurate as possible; it should describe the sense of the bug.Вообще-то summary describe core of the problem, но это уже продвинутые тонкости :)))
>>The number of steps should be minimal, but enough to reproduce the bug. Do not write unnecessary steps. Do not describe trivial actions in several steps (if they don’t cause the bug).Вы мне скажите какой это джуниор различает эту грань между нужными и ненужными шагами. Более того, классика жанра говорит и том, что нужно писать все шаги: а) не факт, что кажущийся незначительным шаг не станет ключевым в определении проблемы; б) не все программисты, особенно джуниоры, настолько классно знают продукт, что могут найти в программе фичу, написанную не ими, 2 года назад без детальных шагов.
А где про альтернативные варианты воспроизведения?
>>Remember the meanings of abbreviations...Используйте абревиатуры по минимуму — люди в команде меняются, это могут читать не только члены команды (например заказчики), поэтому чем меньше непонятных буквосочетаний тем лучше (это же касается сленга)
>>don’t be afraid to discuss anything if you have a different point of view about something (but don’t forget to be polite);Мы все еще про баги или уже перешли в плоскость философии обсуждая что-либо с кем-либо в вежливой манере :)))
>>customer’s word is law. :)Ну и чему вы учите молодую поросль? Все что касается заказчика очень сильно варьируется от проекта к проекту. Бывают достаточно открытые заказчики.
>>customer’s bugs always are «Critical» and have Visibility «Up to 100%»;Из той же оперы. Если команды заказчика и подрядчика интегрированны, то баги будут иметь равноценное значение. Правильные говорить, что баги с продакшина всегда критичны.