Урок 3. Слайд 129

По следам факапов, прекрасное:

Раньше у нас было правило: нельзя выкатываться в пятницу вечером. Теперь у нас новое правило: совсем нельзя.

 Поехали:

Слайд  129
Регрессионное тестирование это повторение. Мы запускали тест на предыдущей версии программы. Теперь мы запускаем его снова. Если программа прошла тест в прошлый раз, мы можем записать выход и сравнить старый с новым. Если в этот раз выход другой, то, возможно, произошла ошибка. Или старые выходные данные устарели.
Регрессионный оракул очень распространен. Некоторые используют его как базу для автоматизации тестирования. Но я продолжаю встречать людей, которые рассказывают мне о своих проектах, в которых 90% несоответствий между текущей и предыдущей версией приложения не являются багами. Некоторые рассказывают о том, что большая часть их времени работы с тестами состоит в том, что они меняют старые тесты в связи с изменениями в программе. Я лично видел подобные ситуации в больших компаниях. Да, выполнение всех этих тестов автоматизировано. Но ручной труд по обновлению всех этих тестов снова и снова огромен, бессмыслен и непродуктивен. Они находят мало багов и дают небольшую уверенность в том, что их нет.

Картинка:

Урок 3. Слайд 128

Вы любите котиков. А котики вас - нет.

Поехали:

Слайд 128
Ограничения тестирования иллюстрируют идею частичного оракула. Очень сложно сказать, является ли ответ правильным или ошибочным, но легко - правдоподобным или невозможным. Если программа говорит нам, что в американском почтовом коде 6 цифр или канадский состоит только из чисел, то неважно, какой ответ верный, так как именно  это информация - ошибочна. Эти типы тестов не подтверждают то, что программа работает. Они делают ошибки очевидными.

Урок 3. Слайд 127

Поехали:

Слайд 127
Я не буду обсуждать все детали этой таблицы в лекции. Их слишком много. Больше о них вы могли бы узнать самостоятельно. Но я дам пару комментариев.
Основная догадка Doug в том, что все оракулы являются эвристиками. Тестирование предоставляет неполные данные, которые пригодны для использования, а не точные и всегда правильные оценки.

Картинка:

Урок 3. Слайд 126

Поехали:

Слайд 126
Список эвристик консистентности Баха и Болтона - одна из структур, которую многие находят полезной. Другая структура, с которой работали более 14 лет, принадлежит Doug Hoffman, который опубликовал идею о том, как сравнивать и оценивать оракулы в виде таблицы.

Картинка:

Урок 3. Слайд 125

А помните, я скидывал истории и шутки планеристов?
Вот и водники подтянулись:
Раз:

Туристы-водники обсуждают:
— По какой реке пойдем?
— Да по Пьяни...
— Это понятно, что по пьяни, а по какой реке-то?
P.S.: Пьяна - pека в Hижегоpодской области.

Два:

 ... влетаем мы с ней в кусты, я ей кричу: "Юбку снимай!" , а она говорит: "Не могу, очко заклинило...

Три:

Зарубился сам - заруби товарища

Четыре:

 Цитата из отчёта: "... стоянка ниже порога сильно осложнена наличием крокодилов..."

Пять:

В альплагере сезон скидок. Скидывается каждый десятый»

 Спасибо Тане за подгон.

Поехали:

Слайд 125
Позвольте мне подвести итог по оракулам консистентности.
Мы исползуем их в трех общих случаях.
Когда мы находим баг, мы пытаемся выяснить. почему мы думаем, что это баг. Если ответ не очевиден, будет удобно спросить: "какой вид несогласованности мы наблюдаем?" А затем мы проводим исследования, чтоб подтвердить или опровергнуть предчувствия.
Когда мы репортим баг, иногда нам нужно объяснить, почему мы считаем, что это баг. Эвристики помогают структурировать наше объяснение: я считаю, что это баг, так как считаю, что люди будут ожидать другого поведения.
И наконец, мы используем эти эвристики как руководство по архитектуре тестов. Когда я знаю. что продукт должен делать, я проектирую тесты так, чтоб они проверяли, делает ли  продукт это.

