Днем услышал фразу, что то типа: "Инициализирует инстанс экземпляра класса объекта". Не дословно, но примерно так. Сперва долго пытался понять смысл фразы. Раз пять переспрашивал: Так все-таки что оно делает-то? Делает-то оно что?
Потом мне, вроде бы, объяснили, чего оно делает. Оставшийся час я выяснял, почему оно ТАК называется. Есть же хорошие простые добрые слова...
Слово Канеру:
Ты не освоишь тестирование пока, ты не изобретешь его.
Не изобретай колеса. Подождите-ка. Разве не изобретение колеса снова и снова чаще всего просходит в истории? Разве это плохо? В конце концов, мы ездим на пневматических шинах, а не на гранитных дисках. Есть тысячи, если не миллионы вариаций на тему колеса. Может быть это урок? Кажется, существует как минимум две причины изобрести что-то снова: адаптировать это к новой ситуации, и изучить как это работает. Мастерство требует и того и другого.
У нас есть коллеги, советующие студентам избегать повторного изобретения тестов или придумывания уже существующих идей по тестированию. Это все равно что наука без экспериментов. Учиться у других – это нормально. Мы считаем, что именно так и важно учиться – если не верите, проверьте название этой книги.
Но если это единственный способ изучения – вы никогда не станете мастером в ремесле тестировщика. Вы будете подмастерьем, не более. Следование инструкциям заведет вас не дальше, чем следование по трассе в направлении Марса. Мы призываем вас изучать тестирование в духе великих механиков и великих программистов: разбирайте все до винтиков, задумывайтесь как они работают, и собирайте обратно подругому. Не ограничивайтесь чужой мудростью, будьте автором своей.
Сначала, ваши тесты, идеи, методы, или документы будут так себе. Это нормально. Просто держите свой мозг включенным, наблюдайте за другими тестировщиками, изучайте, и постоянно оценивайте выхлоп от ваших идей. Если вы хотите преуспеть, практикуйтесь.
Мы годами занимаемся тестированием и мы все еще изобретаем, все еще модифицируем старые идеи. Все коллеги, которых мы уважаем, идут тем же путем.
Показаны сообщения с ярлыком chapter 2. Показать все сообщения
Показаны сообщения с ярлыком chapter 2. Показать все сообщения
среда, 9 ноября 2011 г.
вторник, 8 ноября 2011 г.
Lesson 46
Интересный способ оценки проекта. Один из.
Слово Канеру:
Одним из важных результатов процесса тестирования является хороший, умный тестировщик.
Мы часто слышим аргументы против любых форм тестирования, результаты которых имеют минимальное или не имеют никакого документирования, как будто единственная ценность тестирования состоит в описании тестов. Это игнорирует важный продукт тестирования — собственно тестировщик.
Хорошие тестировщики всегда учатся. С развитием проекта они все глубже понимают продукт и постепенно увеличивают рефлексы и чувствительность к важным частям проекта. Опытный тестировщик, который прошел один или два цикла релиза, способен тестировать с гораздо большей эффективностью — часто без каких-либо инструкций — по сравнению с неопытным, которому нужны письменные инструкции о том, как и что он проверяет в продукте.
Некоторые консультанты и писатели в нашей области кажется верят в то, что неэффективный тестировщик может стать эффективным только путем следования выданным ему инструкциям. По нашему мнению это плохая практика. Она отражает основополагающее заблуждение о тестировании и о людях, которые тестировать умеют.
Когда оцениваете процесс тестирования — смотрите в первую очередь на тестировщиков проекта. Смотрите на то, как они думают и как это влияет на то, что он делают. Только тогда вы сможете оценить работу продукта, который они производят.
Слово Канеру:
Одним из важных результатов процесса тестирования является хороший, умный тестировщик.
Мы часто слышим аргументы против любых форм тестирования, результаты которых имеют минимальное или не имеют никакого документирования, как будто единственная ценность тестирования состоит в описании тестов. Это игнорирует важный продукт тестирования — собственно тестировщик.
Хорошие тестировщики всегда учатся. С развитием проекта они все глубже понимают продукт и постепенно увеличивают рефлексы и чувствительность к важным частям проекта. Опытный тестировщик, который прошел один или два цикла релиза, способен тестировать с гораздо большей эффективностью — часто без каких-либо инструкций — по сравнению с неопытным, которому нужны письменные инструкции о том, как и что он проверяет в продукте.
Некоторые консультанты и писатели в нашей области кажется верят в то, что неэффективный тестировщик может стать эффективным только путем следования выданным ему инструкциям. По нашему мнению это плохая практика. Она отражает основополагающее заблуждение о тестировании и о людях, которые тестировать умеют.
Когда оцениваете процесс тестирования — смотрите в первую очередь на тестировщиков проекта. Смотрите на то, как они думают и как это влияет на то, что он делают. Только тогда вы сможете оценить работу продукта, который они производят.
пятница, 4 ноября 2011 г.
Lesson 45
Слово Канеру:
Если вы создаете процедуры тестирования, опасайтесь «1287.»
Один из нас, Бах, однажды был свидетелем того, как тестировщик писал процедуру тестирования, которая включала в себя строку «Введите 1287 символов в поле». Откуда взялись 1287? Тестировщик объяснил это тем, что по его идее нужно ввести в маленькое поле ввода очень большой набор символов. И, поскольку он слышал, что тестовые процедуры должны быть конкретными, он вернулся и тщательно пересчитал, сколько он ввел символов, их было 1287. И он вставил это в процедуру — и теперь произвольное число закреплено в тесте, как кошка в цементе.
Сверхточность не помогает. Когда вы пишете тест, избегайте любой специфики, которая не релевантна идее тестирования. Включайте любые моменты и тонкости, необходимые для того, чтоб сформулировать и объяснить тест, но позвольте будущему тестировщику поупражняться в творчестве и оценке. Позвольте будущему тестировщику внести изменения, которые сохранят процедуру тестирования свежей и эффективной.
Если вы создаете процедуры тестирования, опасайтесь «1287.»
Один из нас, Бах, однажды был свидетелем того, как тестировщик писал процедуру тестирования, которая включала в себя строку «Введите 1287 символов в поле». Откуда взялись 1287? Тестировщик объяснил это тем, что по его идее нужно ввести в маленькое поле ввода очень большой набор символов. И, поскольку он слышал, что тестовые процедуры должны быть конкретными, он вернулся и тщательно пересчитал, сколько он ввел символов, их было 1287. И он вставил это в процедуру — и теперь произвольное число закреплено в тесте, как кошка в цементе.
Сверхточность не помогает. Когда вы пишете тест, избегайте любой специфики, которая не релевантна идее тестирования. Включайте любые моменты и тонкости, необходимые для того, чтоб сформулировать и объяснить тест, но позвольте будущему тестировщику поупражняться в творчестве и оценке. Позвольте будущему тестировщику внести изменения, которые сохранят процедуру тестирования свежей и эффективной.
четверг, 3 ноября 2011 г.
Lesson 44
Сегодня ничего не понимаю.
Слово Канеру:
Избегай следования процедурам если они не следуют за тобой.
Остерегайся процедур других людей. Они обычно заключаются в сценариях тестирования и процедурах, сформулированных таким образом, что они ничего не говорят о целях, лежащих в основе стратегии тестирования. Это создает большую вероятность того, что ты будешь следовать тестам без полного понимания того, что они делают и на что нужно обращать внимание. Другими словами, вы на самом деле не будете следовать им. В целом, тестовые процедуры плохо описаны и плохо спроектированы так как несколько хороших тестировщиков попытались запрограммировать людей как компьютеры. Если вы хотите следовать процедурам тестирования, то предпочитайте те, что вы спроектировали сами, те что вам принадлежат или те, которые вы тщательно изучили.
Для достижения наилучших результатов вы должны контролировать ваше тестирование, а не вашу документацию. Заставьте ее следовать за вами.
Если вы убеждены, что процедуры тестирования хорошая вещь, по крайней мере изучите, как они работают. Посмотри Things that Make Us Smart: Defending Human Attributes in the Age of the Machine (Norman 1993) и The Social Life of Information (Brown and Duguid 2000).
 |
