Мужской вариант песни: Твоя нежность
Век двадцатый — век больших разлук…
И тебе сейчас трудней, чем мне, —
Ждать труднее, чем идти на риск…
Между нами миллиарды звёзд,
Между нами радиаций яростный дождь,
Но в небо
С далёкой земли
Долетает
Твоя нежность…
Может, надо улететь, чтоб знать,
Сколько в мире алых солнц и лун,
Может, надо улететь, чтоб знать,
Как беспомощно мала земля, —
Но огромна лишь одна земная любовь…
И здесь, во Вселенной,
Меня
Согревает
Твоя нежность.
Я лечу, и на меня глядят
Воспалённые зрачки планет;
Слышу ласковое пенье звёзд, —
Светел голос неземных светил…
Только в мире нет любви
Сильнее земной,
И здесь, во Вселенной,
Меня окрыляет
Твоя нежность…
А тебе ещё осталось ждать
Ровно столько, сколько мне летать…
Слово Канеру
Тестируйте сессиями.
Сессия — защищенный блок времени, от 60 до 90 минут. Во время сессии тестировщик сфокусирован на одной задаче. Если вы тест-менеджер, то защитите целостность сеанса и повесите большую табличку «Не беспокоить» около тестировщика, которую каждый, включая вас, будет уважать, unless a serious problem must be addressed urgently.
Тестировщики, которые не могут найти способ защитить свое время, часто работают короткими отрезками, так как часто отвлекаются на вопросы и митинги.
среда, 31 октября 2012 г.
Lesson 194
dev: это видимо в ветке develop баг, т.к. я вижу еще одну сборку, у которой этот тест упал
tester: Выводы?
dev: Найти и наказать! :)
tester: Я думал, взять и исправить. Ты точно программист?
Слово Канеру
Регламентируйте сессии тестирования, особенно исследовательского.
Перед тем как сесть за компьютер, тестировщик (или пара) должны иметь четкое представление о том, чем они намерены заниматься ближайшие 60-90 минут. Мы называем это регламент сессии. Мы все еще экспериментируем с этим подходом, но он, как нам кажется, работает хорошо.
Преимущество регламента в том, что он помогает сосредоточиться на тестировании и не отвлекаться на непродуктивные направления. Тестировщик не привязан к регламенту. Если он увидит что-нибудь подозрительное или у него появится гениальная идея, он может им следовать. Но во время перерыва он возвращается к регламенту, если нет ничего более интересного и актуального.
We think it is particularly valuable to come up with an explicit charter when two testers are working together as a pair.
Чтоб создать регламент, тестировщик должен поработать с описанием проекта или выбрать задачу, которая займет не больше дня, может создать схему на флипчарте с описанием работы в этой и ближайших тест-сессиях.
Регламент сессии может включать в себя то, что нужно проверить, список инструментов, тактики тестирования, риски, типы ошибок, которые следует искать, документы, необходимые для изучения, результаты, которые мы хотим получить.
tester: Выводы?
dev: Найти и наказать! :)
tester: Я думал, взять и исправить. Ты точно программист?
Слово Канеру
Регламентируйте сессии тестирования, особенно исследовательского.
Перед тем как сесть за компьютер, тестировщик (или пара) должны иметь четкое представление о том, чем они намерены заниматься ближайшие 60-90 минут. Мы называем это регламент сессии. Мы все еще экспериментируем с этим подходом, но он, как нам кажется, работает хорошо.
Преимущество регламента в том, что он помогает сосредоточиться на тестировании и не отвлекаться на непродуктивные направления. Тестировщик не привязан к регламенту. Если он увидит что-нибудь подозрительное или у него появится гениальная идея, он может им следовать. Но во время перерыва он возвращается к регламенту, если нет ничего более интересного и актуального.
We think it is particularly valuable to come up with an explicit charter when two testers are working together as a pair.
Чтоб создать регламент, тестировщик должен поработать с описанием проекта или выбрать задачу, которая займет не больше дня, может создать схему на флипчарте с описанием работы в этой и ближайших тест-сессиях.
Регламент сессии может включать в себя то, что нужно проверить, список инструментов, тактики тестирования, риски, типы ошибок, которые следует искать, документы, необходимые для изучения, результаты, которые мы хотим получить.
суббота, 27 октября 2012 г.
Lesson 193
Забавно, но эти переводы читает кто угодно, кроме тех, для кого я это делаю.
Все кроме моей команды, кроме тестировщиц нашего отдела.
Мда.
Слово Канеру
Назначьте в проекте охотника за багами
Охотник за багами — опытный энтузиаст тестировщик-исследователь. Вот несколько способов тестирования, которые он мог бы использовать:
- Первичное исследовательское тестирование новой области для разработки детальных планов атак, которые смогут выполнить менее опытные тестировщики.
- Исследовать области якобы низкого риска — сможет ли быстро найти ошибки, которые привели бы к переоценке рисков?
- Отладка ключевых областей, которые кажутся склонными к появлению невоспроизводимых ошибок.
- Поиск критических ошибок, которые убедят менеджера перенести дату релиза.
Все кроме моей команды, кроме тестировщиц нашего отдела.
Мда.
Слово Канеру
Назначьте в проекте охотника за багами
Охотник за багами — опытный энтузиаст тестировщик-исследователь. Вот несколько способов тестирования, которые он мог бы использовать:
- Первичное исследовательское тестирование новой области для разработки детальных планов атак, которые смогут выполнить менее опытные тестировщики.
- Исследовать области якобы низкого риска — сможет ли быстро найти ошибки, которые привели бы к переоценке рисков?
- Отладка ключевых областей, которые кажутся склонными к появлению невоспроизводимых ошибок.
- Поиск критических ошибок, которые убедят менеджера перенести дату релиза.
пятница, 26 октября 2012 г.
Lesson 192
Вчера написал в чат группы ссылку на пост Алименкова:
(24.10.2012 19:15:15) mz: http://xpinjection.com/2012/10/24/code-degradation-and-xp-practices/
Человек пишет о проблемах, близких к нашим
Как вы думаете, что у меня спросили потом лично?
Может быть: «как при тех же кадрах повысить приоритет автоматизации, ведь не все мануальщики умеют, а некоторые и не хотят?»
Или может быть «что автор предлагает делать с демотивирующим влиянием усложненных регламентов тестирования фичи на разработчиков?»
Ну, тогда наверное «как продать рефакторинг топам во время дедлайна?»
Нет! Ни хренышка подобного!
Меня, ЧСХ, спросили: «А где ты находишь время все это читать? Мы вот работаем и не успеваем.»
Пиздец.
Потому и не успеваете.
У меня есть встречный вопрос: «а почему вы — ничего этого не читаете?»
Я вот не успеваю читать публикации ориджинал контента по моей профессии, но хотя бы за книгами слежу.
Или может быть наша профессия столь ничтожна, что ей не нужно учиться?
Гугл по запросу Famous Testers ведет нас на страничку
http://www.ranker.com/list/list-of-famous-software-testers/reference
где из 17 человек я слышал имена шестерых, книги трох — читал, четвертого — собираюсь прочесть.
А, да, все не так плохо. Зато все героически прочли дотком Савина.
Как с этим у вас?
Слово Канеру
Попробуйте парное тестирование
Пара тестировщиков, работая вместе, могут сделать работу лучше, чем опытный охотник на ошибки. Пары могут быть стабильными (два человека постоянно работают вместе) или пары могут набираться случайно, как в экстремальном программировании. В такой случае тестировщик, ответственный за данную область, будет искать краткосрочных партнеров, имеющих полезные знания и навыки для тестирования этой области.
Парное тестирование отличается от других видов парной работы, так как тестирование — деятельность по генерации идей, а не выполнении работы по плану. Тестирование — эвристический поиск в открытом многомерном пространстве. Пара поощряет каждого тестировщика объяснять и реализовывать идеи. Когда тестировщик объясняет свои мысли другому, то сам процесс формулирования порождает новые идеи. Если работать добросовестно, то мы верим, что этот процесс ведет к большему количеству лучших идей и тестов.
Мы настоятельно рекомендуем согласовать устав парного тестирования, прежде чем начинать тест-сессии. Чтоб создать устав нужно потратить 5-10 минут времени не у компьютера (а, возможно, у доски), договориться о направлении, в котором вы будете следовать ближайшие 2 часа. Можно сосредоточиться на рисках, попытаться предсказать ошибки, выбрать фичи для тестирования и инструменты. Это будет общее руководство, а не список тестов. Тестировщики могут свободно отходить от устава, чтоб исследовать что-то новое (например для отслеживания обнаруженного подозрительного поведения, включающего в себя работу с несколькими фичами). Однако, когда они выполнят эту задачу, они остановятся, чтоб заглянуть в устав и узнать, что делать дальше. Без устава пары могут потерять фокус.
Также мы верим, что парное тестирование помогает сосредоточиться на задаче, делает проще воспроизведение и анализ ошибки, помогает тестировщику сохранять движение, пока другой делает перерыв или отвлекается. Также мы подозреваем, что при парном тестировании у остальных будет меньше возможностей отвлечь, что тоже не так плохо.
Мы подозреваем, что пара тестировщиков как минимум более эффективна, чем два тестировщика, работающие в одиночку. Они получают больше за меньшее время. Это новая область для работы. Попробуйте тестирование в парах. Посмотрите, как это работает в вашей компании. Можно делать это для определенного класса задач, для определенного круга людей.
(24.10.2012 19:15:15) mz: http://xpinjection.com/2012/10/24/code-degradation-and-xp-practices/
Человек пишет о проблемах, близких к нашим
Как вы думаете, что у меня спросили потом лично?
Может быть: «как при тех же кадрах повысить приоритет автоматизации, ведь не все мануальщики умеют, а некоторые и не хотят?»
Или может быть «что автор предлагает делать с демотивирующим влиянием усложненных регламентов тестирования фичи на разработчиков?»
Ну, тогда наверное «как продать рефакторинг топам во время дедлайна?»
Нет! Ни хренышка подобного!
Меня, ЧСХ, спросили: «А где ты находишь время все это читать? Мы вот работаем и не успеваем.»
Пиздец.
Потому и не успеваете.
У меня есть встречный вопрос: «а почему вы — ничего этого не читаете?»
Я вот не успеваю читать публикации ориджинал контента по моей профессии, но хотя бы за книгами слежу.
Или может быть наша профессия столь ничтожна, что ей не нужно учиться?
Гугл по запросу Famous Testers ведет нас на страничку
http://www.ranker.com/list/list-of-famous-software-testers/reference
где из 17 человек я слышал имена шестерых, книги трох — читал, четвертого — собираюсь прочесть.
А, да, все не так плохо. Зато все героически прочли дотком Савина.
Как с этим у вас?
Слово Канеру
Попробуйте парное тестирование
Пара тестировщиков, работая вместе, могут сделать работу лучше, чем опытный охотник на ошибки. Пары могут быть стабильными (два человека постоянно работают вместе) или пары могут набираться случайно, как в экстремальном программировании. В такой случае тестировщик, ответственный за данную область, будет искать краткосрочных партнеров, имеющих полезные знания и навыки для тестирования этой области.
Парное тестирование отличается от других видов парной работы, так как тестирование — деятельность по генерации идей, а не выполнении работы по плану. Тестирование — эвристический поиск в открытом многомерном пространстве. Пара поощряет каждого тестировщика объяснять и реализовывать идеи. Когда тестировщик объясняет свои мысли другому, то сам процесс формулирования порождает новые идеи. Если работать добросовестно, то мы верим, что этот процесс ведет к большему количеству лучших идей и тестов.
Мы настоятельно рекомендуем согласовать устав парного тестирования, прежде чем начинать тест-сессии. Чтоб создать устав нужно потратить 5-10 минут времени не у компьютера (а, возможно, у доски), договориться о направлении, в котором вы будете следовать ближайшие 2 часа. Можно сосредоточиться на рисках, попытаться предсказать ошибки, выбрать фичи для тестирования и инструменты. Это будет общее руководство, а не список тестов. Тестировщики могут свободно отходить от устава, чтоб исследовать что-то новое (например для отслеживания обнаруженного подозрительного поведения, включающего в себя работу с несколькими фичами). Однако, когда они выполнят эту задачу, они остановятся, чтоб заглянуть в устав и узнать, что делать дальше. Без устава пары могут потерять фокус.
Также мы верим, что парное тестирование помогает сосредоточиться на задаче, делает проще воспроизведение и анализ ошибки, помогает тестировщику сохранять движение, пока другой делает перерыв или отвлекается. Также мы подозреваем, что при парном тестировании у остальных будет меньше возможностей отвлечь, что тоже не так плохо.
Мы подозреваем, что пара тестировщиков как минимум более эффективна, чем два тестировщика, работающие в одиночку. Они получают больше за меньшее время. Это новая область для работы. Попробуйте тестирование в парах. Посмотрите, как это работает в вашей компании. Можно делать это для определенного класса задач, для определенного круга людей.
четверг, 25 октября 2012 г.
вторник, 23 октября 2012 г.
Lesson 191
I must gain worth. Thank you for your kindness.
I must gain worth. Thank you for your kindness.
I must...
I must not... gain worth. There's no kindness in your eyes.
Слово Канеру
Производите ротацию тестировщиков по фичам.
Не заставляйте тестировщика работать с одной областью или фичей с начала и до самого конца проекта. Во-первых, это скучно для большинства тестировщиков. Во-вторых, с течением времени, тестировщик будет настолько узкоспециализированным, что станет менее ценным, чем менее опытный универсал. В-третьих, если специалист уйдет, вы получите дыру в знаниях группы. Четвертое, и самое важное: два тестировщика анализируют одну и ту же фичу разными путями. Они начнут тестирование с разными теориями о ошибках, создадут различные тесты, найдут различные дефекты. Когда один тестировщик начинает чувствовать себя уверенным в качестве части программы, переместите его в другую область. Новый тестировщик, назначенный для тестирования, найдет дефекты, о которых предыдущий даже не думал.
Fran McKain предлагает оценку контекста:
Вот некоторые предостережения. Некоторые наборы фич являются настолько большими, что очень много времени займет изучение этой области для эффективного тестирования. Ротация будет поддерживать лишь низкое качество тестирования.
Мы согласны с важностью специализации, но задаемся вопросом: как управлять рисками, ею созданными: Возможно, одним из способов будет парное тестирование, сопрядение специалиста с другими тестировщиками группы.
I must gain worth. Thank you for your kindness.
I must...
I must not... gain worth. There's no kindness in your eyes.
Слово Канеру
Производите ротацию тестировщиков по фичам.
Не заставляйте тестировщика работать с одной областью или фичей с начала и до самого конца проекта. Во-первых, это скучно для большинства тестировщиков. Во-вторых, с течением времени, тестировщик будет настолько узкоспециализированным, что станет менее ценным, чем менее опытный универсал. В-третьих, если специалист уйдет, вы получите дыру в знаниях группы. Четвертое, и самое важное: два тестировщика анализируют одну и ту же фичу разными путями. Они начнут тестирование с разными теориями о ошибках, создадут различные тесты, найдут различные дефекты. Когда один тестировщик начинает чувствовать себя уверенным в качестве части программы, переместите его в другую область. Новый тестировщик, назначенный для тестирования, найдет дефекты, о которых предыдущий даже не думал.
Fran McKain предлагает оценку контекста:
Вот некоторые предостережения. Некоторые наборы фич являются настолько большими, что очень много времени займет изучение этой области для эффективного тестирования. Ротация будет поддерживать лишь низкое качество тестирования.
Мы согласны с важностью специализации, но задаемся вопросом: как управлять рисками, ею созданными: Возможно, одним из способов будет парное тестирование, сопрядение специалиста с другими тестировщиками группы.
Lesson 190
Слово Канеру
Продайте или передайте задачу другому тестировщику, если первый плохо выполняет ее.
Тестировщик, блестяще справляющийся с проверкой качества данных, может быть перегружен, если он попытается спланировать тестирования большого количества конфигураций. Разные тестировщики имеют разные сильные стороны. Поощряйте их рисковать и развиваться, по возможности обеспечьте наставником в новом для них виде работы, наблюдайте за их прогрессом. Если тестировщик исключительно медленно выполняет задачу или продолжает писать неэффективные багрепорты, то этот вид работы ему не подходит (слишком тяжело, требует знаний в незнакомой области, слишком скучно, требует контакта с разработчиком). Не держите тестировщиков на задачах, которые им не подходят. В идеале, вы могли бы найти другого тестировщика, который хотел бы взять на себя задачу в обмен на другую. Возможностей для здорового торга всегда много, если вы внимательно посмотрите.
Продайте или передайте задачу другому тестировщику, если первый плохо выполняет ее.
Тестировщик, блестяще справляющийся с проверкой качества данных, может быть перегружен, если он попытается спланировать тестирования большого количества конфигураций. Разные тестировщики имеют разные сильные стороны. Поощряйте их рисковать и развиваться, по возможности обеспечьте наставником в новом для них виде работы, наблюдайте за их прогрессом. Если тестировщик исключительно медленно выполняет задачу или продолжает писать неэффективные багрепорты, то этот вид работы ему не подходит (слишком тяжело, требует знаний в незнакомой области, слишком скучно, требует контакта с разработчиком). Не держите тестировщиков на задачах, которые им не подходят. В идеале, вы могли бы найти другого тестировщика, который хотел бы взять на себя задачу в обмен на другую. Возможностей для здорового торга всегда много, если вы внимательно посмотрите.
четверг, 18 октября 2012 г.
Lesson 189
Слово Канеру
Нет правильного соотношения количества тестировщиков и разработчиков
Люди часто спрашивают, каково верное соотношение тестировщиков и разработчиков. Мы считаем, что это неправильный вопрос (Kaner и соавт. 2000 и Hendrickson 2001a).
Во-первых, два человека могут иметь ввиду разные вещи, говоря, что у них соотношение один к одному. В разных компаниях считают разные люди, это делает невозможным сравнение компаний по такому признаку.
Во-вторых, соотношение акцентирует внимание на количестве, а не на работе, которая выполняется. Предположим, что на последнем проекте программист потратил 16 человеко-месяцев на проектирование и написание кода, а тестировщик провел 24 человеко-месяца, занимаясь поиском ошибок. Соотношение 24 к 16 или 3 к 2 является точным, но не информативным. Измените количество нового кода, количество сторонних компонент, объем кода с прошлого проекта, который может быть использован, баланс ответственности за устранение проблем, и массу других переменных — и соотношение окажется неверным. Вместо того, чтоб говорить о соотношениях, говорите о работе, которую вам нужно сделать и людях, которые понадобятся для этого.
Нет правильного соотношения количества тестировщиков и разработчиков
Люди часто спрашивают, каково верное соотношение тестировщиков и разработчиков. Мы считаем, что это неправильный вопрос (Kaner и соавт. 2000 и Hendrickson 2001a).
Во-первых, два человека могут иметь ввиду разные вещи, говоря, что у них соотношение один к одному. В разных компаниях считают разные люди, это делает невозможным сравнение компаний по такому признаку.
Во-вторых, соотношение акцентирует внимание на количестве, а не на работе, которая выполняется. Предположим, что на последнем проекте программист потратил 16 человеко-месяцев на проектирование и написание кода, а тестировщик провел 24 человеко-месяца, занимаясь поиском ошибок. Соотношение 24 к 16 или 3 к 2 является точным, но не информативным. Измените количество нового кода, количество сторонних компонент, объем кода с прошлого проекта, который может быть использован, баланс ответственности за устранение проблем, и массу других переменных — и соотношение окажется неверным. Вместо того, чтоб говорить о соотношениях, говорите о работе, которую вам нужно сделать и людях, которые понадобятся для этого.
Lesson 188
Слово Канеру
Человек, который будет делать работу должен сказать вам, сколько времени она займет.
Менеджеры обычно недооценивают задачи, которые они делегируют другим. Если вам нужна оценка, имеет смысл спросить ее у человека, который будет работать с задачей и отчитываться за нее. Если оценка тестировщика намного больше, чем ваша, не пытайтесь переубедить его изменить оценку. Вместо этого попытайтесь понять, каким он видит объем задач, что он собирается еще делать, какие факторы заставляют его увеличить оценку. Это может стать прекрасной возможностью помочь вашему тестировщику работать эффективней. Может быть, вы переопределите задачу или измените оценки. Запугивание может изменить оценку, но задача все равно займет больше времени. И позднее ваш график будет отставать от реальности.
Сказав это, мы подумали, что вы могли бы прочесть вдумчивый ответ Pat McGee.
«Человек, который будет делать работу должен сказать вам, сколько времени...» Мне сильно не нравится эта практика. Я считаю, что многие люди не уделяют достаточно внимания тому, как они дают оценки. Я видел ситуацию, когда программист дал оценку в 2 недели, менеджер сказал, что это должно занять не более двух дней и оно\, действительно, заняло полтора дня. It passed review on the first attempt, too. Но также я наблюдал и обратные ситуации, когда работа заняла намного больше времени. Я считаю, что оценку должен давать тот, кто больше других обращает внимание на то, сколько времени занимает та или иная работа. Иногда это менеджер. Иногда сотрудник. Иногда такого человека нет. Несмотря на все это, я считаю, что ваше оригинальная идея упрощена до полной бесполезности.
Разница между нашими подходами в том, что Pat получает оценку от лучше проинформированного человека. Мы же берем оценку от человека, который столкнется с последствиями, если оценка будет неправильной (и который заинтересован в том, чтоб получить качественные оценки). Оба подхода кажутся нам разумными и оба гораздо лучше, чем распространенный подход — выдавать желаемое за действительное.
Человек, который будет делать работу должен сказать вам, сколько времени она займет.
Менеджеры обычно недооценивают задачи, которые они делегируют другим. Если вам нужна оценка, имеет смысл спросить ее у человека, который будет работать с задачей и отчитываться за нее. Если оценка тестировщика намного больше, чем ваша, не пытайтесь переубедить его изменить оценку. Вместо этого попытайтесь понять, каким он видит объем задач, что он собирается еще делать, какие факторы заставляют его увеличить оценку. Это может стать прекрасной возможностью помочь вашему тестировщику работать эффективней. Может быть, вы переопределите задачу или измените оценки. Запугивание может изменить оценку, но задача все равно займет больше времени. И позднее ваш график будет отставать от реальности.
Сказав это, мы подумали, что вы могли бы прочесть вдумчивый ответ Pat McGee.
«Человек, который будет делать работу должен сказать вам, сколько времени...» Мне сильно не нравится эта практика. Я считаю, что многие люди не уделяют достаточно внимания тому, как они дают оценки. Я видел ситуацию, когда программист дал оценку в 2 недели, менеджер сказал, что это должно занять не более двух дней и оно\, действительно, заняло полтора дня. It passed review on the first attempt, too. Но также я наблюдал и обратные ситуации, когда работа заняла намного больше времени. Я считаю, что оценку должен давать тот, кто больше других обращает внимание на то, сколько времени занимает та или иная работа. Иногда это менеджер. Иногда сотрудник. Иногда такого человека нет. Несмотря на все это, я считаю, что ваше оригинальная идея упрощена до полной бесполезности.
Разница между нашими подходами в том, что Pat получает оценку от лучше проинформированного человека. Мы же берем оценку от человека, который столкнется с последствиями, если оценка будет неправильной (и который заинтересован в том, чтоб получить качественные оценки). Оба подхода кажутся нам разумными и оба гораздо лучше, чем распространенный подход — выдавать желаемое за действительное.
вторник, 16 октября 2012 г.
Lesson 187
Как вы все, конечно же, помните, недавно у нас самопровелась одна тест-сессия.
Сегодня расширили формат, пригласив потестировать аналитика и разработчика. Выбрали матерых, чтоб значит, пафос, смысл и вообще.
Что особенно приятно, сегодня ее организовала с моей подачи новенькая. А то чо все я да я?
По результатампобедила дружба выяснилось:
1. Что аналитики едят свой хлеб не зря. Некоторые не зря мажут на него икру. Не было ничего сверхъестественного, и в конечном счете, например я бы тоже все нашел. Но за отведенный час именно аналитик нашел больше.
2. Что тестировщиков нанимают не зря. Потому что программисты тестировать могут. И базовый минимум дефектов находят. Но не хотят и сдаются через полчаса.
3. Что автоматизатор из моей группы молодец и всем мальчишкам пример. Находит удивительное-рядом, критичное и хрен бы кто догадался посмотреть. При этом даже не запуская функциональность, а просто вдумчиво разглядывая код.
4. Что не можешь занять первое место — займись лучше организацией.
5. Что некоторые постановки лучше даже не читать. Целее будешь.
Пикрандом.
Слово Канеру
Чтоб запланировать набор задач, оцените количество времени, необходимое для выполнения каждой из них.
Ваша работа состоит из выполнения большого количества задач. Составьте их список (см. Канер, 1996b и любые другие книги по управлению проектами, охватывающие работы по оценке). Некоторые задачи можно описать только в общих чертах; другие можно разбить на мелкие части. По мере возможностей, создавайте отдельные задачи на все, что может занять больше дня. Оцените (предположите) сколько времени займет задача, прибавьте 25 процентов (больше или меньше в зависимости от компании) для совещаний, обучения и других работ вне проекта и используйте полученное значение, как время, необходимое для решения задачи.
Этот метод выглядит проще, чем на самом деле. Составление списка задач — не так тривиально, очень легко пропустить задачи или недооценить их.
Пробуйте и другие методы для оценок:
- Если вы делали и другие проекты, подобные этому, возьмите за основу время, которое они заняли.
- If you have a sense of the length and complexity of the program and a model based on data in your current company that relates length and complexity to duration of testing, apply the model to derive an estimate.
- Если вы чувствуете, что существуют риски, связанные с проектом, оцените время для проверки этих рисков
- Другие факторы, которые вы могли бы оценить. Например, если вы знаете, что программисты особенно хорошо знают этот тип приложений, то, вероятно, потребуется меньше времени на тестирование. Если этот конкретный программист делает много ошибок, чем остальные, то, возможно, понадобится больше времени на тестирование. Если пользовательская документация уже написана четко и ясно, если известен образ действий и входные данные пользователей, то тестировать будет проще.
Вы имеете возможность оценить объем тестирования в любой момент проекта, используя подобные методы. Чем дольше идет проект, тем точнее должны быть ваши оценки.
Сегодня расширили формат, пригласив потестировать аналитика и разработчика. Выбрали матерых, чтоб значит, пафос, смысл и вообще.
Что особенно приятно, сегодня ее организовала с моей подачи новенькая. А то чо все я да я?
По результатам
1. Что аналитики едят свой хлеб не зря. Некоторые не зря мажут на него икру. Не было ничего сверхъестественного, и в конечном счете, например я бы тоже все нашел. Но за отведенный час именно аналитик нашел больше.
2. Что тестировщиков нанимают не зря. Потому что программисты тестировать могут. И базовый минимум дефектов находят. Но не хотят и сдаются через полчаса.
3. Что автоматизатор из моей группы молодец и всем мальчишкам пример. Находит удивительное-рядом, критичное и хрен бы кто догадался посмотреть. При этом даже не запуская функциональность, а просто вдумчиво разглядывая код.
4. Что не можешь занять первое место — займись лучше организацией.
5. Что некоторые постановки лучше даже не читать. Целее будешь.
Пикрандом.
Слово Канеру
Чтоб запланировать набор задач, оцените количество времени, необходимое для выполнения каждой из них.
Ваша работа состоит из выполнения большого количества задач. Составьте их список (см. Канер, 1996b и любые другие книги по управлению проектами, охватывающие работы по оценке). Некоторые задачи можно описать только в общих чертах; другие можно разбить на мелкие части. По мере возможностей, создавайте отдельные задачи на все, что может занять больше дня. Оцените (предположите) сколько времени займет задача, прибавьте 25 процентов (больше или меньше в зависимости от компании) для совещаний, обучения и других работ вне проекта и используйте полученное значение, как время, необходимое для решения задачи.
Этот метод выглядит проще, чем на самом деле. Составление списка задач — не так тривиально, очень легко пропустить задачи или недооценить их.
Пробуйте и другие методы для оценок:
- Если вы делали и другие проекты, подобные этому, возьмите за основу время, которое они заняли.
- If you have a sense of the length and complexity of the program and a model based on data in your current company that relates length and complexity to duration of testing, apply the model to derive an estimate.
- Если вы чувствуете, что существуют риски, связанные с проектом, оцените время для проверки этих рисков
- Другие факторы, которые вы могли бы оценить. Например, если вы знаете, что программисты особенно хорошо знают этот тип приложений, то, вероятно, потребуется меньше времени на тестирование. Если этот конкретный программист делает много ошибок, чем остальные, то, возможно, понадобится больше времени на тестирование. Если пользовательская документация уже написана четко и ясно, если известен образ действий и входные данные пользователей, то тестировать будет проще.
Вы имеете возможность оценить объем тестирования в любой момент проекта, используя подобные методы. Чем дольше идет проект, тем точнее должны быть ваши оценки.
четверг, 11 октября 2012 г.
Lesson 186
Слово Канеру
Никогда не планируйте бюджет только для 2 циклов тестирования
Некоторые лаборатории тестирования закладывают бюджет на 2 цикла тестирования. В первом цикле, говорят они, мы найдем все ошибки. Во время второго цикла мы проверим исправления дефектов. Пока они не создадут новые тесты, продукт не будет меняться в любом случае, кроме исправления найденных ими ошибок. В реальном мире, нам придется тестировать продукт более, чем 2 раза:
- Как только мы узнаем что-то новое о продукте (во второй раз вы в любом случае знаете больше, чем в первый) мы думаем о новых, лучших тестах и сможем найти новые ошибки. Если вы работаете с двуступенчатой моделью, то у вас будет сильный стимул к созданию новых тестов
- Даже если программисты пытаются исправить все ошибки, найденные в первом цикле тестирования, вероятность того, что они не будут создавать новые небольшие ошибки при исправлении старых мала.
- Как правило, вы обнаружите, что некоторые тесты даже нельзя провести из за обнаруженных дефектов. Это блокирующие дефекты. Эти тесты не будут проведены в первом цикле тестирования, что если они обнаружат ошибки во втором?
Время от времени мы наблюдаем бюджеты на два цикла тестирования, в которые затем не укладываются. Поскольку изначальное предположение нереально, а задержки в графике неизбежны, то каждое изменение графика трактуется как провал и задержка группы тестирования.
Никогда не планируйте бюджет только для 2 циклов тестирования
Некоторые лаборатории тестирования закладывают бюджет на 2 цикла тестирования. В первом цикле, говорят они, мы найдем все ошибки. Во время второго цикла мы проверим исправления дефектов. Пока они не создадут новые тесты, продукт не будет меняться в любом случае, кроме исправления найденных ими ошибок. В реальном мире, нам придется тестировать продукт более, чем 2 раза:
- Как только мы узнаем что-то новое о продукте (во второй раз вы в любом случае знаете больше, чем в первый) мы думаем о новых, лучших тестах и сможем найти новые ошибки. Если вы работаете с двуступенчатой моделью, то у вас будет сильный стимул к созданию новых тестов
- Даже если программисты пытаются исправить все ошибки, найденные в первом цикле тестирования, вероятность того, что они не будут создавать новые небольшие ошибки при исправлении старых мала.
- Как правило, вы обнаружите, что некоторые тесты даже нельзя провести из за обнаруженных дефектов. Это блокирующие дефекты. Эти тесты не будут проведены в первом цикле тестирования, что если они обнаружат ошибки во втором?
Время от времени мы наблюдаем бюджеты на два цикла тестирования, в которые затем не укладываются. Поскольку изначальное предположение нереально, а задержки в графике неизбежны, то каждое изменение графика трактуется как провал и задержка группы тестирования.
среда, 10 октября 2012 г.
Lesson 185
Слово Канеру
«Достаточно тестировать» значит «моим клиентам достаточно информации для принятия правильного решения»
Так как тестирование является процессом сбора информации, у вас есть возможность остановиться, когда вы ее собрали достаточно. Вы могли бы остановиться после того, как найдете каждый баг, но удостовериться в том, что больше ошибок нет нельзя, это займет бесконечное количество времени. Вместо этого вы должны остановиться, когда есть основания полагать, что вероятность наличия в продукте неизвестных проблем достаточно низка.
Вот несколько факторов, влияющих на принятие решение о завершении тестирования(обеспечивающий низкий шанс появления ранее не обнаруженных баг ):
- Вы знаете, какие проблемы могли бы найти, если бы они существовали.
- Вы знаете, в каких частях продукта могут быть проблемы.
- Вы изучили продукт до степени, соразмерной рискам.
- Ваша стратегия тестирования в достаточной степени диверсифицирована, чтоб защититься от туннельного видения.
- Вы использовали для тестирования все доступные ресурсы.
- Вы использовали все стандарты тестирования, которых от вас ждут клиенты.
- Вы определили стратегию тестирования, результаты тестирования, анализ настолько точно и ясно, насколько могли.
Если вы сделали все это умело и добросовестно, то любой плохой баг, появившийся после релиза, будет соответствовать одной из причин:
- Вы не так хорошо понимаете динамику рисков, как думаете. Теперь вы знаете о ней больше.
- Вы ошиблись при тестировании. В следующий раз будьте лучше.
- Вы неверно оценили риски. Но менеджмент для того и нужен, чтоб брать на себя риски. Херня случается.
Ваша способность понимать, что информации достаточно, будет улучшаться по мере приобретения опыта тестирования продукта. Не грех в тестировании — пропустить ошибку. Грех — быть легкомысленным, беззаботным, не учиться на своем опыте.
«Достаточно тестировать» значит «моим клиентам достаточно информации для принятия правильного решения»
Так как тестирование является процессом сбора информации, у вас есть возможность остановиться, когда вы ее собрали достаточно. Вы могли бы остановиться после того, как найдете каждый баг, но удостовериться в том, что больше ошибок нет нельзя, это займет бесконечное количество времени. Вместо этого вы должны остановиться, когда есть основания полагать, что вероятность наличия в продукте неизвестных проблем достаточно низка.
Вот несколько факторов, влияющих на принятие решение о завершении тестирования(обеспечивающий низкий шанс появления ранее не обнаруженных баг ):
- Вы знаете, какие проблемы могли бы найти, если бы они существовали.
- Вы знаете, в каких частях продукта могут быть проблемы.
- Вы изучили продукт до степени, соразмерной рискам.
- Ваша стратегия тестирования в достаточной степени диверсифицирована, чтоб защититься от туннельного видения.
- Вы использовали для тестирования все доступные ресурсы.
- Вы использовали все стандарты тестирования, которых от вас ждут клиенты.
- Вы определили стратегию тестирования, результаты тестирования, анализ настолько точно и ясно, насколько могли.
Если вы сделали все это умело и добросовестно, то любой плохой баг, появившийся после релиза, будет соответствовать одной из причин:
- Вы не так хорошо понимаете динамику рисков, как думаете. Теперь вы знаете о ней больше.
- Вы ошиблись при тестировании. В следующий раз будьте лучше.
- Вы неверно оценили риски. Но менеджмент для того и нужен, чтоб брать на себя риски. Херня случается.
Ваша способность понимать, что информации достаточно, будет улучшаться по мере приобретения опыта тестирования продукта. Не грех в тестировании — пропустить ошибку. Грех — быть легкомысленным, беззаботным, не учиться на своем опыте.
Lessin 184
Слово Канеру
Нет универсальной формулы, чтоб сказать, когда хватит тестировать.
Мы хотели бы знать способ, с помощью которого можно определить, что мы провели достаточно тестов. Такие формулы предлагались. Мы считаем, что у всех таких формул есть проблемы. Кроме того, мы считаем, что лучше жить с неопределенностью, чем с ложной уверенностью. Правильное решение о прекращении тестирования основано на навыках и суждениях о факторах, которые, как вы считаете, на него влияют.
Так что не беспокойтесь о формуле. Беспокойтесь о том, как использовать вашу голову.
Нет универсальной формулы, чтоб сказать, когда хватит тестировать.
Мы хотели бы знать способ, с помощью которого можно определить, что мы провели достаточно тестов. Такие формулы предлагались. Мы считаем, что у всех таких формул есть проблемы. Кроме того, мы считаем, что лучше жить с неопределенностью, чем с ложной уверенностью. Правильное решение о прекращении тестирования основано на навыках и суждениях о факторах, которые, как вы считаете, на него влияют.
Так что не беспокойтесь о формуле. Беспокойтесь о том, как использовать вашу голову.
четверг, 4 октября 2012 г.
Lesson 183
В рамках инициативы «все что угодно, лишь бы не работать» провели эксперимент — обмен опытом с легким налетом фаллометрии.
Взяли задачу на тестирование, которая обычно делается одним тестером 2-4 часа и дали ее всем на час.
Все — это моя группа автоматизаторов, я и один ручной тестер у которого лицо выражением не напоминало «язанятанеподходи».
То есть четыре участника.
Час тестим постановку, потом собираемся, рассказываем о кейсах, которые использовали и которые не успели проверить. Делимся ошибками и обсуждаем — как нашли и почему не нашли.
По результатам: я и ручной тестер нашли две одинаковые ошибки. Один АТ не нашел баг. Другой ат сперва придумывал реально крутые нетипичные и многообещающие кейсы, а потом нашел очевидный баг, который никто не заметил.
Выводы. Опыт полезный, руководителю ручных тестеров порекомендовал ставить его на поток в таком виде:
Берется большая задача. На 4 часа, на 2 дня — неважно. Назначается ответственный. Он собирает народ, все вместе ее тестируют 1 час, затем собираются, обсуждают. Ответственный записывает все результаты этого брейнсторма и дальше пилит сам.
Больше велосипедов, хороших и разных.
И да, у нас появились еще две тестировщицы, ня. Не наташи, но вопрос решается.
Пикрандом по запросу "Наташа":
Слово Канеру
Возможность для тестирования возникает каждый раз, когда артефакт разработки переходит из одних рук в другие
Программы появляются не сразу готовыми, их пишут функция за функцией, фича за фичей. Аналогично — спецификации, требования и мануалы: они пишутся по разделам, глава за главой, часть за частью. Возможность для тестирования возникает каждый раз, когда такая часть готова. Это способ тестировать на всех этапах разработки продукта. Тестируйте то, что готово к тестированию, как только оно станет готовым к тестированию.
Взяли задачу на тестирование, которая обычно делается одним тестером 2-4 часа и дали ее всем на час.
Все — это моя группа автоматизаторов, я и один ручной тестер у которого лицо выражением не напоминало «язанятанеподходи».
То есть четыре участника.
Час тестим постановку, потом собираемся, рассказываем о кейсах, которые использовали и которые не успели проверить. Делимся ошибками и обсуждаем — как нашли и почему не нашли.
По результатам: я и ручной тестер нашли две одинаковые ошибки. Один АТ не нашел баг. Другой ат сперва придумывал реально крутые нетипичные и многообещающие кейсы, а потом нашел очевидный баг, который никто не заметил.
Выводы. Опыт полезный, руководителю ручных тестеров порекомендовал ставить его на поток в таком виде:
Берется большая задача. На 4 часа, на 2 дня — неважно. Назначается ответственный. Он собирает народ, все вместе ее тестируют 1 час, затем собираются, обсуждают. Ответственный записывает все результаты этого брейнсторма и дальше пилит сам.
Больше велосипедов, хороших и разных.
И да, у нас появились еще две тестировщицы, ня. Не наташи, но вопрос решается.
Пикрандом по запросу "Наташа":
Слово Канеру
Возможность для тестирования возникает каждый раз, когда артефакт разработки переходит из одних рук в другие
Программы появляются не сразу готовыми, их пишут функция за функцией, фича за фичей. Аналогично — спецификации, требования и мануалы: они пишутся по разделам, глава за главой, часть за частью. Возможность для тестирования возникает каждый раз, когда такая часть готова. Это способ тестировать на всех этапах разработки продукта. Тестируйте то, что готово к тестированию, как только оно станет готовым к тестированию.
Lesson 182
Сегодня было снежное замечательное утро.
Вот пруфпик снега:
Вот пруфпики замечательности - раз:
два:
и три:
Слово Канеру
Качественное планирование тестирования делает последующие изменения легкими.
Если изменения на поздних этапах неизбежны, наша задача — создать процесс тестирования, который сможет с ними работать. Вот несколько советов:
- Вместо разработки большого набора тестов до начала тестирования, разрабатывайте тесты тогда, когда они вам нужны. Если дальнейшие изменения в продукте сделают их устаревшими, то они будут полезными хотя бы какое-то время.
- Не создавайте огромных документов по тестированию, требующих больших эксплуатационных расходов, таких как подробные сценарии тестирования. Держите документы настолько маленькими, насколько это возможно.
- Не привязывайте ручные или автоматизированные тесты к специфике GUI, кроме тестов, специально для этого предназначенных. Даже если вы тестируете в качестве конечного пользователя, обязательно работающего через интерфейс, не завязывайте ваши тесты на мелкие детали интерфейса, так как они могут меняться.
- Проектируйте автоматизированные тесты так, чтоб максимизировать их ремонтопригодность и переносимость между платформами. (См. часть 5, «Автоматизация тестирования»)
- Создайте набор тестов, следящих за действиями, которые повторяются в программе постоянно. Это сохранит время на планирование и упростит делегирование, когда будуту добавлены фичи или функциональность будет изменена.
- Создайте качественный набор Smoke тестов, для быстрого обнаружения сбоев в ПО. Если программисты вносят значительные изменения, то они, вероятно, часто пересобирают ПО и с удовольствием будут высылать вам новые билды как можно чаще. Smopke-тесты дешево находят плохие сборки, что делает их полезными для того, чтоб справиться с частыми билдами.
- Всерьез рассмотрите возможность использования техник экстремального программирования для разработки автоматизированных тестов (Beck 1999 и Jeffries в 2000). В частности мы рекомендуем разработать общую архитектуру для автоматизированных тестов, а затем итеративно дорабатывать их код, минимизируя риски проекта (здесь проект автоматизации рассматривается как подпроект продукта). Попробуйте программирование в парах, общайтесь с заинтересованными лицами (другими тестировщиками, менеджерами) чтоб определить направления работы.
- Разработайте модель пользователя продукта, определите пользу, которую хочет получить пользователь от продукта. Создайте комплексные тесты на основе этой модели. Большинство таких тестов не будет быстро меняться, так как они ориентированы на цели пользователя, а не на детали реализации.
- Помогите программистам создать большой набор юнит-тестов и других тестов, проверяющих базовую функциональность продукта. Они могут запускаться каждый раз при изменении кода, перед отправкой в тестирование.
Эти предложения не так важны, как общий принцип: анализ практик тестирования применительно к вашей ситуации. Определите, с какими тратами и проблемами вы сталкиваетесь в случае поздних изменений ПО. Затем найдите способы изменить ваши процессы, чтоб уменьшить эти затраты и решить проблемы, или размазать из по всему периоду разработки продукта.
Вот пруфпик снега:
 |
