Слово Канеру:
Вас труднее обмануть, если вы знаете, что вы дурак.
Мошенники говорят, что легче всего обмануть тех, кто убежден, что его невозможно обмануть. Вы можете применить этот принцип в своей работе тестировщика. Убедите себя в том, что вы дурак. Это несложно, просто осторожно наблюдайте за своими ошибками во время тестирования. Записывайте каждый раз, когда другой тестировщик обнаружил проблему там, где вы могли бы ее обнаружить, но не сделали этого.
Если вы знаете, что вас легко обмануть, то вы становитесь немного более внимательным. Вы и ваш ум сильнее и подробнее работают с деталями стратегии тестирования. Это один из самых быстрых путей совершенствования начинающего тестировщика, так как сознание того, что вы дурак — это отношение, а не навык или знание. Проблема начинающих тестировщиков в том, что для них этот принцип — просто вера («Мне сказали, что я должен думать, что меня можно обмануть...»); в то время как чувства и рефлексы опытных тестировщиков были разбужены и обострены болью от постоянного накручивания («Я помню большой возврат 94-го. Мы не могли представить себе, что вирус может заразить наш золотой мастер-диск. Я потерял свою невинность в тот день.»)
вторник, 25 октября 2011 г.
понедельник, 24 октября 2011 г.
Процент багов найденных различными техниками.
Проценты багов найденных различными техниками.
Обнаружено у А. Селяева, ориджинал контент тут.
Тут не написано, сколько это стоит трудозатрат, это бы серьезно поменяло картину.
Опытные товарищи говорят, что львиная доля приходится на - Personal desk checking of code, да и reviewsстоят недешево.
UPD: Там и дальше интересно:
non-critical bugs are twice as expensive to fix after release, on average. However, the multiplier becomes much, much larger for severe bugs: according to several estimates severe bugs are 100 times more expensive to fix after shipping than they are to fix before shipping.
 |
| Альбом: bug |
Обнаружено у А. Селяева, ориджинал контент тут.
Тут не написано, сколько это стоит трудозатрат, это бы серьезно поменяло картину.
Опытные товарищи говорят, что львиная доля приходится на - Personal desk checking of code, да и reviewsстоят недешево.
UPD: Там и дальше интересно:
non-critical bugs are twice as expensive to fix after release, on average. However, the multiplier becomes much, much larger for severe bugs: according to several estimates severe bugs are 100 times more expensive to fix after shipping than they are to fix before shipping.
воскресенье, 23 октября 2011 г.
Осенним вечером
Меняю пособие "Радость шизофрении" и вторую личность на чертежи ионного бобролёта.
Баш.
Раз
Два
Три
Баш.
Раз
 |
| Альбом: randompics4lj |
Два
 |
| Альбом: randompics4lj |
Три
 |