| Альбом: randompics4lj |
Слово Канеру:
Избегай следования процедурам если они не следуют за тобой.
Остерегайся процедур других людей. Они обычно заключаются в сценариях тестирования и процедурах, сформулированных таким образом, что они ничего не говорят о целях, лежащих в основе стратегии тестирования. Это создает большую вероятность того, что ты будешь следовать тестам без полного понимания того, что они делают и на что нужно обращать внимание. Другими словами, вы на самом деле не будете следовать им. В целом, тестовые процедуры плохо описаны и плохо спроектированы так как несколько хороших тестировщиков попытались запрограммировать людей как компьютеры. Если вы хотите следовать процедурам тестирования, то предпочитайте те, что вы спроектировали сами, те что вам принадлежат или те, которые вы тщательно изучили.
Для достижения наилучших результатов вы должны контролировать ваше тестирование, а не вашу документацию. Заставьте ее следовать за вами.
Если вы убеждены, что процедуры тестирования хорошая вещь, по крайней мере изучите, как они работают. Посмотри Things that Make Us Smart: Defending Human Attributes in the Age of the Machine (Norman 1993) и The Social Life of Information (Brown and Duguid 2000).
среда, 2 ноября 2011 г.
Lesson 43
Примерно с 2.9 релиза selenium начал нормально отрабатывать MoveTargetOutOfBoundsException — это когда нельзя пецкнуть элемент, находящийся вне рабочей области браузера. Cегодня обновил pom.xml и на тебе: наш «боевой фазер» находит четверть сотни такой хрени — и это на чистой базе.
Стоит похвалить и ручных тестировщиков — они об этом уже знали и повесили тикет в виде темно-розового сердечка(светло розовые сердечки менее приоритетны).
Ну а я что? Я прям обрадовался и решил, что мое существование в проекте становится близким к смыслу.
Сказал мол — даешь новые типы тестов в массы. Даешь автоматические тесты на права как в фейсбуке. А мне, как водится, тут же объяснили, что все это уже продумано без меня, запланировано до нас и вообще вчера обсуждалось с Наташей Р..
Велосипед изобрели до меня. Это печально.
Слово Канеру:
Свежий взгляд найдет багу.
Понять смысл чего-либо это сложный интеллектуальный процесс преобразования новой информации в то, что вы уже знаете, изменяя при этом то, что вы уже знаете, для размещения новой информации. После того, как вы поняли смысл продукта или фичи вы имеете их ментальную карту и вашему мозгу становится легче с этим работать. Это может быть проблемой для тестировщиков. Если вы хорошо знаете продукт, то вы делаете много допущений о нем и вы не так часто проверяете эти допущения.
Эта ситуация имеет по крайней мере три последствия для тестирования:
- Когда вы получаете продукт или фичу, уделите особое внимание тому, что смущает или раздражает вас. Это может говорить о том, какой окажется реакция пользователей на продукт.
- Если у вас в команде новички — работайте вместе с ними. Наблюдайте за их реакцией на продукт и на то, как они изучают его.
- Остерегайтесь попадания тестирования в колею. Даже если вы не следуете жестким сценариям тестирования, вы можете быть так хорошо знакомы с особенностями продукта, что вы будете тестировать все более сужающиеся части продукта. Внесите изменения там где вы можете или обменяйтесь обязанностями с другим тестировщиком.
Стоит похвалить и ручных тестировщиков — они об этом уже знали и повесили тикет в виде темно-розового сердечка(светло розовые сердечки менее приоритетны).
Ну а я что? Я прям обрадовался и решил, что мое существование в проекте становится близким к смыслу.
Сказал мол — даешь новые типы тестов в массы. Даешь автоматические тесты на права как в фейсбуке. А мне, как водится, тут же объяснили, что все это уже продумано без меня, запланировано до нас и вообще вчера обсуждалось с Наташей Р..
Велосипед изобрели до меня. Это печально.
 |