Машинок пост

Намедни в Екатеринбурге катались красивые машинки.
Я люблю машинки и устремился посмотреть.
Машинки - были, моторы - ревели, зрителей - тьма. все как положено. Вот только из за последнего пункта большая часть зрителей наблюдала машинки примерно так же как я - через узкую щелочку между передними рядами:

Но ревели болиды мощно, все как положено.

Четверостишья пост

По мотивам, опять же, сего творчества, но сам.

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

Вот например:

Мы пишем интернет портал
Выходим на миллиардный рынок
Тестировщик отдыхает
Все и так сломано

Урок 3. Слайды 123-124

Я считаю, это очень правильное и ответственное отношение к детской психике:

Поехали:

Слайд 123
Давайте рассмотрим самый сложный для обсуждения предмет - согласованность с целями. иногда очевидно, что программа предполагает облегчение выполнения определенной задачи. Если это достаточно очевидно, то все, что вам нужно сделать, это сказать: "Я пытался сделать это".
Но в некоторых случаях программисты не понимают целей программ и то, какую пользу она должна приносить заказчикам. Эта проблема особенно часто встречается в компаниях, которые считают, что программисты это просто люди, которые превращают в код то, что написано в спецификациях. Такое отношение можно заметить во многих книгах и им заражены многие компании.
в таких случаях, программисты отвечают: "Но мы сделали все что должны были". Они могут быть правы, но программа будет все еще с ошибкой. Вам нужно спорить не с программистами, а с теми, кто сказал им так делать.

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

• Чего хотят люди достичь, используя эту программу?
• Какова природа задачи?
• Как выполняют ее люди в реальном мире?
• Как люди понимают, что они выполнили такую задачу?

Слайд 124
Чтоб заполучить аргументы, вам понадобится провести собственное исследование. Вам нужно будет найти источники информации, которые подтвердят или опровергнут ваше мнение о том, что именно эта программа создана для того, чтоб делать именно эти задачи более простым способом. Некоторые мои коллеги говорили, что в их компаниях тестировщиков не радует перспектива тратить время на подобную работу. Это так для многих компаний, ведь они платят вам только за 40 часов времени в неделю, а как проводить остальные часы - дело ваше. В серьезной степени, в моем опыте работы в американских и канадских компаниях, люди, работающие над своей карьерой, работали над этим в собственное время.
Другим тестировщикам еще сложнее. В их компаниях менеджмент не привлекает тестировщиков к оценке архитектуры продукта, только к реализации. Это, возможно, верный подход в случае, если вы работаете в независимой тестовой лаборатории и продукт нужно тестировать однократно.
Но я наблюдал подобный подход у многих менеджеров и тестировщиков в компаниях, которые тестировали собственный продукт.
В такой ситуации нужно быть осторожным. Выбирайте свои аргументы.  Вы должны быть уверены в том, что говорите. И вы должны быть уверены, что ваши источники информации достоверны. И если это так, что вы определенно принесете пользу вашей компании и себе.
Чем лучше вы понимаете бизнес цели вашей компании и чем лучше ваш продукт им соответствует, тем больше уважения вы получите и тем быстрее будете двигаться по служебной лестнице.

Неба пост

Анекдоты парапланеристов.

Настоятельно рекомендую к прочтению. Это даже не анекдоты, а истории. Применимые, так скажем. О учениках:

- Учитель, спрашивали у Кокурина, почему у тебя в этом году разбилось четыре ученика?
- Я сам удивлен. 

О безопасности:

Учитель сказал: «Посещение своих поломанных братьев в травматологии, укрепляет добродетель и безопасность полетов. 

О истории:

У Кокурина спросили: «Как Вы относитесь к статьям N о воздушной акробатике?»
- Он загадочно ответил: «История пишется выжившими».