| Альбом: randompics4lj |
суббота, 22 октября 2011 г.
пятница, 21 октября 2011 г.
Ненависти пост.
Ubuntu 11.10
Поставил, оценил интерфейс unity.
И грязно выругался.
Буду либо даунгрейдиться на выходных, либо привыкать к плохому.
Поставил, оценил интерфейс unity.
И грязно выругался.
Буду либо даунгрейдиться на выходных, либо привыкать к плохому.
ы!
Хочу от Оргов вообще и Баранцева в частности какой-нибудь ништячок.
Я собрал на просмотр confeT&qa 10 человек. Кто больше?
З.Ы. Бита с автографом - хороший ништячок.
Я собрал на просмотр confeT&qa 10 человек. Кто больше?
З.Ы. Бита с автографом - хороший ништячок.
Lesson 39
Тестероконференция ок, но народ идет неохотно, ссылаются на заняты и поздно.
На доклады по автоматизации не идут:
Автоматические тестировщики - говорят, что все это уже знают,
Ручные утверждают, что ничего не понимают.
Расстрелял бы.
Слово Канеру:
Ты не можешь избежать предубеждения, но ты можешь управлять им.
Вы необъективны. Это заставляет вас с большей вероятностью выбирать одни, а не другие тесты. Если есть длинное поле для редактирования, то скорее вы введете в него что-то вроде 1111111111, нежели 3287504619, так как легче ввести строку из повторяющихся символов, чем из случайных. Это небольшое отклонение, но все-таки отклонение. Более зловещим является тот факт, что большинство тестеров склоняются в пользу тестирования более очевидных функций, которые могут и не быть важными. Также, многие тестировщики склоняются к пользователям, которые думают как они и склонны выполнять тесты с простыми и искаженными входными данными, в отличии от реалистичных входных данных умеренной сложности.
Несколько популярных предубеждений:
Ассимиляция. Мне больше нравится создавать тесты так, чтоб интерпретировать их будущие результаты так, чтоб они подтверждали мое мнение о продукте.
Подтверждение. Мне больше нравится обращать внимание на те результаты тестов, которые подтверждают мое мнение о продукте.
Доступность. Если я легко могу придумать сценарий, в котором пользователь ведет себя определенным образом, то я буду считать, что этот сценарий описывает наиболее вероятное поведение пользователя.
Первенство. Я буду больше доверять мнению, составленному во время первого наблюдения.
Новизна. Я буду больше доверять мнению, составленному во время недавнего наблюдения.
Эффект рамки. Моя реакция на отчет об ошибке сильно зависит от формулировки и независима от того, что отчет значит.
Известность. Я буду придавать больший вес пользователям с которыми я знаком.
Репрезентативность. Я ожидаю, что у маленьких проблем небольшие причины, в то время как большие проблемы требуют больших причин.
Вы не можете избежать этих предубеждений. Они по большей части, зашиты в наш мозг. То что вы можете сделать — управлять ими. Например — путем изучения предубеждений и практикуя их осознание, вы будете более оснащенным для того, чтоб компенсировать их в вашем мышлении. Разнообразие тоже является защитой от большого предубеждения. Если много тестировщиков бренстормят тесты вместе, они могут минимизировать влияние многих тестировщицких предубеждений. По определению эвристика — это тоже предубеждение. Мы используем эвристику так как надеемся, что это предубеждение будет полезным.
На доклады по автоматизации не идут:
Автоматические тестировщики - говорят, что все это уже знают,
Ручные утверждают, что ничего не понимают.
Слово Канеру:
Ты не можешь избежать предубеждения, но ты можешь управлять им.
Вы необъективны. Это заставляет вас с большей вероятностью выбирать одни, а не другие тесты. Если есть длинное поле для редактирования, то скорее вы введете в него что-то вроде 1111111111, нежели 3287504619, так как легче ввести строку из повторяющихся символов, чем из случайных. Это небольшое отклонение, но все-таки отклонение. Более зловещим является тот факт, что большинство тестеров склоняются в пользу тестирования более очевидных функций, которые могут и не быть важными. Также, многие тестировщики склоняются к пользователям, которые думают как они и склонны выполнять тесты с простыми и искаженными входными данными, в отличии от реалистичных входных данных умеренной сложности.
Несколько популярных предубеждений:
Ассимиляция. Мне больше нравится создавать тесты так, чтоб интерпретировать их будущие результаты так, чтоб они подтверждали мое мнение о продукте.
Подтверждение. Мне больше нравится обращать внимание на те результаты тестов, которые подтверждают мое мнение о продукте.
Доступность. Если я легко могу придумать сценарий, в котором пользователь ведет себя определенным образом, то я буду считать, что этот сценарий описывает наиболее вероятное поведение пользователя.
Первенство. Я буду больше доверять мнению, составленному во время первого наблюдения.
Новизна. Я буду больше доверять мнению, составленному во время недавнего наблюдения.
Эффект рамки. Моя реакция на отчет об ошибке сильно зависит от формулировки и независима от того, что отчет значит.
Известность. Я буду придавать больший вес пользователям с которыми я знаком.
Репрезентативность. Я ожидаю, что у маленьких проблем небольшие причины, в то время как большие проблемы требуют больших причин.
Вы не можете избежать этих предубеждений. Они по большей части, зашиты в наш мозг. То что вы можете сделать — управлять ими. Например — путем изучения предубеждений и практикуя их осознание, вы будете более оснащенным для того, чтоб компенсировать их в вашем мышлении. Разнообразие тоже является защитой от большого предубеждения. Если много тестировщиков бренстормят тесты вместе, они могут минимизировать влияние многих тестировщицких предубеждений. По определению эвристика — это тоже предубеждение. Мы используем эвристику так как надеемся, что это предубеждение будет полезным.
среда, 19 октября 2011 г.
Lesson 38
Слово Канеру
Используйте эвристику для быстрой генерации идей тестирования.
Эвристика это правила мышления, способы делать обоснованные предположения. Это слово произошло от греков, означает «служащее для обнаружения». Эвристика не гарантирует правильного ответа, но тем не меняя, она полезна. Основополагающая книга по эвристике: How to Solve It (Polya 1957).
Так как число возможных тестов бесконечно, мы сделаем предположение о том, что небольшая группа тестов будет эффективна при наших ограничениях времени и бюджета. Опытные тестировщики собирают и обмениваются эвристическими методами, улучшающими качество их предположений. Хороший набор эвристик позволяет создавать тесты очень быстро. Вот некоторые примеры:
- Тестируйте границы. Наиболее вероятно именно они невнятно описаны в спецификациях.
- Проверяйте сообщения об ошибке. Код обработки ошибок, как правило, хуже кода основной функциональности.
- Тестируйте на конфигурациях, которые отличаются от конфигураций программистов. Свою конфигурацию программист уже проверил.
- Выполняйте тесты на сложной, раздражающей настройке. Тесты с простой настройкой, скорее всего, уже проводились.
- Избегайте избыточных тестов. Если один тест повторяет другой, то что вам это даст?
Чтоб правильно использовать эвристику нужно знать: в ней нет мудрости. Мудрость в вас. Все, что делает эвристика — дает вам гипотезы. Слепо следуя эвристикам вы не придете к хорошим практикам тестирования. Когда вы их собираете, попытайтесь понять и обосновать все условия, при которых они работают.
Используйте эвристику для быстрой генерации идей тестирования.
Эвристика это правила мышления, способы делать обоснованные предположения. Это слово произошло от греков, означает «служащее для обнаружения». Эвристика не гарантирует правильного ответа, но тем не меняя, она полезна. Основополагающая книга по эвристике: How to Solve It (Polya 1957).
Так как число возможных тестов бесконечно, мы сделаем предположение о том, что небольшая группа тестов будет эффективна при наших ограничениях времени и бюджета. Опытные тестировщики собирают и обмениваются эвристическими методами, улучшающими качество их предположений. Хороший набор эвристик позволяет создавать тесты очень быстро. Вот некоторые примеры:
- Тестируйте границы. Наиболее вероятно именно они невнятно описаны в спецификациях.
- Проверяйте сообщения об ошибке. Код обработки ошибок, как правило, хуже кода основной функциональности.
- Тестируйте на конфигурациях, которые отличаются от конфигураций программистов. Свою конфигурацию программист уже проверил.
- Выполняйте тесты на сложной, раздражающей настройке. Тесты с простой настройкой, скорее всего, уже проводились.
- Избегайте избыточных тестов. Если один тест повторяет другой, то что вам это даст?
Чтоб правильно использовать эвристику нужно знать: в ней нет мудрости. Мудрость в вас. Все, что делает эвристика — дает вам гипотезы. Слепо следуя эвристикам вы не придете к хорошим практикам тестирования. Когда вы их собираете, попытайтесь понять и обосновать все условия, при которых они работают.
Lesson 37
Слово Канеру
При тестировании сложного продукта: погружайтесь и выходите
Иногда сложность бывает огромной. Вы можете почувствовать себя интеллектуально парализованным. Поэтому тестируйте сложные наборы функций набегами. Ваш ум обладает удивительной способностью понимать сложные вещи, но не ждите. Что он поймет все и сразу. Набросьтесь на продукт в течении 30-60 минут. Затем остановитесь и займитесь чем-нибудь другим. Это метод погружения и выхода. Не беспокойтесь о непродуктивности этого короткого промежутка времени.
Самое замечательное в этом методе то, что он не требует плана, кроме выделения части продукта и работы с ней. После нескольких циклов вы представите себе модель и контуры продукта. Более организованная стратегия тестирования и изучения придет вам в голову. Это работает как по волшебству. В конце-концов вы будете знать достаточно, чтоб создать комплексный план тестирования, который поможет вам.
При тестировании сложного продукта: погружайтесь и выходите
Иногда сложность бывает огромной. Вы можете почувствовать себя интеллектуально парализованным. Поэтому тестируйте сложные наборы функций набегами. Ваш ум обладает удивительной способностью понимать сложные вещи, но не ждите. Что он поймет все и сразу. Набросьтесь на продукт в течении 30-60 минут. Затем остановитесь и займитесь чем-нибудь другим. Это метод погружения и выхода. Не беспокойтесь о непродуктивности этого короткого промежутка времени.
Самое замечательное в этом методе то, что он не требует плана, кроме выделения части продукта и работы с ней. После нескольких циклов вы представите себе модель и контуры продукта. Более организованная стратегия тестирования и изучения придет вам в голову. Это работает как по волшебству. В конце-концов вы будете знать достаточно, чтоб создать комплексный план тестирования, который поможет вам.
Lesson 36
Переехали в комнату с большими окнами и впятеро меньшим количеством народу.
Тут тихо и работоспособно.
Слово Канеру:
Не путайте тесты и тестирование
Что значит создать тест? Это может означать, что тестировщик провел сессию исследовательского тестирования с результатом в виде эфемерных тестов без какой либо документации. Это может означать, что тестировщик создал набор исполняемых программ или набор подробных процедур испытаний. Это может быть ссылка на высокоуровневую матрицу тестирования, тест-план или набор тестовых данных.
Концепция, по которой тест становится самодостаточным, осязаемым, и независимым от других тестов удобна (мы будем ее придерживаться при написании этой книги), но очень ограничена. Это то, что важно в тестировании, а не то, как вы делите тесты на пакеты или как называете тесты.
Тестирование это то, что связано со следующими четырьмя активностями:
- Конфигурирование. Подготовьте продукт к тестам. Создайте начальное состояние. В противном случае результаты тестов могут быть испорчены меняющимися параметрами.
- Оперирование. Поток данных о продукте. Подавайте команды. Взаимодействуйте с ним. В противном случае, вы просто сидите и наблюдаете, а не тестируете.
- Наблюдение. Собирайте информацию о том, как продукт ведет себя, о выходной информации, о состоянии системы в целом, о взаимодействии с другими продуктами и так далее. Вы не можете наблюдать за всем, но все, за чем вы не наблюдаете, может привести к ошибке.
- Оценка. Применяйте правила, выводы, механизмы которые обнаружат баги в том, что вы наблюдаете. В противном случае в вашем докладе не будет проблем, или вы будете просто передавать данные клиентам, которые должны будут выполнить оценку самостоятельно.
Созидание имеет много форм. Не стоит зацикливаться на форме, просто убедитесь, что эти четыре активности присутствуют. Сосредоточитесь на том, кто их выполняет и на том, насколько хорошо тесты соответствуют миссии и цели тестирования.
Тут тихо и работоспособно.
Слово Канеру:
Не путайте тесты и тестирование
Что значит создать тест? Это может означать, что тестировщик провел сессию исследовательского тестирования с результатом в виде эфемерных тестов без какой либо документации. Это может означать, что тестировщик создал набор исполняемых программ или набор подробных процедур испытаний. Это может быть ссылка на высокоуровневую матрицу тестирования, тест-план или набор тестовых данных.
Концепция, по которой тест становится самодостаточным, осязаемым, и независимым от других тестов удобна (мы будем ее придерживаться при написании этой книги), но очень ограничена. Это то, что важно в тестировании, а не то, как вы делите тесты на пакеты или как называете тесты.
Тестирование это то, что связано со следующими четырьмя активностями:
- Конфигурирование. Подготовьте продукт к тестам. Создайте начальное состояние. В противном случае результаты тестов могут быть испорчены меняющимися параметрами.
- Оперирование. Поток данных о продукте. Подавайте команды. Взаимодействуйте с ним. В противном случае, вы просто сидите и наблюдаете, а не тестируете.
- Наблюдение. Собирайте информацию о том, как продукт ведет себя, о выходной информации, о состоянии системы в целом, о взаимодействии с другими продуктами и так далее. Вы не можете наблюдать за всем, но все, за чем вы не наблюдаете, может привести к ошибке.
- Оценка. Применяйте правила, выводы, механизмы которые обнаружат баги в том, что вы наблюдаете. В противном случае в вашем докладе не будет проблем, или вы будете просто передавать данные клиентам, которые должны будут выполнить оценку самостоятельно.
Созидание имеет много форм. Не стоит зацикливаться на форме, просто убедитесь, что эти четыре активности присутствуют. Сосредоточитесь на том, кто их выполняет и на том, насколько хорошо тесты соответствуют миссии и цели тестирования.
понедельник, 17 октября 2011 г.
Так
Дочитал Deadline Демарко.
Мысль в тему: "Человек ты, конечно, хороший, но как собутыльник - говно"
Может быть, для менеджеров там и масса полезной инфы, но роман - так себе.
Не, нормальная книжка, но после нее, сука, осталось ощущение, что пони накакали радугой тебе прямо в душу. Через недельку надо перечитать Йордана или Сирилла.
А сейчас пан Анджей:
Мир, милостивые государи, за последнее время взял, да и увеличился. Но в то же время как бы и уменьшился.
Мысль в тему: "Человек ты, конечно, хороший, но как собутыльник - говно"
Может быть, для менеджеров там и масса полезной инфы, но роман - так себе.
Не, нормальная книжка, но после нее, сука, осталось ощущение, что пони накакали радугой тебе прямо в душу. Через недельку надо перечитать Йордана или Сирилла.
А сейчас пан Анджей:
Мир, милостивые государи, за последнее время взял, да и увеличился. Но в то же время как бы и уменьшился.
воскресенье, 16 октября 2011 г.
Так
Помните, как-то я спрашивал у вас, как вам фильм Последний король шотландии?
Я его тогда посмотрел, честно скажу, сильный фильм, отличный кастинг на роль Иди Амина.
Но так получилось, что фильм мне не очень понравился, причем по моей вине - еще до просмотра я ознакомился с биографией диктатора.
И по сравнению с ней фильм скучен, добр, мил и спокоен. И киношный Амин во сто крат милее того, реального.
Пошли дальше.
Контора заботится о нас, и, как я рассказывал, дала погоняться читалку. Как водится, с напутствием: читать только полезную литературу по работе. Конторе я отчитаюсь позднее, а пока вам.
Читалка: Amazon Kindle 3
Стоит тыщ 5, fb2 не понимает поэтому Calibre обязательна к установке. Проблем с настройкой никаких, девайс прост как флешка - залил и читай.Комрады тут стонали, что нет древовидной иерархии книг, на что я могу ответить:
- На страницу помещается десять книг, а это много больше месяца чтения, так что не надо звездеть. И так нормально.
О главном - о том как читать. Читать - отлично. Последние лет пять в бумажном виде я читаю только каждую пятую книгу, остальные с экрана, от киндла я ждал чего-то подобного. Сел в кресло, включил... и понял, что это хоть и электронная, но, блин, бумага! В темноте не почитать.
В остальном - отлично лежит в руке, легкая, листать приятно.
Настоятельно рекомендую вам,и может быть скоро куплю себе.Зачем, если и так есть с чего читать? Все просто, чтоб читать. Ведь если купил ебук, то будь добр, читай с него, и отдать несколько тысяч рублей, чтоб заставить себя читать - не так уж и дорого, не так ли?
Теперь о книгах.
1. Сэр Терри Пратчетт, Патриот
2. Том ДеМарко, «Deadline. Роман об управлении проектами»
3. E. Dusting, Automated Software Testing
4. А. Сапковский, Божьи Воины
Я его тогда посмотрел, честно скажу, сильный фильм, отличный кастинг на роль Иди Амина.
Но так получилось, что фильм мне не очень понравился, причем по моей вине - еще до просмотра я ознакомился с биографией диктатора.
И по сравнению с ней фильм скучен, добр, мил и спокоен. И киношный Амин во сто крат милее того, реального.
Пошли дальше.
Контора заботится о нас, и, как я рассказывал, дала погоняться читалку. Как водится, с напутствием: читать только полезную литературу по работе. Конторе я отчитаюсь позднее, а пока вам.
Читалка: Amazon Kindle 3
Стоит тыщ 5, fb2 не понимает поэтому Calibre обязательна к установке. Проблем с настройкой никаких, девайс прост как флешка - залил и читай.Комрады тут стонали, что нет древовидной иерархии книг, на что я могу ответить:
- На страницу помещается десять книг, а это много больше месяца чтения, так что не надо звездеть. И так нормально.
О главном - о том как читать. Читать - отлично. Последние лет пять в бумажном виде я читаю только каждую пятую книгу, остальные с экрана, от киндла я ждал чего-то подобного. Сел в кресло, включил... и понял, что это хоть и электронная, но, блин, бумага! В темноте не почитать.
В остальном - отлично лежит в руке, легкая, листать приятно.
 |