| Альбом: randompics4lj |
Слово Канеру:
Свежий взгляд найдет багу.
Понять смысл чего-либо это сложный интеллектуальный процесс преобразования новой информации в то, что вы уже знаете, изменяя при этом то, что вы уже знаете, для размещения новой информации. После того, как вы поняли смысл продукта или фичи вы имеете их ментальную карту и вашему мозгу становится легче с этим работать. Это может быть проблемой для тестировщиков. Если вы хорошо знаете продукт, то вы делаете много допущений о нем и вы не так часто проверяете эти допущения.
Эта ситуация имеет по крайней мере три последствия для тестирования:
- Когда вы получаете продукт или фичу, уделите особое внимание тому, что смущает или раздражает вас. Это может говорить о том, какой окажется реакция пользователей на продукт.
- Если у вас в команде новички — работайте вместе с ними. Наблюдайте за их реакцией на продукт и на то, как они изучают его.
- Остерегайтесь попадания тестирования в колею. Даже если вы не следуете жестким сценариям тестирования, вы можете быть так хорошо знакомы с особенностями продукта, что вы будете тестировать все более сужающиеся части продукта. Внесите изменения там где вы можете или обменяйтесь обязанностями с другим тестировщиком.
суббота, 29 октября 2011 г.
Lesson 42
Рисовали мы тут диаграммы - кто как работает, что на входе, какой продукт на выходе и так далее. Для всех. Чтоб выяснить, на каких печеньках сэкономить и вообще понять, что происходит.
Примерно так выглядит небольшая часть диаграммы работ у программистов:
Оно же ИРЛ:
А вот так - у автотестеров:
Оно же ИРЛ:
Как то так.
Слово Канеру:
Путаница это инструмент тестировщика.
Если вы чувствуете, что запутались, знайте, это может говорить вам о чем-то важном.
Это путаница в спецификациях? Неясности в спецификациях часто появляются чтоб скрыть важные разногласия среди влиятельных заинтересованных сторон.
Это путаница в продукте? Он может быть сломан.
Это путаница в пользовательской документации?Эта часть продукта может быть очень сложной. Слишком много разных сценариев использования и несоответствий между ними, чтоб описать их.
Лежащая в основе проблема трудна для понимания? Некоторые системы, которые мы пытаемся автоматизировать, по своей сути сложны или включают в себя различные технические вопросы. Программисты тоже находят их сложными и это приводит к ошибкам, упущениям, непониманию, переупрощению.
Чем больше ты знаешь о продукте, технологиях и тестировании вообще, тем лучший компас у тебя появится, который покажет тебе, где лежат важные проблемы.
В тестировании, если ты ничего не знаешь о продукте, то ты хотя бы понимаешь, что запутался. В этой ситуации путаница, в форме вопросов о проблеме, которые никто не имел смелости поднять, может быть лучшим результатом
Примерно так выглядит небольшая часть диаграммы работ у программистов:
 |
| Альбом: office |
Оно же ИРЛ:
 |
| Альбом: office |
А вот так - у автотестеров:
 |
| Альбом: office |
Оно же ИРЛ:
 |