Я вот думаю, что надо и про свою профессию что-нибудь такое найти или сочинить. А про вашу есть?

Урок 3. Слайды 121-122

Меня вообще кто-нибудь читает? Живые люди?
В последнее время мне от политики становится грустно и немного тошнит.
Если тут есть кто живой - накидайте в комментарии блоги живых людей, которые пишут о жизни, о мире вокруг, о деле которому служат. А не делают репосты о новостях политики.

Пожалуйста. Я в ответ в ближайших выпусках тоже забацаю ссылки на настоящих, живых людей.


Поехали:

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

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

Стенограффия

Чуть ли не месяц назад задумал проехаться по всем площадкам Стенограффии.
Вчера - настал день, всего в новости было указано 15 площадок:

Я посетил 11.  Результаты достаточно странные.
Большая часть площадок не порадовала вообще:

Ну совсем:

И даже так:

Да, да, конечно я софткал и Гагарина. Его не сфотографировал ленивый только:

Но нашел и ряд непопсовых мотивов:

Еще:

Дальше:

И так:

А это уже не стенограффия, а оформление магазина Воздух. Стильно сделали ребята:

Итого: поездкой остался доволен, граффити - тоже. Но думал, будет больше.
В следующий раз хочу прокатиться по Ingress подборке граффити, дворовых памятников, да вообще интересных штук. Там их большая база.
Екатеринбург хороший город, тут удивительное за каждым углом.

Урок 3. Слайды 120

Я считаю именно эту мысль очень важной. А этот список - готовый чеклист для защиты багов или поиска неявной спецификации.

Поехали:

Слайд 120
Бах и Болтон подходят к проблеме другим путем. Если программа показывает что-то, что не выглядит правильным, то на чем основывается это чувство? Чем аргументирует тестировщик, говоря, что программа работает некорректно? Они разработали список эвристик консистентности, описывающих ожидания людей.
Например, когда вы сравниваете программу со спецификацией или рекламой или мануалом, вы наблюдаете неконсистентность с тем, что компания заявила о программе. Когда вы сравниваете результаты теста с эталонной программой, вы наблюдаете неконсистентность со сравниваемым продуктом. Но есть ограничения по сравниваемости. Мы знаем, что два продукта можно сравнить в одном направлении - работа с числами и данными, но нельзя в другом - работа  с памятью.

Содержимое слайда:

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

Урок 3. Слайды 118-119

Поехали:

Слайд 118
Работая с паззлами, студенты часто говорят, что они могут решить, корректен ли размер, измеряя его.
Все не так просто. Единица измерения размера символа - точка. В дюйме 72 точки. Но символы, высота которых 10 точек намного короче своих двойников в других шрифтах.
Так что вместо того, чтоб попытаться точно измерить, что может быть очень сложно, мы полагаемся на простую эвристику, которая состоит в сравнении больших символов с меньшими и в сравнении с другой программой, которой мы больше доверяем.

Слайд 119
Вернемся к оригинальной идее о том, что тестирование это сравнение результата теста с ожидаемым.
Тут есть четыре проблемы:
Первая: наши ожидания могут быть ошибочными.Если программа работает не так, как описано в спецификации, то часто это бывает из за того, что ошибка в спецификации или она устарела. Если программа работает не так как эталонная, то может случиться, что в эталонной программе баг.