| Альбом: Быстрая загрузка |
Настоятельно рекомендую вам,и может быть скоро куплю себе.Зачем, если и так есть с чего читать? Все просто, чтоб читать. Ведь если купил ебук, то будь добр, читай с него, и отдать несколько тысяч рублей, чтоб заставить себя читать - не так уж и дорого, не так ли?
Теперь о книгах.
1. Сэр Терри Пратчетт, Патриот
2. Том ДеМарко, «Deadline. Роман об управлении проектами»
3. E. Dusting, Automated Software Testing
4. А. Сапковский, Божьи Воины
пятница, 14 октября 2011 г.
Lesson 35
Сегодня отучал fuzz тест совершать ритуальное самоубийство путем удаления прав у сотрудника, под которым он ходит. И приучал его внятно, по-русски, рассказывать о найденных багах в частности и о ходе процесса в целом.
Слово Канеру:
В конце концов, все, что у вас есть, это представление о продукте.
Все что вы знаете о качестве продукта — предположения. Независимо от того, чем оно подтверждено, вы не можете быть до конца уверены в своей правоте. Поэтому каждый раз, когда вы докладываете о качестве продукта, вы должны осознавать, что содержание доклада определено тестированием, и понимать ограничения вашего процесса тестирования.
Слово Канеру:
В конце концов, все, что у вас есть, это представление о продукте.
Все что вы знаете о качестве продукта — предположения. Независимо от того, чем оно подтверждено, вы не можете быть до конца уверены в своей правоте. Поэтому каждый раз, когда вы докладываете о качестве продукта, вы должны осознавать, что содержание доклада определено тестированием, и понимать ограничения вашего процесса тестирования.
четверг, 13 октября 2011 г.
Lesson 34
Сегодня учил тест врать-врать, да не завираться.
А еще учил этот же тест не тащить ничего с панели управления
Вроде как научил, но он все равно нет-нет, да добавит какую-нибудь ссылку в избранное.
Да, чуть не забыл! Мне дали на недельку офисный киндл погоняццо. Буду лабать обзор же! Ну киндла и книжки, что я с него прочту. Если я вас не обману, это будут Пратчетт, Демарко ну и Дастин, например.
Слово Канеру:
«Это работает» на самом деле означает, что некоторые требования в определенной степени удовлетворены.
Иногда вы слышите как кто-нибудь говорит: «я проверил, это работает», «я уверен, это работает», или «сейчас это работает лучше». Мы рекомендуем переводить «это работает» как «некоторые требования в определенной степени удовлетворены». Вопросы, которые должны немедленно появиться у вас:
Что «это»? О какой части продукта мы говорим?
В каком виде? Что именно наблюдалось?
Какие требования были проверены? Корректность? Производительность?
В той ли степени выполнены требования, чтоб пройти тест? Это работает только нормально или в высшей степени отлично?
Когда это работает? В каких обстоятельствах продукт был покрыт тестами? Насколько эти обстоятельства можно безопасно обобщать?
Вам не придется задавать эти вопросы вслух, если вы этого не хотите. Дело в том, что фраза «это работает» бессмысленна без дальнейшей квалификации. И когда вы думаете «это работает» - это тоже может соответствовать чьим-то определениям.
А еще учил этот же тест не тащить ничего с панели управления
Вроде как научил, но он все равно нет-нет, да добавит какую-нибудь ссылку в избранное.
Да, чуть не забыл! Мне дали на недельку офисный киндл погоняццо. Буду лабать обзор же! Ну киндла и книжки, что я с него прочту. Если я вас не обману, это будут Пратчетт, Демарко ну и Дастин, например.
Слово Канеру:
«Это работает» на самом деле означает, что некоторые требования в определенной степени удовлетворены.
Иногда вы слышите как кто-нибудь говорит: «я проверил, это работает», «я уверен, это работает», или «сейчас это работает лучше». Мы рекомендуем переводить «это работает» как «некоторые требования в определенной степени удовлетворены». Вопросы, которые должны немедленно появиться у вас:
Что «это»? О какой части продукта мы говорим?
В каком виде? Что именно наблюдалось?
Какие требования были проверены? Корректность? Производительность?
В той ли степени выполнены требования, чтоб пройти тест? Это работает только нормально или в высшей степени отлично?
Когда это работает? В каких обстоятельствах продукт был покрыт тестами? Насколько эти обстоятельства можно безопасно обобщать?
Вам не придется задавать эти вопросы вслух, если вы этого не хотите. Дело в том, что фраза «это работает» бессмысленна без дальнейшей квалификации. И когда вы думаете «это работает» - это тоже может соответствовать чьим-то определениям.
среда, 12 октября 2011 г.
Lesson 33
Сегодня вджобывал.
PMD помогло выяснить, что система тестирования старого проекта является тонко сбалансированной конструкцией из костылей.
До меня ме-е-едленно, но верно - самым эффективным способом, через личный негативный опыт - начинают доходить причины того, почему нач так сильно докапывался до требований и кода новой тестирующей системы. Он докапываться уже более менее перестал, но теперь я чувствую, что я должен занять его место.
Слово Канеру:
Используй подразумеваемые, скрытые спецификации точно так же как явные.
Не все ссылки, содержащие важную информацию для ваших тестов, могут быть явно представлены вам:
- Явная спецификация является полезным источником информации о требованиях, авторитет которого признан клиентами («Да, это спецификация. Это описание продукта»).
- Неявная спецификация является полезным источником информации о требованиях, авторитет которого не признан клиентами («Это не спецификация, но это имеет смысл»).
Авторитет неявной спецификации появляется из убедительности и достоверности содержащихся в ней сведений, а не волей клиентов. В большинстве случаев только часть неявной спецификации относится к продукту. Неявные спецификации могут принимать разные формы:
- Готовые продукты
- Релевантные продукты
- Старые версии продукта
- Дискуссии о продукте в почте
- Комментарии разработчиков
- Журнальные статьи (например обзор старых версий продукта)
- Книги по релевантным предметам (книга по учету может относиться к приложению по учету)
- Руководства по созданию пользовательского интерфейса
- Требования операционных систем
- Ваш личный основанный на фактах опыт
Когда продукт нарушает явные спецификации, вы получаете простую, легкозарепорчиваемую таску: «Продукт нарушает спецификацию, продукт, вероятно, сломан». Когда нарушена неявная спецификация, вам придется потрудиться больше: «В Microsoft Office, F4 забиндена на повторение команды. Если мы не будем делать так же, то мы можем запутать наших пользователей, они используют Office для повседневной работы.» И хотя никто не сказал бы, что MS Office это спецификация для вашего продукта, ваши клиенты могут согласиться, что выравнивание пользовательского интерфейса по нему может улучшить юзабилити продукта. В таком случае Office становится неявной спецификацией вашего продукта.
Некоторые тестировщики задаются вопросом, почему проектировщики не вставят все полезное в явные спецификации и им приходится пользоваться неявными. Ответ простой: хотя это было бы удобно для тестировщиков, это дорого и ненужно. Наши клиенты доверяют нам использование любых ссылок, которые потребуются или будут важными для решения проблем в нашей работе.
PMD помогло выяснить, что система тестирования старого проекта является тонко сбалансированной конструкцией из костылей.
До меня ме-е-едленно, но верно - самым эффективным способом, через личный негативный опыт - начинают доходить причины того, почему нач так сильно докапывался до требований и кода новой тестирующей системы. Он докапываться уже более менее перестал, но теперь я чувствую, что я должен занять его место.
Слово Канеру:
Используй подразумеваемые, скрытые спецификации точно так же как явные.
Не все ссылки, содержащие важную информацию для ваших тестов, могут быть явно представлены вам:
- Явная спецификация является полезным источником информации о требованиях, авторитет которого признан клиентами («Да, это спецификация. Это описание продукта»).
- Неявная спецификация является полезным источником информации о требованиях, авторитет которого не признан клиентами («Это не спецификация, но это имеет смысл»).
Авторитет неявной спецификации появляется из убедительности и достоверности содержащихся в ней сведений, а не волей клиентов. В большинстве случаев только часть неявной спецификации относится к продукту. Неявные спецификации могут принимать разные формы:
- Готовые продукты
- Релевантные продукты
- Старые версии продукта
- Дискуссии о продукте в почте
- Комментарии разработчиков
- Журнальные статьи (например обзор старых версий продукта)
- Книги по релевантным предметам (книга по учету может относиться к приложению по учету)
- Руководства по созданию пользовательского интерфейса
- Требования операционных систем
- Ваш личный основанный на фактах опыт
Когда продукт нарушает явные спецификации, вы получаете простую, легкозарепорчиваемую таску: «Продукт нарушает спецификацию, продукт, вероятно, сломан». Когда нарушена неявная спецификация, вам придется потрудиться больше: «В Microsoft Office, F4 забиндена на повторение команды. Если мы не будем делать так же, то мы можем запутать наших пользователей, они используют Office для повседневной работы.» И хотя никто не сказал бы, что MS Office это спецификация для вашего продукта, ваши клиенты могут согласиться, что выравнивание пользовательского интерфейса по нему может улучшить юзабилити продукта. В таком случае Office становится неявной спецификацией вашего продукта.
Некоторые тестировщики задаются вопросом, почему проектировщики не вставят все полезное в явные спецификации и им приходится пользоваться неявными. Ответ простой: хотя это было бы удобно для тестировщиков, это дорого и ненужно. Наши клиенты доверяют нам использование любых ссылок, которые потребуются или будут важными для решения проблем в нашей работе.
вторник, 11 октября 2011 г.
Для себя
http://download.naumen.ru/upload/SD/2011-08-30_19.31_ST_GTD_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-08-31_19.39_ST_Comm_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-03_14.02_ST_Confr_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-07_22.47_ST_UML_Webinar_part_1.wmv
http://download.naumen.ru/upload/SD/2011-09-08_22.31_ST_UML_Webinar_part_2.wmv
http://download.naumen.ru/upload/SD/2011-09-09_20.04_ST_Scrum_Team_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-13_19.32_ST_IssueTracker_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-14_19.31_ST_Scrum_Requirements1_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-15_19.34_ST_Scrum_Requirements2_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-22_19.32_ST_CSD_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-23_22.30_ST_DMA_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-08-31_19.39_ST_Comm_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-03_14.02_ST_Confr_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-07_22.47_ST_UML_Webinar_part_1.wmv
http://download.naumen.ru/upload/SD/2011-09-08_22.31_ST_UML_Webinar_part_2.wmv
http://download.naumen.ru/upload/SD/2011-09-09_20.04_ST_Scrum_Team_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-13_19.32_ST_IssueTracker_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-14_19.31_ST_Scrum_Requirements1_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-15_19.34_ST_Scrum_Requirements2_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-22_19.32_ST_CSD_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-23_22.30_ST_DMA_Webinar.wmv
понедельник, 10 октября 2011 г.
Воскресный потрындец.
О тестировании.
Вот тут мне сказали:
.. в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
и так может повториться и еще раз, и еще раз..
Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
На что я ответил, не претендуя при этом на какую-то вселенскую истину, а просто рассказывая как есть:
... побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлемые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
Перечитал я свой ответ и мне аж блин самому понравилось.
Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.
Ну, что поделаешь, тогда я расскажу, как это работает у нас. Ну или как мне бы хотелось, чтоб оно работало. Мою версию.
Waterfall нам говорит, что тестирование это этап. До своего этапа тестировщики пишут сценарии и прочие автотесты, а после - пьют горькую и проводят ретроспективы по кабакам. Как то так:
Продвинутый ватерфалл предлагает чуть допилить схему:
Мы реально нормальные и понимаем, что люди эту схему выстрадали, потому и мы ее применяем. То есть имеется тестирование на всех этапах - тестирование требований, юниты, персональный тестер программиста, дейли, предрелиз - все честь по чести. Это в масштабах продукта.
А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:
Это - дано. А потом Реальность донесла свое видение ситуации:
1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(хитрожопые аналитики моментально прочухали, что тут есть люди, которые могут делать их работу), поэтому стало отдельной от полного сопровождения фичи опцией
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки
Теперь умножаем это на количество клиентов и получаем достаточно интересную реальность, в которой вполне жизнеспособен например такой сценарий:
ПМ желает клиенту пару фич и фиксов. И организует заявку, с блоком "задание на тестирование", который ПМ составляет как из кубиков.
Эта фича требует полного сопровождения, от постановки до релиза, двум фиксам хватит ретеста в рамках скрама и дейли автотестов, этот фикс - нужно ручками проверить перед релизом. Полного тестирования релиза не надо, хватит интеграционных.
Заявка - пакет работ - попадает на ответственного тестировщика,
который выбирает незанятый народ(выгрызает время у занятого), узнает ссылки, явки и пароли, просит натравить на стенд боевые скрипты, потом суммирует результаты и высылает инфу ПМу. Который и ведет заявку дальше...
То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.
Ну а равномерность загрузки обеспечивается большим количеством клиентов, ПМов, собственно тестировщиков (9 штук, это целое отделение), а так же здоровым пофигизмом последних.
Пока что мы еще не полностью перешли на принцип TaaS - хотя бы потому, что а) не планировали этого делать б) вообще не знали, что этим занимаемся, просто работали.
Плюсы - удовлетворенность клиентов - ПМов. Они вроде как вовлечены в процесс и сами собирают конструктор тестирования. А значит и претензий меньше.
Еще - постоянная ротация задач и клиентов тестировщика. Возможность поруководить другими, заняться организацией и планированием.
Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.
P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.
P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.
P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятомвоображении отделе. Я развивал мысль о том, как мы идем в сторону Testing as a Service.
Вот тут мне сказали:
.. в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
и так может повториться и еще раз, и еще раз..
Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
На что я ответил, не претендуя при этом на какую-то вселенскую истину, а просто рассказывая как есть:
... побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлемые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
Перечитал я свой ответ и мне аж блин самому понравилось.
Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.
Ну, что поделаешь, тогда я расскажу, как это работает у нас. Ну или как мне бы хотелось, чтоб оно работало. Мою версию.
Waterfall нам говорит, что тестирование это этап. До своего этапа тестировщики пишут сценарии и прочие автотесты, а после - пьют горькую и проводят ретроспективы по кабакам. Как то так:
 |
