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

Поехали:

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

Картинка:

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

Поехали:

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

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

Призыва пост

Друзья, коллеги, знакомые и незнакомые мне люди. Предлагаю в эту субботу велопокатушку до Исети или Аяти. Маршрут запощу завтра. Пишите!

 

Разработки пост

Если вы считаете себя аккуратным и организованным человеком с воображением - выполните в своем проекте эту команду: git log | grep fix
Вдумчиво почитайте вывод. Если вы все еще считаете себя аккуратным и организованным  человеком с воображением - прошу результаты в комментарии.

Ну а нам с вами - нормальным людям - можно хвастаться соотношением коммитов с fix к остальным.

Ну и да, из прекрасного, вполне возможно, что мое, вроде бы даже подряд:

fix исправление прохождения теста
fix test
fix исправление прохождения теста (докоммит)

 Чье-то из старого:

fix test
fix compilation error
findbugs fix
fix compilation error

Чувствуется сюжет: 

fix DDLTool
 fix ddl tests

И боль: 

fix 
Merge conflict fix

А это практически workflow разработки: 

some minor bugfixes
 some bugs with logging were fixed
some pull request fixes 
code review fixeslittle review fix

И просто от души: 

some fixes were made
one more juggler fix
some really hot fixes

Урок 3. Слайд 132-133

Ну или как-то так:

Поехали:

Слайд 132
Оракулы могут реализовывать различные модели и проверять, является ли программа согласованной с точкой зрения оракула.
При создании оракула тестировщик может использовать любую полезную информацию.

Содержимое слайда:
Какие аспекты вещей которые мы моделируем могут направлять наш процесс создания модели?
возможности
предпочтения
- компетентный анализ
- записи техподдержки
хронология
последовательности действий
- диаграмма состояний
- диаграмма управления
диаграммы данных
взаимодействия и зависимости
- деревья принятия решений
- диаграмма зависимости данных
таксономия мотивы
- анализ интересов
Слайд 133
Цель моделирования не обязательно состоит в том, чтоб доказать, что ПО работает правильно или нет. Цель часто состоит в том, чтоб выработать лучшее понимание и создать отправные точки для будущих исследований, иногда превращающихся в отчеты об ошибках или в уточнение модели.

Содержимое слайда:
Что делает модель моделью?

• Модель проще объекта за счет скрытия ряда аспектов
• С моделью можно работать делая предсказания и принимая решения на счет оригинала
• С моделью проще работать, чем с оригиналом

Халявы пост

На совещании:
Кодер:
- а как насчет темы сувенирки?
Манагер: 
- у нас даже макетов нет
Прогер:
- футболки, кружки
Тестер: 
- манетки, дисковые тормоза...

Урок 3. Слайд 130-131

Поехали:

Слайд 130
Следующие несколько оракулов основаны на моделях. Модель это упрощенное представление системы, обычно упрощающее понимание процесса.


Слайд 131
Мы можем создавать модели практически для всего. Представьте, что кто-то продает страховые полисы, используя программу для того, чтоб помочь себе лучше понимать нужды клиента и для выставления счетов. Такая программа реализует модель процесса продажи. Программа реализует фичи - те фичи, которые архитектор считал важными. Программа задает те вопросы для получения информации, которые архитектор считал важными и не задает другие, неважные вопросы.
И если ПО помогает продавцу  быстро получить нужную информацию и проводить правильную политику продаж, то модель хорош.
Если продавец работает в обход ПО, или чувствует, что ему задают неправильные вопросы, или в неправильном порядке, или неправильным способом, то модель плоха.

Содержимой слайда:
Несколько оракулов основаны на следующих моделях:

• физического процесса, эмулируемого, анализируемого или контролируемого ПО
• бизнес процесса, эмулируемого, анализируемого или контролируемого ПО
• ПО, эмулируемого, анализируемого или тестируемого другим ПО
• устройства с которым ПО взаимодействует
• реакции и ожидания сообществ
• юзкейсы продукта
• пользовательский интерфейс продукта
• объекты, создаваемые продуктом

Соревнований пост

Третьего дня принял участие в своем первом любительском велосоревновании.
Организаторы - pro velo EKB, за что им большое спасибо.
Если интересно - прочтите отчет оргов.

Коротко по результатам - призовых мест не занял, хех.
Подробней:
Народу собралось не то, чтобы много, в основном орги и их знакомые, как я понял.
Процесс - квалификация для организации сетки, затем на выбывание.
Дистанция - 1 км судя по организаторам, 920-950м судя по страве.
Квалификацию стартовал первым в паре с будущей бронзой.
Проехал отстойно даже для меня - 1:47, больше 30км/ч не ехал - дыхания хватило на полдистанции, а дальше опал. Ну, а оппонент обошел меня на раз-два. Шестой из восьми по времени, но видно было, что все не выкладывались на полную.

По итогам попал в пару с тем же самым человеком. Шансов не было, хотел хотя бы проехать не так плохо, что мне вполне себе удалось - 1:32, что для меня вполне себе на уровне. График по скорости из стравы:

 

Видно, что дыхания опять не хватило до финиша, но уже получше. Ехал на 3-5 и 3-6.

Ну а затем была упорная борьба за победу.

Для финального заезда даже тормознули машину и организовали камеру, едущую перед участниками, по моему очень круто.

В перерывах общались за разное и рассматривали велосипеды.
У серебра был найнер с карбоновой рамой и это, мать его, круто. Хочу. Следующий буду брать именно карбон, иначе к чему это все?
Приехало три или четыре двухподвеса, но в соревнованиях участия не принимали.
Посмотрели на мой велосипед. Доходчиво объяснили мне, что рама и руль у меня конечно, ок, а вот все остальное надо было выбрасывать сразу же после покупки. Словами пояснить не могли, дали покатать на своих. Понял, что имелось в виду после первых метров. Если переключатели у меня еще сойдут, то тормоза ни в какое сравнение.

Где то во время полуфинала мимо с гиканьем проехали с десяток представителей нетитульной нации на камах, бэмиках и еще чем-то мелкоколесном и невнятном.
Участники соревнований смотрели на них с грустью и завистью, так как перли они ну прям на приличной такой скорости. Меньше нашей, но на бэмиках...

По итогам - надеюсь это не последняя движуха оргов. Буду ждать дистанций в 5,10 и 20км, хех.
Ну и фоточки. Все вместе:

 

Победители. Я ездил в паре с тем, что справа:

 Легкая акробатика:

Таблица:

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

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

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