| Альбом: office |
Как то так.
Слово Канеру:
Путаница это инструмент тестировщика.
Если вы чувствуете, что запутались, знайте, это может говорить вам о чем-то важном.
Это путаница в спецификациях? Неясности в спецификациях часто появляются чтоб скрыть важные разногласия среди влиятельных заинтересованных сторон.
Это путаница в продукте? Он может быть сломан.
Это путаница в пользовательской документации?Эта часть продукта может быть очень сложной. Слишком много разных сценариев использования и несоответствий между ними, чтоб описать их.
Лежащая в основе проблема трудна для понимания? Некоторые системы, которые мы пытаемся автоматизировать, по своей сути сложны или включают в себя различные технические вопросы. Программисты тоже находят их сложными и это приводит к ошибкам, упущениям, непониманию, переупрощению.
Чем больше ты знаешь о продукте, технологиях и тестировании вообще, тем лучший компас у тебя появится, который покажет тебе, где лежат важные проблемы.
В тестировании, если ты ничего не знаешь о продукте, то ты хотя бы понимаешь, что запутался. В этой ситуации путаница, в форме вопросов о проблеме, которые никто не имел смелости поднять, может быть лучшим результатом
среда, 26 октября 2011 г.
Lesson 41
Слово Канеру:
Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.
Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.
Этот же вопрос стоит задать, когда вы не находите баги в процессе тестирования и это создает проблемы вашим клиентам. Не бейте себя по голове, пока не проверите, что случилось со стратегией тестирования. Случилось бы это, если бы вы следовали верной стратегии тестирования? Если это случайность — следуйте прежним курсом. Но, если вы пропустили баг из-за того, что ваша стратегия тестирования сфокусирована на других типах проблем, используйте эту возможность, чтоб изменить ее.
Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.
Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.
Этот же вопрос стоит задать, когда вы не находите баги в процессе тестирования и это создает проблемы вашим клиентам. Не бейте себя по голове, пока не проверите, что случилось со стратегией тестирования. Случилось бы это, если бы вы следовали верной стратегии тестирования? Если это случайность — следуйте прежним курсом. Но, если вы пропустили баг из-за того, что ваша стратегия тестирования сфокусирована на других типах проблем, используйте эту возможность, чтоб изменить ее.
вторник, 25 октября 2011 г.
Lesson 40
Слово Канеру:
Вас труднее обмануть, если вы знаете, что вы дурак.
Мошенники говорят, что легче всего обмануть тех, кто убежден, что его невозможно обмануть. Вы можете применить этот принцип в своей работе тестировщика. Убедите себя в том, что вы дурак. Это несложно, просто осторожно наблюдайте за своими ошибками во время тестирования. Записывайте каждый раз, когда другой тестировщик обнаружил проблему там, где вы могли бы ее обнаружить, но не сделали этого.
Если вы знаете, что вас легко обмануть, то вы становитесь немного более внимательным. Вы и ваш ум сильнее и подробнее работают с деталями стратегии тестирования. Это один из самых быстрых путей совершенствования начинающего тестировщика, так как сознание того, что вы дурак — это отношение, а не навык или знание. Проблема начинающих тестировщиков в том, что для них этот принцип — просто вера («Мне сказали, что я должен думать, что меня можно обмануть...»); в то время как чувства и рефлексы опытных тестировщиков были разбужены и обострены болью от постоянного накручивания («Я помню большой возврат 94-го. Мы не могли представить себе, что вирус может заразить наш золотой мастер-диск. Я потерял свою невинность в тот день.»)
Вас труднее обмануть, если вы знаете, что вы дурак.
Мошенники говорят, что легче всего обмануть тех, кто убежден, что его невозможно обмануть. Вы можете применить этот принцип в своей работе тестировщика. Убедите себя в том, что вы дурак. Это несложно, просто осторожно наблюдайте за своими ошибками во время тестирования. Записывайте каждый раз, когда другой тестировщик обнаружил проблему там, где вы могли бы ее обнаружить, но не сделали этого.
Если вы знаете, что вас легко обмануть, то вы становитесь немного более внимательным. Вы и ваш ум сильнее и подробнее работают с деталями стратегии тестирования. Это один из самых быстрых путей совершенствования начинающего тестировщика, так как сознание того, что вы дурак — это отношение, а не навык или знание. Проблема начинающих тестировщиков в том, что для них этот принцип — просто вера («Мне сказали, что я должен думать, что меня можно обмануть...»); в то время как чувства и рефлексы опытных тестировщиков были разбужены и обострены болью от постоянного накручивания («Я помню большой возврат 94-го. Мы не могли представить себе, что вирус может заразить наш золотой мастер-диск. Я потерял свою невинность в тот день.»)
пятница, 21 октября 2011 г.
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
Переехали в комнату с большими окнами и впятеро меньшим количеством народу.
Тут тихо и работоспособно.
Слово Канеру:
Не путайте тесты и тестирование
Что значит создать тест? Это может означать, что тестировщик провел сессию исследовательского тестирования с результатом в виде эфемерных тестов без какой либо документации. Это может означать, что тестировщик создал набор исполняемых программ или набор подробных процедур испытаний. Это может быть ссылка на высокоуровневую матрицу тестирования, тест-план или набор тестовых данных.
Концепция, по которой тест становится самодостаточным, осязаемым, и независимым от других тестов удобна (мы будем ее придерживаться при написании этой книги), но очень ограничена. Это то, что важно в тестировании, а не то, как вы делите тесты на пакеты или как называете тесты.
Тестирование это то, что связано со следующими четырьмя активностями:
- Конфигурирование. Подготовьте продукт к тестам. Создайте начальное состояние. В противном случае результаты тестов могут быть испорчены меняющимися параметрами.
- Оперирование. Поток данных о продукте. Подавайте команды. Взаимодействуйте с ним. В противном случае, вы просто сидите и наблюдаете, а не тестируете.
- Наблюдение. Собирайте информацию о том, как продукт ведет себя, о выходной информации, о состоянии системы в целом, о взаимодействии с другими продуктами и так далее. Вы не можете наблюдать за всем, но все, за чем вы не наблюдаете, может привести к ошибке.
- Оценка. Применяйте правила, выводы, механизмы которые обнаружат баги в том, что вы наблюдаете. В противном случае в вашем докладе не будет проблем, или вы будете просто передавать данные клиентам, которые должны будут выполнить оценку самостоятельно.
Созидание имеет много форм. Не стоит зацикливаться на форме, просто убедитесь, что эти четыре активности присутствуют. Сосредоточитесь на том, кто их выполняет и на том, насколько хорошо тесты соответствуют миссии и цели тестирования.
Тут тихо и работоспособно.
Слово Канеру:
Не путайте тесты и тестирование
Что значит создать тест? Это может означать, что тестировщик провел сессию исследовательского тестирования с результатом в виде эфемерных тестов без какой либо документации. Это может означать, что тестировщик создал набор исполняемых программ или набор подробных процедур испытаний. Это может быть ссылка на высокоуровневую матрицу тестирования, тест-план или набор тестовых данных.
Концепция, по которой тест становится самодостаточным, осязаемым, и независимым от других тестов удобна (мы будем ее придерживаться при написании этой книги), но очень ограничена. Это то, что важно в тестировании, а не то, как вы делите тесты на пакеты или как называете тесты.
Тестирование это то, что связано со следующими четырьмя активностями:
- Конфигурирование. Подготовьте продукт к тестам. Создайте начальное состояние. В противном случае результаты тестов могут быть испорчены меняющимися параметрами.
- Оперирование. Поток данных о продукте. Подавайте команды. Взаимодействуйте с ним. В противном случае, вы просто сидите и наблюдаете, а не тестируете.
- Наблюдение. Собирайте информацию о том, как продукт ведет себя, о выходной информации, о состоянии системы в целом, о взаимодействии с другими продуктами и так далее. Вы не можете наблюдать за всем, но все, за чем вы не наблюдаете, может привести к ошибке.
- Оценка. Применяйте правила, выводы, механизмы которые обнаружат баги в том, что вы наблюдаете. В противном случае в вашем докладе не будет проблем, или вы будете просто передавать данные клиентам, которые должны будут выполнить оценку самостоятельно.
Созидание имеет много форм. Не стоит зацикливаться на форме, просто убедитесь, что эти четыре активности присутствуют. Сосредоточитесь на том, кто их выполняет и на том, насколько хорошо тесты соответствуют миссии и цели тестирования.
пятница, 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 становится неявной спецификацией вашего продукта.
Некоторые тестировщики задаются вопросом, почему проектировщики не вставят все полезное в явные спецификации и им приходится пользоваться неявными. Ответ простой: хотя это было бы удобно для тестировщиков, это дорого и ненужно. Наши клиенты доверяют нам использование любых ссылок, которые потребуются или будут важными для решения проблем в нашей работе.
четверг, 6 октября 2011 г.
Lesson 32
Дорогое мироздание. Сегодня весь день я вручаю разным людям ништяки.
Я вручил кота.
Я вручил кружку.
Я вручу колонки.
Дорогое мироздание. Я хочу пива. Гиннес, желательно.
Примерно так:
Ну или так:
Ну хотя бы так:
Слово Канеру:
Вы получите требования совещаясь, делая выводы и проверяя ссылки.
Если вы ожидаете получить требования на пучке пергамента, проштампованном печатью вселенской правды, найдите другую работу. В лучшем случае, который с нами происходил, требования (которые включали все возможные виды спецификаций, вариантов использования, видений документов и так далее) были неполными и противоречивыми, хотя и были полезными и информативными. В худшем случае, который мы наблюдали, документация была неполной, двусмысленной, неинформативной и бесполезной.
Тестировщик, который использует проектную документацию (спецификации продукта) в качестве единственного источника требований калечит весь процесс тестирования. В любой команде тестирования, которой мы управляли, подобное поведение было бы преступлением.
Информация о требованиях поступает по трем основным путям:
Совещания. Общение с кем-любо, чье мнение о качестве продукта является решающим и изучение того, что является важным для него.
Выводы. Определите важные требования путем экстрапроляции от других вещей, которые вы знаете о проекте или продукте.
Ссылки. Откройте для себя явные и неявные спецификации и основывайтесь на них.
Во многих проектах большинство требований, которые использовали хорошие тестировщики были получены из совещаний, выводов и неявных спецификаций. Это твоя работа — выискивать информацию, необходимую для тестирования.
Отличная книга об этом: Exploring Requirements: Quality Before Design (Gause and Weinberg 1989).
Я вручил кота.
Я вручил кружку.
Я вручу колонки.
Дорогое мироздание. Я хочу пива. Гиннес, желательно.
Примерно так:
 |