| Альбом: bug |
Продвинутый ватерфалл предлагает чуть допилить схему:
 |
| Альбом: bug |
Мы реально нормальные и понимаем, что люди эту схему выстрадали, потому и мы ее применяем. То есть имеется тестирование на всех этапах - тестирование требований, юниты, персональный тестер программиста, дейли, предрелиз - все честь по чести. Это в масштабах продукта.
А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:
 |
| Альбом: bug |
Это - дано. А потом Реальность донесла свое видение ситуации:
1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки
Теперь умножаем это на количество клиентов и получаем достаточно интересную реальность, в которой вполне жизнеспособен например такой сценарий:
ПМ желает клиенту пару фич и фиксов. И организует заявку, с блоком "задание на тестирование", который ПМ составляет как из кубиков.
 |
| Альбом: bug |
Эта фича требует полного сопровождения, от постановки до релиза, двум фиксам хватит ретеста в рамках скрама и дейли автотестов, этот фикс - нужно ручками проверить перед релизом. Полного тестирования релиза не надо, хватит интеграционных.
Заявка - пакет работ - попадает на ответственного тестировщика,
 |
| Альбом: bug |
который выбирает незанятый народ(выгрызает время у занятого), узнает ссылки, явки и пароли, просит натравить на стенд боевые скрипты, потом суммирует результаты и высылает инфу ПМу. Который и ведет заявку дальше...
То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.
 |