Вторая: даже если программа и оракул совпали, то тут все равно может быть баг. вспомните программу которая складывает 2 и 3 пять часов. Эталонная программа не даст всех возможных случаев. Нет полных спецификаций. Всегда есть аспект программы - в большинстве случаев достаточно важный - для которых тестировщик не знает, как определить, правильно или нет ведет себя программа.
Третья. У Open Office и WordPad был в сущности один и тот же баг со шрифтами, но я сказал, что это серьезный баг для Open Office и тривиальный для WordPad. Когда Джеймс учит этому, он говорит, что он, вероятно, не репортил бы формально этот баг, а просто рассказал о нем программистам. В моей практике все немного по другому. я хочу чтоб все особенности были записаны, поэтому я репорчу о каждом несоответствии между результатами и ожиданиями. Но если я считаю, что это неважно, то я так и говорю. Я не трачу много времени на это и я не давлю на людей, чтоб они это исправляли. Чтоб определить серьезность бага, мы должны полагаться на человеческие суждения. в этом оракулы редко помогают.
И наконец, есть проблема доверия. Когда вы говорите, что программа работает некорректно, почему вам кто-то должен верить. Может быть, никто не стал бы оспаривать вас, если бы вашим оракулом была спецификация или заслуживающая доверия эталонная программа. Но что, если программа плохо себя ведет способом, который не покрывается оракулом? Игнорировать? Репортить и надеяться, что вам не придется ее защищать? Мы репортим, но мы должны быть уверены, что читатель будет ясно понимать, почему мы считаем, что это проблема.

Урок 3. Слайды 115-117

Научился проезжать 10-20 метров по ровной поверхности не держась руками за руль.
Нужно больше кодов бессмертия, хм.

Поехали:

Слайд 115
Чтоб оценить результат теста, полезным будет думать о рисках или о влиянии.
В случае WordPad'а небольшая ошибка в размере шрифта практически не несет риска. Никто не будет относиться к этой программе как к серьезному текстовому процессору и не будет работать в ней с разметкой текста.

Слайд 116
В отличие от него, для Word'а, профессиональной настольной программы, подобная ошибка будет серьезной проблемой. Эти программы спроектированы так, чтоб поощрять ожидания профессионального отношения к форматированию текста.

Слайд 117
Если вы один из моих студентов, то вы наверняка работали с примерами перед просмотром видео. В примерах спрашивается, корректно ли отображает Open Office шрифты.
Если мы хотим тщательно это протестировать то должны подумать о некоторых вещах, которые стоило проверить:
Мы должны проверить каждый шрифт, так как с некоторыми программа может работать отлично, но сломаться на других. Да, такое случалось. Мы можем винить в этом нестандартные коды для этих шрифтов, но если Word отображает их корректно, а Open Office нет, то это проблема.
Мы должны проверить каждый символ.
И мы должны проверить взаимодействие со всеми переменными, имеющими отношение к шрифтам.

Урок 3. Слайды 112-114

Ничего не происходит.

Поехали:

Слайд 112
Если смотреть более внимательно, то мы заметим, что WordPad и MS Word выглядят полностью аналогично в этом плане.

Слайд 113
Но у нас есть способ легко сделать наш тест более точным. Выделив текст, мы сможем увидеть конкретную ширину и высоту шрифта и визуально сравнить редакторы.
Это одна из важных тактик тест дизайна. Когда результаты требуют человеческой инспекции, найдите способ сделать эту инспекцию более точной, простой и очевидной. Сравнение с эталонной программой - слишком долгий путь.
В данном случае, как и в случае с Open Office, WordPad некорректно обрабатывает разницу в размерах шрифтов, в частности в ширине.

Слайд 114
Мы видим разницу. Word обрабатывает размеры корректно. Open Office и WordPad - нет. Должны ли мы беспокоиться об этой разнице? Нет системы, которая решит это за вас. Здесь необходимо человеческое суждение.

Урок 3. Слайды 110-111

Мда. На Урале лето бывает только за деньги и в другой стране.

Поехали:

Слайд 110
Давайте рассмотрим пример. Это скриншот текстового процессора Open Office.  Open Office - свободное ПО, но при этом прямой конкурент Microsoft Office. Люди используют обе эти программы для самых разных целей. Open Office спроектирован так, чтоб быть полностью совместимым с MS Office, так что людям удобно работать в каждой из программ, нужно лишь сохранить файлы и редактировать их иногда в Open Office иногда в MS Office.
Тест показывает, как Open Office отображает различные размеры шрифтов.
Если вы посмотрите внимательно, вы увидите, что программа отображает одинаково разные размеры шрифтов. Например шрифты 7.5 и 8.5 одного размера.
Люди, используют  Open Office для серьезной работы, включая разметку сложных документов. Если он не может отображать размеры шрифтов корректно, это серьезная проблема.