| Альбом: home |
Ну или так:
 |
| Альбом: home |
Ну хотя бы так:
 |
| Альбом: home |
Слово Канеру:
Вы получите требования совещаясь, делая выводы и проверяя ссылки.
Если вы ожидаете получить требования на пучке пергамента, проштампованном печатью вселенской правды, найдите другую работу. В лучшем случае, который с нами происходил, требования (которые включали все возможные виды спецификаций, вариантов использования, видений документов и так далее) были неполными и противоречивыми, хотя и были полезными и информативными. В худшем случае, который мы наблюдали, документация была неполной, двусмысленной, неинформативной и бесполезной.
Тестировщик, который использует проектную документацию (спецификации продукта) в качестве единственного источника требований калечит весь процесс тестирования. В любой команде тестирования, которой мы управляли, подобное поведение было бы преступлением.
Информация о требованиях поступает по трем основным путям:
Совещания. Общение с кем-любо, чье мнение о качестве продукта является решающим и изучение того, что является важным для него.
Выводы. Определите важные требования путем экстрапроляции от других вещей, которые вы знаете о проекте или продукте.
Ссылки. Откройте для себя явные и неявные спецификации и основывайтесь на них.
Во многих проектах большинство требований, которые использовали хорошие тестировщики были получены из совещаний, выводов и неявных спецификаций. Это твоя работа — выискивать информацию, необходимую для тестирования.
Отличная книга об этом: Exploring Requirements: Quality Before Design (Gause and Weinberg 1989).
среда, 5 октября 2011 г.
Lesson 31
Френды планируют очередную социопати с песнями под гитару. Вот бы хоть одним глазком на такое посмотреть.
Добрые врачи вкололи грипп в руку и только потом сказали, что алкоголь нельзя.
Кстати, у Канера всего 293 урока. Я перевел 31. Как вы думаете, на сколько меня хватит?
Слово Канеру:
Требование качества или некоего условия имеет значение для тех, кто принимает решение.
Ты можешь выбирать из многих условий или требований. Это определение хорошо работает для тестировщиков. Как тестировщик ты должен знать, чье мнение о качестве является определяющим. Узнайте, чего они хотят и чего не хотят. Этот взгляд на требования уберет различия между разработкой ПО «по требованиям»(набор положений, определенный в списке требований и утвержденный людьми, имеющими на это право) и по другим видам спецификаций. Для целей тестирования в требовании должны быть описаны все состояния или качества, которыми должен обладать продукт.
Разные клиенты хотят разных вещей от продукта, они даже не обязательно знают, чего они хотят, и чего будут хотеть через некоторое время. Это делает нашу работу более интересной. Добро пожаловать в тестирование.
Добрые врачи вкололи грипп в руку и только потом сказали, что алкоголь нельзя.
Кстати, у Канера всего 293 урока. Я перевел 31. Как вы думаете, на сколько меня хватит?
Слово Канеру:
Требование качества или некоего условия имеет значение для тех, кто принимает решение.
Ты можешь выбирать из многих условий или требований. Это определение хорошо работает для тестировщиков. Как тестировщик ты должен знать, чье мнение о качестве является определяющим. Узнайте, чего они хотят и чего не хотят. Этот взгляд на требования уберет различия между разработкой ПО «по требованиям»(набор положений, определенный в списке требований и утвержденный людьми, имеющими на это право) и по другим видам спецификаций. Для целей тестирования в требовании должны быть описаны все состояния или качества, которыми должен обладать продукт.
Разные клиенты хотят разных вещей от продукта, они даже не обязательно знают, чего они хотят, и чего будут хотеть через некоторое время. Это делает нашу работу более интересной. Добро пожаловать в тестирование.
вторник, 4 октября 2011 г.
Lesson 30
Мне протянули интернеты.
Посылаю лучи ненависти техподдержке провайдера Кабинет. Мало того, что у них на сайте не указана почта - телефон они тоже игнорируют.
Обратно же, посылаю лучи благодарности монтажникам Кабинета, которые пришли в оговоренное время и решили вопрос в кратчайшие сроки, при этом не спросив попользоваться туалетом (привет, конвексы и голдам, хех).
Слово Канеру:
Используй логику гипотезы и опровержения для оценки продукта
Философ Карл Поппер ввел метод гипотезы и опровержения в начале XX века, когда работал над проблемой различий религии и науки. Метод основан на предположении, что ученый не может быть абсолютно уверен относительно какого-либо факта или теории о природе. Все существующее — гипотезы. Некоторые гипотезы, такие как существование гравитации, очень сильны. Гипотезой, а не фактом их делает то, что можно представить себе новую информацию. Которая, если бы она существовала, заставила бы нас отказаться от гипотезы. Поппер заметил, что хотя мы и не можем доказать, что гипотеза верна, но мы можем доказать, что она ложна. Поэтому он предложил, что уверенность в данной гипотезе будет следовать из постоянных безуспешных попыток опровергнуть ее.
Этот метод создания гипотез и попыток опровергнуть их применим в тестировании по трем важным направлениям:
- Это более мощный способ показать, что продукт сломан, нежели, для того, чтоб показать, что продукт работает. Когда ты хочешь показать, что продукт работает — ищи способы опровергнуть предположение, что продукт работает, и, возможно, ты будешь тестировать лучше.
- Хорошо сформированные представления о ПО (как он себя ведет, насколько хорош, и так далее) должны быть сфальсифицированы. Это значит, что мы должны быть готовы представить новую информацию о продукте, которая бы противоречила нашим представлениям о нем. В противном случае наше представление не больше чем вера. Вера хороша в частной жизни, но она яд для тестирования.
Кстати, френды, помогите перевести последние два предложения. Что-то я не могу уловить суть.
- Beware of tests that purport to validate or certify a product in a way that goes beyond the specific tests you ran. No amount of testing provides certainty about the quality of the product.
Заранее спасибо.
лекции, bret pettichord, lessons learned in software testing, james bach, chapter 2, cem kaner, жизнь
Посылаю лучи ненависти техподдержке провайдера Кабинет. Мало того, что у них на сайте не указана почта - телефон они тоже игнорируют.
Обратно же, посылаю лучи благодарности монтажникам Кабинета, которые пришли в оговоренное время и решили вопрос в кратчайшие сроки, при этом не спросив попользоваться туалетом (привет, конвексы и голдам, хех).
Слово Канеру:
Используй логику гипотезы и опровержения для оценки продукта
Философ Карл Поппер ввел метод гипотезы и опровержения в начале XX века, когда работал над проблемой различий религии и науки. Метод основан на предположении, что ученый не может быть абсолютно уверен относительно какого-либо факта или теории о природе. Все существующее — гипотезы. Некоторые гипотезы, такие как существование гравитации, очень сильны. Гипотезой, а не фактом их делает то, что можно представить себе новую информацию. Которая, если бы она существовала, заставила бы нас отказаться от гипотезы. Поппер заметил, что хотя мы и не можем доказать, что гипотеза верна, но мы можем доказать, что она ложна. Поэтому он предложил, что уверенность в данной гипотезе будет следовать из постоянных безуспешных попыток опровергнуть ее.
Этот метод создания гипотез и попыток опровергнуть их применим в тестировании по трем важным направлениям:
- Это более мощный способ показать, что продукт сломан, нежели, для того, чтоб показать, что продукт работает. Когда ты хочешь показать, что продукт работает — ищи способы опровергнуть предположение, что продукт работает, и, возможно, ты будешь тестировать лучше.
- Хорошо сформированные представления о ПО (как он себя ведет, насколько хорош, и так далее) должны быть сфальсифицированы. Это значит, что мы должны быть готовы представить новую информацию о продукте, которая бы противоречила нашим представлениям о нем. В противном случае наше представление не больше чем вера. Вера хороша в частной жизни, но она яд для тестирования.
Кстати, френды, помогите перевести последние два предложения. Что-то я не могу уловить суть.
- Beware of tests that purport to validate or certify a product in a way that goes beyond the specific tests you ran. No amount of testing provides certainty about the quality of the product.
Заранее спасибо.
лекции, bret pettichord, lessons learned in software testing, james bach, chapter 2, cem kaner, жизнь
среда, 28 сентября 2011 г.
Lesson 29
А у нас в офис привезли тестовые амазонкиндлы.
Я уже себе хочу такой, он замечательный. Только я пока не понимаю, зачем он мне нужен, у меня есть с чего читать.
К сегодняшнему переводу — слово «абдукция» - реально существует.
Слово Канеру:
Используй абдуктивное мышление, чтоб найти гипотезы.
Абдуктивное мышление, также известное как гипотетическая индукция, это причудливое название для важных форм размышлений, которые тестировщики используют каждый день: рассужlения для поиска лучшего объяснения. Оно звучит как:
1. Ты собрал некую информацию и хочешь найти ее смысл.
2. Ты строишь различные предположения, которые могут объяснить эту информацию.
3. Ты нашел больше информации, которая поможет тебе подтвердить или опровергнуть некоторые предположения.
4. Ты выбрал из всех вариантов самое понятное предположение, которое объясняет всю важную информацию, или, если всего этого не хватает, чтоб подтвердить выводы, продолжаешь поиск.
Абдуктивное мышление это базовый метод для науки тестирования. Доктора используют его, чтоб диагностировать болезни. Тестировщики используют его, когда делают предположения о том, чем является продукт и о том, как он должен и не должен работать. Если ты хочешь лучше мыслить абдуктивно:
- Собери больше информации
- Собери больше важной информации
- Собери больше достоверной информации
- Пойми причины и следствия, применимые к этой информации
- Идентифицируй больше хороших гипотез, которые объяснят информацию
- Собери больше информации которая сможет опровергнуть каждое предположение
- Собери больше информации, которая сможет разграничить гипотезы
- Не останавливайся на гипотезе пока она не будет объяснять всю важную информацию и не будет подтверждена информацией, собранной позднее.
Абдукция это системный метод для поиска хороших гипотез. Хотя абдуктивное мышление не предоставляет полную определенность, это лучшая техника, которую мы можем себе позволить в данной ситуации.
 |