| Альбом: office |
Вот пруфпики замечательности - раз:
 |
| Альбом: office |
два:
 |
| Альбом: office |
и три:
 |
| Альбом: office |
Слово Канеру
Качественное планирование тестирования делает последующие изменения легкими.
Если изменения на поздних этапах неизбежны, наша задача — создать процесс тестирования, который сможет с ними работать. Вот несколько советов:
- Вместо разработки большого набора тестов до начала тестирования, разрабатывайте тесты тогда, когда они вам нужны. Если дальнейшие изменения в продукте сделают их устаревшими, то они будут полезными хотя бы какое-то время.
- Не создавайте огромных документов по тестированию, требующих больших эксплуатационных расходов, таких как подробные сценарии тестирования. Держите документы настолько маленькими, насколько это возможно.
- Не привязывайте ручные или автоматизированные тесты к специфике GUI, кроме тестов, специально для этого предназначенных. Даже если вы тестируете в качестве конечного пользователя, обязательно работающего через интерфейс, не завязывайте ваши тесты на мелкие детали интерфейса, так как они могут меняться.
- Проектируйте автоматизированные тесты так, чтоб максимизировать их ремонтопригодность и переносимость между платформами. (См. часть 5, «Автоматизация тестирования»)
- Создайте набор тестов, следящих за действиями, которые повторяются в программе постоянно. Это сохранит время на планирование и упростит делегирование, когда будуту добавлены фичи или функциональность будет изменена.
- Создайте качественный набор Smoke тестов, для быстрого обнаружения сбоев в ПО. Если программисты вносят значительные изменения, то они, вероятно, часто пересобирают ПО и с удовольствием будут высылать вам новые билды как можно чаще. Smopke-тесты дешево находят плохие сборки, что делает их полезными для того, чтоб справиться с частыми билдами.
- Всерьез рассмотрите возможность использования техник экстремального программирования для разработки автоматизированных тестов (Beck 1999 и Jeffries в 2000). В частности мы рекомендуем разработать общую архитектуру для автоматизированных тестов, а затем итеративно дорабатывать их код, минимизируя риски проекта (здесь проект автоматизации рассматривается как подпроект продукта). Попробуйте программирование в парах, общайтесь с заинтересованными лицами (другими тестировщиками, менеджерами) чтоб определить направления работы.
- Разработайте модель пользователя продукта, определите пользу, которую хочет получить пользователь от продукта. Создайте комплексные тесты на основе этой модели. Большинство таких тестов не будет быстро меняться, так как они ориентированы на цели пользователя, а не на детали реализации.
- Помогите программистам создать большой набор юнит-тестов и других тестов, проверяющих базовую функциональность продукта. Они могут запускаться каждый раз при изменении кода, перед отправкой в тестирование.
Эти предложения не так важны, как общий принцип: анализ практик тестирования применительно к вашей ситуации. Определите, с какими тратами и проблемами вы сталкиваетесь в случае поздних изменений ПО. Затем найдите способы изменить ваши процессы, чтоб уменьшить эти затраты и решить проблемы, или размазать из по всему периоду разработки продукта.
вторник, 2 октября 2012 г.
Lesson 181
Слово Канеру
Программисты как торнадо
Продавцы инструментов тестирования пытаются убедить компанию создавать тесты уровня пользовательского интерфейса, создаваемые путем захвата и воспроизведения. Им отвечают, что это не будет работать, так как программисты будут менять набор фич продукта и их интерфейс. Продавцы отвечают, что тестировщики должны подтолкнуть программистов к следованию инженерным подходам, в которых используется замораживание интерфейса и набора фич на ранних стадиях проекта. Тогда тестировщики смогут выполнять свою работу.
Основная ценность такого шага в том, что он поможет вам признать, что вы не хотите работать с подобными продавцами. Подобные плохие советы упоминались ранее (отказываться от тестирования, если вам не предоставили спецификацию, урок 173), они основаны на вещах и событиях, которые в вашей компании не происходят.
На среднем западе США у домов есть подвалы. Исторически сложилось так, что подвал — место, где укрываются от торнадо. Вы не должны брать за основу опыт строителей. А еще вы могли бы пропустить создание подвала и заявить, что торнадо быть не должно. Однако это заявление не несет пользы, когда за окном торнадо и движется оно на вас.
Программисты как торнадо. Думайте о них как о природной силе. Они делают то, что делают. От компании к компании программисты будут сильно меняться. Проектируйте тесты соответственно.
Программисты как торнадо
Продавцы инструментов тестирования пытаются убедить компанию создавать тесты уровня пользовательского интерфейса, создаваемые путем захвата и воспроизведения. Им отвечают, что это не будет работать, так как программисты будут менять набор фич продукта и их интерфейс. Продавцы отвечают, что тестировщики должны подтолкнуть программистов к следованию инженерным подходам, в которых используется замораживание интерфейса и набора фич на ранних стадиях проекта. Тогда тестировщики смогут выполнять свою работу.
Основная ценность такого шага в том, что он поможет вам признать, что вы не хотите работать с подобными продавцами. Подобные плохие советы упоминались ранее (отказываться от тестирования, если вам не предоставили спецификацию, урок 173), они основаны на вещах и событиях, которые в вашей компании не происходят.
На среднем западе США у домов есть подвалы. Исторически сложилось так, что подвал — место, где укрываются от торнадо. Вы не должны брать за основу опыт строителей. А еще вы могли бы пропустить создание подвала и заявить, что торнадо быть не должно. Однако это заявление не несет пользы, когда за окном торнадо и движется оно на вас.
Программисты как торнадо. Думайте о них как о природной силе. Они делают то, что делают. От компании к компании программисты будут сильно меняться. Проектируйте тесты соответственно.
Lesson 180
Мало того, что тестировщик это аджайл, нанотехнологии и кавай, это еще и с каждым часом все более престижная профессия.
К нам идут не только осветители, бармены и грузчики, но теперь - и юристы. Так победим.
Слово Канеру
Сигнализируйте о проблемах управления конфигурациями менеджеру проекта.
Какова вероятность того, что исправление бага сломает что-либо еще в продукте или исправленный баг вернется? Вероятность побочных эффектов широко варьируется в зависимости от компании и проекта. Мы видели компании, в которых почти не было побочных эффектов, и мы видели компании, страдавшие от них.
Побочные эффекты появляются в старом, часто исправляемом, сильно связанном и плохо документированном коде. Но даже относительно чистый код страдает от проблем побочных эффектов. Одной из распространенных причин является плохое управление конфигурациями.
Если исправленные баги возвращаются, исправляются, снова возвращаются день за днем, то вы, вероятно, наблюдаете за проблемой управления исходным кодом. Либо группа разработки решит эту проблему, либо вы будете постоянно перепроверять этот код в каждой сборке.
Иногда проблема не в управлении конфигурациями. Чтоб проиллюстрировать это Rex Black рассказал нам о «подпроекте тестирования на четыре месяца с четырьмя сотнями ошибок, каждая из которых была переоткрыта в среднем по два с половиной раза.» Он сказал: «Это не проблема управления конфигурациями, это проблема вызвана некачественным планированием.»
В любом случае, поговорите с менеджером проекта о этой проблеме и попросите совета.
Если проблема не исчезнет, сообщите о необходимости высокого уровня регрессионного тестирования (и связанных с этим работ) в отчете о статусе продукта. В той степени, в которой это покажется постоянной проблемой компании, проекты будущих бюджетов предусмотрят возможность широкого использования автоматизации тестирования.
К нам идут не только осветители, бармены и грузчики, но теперь - и юристы. Так победим.
Слово Канеру
Сигнализируйте о проблемах управления конфигурациями менеджеру проекта.
Какова вероятность того, что исправление бага сломает что-либо еще в продукте или исправленный баг вернется? Вероятность побочных эффектов широко варьируется в зависимости от компании и проекта. Мы видели компании, в которых почти не было побочных эффектов, и мы видели компании, страдавшие от них.
Побочные эффекты появляются в старом, часто исправляемом, сильно связанном и плохо документированном коде. Но даже относительно чистый код страдает от проблем побочных эффектов. Одной из распространенных причин является плохое управление конфигурациями.
Если исправленные баги возвращаются, исправляются, снова возвращаются день за днем, то вы, вероятно, наблюдаете за проблемой управления исходным кодом. Либо группа разработки решит эту проблему, либо вы будете постоянно перепроверять этот код в каждой сборке.
Иногда проблема не в управлении конфигурациями. Чтоб проиллюстрировать это Rex Black рассказал нам о «подпроекте тестирования на четыре месяца с четырьмя сотнями ошибок, каждая из которых была переоткрыта в среднем по два с половиной раза.» Он сказал: «Это не проблема управления конфигурациями, это проблема вызвана некачественным планированием.»
В любом случае, поговорите с менеджером проекта о этой проблеме и попросите совета.
Если проблема не исчезнет, сообщите о необходимости высокого уровня регрессионного тестирования (и связанных с этим работ) в отчете о статусе продукта. В той степени, в которой это покажется постоянной проблемой компании, проекты будущих бюджетов предусмотрят возможность широкого использования автоматизации тестирования.
Подписаться на:
Сообщения (Atom)