Слайд 111
Рассмотрим WordPad, который поставляется бесплатно вместе с системой от MS  и люди используют его только для асмых простых правок. На этой картинке нет очевидных проблем.

Урок 3. Слайды 107-109

Поехали:

Слайд 107
Ошибкой будет считать, как это делают многие тестировщики, что эвристики являются правилами, а не руководством.

Содержимое слайда:
Тестирование - об идеях. Эвристики дадут вам идеи.

• Эвристика это не всегда срабатывающая идея или метод, коорый может упростить решение проблемы.
• Эвристика может навредить, если будет использоваться как авторитетное правило.
• Эвристика может дать мудрый совет, но только в контексте. Сама по себе она не мудра.
• Ваше отношение к эвристикам является ключевым моментом их применения.

Слайд 108
Когда мы даем оценку тестам, мы можем сделать два типа ошибок.
Первая - Пропуск. Кажется, что программа прошла тест, хотя на самом деле нет.
Вторая - Ложная тревога. Выглядит так, как будто тест не пройден, хотя на самом деле поведение программы корректно.
Когда мы полагаемся на оракул эвристику мы имеем возможность совершить любую из этих двух ошибок.

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

Прекрасное

Первый и лучший комментарий к статье на хабре
Почему вы до сих пор не используете git-flow?

Потому что моих знаний git хватает, чтобы отлично его использовать и без git-flow.

Урок 3. Слайды 104-106

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

Тайная тропка вокруг садов.

Внезапно появляющийся мост через ЕКАД:

Спуск у Шиловки:

Встреча с полицией, списывают номера рам. На 9 минуте.

Цель визита:

Поехали:

Слайд 104
Таким образом, мы не можем быть уверены, что программа прошла тест.

Содержимое слайда:
Это работает
в действительности означает
какие-то требования в какой то степени выполнены

Слайд 105
Любой инструмент иногда ошибается, но его все еще можно при этом использовать, это эвристика. Все оракулы - эвристика. Они врут, но их можно использовать.

Слайд 106
Доверие к эвристикам - основа инженерии. Billy Koen красноречиво описал этот факт в своем вводном тексте, вместе с основными характеристиками эвристик.
Эвристики могут противоречить друг другу или вести вас к ошибочным выводам. Они врут, но их можно использовать и они позволяют нам решать проблемы, которым нет авторитетного объяснения.

Урок 3. Слайды 102-103

С утра поехал обкатывать новые педали. Судя по страве:
+4% скорости итого
+8% скорости на подъемах

Пока катил обратно по городу, пытался прыгать.
Итог:

Уже заменил на новые, но обидно, всего два дня, и сотни не продержались.

Поехали:

Слайд 102

Допустим, вы решили измерять время ответа для каждого теста. Теперь, если программа складывает 2 и 3 один час - вы опишете это. Но как насчет использования памяти? А диск? А вдруг ваша программа содержит вредоносный код, рассылающий спам, когда вы используете функцию оповещения по почте.
Hoffman пришел к выводу, что у нас нет возможности наблюдать за всеми потенциально опасными аспектами входа и выхода. Все, что мы можем сделать, так это надеяться, что большую часть времени переменные, за которыми мы не наблюдаем, не влияют на то, прошла ли программа тест.

Слайд 103
Другая проблема возникает, когда мы автоматизируем тестирование. Hoffman и я консультировали компанию, которая встроила около 1100 различных проверок в свое ПО. После каждого теста мы запускали все эти проверки. Но каждый раз, когда мы запускали такую проверку, она сама меняла состояние компьютера. Первая проверка говорила нам о состоянии после теста. Вторая проверка рассказывала о состоянии после теста и первой проверки. Чем больше проверок мы запускали, тем больший сайд-эффект накапливался на машине. И он мог влиять на результаты проверок и тестирования.
У нас нет возможности наблюдать все аспекты выходных значений теста.