| Альбом: office |
Я уже себе хочу такой, он замечательный. Только я пока не понимаю, зачем он мне нужен, у меня есть с чего читать.
К сегодняшнему переводу — слово «абдукция» - реально существует.
Слово Канеру:
Используй абдуктивное мышление, чтоб найти гипотезы.
Абдуктивное мышление, также известное как гипотетическая индукция, это причудливое название для важных форм размышлений, которые тестировщики используют каждый день: рассужlения для поиска лучшего объяснения. Оно звучит как:
1. Ты собрал некую информацию и хочешь найти ее смысл.
2. Ты строишь различные предположения, которые могут объяснить эту информацию.
3. Ты нашел больше информации, которая поможет тебе подтвердить или опровергнуть некоторые предположения.
4. Ты выбрал из всех вариантов самое понятное предположение, которое объясняет всю важную информацию, или, если всего этого не хватает, чтоб подтвердить выводы, продолжаешь поиск.
Абдуктивное мышление это базовый метод для науки тестирования. Доктора используют его, чтоб диагностировать болезни. Тестировщики используют его, когда делают предположения о том, чем является продукт и о том, как он должен и не должен работать. Если ты хочешь лучше мыслить абдуктивно:
- Собери больше информации
- Собери больше важной информации
- Собери больше достоверной информации
- Пойми причины и следствия, применимые к этой информации
- Идентифицируй больше хороших гипотез, которые объяснят информацию
- Собери больше информации которая сможет опровергнуть каждое предположение
- Собери больше информации, которая сможет разграничить гипотезы
- Не останавливайся на гипотезе пока она не будет объяснять всю важную информацию и не будет подтверждена информацией, собранной позднее.
Абдукция это системный метод для поиска хороших гипотез. Хотя абдуктивное мышление не предоставляет полную определенность, это лучшая техника, которую мы можем себе позволить в данной ситуации.
Lesson 28
Ну и я не пройду мимо тренда блогосферы.
Путин, Медведев, Кудрин, ужас пыщ, пыщ!
О интересном. Недавно купленый asus tf101 я последний раз полностью зарядил в субботу, в 15:30. По вечерам на нем пару часов смотрю фильмы, читаю книжки. Сегодня вечер вторника, осталось примерно четверть заряда. Убермашина!
Ну да, еще скоро допишу хороший годный тест. Кстати, нас - автоматических тестировщиков - хотят отселить в кабинет с большим окном.
В целом ОК.
Слово Канеру:
Исследование включает в себя много способов мышления.
Исследование — детективная работа. Это бесконечный поиск. Думайте исследовании как о движении в космосе. Оно включает в себя прямое, обратное и нестандартное мышление.
Прямое мышление. Работайте от того, что вы знаете к тому, что вы не знаете. Двигайтесь от того, что вы видели к тому, что вы еще не видели. Ищите последствия и побочные эффекты. Пример: Я вижу пункт меню «Печать». Я кликаю по нему, чтоб узнать, что случится.
Обратное мышление. Двигайтесь от того, что вы ожидаете или представляете к тому, что что вы знаете, пытаясь подтвердить или опровергнуть ваши гипотезы. Пример: Интересно, есть ли возможность напечатать этот документ? Я посмотрю в меню и узнаю, есть ли там пункт печати документа.
Нестандартное мышление: Позвольте себе отвлекаться на идеи, которые приходят в голову. Изучите, как они касаются основного направления движения. Пример: это интересный график. Эй, я напечатаю несколько сложных графиков и посмотрю, что случится.
Процесс исследования работает даже если у вас нет продукта для тестирования. Вы можете исследовать документацию или провести интервью с программистами, используя тот же способ мышления. Вы идете вперед за счет создания более богатых, полных ментальных моделей продукта. Эти модели позволят вам создавать более эффективные тесты.
Путин, Медведев, Кудрин, ужас пыщ, пыщ!
О интересном. Недавно купленый asus tf101 я последний раз полностью зарядил в субботу, в 15:30. По вечерам на нем пару часов смотрю фильмы, читаю книжки. Сегодня вечер вторника, осталось примерно четверть заряда. Убермашина!
Ну да, еще скоро допишу хороший годный тест. Кстати, нас - автоматических тестировщиков - хотят отселить в кабинет с большим окном.
В целом ОК.
Слово Канеру:
Исследование включает в себя много способов мышления.
Исследование — детективная работа. Это бесконечный поиск. Думайте исследовании как о движении в космосе. Оно включает в себя прямое, обратное и нестандартное мышление.
Прямое мышление. Работайте от того, что вы знаете к тому, что вы не знаете. Двигайтесь от того, что вы видели к тому, что вы еще не видели. Ищите последствия и побочные эффекты. Пример: Я вижу пункт меню «Печать». Я кликаю по нему, чтоб узнать, что случится.
Обратное мышление. Двигайтесь от того, что вы ожидаете или представляете к тому, что что вы знаете, пытаясь подтвердить или опровергнуть ваши гипотезы. Пример: Интересно, есть ли возможность напечатать этот документ? Я посмотрю в меню и узнаю, есть ли там пункт печати документа.
Нестандартное мышление: Позвольте себе отвлекаться на идеи, которые приходят в голову. Изучите, как они касаются основного направления движения. Пример: это интересный график. Эй, я напечатаю несколько сложных графиков и посмотрю, что случится.
Процесс исследования работает даже если у вас нет продукта для тестирования. Вы можете исследовать документацию или провести интервью с программистами, используя тот же способ мышления. Вы идете вперед за счет создания более богатых, полных ментальных моделей продукта. Эти модели позволят вам создавать более эффективные тесты.
Подписаться на:
Сообщения (Atom)