| Альбом: bug |
Ну а равномерность загрузки обеспечивается большим количеством клиентов, ПМов, собственно тестировщиков (9 штук, это целое отделение), а так же здоровым пофигизмом последних.
Пока что мы еще не полностью перешли на принцип TaaS - хотя бы потому, что а) не планировали этого делать б) вообще не знали, что этим занимаемся, просто работали.
Плюсы - удовлетворенность клиентов - ПМов. Они вроде как вовлечены в процесс и сами собирают конструктор тестирования. А значит и претензий меньше.
Еще - постоянная ротация задач и клиентов тестировщика. Возможность поруководить другими, заняться организацией и планированием.
Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.
P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.
P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.
P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятом
Воскресный потрындец.
Обо всем подряд.
Купил себе кресло. Хотел новое такое:
Но купил не новое такое:
Тоже хорошо, в добавку побывал в гостях у будущей звезды программирования Даши, хех. Там поили чаем, кормили кексом и вид из окна.
Буду больше читать. Ведь теперь у меня есть все, что нужно: кресло, клечатый плед, молескин. Коэльо я отдал маме, но могу закачать в ридер.
Купил себе кресло. Хотел новое такое:
 |
| Альбом: office |
Но купил не новое такое:
 |
| Альбом: office |
Тоже хорошо, в добавку побывал в гостях у будущей звезды программирования Даши, хех. Там поили чаем, кормили кексом и вид из окна.
Буду больше читать. Ведь теперь у меня есть все, что нужно: кресло, клечатый плед, молескин. Коэльо я отдал маме, но могу закачать в ридер.
Подписаться на:
Сообщения (Atom)