Урок 3. Слайд 101

Говорят, пословица американская:

If you meet an asshole in the morning, you met an asshole. If you meet assholes all day, you're the asshole.

Так будем же добрее, ага. 

Поехали:

Слайд 101
Hoffman продолжает дискуссию о эталонном оракуле. Допустим у нас есть две программы. Мы подаем один и тот же вход, наблюдаем одинаковый выход, но сравнивать стало только сложнее. Должна ли первая программа использовать  столько же памяти, сколько вторая? Работать так же быстро?
Все что мы могли бы сказать, так это то, что их поведение должно быть похожим настолько точно, насколько мы это описали.

Содержимое слайда:

 

Урок 3. Слайд 100

Намедни сменил педали на контактные. Будет как минимум - весело.
Если кому интересно, то брал самое дефолтное:
Wellgo WPD-801:

и Tempesta Rhyno:

Все вместе 4200 рублей.
По ощущениям от первых полутора часов езды:
- выше скорость - движения и уставания, хех.
- уже падал. И еще буду.
- принудительная правильная постановка ноги на педаль
- распрыжка всем велосипедом, уиии!



Поехали:

Слайд 100
Работа Weyker'а была совершенно проигнорирована академическим сообществом производителей ПО. Потребовалось 18 лет для того, чтоб Doug Hoffman прошел через те же самые проблемы и озвучил их на конференции практиков тестирования ПО. Их челюсти упали, когда они увидели эту диаграмму.
Когда мы проводим тест, мы определяем вход и наблюдаем за выходом. Мы можем определить столько входных данных, сколько хотим, включая конфигурацию системы, точно так же, как и данные, которые мы скармливаем программе.
Но мы всегда оставляем некоторые вещи неопределенными. Когда в последний раз вы описывали в кейсе программы, которые в это время уже есть в памяти компьютера? Или сколько было у компьютера свободной памяти и места на жестком диске? Или в какой час дня или день месяца. Обычно это не имеет значения. Но не всегда. В этом одна из ключевых причин существования сложновоспроизводимых багов. Баг зависит от чего-то, что мы не знали и что мы не меняли.
Вдобавок, мы наблюдаем не за всем выходом. Представьте программу, которая складывает числа 2 и 3. Она возвращает 5, как и должна. Она пройдет тест? Наверное. Но ей требуется 6 часов, чтоб вернуть результат. Это приемлемо? Как часто вы измеряете время, за которое программа возвращает результат? Многие автоматические тесты слепы в этом отношении.

Содержимое слайда:

Урок 3. Слайды 97-99

Две тысячи километров в этом году. Нужно больше.

Поехали:

Слайд 97
Проблема в том, что нет гарантированных механизмов проверки корректности результатов теста. Вместо этого, каждый раз, сравнивая результат теста с ожидаемым поведением, мы выносим приговор. Любой наш приговор подвержен ошибкам. Это наша реальность.

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

Слайд 98
Если вы посмотрите на стандарты проектирования ПО, такие как IEEE 829, вы заметите, что каждый тест кейс должен быть полностью описан. Он должен включать все входные данные, включая ожидаемый результат и тестовое окружение.

Слайд 99
Но как описать ваше тестовое окружение?
Это скриншот моего диспетчера задач. Все эти процессы находятся в памяти. Большинство запускается, когда я включаю компьютер. У меня нет даже идеи о том, какой как узнать версию всех этих программ. программы, запущенные параллельно с тестируемой могут влиять на ее поведение. Они могут конфликтовать за доступ к ресурсам, работать медленней вместе или даже использовать один и тот же участок памяти.
За годы работы я наблюдал достаточно случаев, когда мы трассировали проблему до программ, находящихся в памяти. Очевидно, это может относиться к любому тесту.
Редко можно увидеть тест, который описывает все версии программ, находящихся в памяти. И подобная спецификация будет бессмысленной, так как любая из этих программ может быть обновлена без вашего ведома.

Урок 3. Слайды 94-96

В выходные разблокировал ачивку - проехать сотню километров зараз.
Пруф
Идею поддержали @igorlukanin, @xoposhiy и @sameoldmadness
Открыли отличную тропу до Березовского, с мостом через большую кольцевую. рекомендую.

Примерно к часу были у Сарапулки. Там заканчивались соревнования 5я жажда скорости.
Прокатились вместе с шоссерами. Ачивку "обогнать шоссера на МТБ в его родной стихии" разблокировать не смогли.
Для справки, лучшая средняя скорость  участников - 44км/ч, худшая средняя - 28км/ч
Я ехал 24км/ч, Паша 25 км/ч.

На обратном пути нас тормознула доблестная полиция и списала номера рам с целью поиска угнанных. За что от нас ГиБДД большое спасибо - какая-то работа идет.

В непогоду, само собой, попали, которую и пережидали в каком-то подъезде вблизи шарташа, походу решив, что надо создавать подъездный стартап, раз уж нас тут собралось четверо, причем есть бекенд, фронтенд, тестер и ПМ.

В целом маршрут рекомендую, занятно.

Поехали:

Слайд 94
Вот несколько связанных с оракулами определений, которые будут часто использоваться в лекциях.

Содержимое слайда:
SUT: тестируемое ПО. Аналогично AUT - тестируемое приложение. или PUT - тестируемая программа.
Эталонная программа - если мы сравниваем поведение SUT с поведением другой программы, то вторая будет называться эталонной.
Компаратор: человек или ПО, сравнивающие поведение SUT и оракула.

Слайд 95
Тестирование было бы намного проще, если бы у нас были настоящие оракулы. Но у нас их нет.
Рассмотрим эталонный оракул, для примера. Когда мы сравниваем вычисления в двух таблицах, возможна ситуация, когда в них присутствует одинаковая ошибка. Nancy Levenson's работа с системами связанными с безопасностью показывает, что такое случается чаще, чем вы могли бы думать. Разные реализации могут быть основаны на одном и том же неверном алгоритме или быть связанными с одинаково неправильным пониманием алгоритма. Вдобавок, тестируемая таблица может быть корректной, а ошибка находиться в эталонном ПО.
Иногда баги попадают и в эталонное ПО

Слайд 96
Elayne Wayker опубликовала блестящий документ в 1980 году, демонстрирующий, что в большинстве случаев обычные оракулы не существуют. Она заложила идею того, что мы сейчас называем эвристиками.

Мастерства пост

Агонь.
А как тормозами отрабатывает, а?

Урок 3. Слайды 92-93

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

Для большого круга через Северку:

 

 Давненько там не был, хм.

Поехали:

Слайд 92
Список литературы.
(См. выше, уже переводил)

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

Необходимости тренировок пост

Таблица разрядов для велосипедистов.
По времени:

 

И по скорости:

Специально отдельно не катал, но судя по страве, моя крейсерская по ровному для 10км - 28-32 км/ч.
То есть не тяну даже на первый юношеский.
Я, конечно, в курсе, что эти таблицы для ровных дорог, а не старо московского тракта, и шоссейных велосипедов, а не MTB найнера, но все же...

Но вообще было бы интересно взять у кого-нибудь шоссер и проверить себя.

Прекрасного пост

У Дануты Сандерос невыразимо красивые стихи. Там длинное, но прочтите полностью. Сюда накину цитат.
Раз:

Их тут было полно и встарь,
иначе откуда
это уральское чудо:
светлоглазые девушки
ледяной, неземной красоты?

Два:

Здесь могут стянуть минуту,
две или пять.
Будешь на них опаздывать,
или всех ровно столько ждать.