Урок 1. Слайды 45-46

Сегодня солнечно. Погода сегодня гораздо  лучше людей.

Поехали:

Слайд 45
И наконец, последнее определение на сегодня.
Независимое тестирование это тестирование, которое проводится без влияния команды разработки.
Классический пример - тестирование независимой лабораторией тестирования. Например, в США создатели электронных систем голосования должны предоставить свои машины для тестирования независимой лабораторией.
Между прочим, их оценка наряду с системным тестированием включает в себя инспекции кода и юнит тесты.
Независимое тестирование не обязательно должно быть тестированием черного ящика.
Но тестирование не будет независимым только потому, что оно внешнее.
Создатели машин для голосования решают, какая именно будет проводит оценку их машин и они платят этой лаборатории. Если вы создаете такие машины и чувствуете, что независимая лаборатория слишком критически относится к вашему продукту, будете ли вы работать с ней дальше? Как вы думаете, будет ли лаборатория проектировать свои тесты так, чтоб уменьшить вероятность потерять свой бизнес?Где здесь независимость?
Независимое тестирование не обязательно должно быть внешним. В некоторых компаниях есть свои независимые группы тестирования. В качестве примера того, как компании отстаивают подобную независимость, можно привести случай, когда тестировщики отчитываются не руководителю программистов.
На практике имеет смысл рассматривать степень независимости. Одно тестирование более независимо, чем другое.
Кстати, даже если некоторые люди отстаивают позицию, что все тестирование должно быть независимым, это не обязательно то, что вам нужно. Тестировщики, работающие в тесном контакте с программистами продукта имеют больше информации о продукте и особенностях реализации и могут влиять на его тестируемость, чем тестировщики, находящиеся далеко от программистов. Относительная польза от сотрудничества по сравнению с независимостью - сложный параметр и зависит от множества особенностей корпорации.

Слайд 46
Я хочу завершить эту первую лекцию несколькими вопросами к вам.

(Примечание переводчика: а сейчас страниц шесть вопросов)

Урок 1. Слайды 43-44

По два бага в приложении на строчку постановки. Вывод очевиден: постановки - зло.

Поехали:

Слайд 43
Многие программисты работают по контракту. Заказчикам нужно ПО и они договариваются с компанией разработчиком на его создание. Многие годы большая часть создаваемого По была написана таким способом и большая часть стандартов разработки создана с предположением, что разработка идет именно таким способом.
В мире заказного ПО контракт обычно включает в себя процесс определения заказчиком, полностью ли ПО реализовано, и оплату после этого этапа.
Если этот процесс включает в себя тестирование, а это обычно так, мы называем такое тестирование приемочным.

Слайд 44
Также компании разрабатывают ПО на продажу и тоже тестируют его. Например, Electronic Arts тестирует свои игры перед продажей.
Другие компании пишут ПО для работы с собственными сервисами, и они тоже тестируют это ПО перед вводом в эксплуатацию, или, как они это называют, продакшеном.
Многие люди и такое тестирование называют приемочным. Я не большой фанат подобного использования термина, так как оно скрывает большое отличие. В традиционном приемочном тестировании заказчик проводит или контролирует тестирование и принимает решение о приеме продукта.
В остальных случаях группа разработки проводит тестирование и принимает решение о релизе продукта на продажу или для внутреннего использования. На мой взгляд, здесь есть разница.
Сдается мне, эти люди хотят использовать термин приемочного тестирования как синоним системного тестирования. Я не собираюсь этого делать.
Но достаточно много людей используют этот термин таким способом, или несколькими другими способами, поэтому вы должны проверить, что люди имеют в виду, перед тем как делать предположения о предмете разговора.

Видяшки про DUMP 2014

Выложили видео с дампа. В том числе с моими тестерами:

• Тестирование без тестировщиков
• Тестирование на аутсорс
• Опыт внедрения тестирования
• Автоматизация тестирования верстки
• Когда тесты пишут разработчики
• RobotFramework
• Управление конфигурациями и тестовой средой

Рутина

В целом прижился, и даже зовут его Григорий.

Урок 1. Слайды 40-42

Вот я вообще не понимаю, как адекватно перевести на русский термин parafunctional testing. Поэтому буду писать здесь и далее - парафункциональное. 

Поехали:

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

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

Слайд 42
В отличие от этого, парафункциональное тестирование включает все, что не является функциональным тестированием. Многие люди предпочитают называть это нефункциональным тестированием.
Я не считаю это различие полезным, так как класс парафункциональных тестов огромен и разнообразен. Тестирование сопровождаемости программы кардинально отличается от тестирования удобства использования или масштабируемости по производительности. Мы должны проводить эти тесты, но сваливать их в одну кучу под одно неуклюжее слово никому не помогает продумывать эти разные типы задач, не помогает планировать на них бюджет и время. Вместо этого, такое определение объединяет множество различных понятий в одно и поощряет недооценивать объем работы по каждой из них.

Урок 1. Слайды 37-39

Жизненное с баша:

ХХХ: Как у тебя на любовном фронте?
УУУ: Нормально. Жду, пока ее жених умрет...

Понеслась:

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

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

Слайд 39
Больше, чем контраст между системным тестированием и юнит тестированием, я подчеркиваю контраст между системным тестированием и тестированием уровня реализации.
Тестирование уровня реализации это тестирование того, как программа была написана.
Уровень реализации это тестирование белого ящика. Когда мы проводим такое тестирование, мы задаем вопросы:

• Как хорошо был написан код?
• Есть ли возможности для его оптимизации?
• Может ли программа работать так, как задумывалось?

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

К просмотру рекомендуется

Максим Дорофеев, очередное замечательное.
В докладе рассказывается о применении мыслительных инструментов Голдратта в проведении ретроспектив. 

Хороший кадр:

Урок 1. Слайды 34-36

Просто кот.

Поехали:

Слайд 34
Точно так же, как тестирование белого ящика является противоположностью тестированию черного ящика, структурное тестирование является противоположностью тестированию поведенческому.

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

Слайд 36
Концепция юнит тестирования, однако, не обязательно связана с тестированием отдельных функций методом белого ящика.
К примеру, IEEE стандарт в юнит тестировании ПО дает больше общих определений.
Одна из техник тестирования черного ящика включает запуск тестов сфокусированных на отдельной фиче. Это называется тестированием функции. Цель заключается в том, чтоб убедиться, что фича работает сама по себе, без взаимодействия с другими. Это пример тестирования черного ящика в юнит тестирвоании.

Рутина

Фо́бос (др.-греч. φόβος «страх») 

Если искать компании с названием Фобос, то мы найдем: 

• контору по продаже гидромассажных ванн
• риэлтора из Дзержинска
• метеорологов
• производителя мебели
• пару разработчиков ПО

Урок 1. Слайды 32-33

Погода. Ненависть.

Поехали:

Слайд 32
Другой базовый подход к тестированию называется поведенческое тестирование.Такие тесты проверяют видимое поведение программы, но часто создаются с учетом знаний о коде.
Поведенческое тестирование похоже на тестирование черного ящика, за исключением того, что не является тестированием черного ящика.

Слайд 33
Если мы хотим использовать тестирование на системном уровне для исследования того, что программа ведет себя так, как закодирована, мы можем использовать поведенческое тестирование.
Как программист я провожу массу тестов такого рода, чтоб увидеть, что мой код работает. Я называю то, что я делаю тестированием белого ящика.
Но когда я тестирую чужой код, я делаю кое что другое. У меня меньше вопросов о внутренней реализации программы и больше о работающей программе. Конечно, ошибки кодирования уменьшают ценность ПО и я хочу найти их. Но для подготовки к тестированию я должен узнать, кто будет программу и зачем, с какими устройствами и платформами она будет работать, какие виды проблем сделают ее применение на рынке невозможным. У вас нет возможности узнать это из кода.
Идея поведенческого тестирования популярна среди ученых в IT. Если вы делаете акцент на преподавании программирования, то нужды пользователей и платформы не так важны. Требованиями к ПО будет то, что вы скажете студентам. реальность не важна. Это академическое упражнение. В такой ситуации тестирование черного ящика не имеет смысла. Но когда преподаватели подобных курсов описывают тестирование черного ящика как тестирование основанное на невежестве, я не думаю, что они понимают, о чем говорят.

Урок 1. Слайды 29-31

Тема разговоров сегодняшнего дня - метелька и печалька по ее поводу.

Что я вынес из этого урока? Тестирование черного и белого ящика - не техники.
 Поехали:

Слайд 29
Противоположность тестированию черного ящика - тестирование стеклянного ящика.  Мы смотрим внутрь ящика и проектируем тесты, основываясь на характеристиках кода. Многие люди называют тестирование стеклянного ящика тестированием белого ящика.

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

Слайд 31
Черный и белый ящики описывают основные подходы к тестированию. Многие люди называют их техниками, но это не так.
Техника это способ делать что-либо. Когда мы учим кого-то технике, мы рассказываем ему, как выполнить конкретную задачу. Мы рассмотрим несколько техник в следующей лекции. Но тестирование черного и белого ящика - это способ мышления в рамках техник. Это не техники сами по себе.

Урок 1. Слайды 24-28

А у нас был релиз. и программисты таки молодцы. Стало лучше.

Поехали:

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

Слайд 25
Основная проблема в том, что у людей есть разные точки зрения на то, что нужно делать, чтоб тестировать хорошо. Люди, стоящие на сильно отличающихся теоретических позициях используют язык по-разному.
И я не смогу изменить этот факт во время этого курса. И  я не претендую создать единственно верное техническое определение. В среде разработки по этому поводу идет обширная полемика. Мы должны принять это и работать с этим.
Реальные словари часто приводят несколько определений некоторых слов.
Действительно хорошие словари, вроде оксфордского дают несколько определений и приводят примеры использования, со ссылками на авторитетные источники, определяющие тот или иной способ использования.

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

Слайд 27
курс о тестировании черного ящика на системном уровне. Давайте посмотрим, что это значит.

Слайд 28
Давайте начнем с определения черного ящика. Исторически, до появления компьютеров и ПО, люди говорили о изучении устройств как о изучении черного ящика.

Понятие черного ящика - понятие "закрытой" вещи. Вы не имеете возможности посмотреть внутрь нее и понять, как она работает. Вместо этого у вас есть возможность подавать ей что-нибудь на вход (например нажимать кнопки) и смотреть что случится. Когда мы тестируем методом черного ящика мы не знаем и не изучаем то, как закодирована программа.Все, что мы делаем во время такого тестирования, так это смотрим, делает ли программа то, что должна и не делает ли она того, чего не должна делать.
Представление о том, что программа должна делать мы получаем от нужд и ожиданий людей, которые ее используют, от характеристик систем, которые взаимодействуют с ней и правил, которые управляют ей.

About face 3: the essentials of interact

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

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

Утреннее

Вот тут почитайте, о прохождении медицинской комиссии на права. Да и вообще много жизненного и интересного:

-- Ну хорошо, давайте что-нибудь из школьной программы. Днём обычно теплее, чем ночью?
-- Да, теплее.
-- Почему?
-- Потому что солнечные лучи несут тепло.
-- А ночью что?
-- А ночью — лунные лучи...
-- Несут леденящий холод?

Урок 1. Слайды 22-23

А у нас сегодня метель. Вот такое гребаное короткое уральское лето.

Поехали:

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

Слайд 23
Мы не можем полностью протестировать продукт. Для этого нужно провести слишком много тестов. Но у нас есть возможность сфокусировать нашу работу вокруг наших информационных целей. Что я под ними понимаю? Информационная цель это ответ на вопрос: "какой вид информации наиболее интересен нам во время этого теста?"
Например, на одном проекте мы можем сосредоточиться на поиске максимально возможного количества багов. Я называю это охотой на баги. В другом проекте или в другое время того же самого проекта, мы будем уделять меньше времени поиску багов, но обратим внимание на то, насколько продукт соответствует требованиям спецификации или насколько он безопасен. Мы будем проводить разные тесты и ходить разными путями для оптимизации получения различных типов информации.

Содержимое слайда:
Тестирование это всегда поиск информации.

• Поиск важных багов
• Оценка качества продукта
• Помощь менеджерам в оценке прогресса проекта
• Помощь менеджеру в принятии решения о релизе
• Блокирование преждевременного релиза
• Помощь в предсказании и контроле стоимости поддержки продукта
• Проверка совместимости с другими продуктами
• Поиск безопасных сценариев использования продукта
• Оценка соответствию спецификациям
• Проверка соответствия продукта конкретным стандартам
• Проверка соответствия процесса тестирования соответствующим стандартам
• Минимизация рисков связанных с безопасностью
• Помощь клиентам в улучшении качества и тестируемости продукта
• Помощь клиентам в улучшении их процессов
• Оценка продукта для третьих лиц.

Урок 1. Слайды 17-21

Третьего дня попробовали недавно открывшийся бельгийский бар Brugge. Много сортов занятного пива, вот такие вот классные бокалы:

Немного тесновато. Но в целом - неплохо, рекомендую.
Выходные были короткие, но интересные.

Поехали:

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

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

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

Слайд 20
Следующее наше определение - качество. В следующем нашем курсе - защита багов - мы рассматриваем несколько определений качества. Сейчас мы сфокусируемся на наиболее полезном.
Качество это ценность для кого-либо. У этого определения есть два важных аспекта.
Первый - ценность. Сказать, что изменение улучшает качество означает сказать, что изменение добавляет стоимость продукту, или если изменение не будет произведено, то продукт будет стоить меньше.
Второй аспект - ценность для кого-либо. Качество субъективно. То, что будет делать продукт более ценным для вас - может сделать его менее ценным для кого-либо еще. Например, программа может быть очень проста для изучения для вас, и если мы сделаем ее такой же, как другая программа, с которой вы уже знакомы. Это добавит ценности для вас, но кто-то другой не знаком с вашими любимыми программами и для него качество нашей программы уменьшится. Мы могли бы сделать опцию, позволяющую людям выбирать пользовательский интерфейс или дизайн, но это очень сложное изменение.Сейчас люди изучают дизайн программ и делают свой выбор. Это может быть добавить ценности для некоторых людей, но, вероятно, сделает программу сложнее и менее ценной для других.

Слайд 21
Это подводит нас к идее бага. Все, что уменьшает качества продукта - баг. Сейчас мы создали интересную проблему. Баг для кого-то еще может быть фичей для вас.
Это может быть более широким определением бага, чем то, к которому мы привыкли. Многие программисты считают, что только ошибки в коде могут быть багами. Но это все равно, что считать, что программа это код исполняемый на компьютере. Это очень узкое восприятие.
На этом курсе и в коммерческом мире мы вынуждены мыслить более широко - о уменьшении или увеличении ценности продукта. А не только о работоспособности кода.

Ненависти и немного грусти пост

По мотивам новости Образовательным учреждениям предлагают следить за интернет-активностью учащихся и педагогов

Постановление можно найти здесь.
Заголовок новости вот про эти строки из пункта 2.3

е) анализ наличия персональных сайтов и страниц в сети Интернет среди обучающихся и работников организации, основных направлений обмена и распространения информации, в том числе информации околорадикального толка;
ж) мониторинг посещаемости обучающимися и работниками организации Интернет-ресурсов, форумов, блогов и сообществ в социальных сетях, занимающихся распространением информации террористической и экстремистской направленности;

Конечно бред, конечно, делать это некому. У меня мама - преподаватель математики, классный руководитель, но вот как то не вижу я, что она вечерами просматривает вконтактики своих оболтусов.

Но там и дальше интересно. Знаете, что должны делать образовательные учреждения при помощи министерства образования?

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

Министерства не попутали?
Да. не читайте на ночь постановления правительства.

Велогородское

Ни разу не был:

Друзья

Прекрасно же:

— ...К тому же, Алиса, ты сейчас как раз во второй клетке. Доберешься до восьмой…— голос Белой Королевы вдруг изменился. — Получишь. Тортик.

 Вот тут дальше и еще.

Спольски о багах, опыте и старом коде.

На Хабре перевод.
Рекомендую прочесть весь, избранные цитаты. Раз:

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

Два:

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

Кот символизирует:

 

Так

Доброго утра:

Я думаю, что место легко узнать.

Еще цитата из Купера

О горизонтальной прокрутке:

Горизонтальная прокрутка текста – это нечто ужасное, и она не должна
применяться нигде и никогда. Помните: мы говорим только о тексте.

Урок 1. Слайды 11-16

С добрым утром.

 Идем дальше:

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

Содержимое слайда:
Цели курса BBST

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

Слайд 12
Это цели, которых мы достигнем на этом курсе. Первая лекция вводит базовые понятия курса. Дальнейшие лекции рассматривают ключевые проблемы тестирования. По мере развития вашей карьеры вам понадобится больше знаний. Лучшая альтернатива обучению - работа с профессионалами онлайн. Остальные наши цели - помочь вам улучшить ваши навыки коммуникации как студента онлайн курса.

Содержимое слайда:
Знания о тестировании.
Ключевые проблемы тестирования:

• Информация о миссии и стратегии тестирования
• Оракулы и эвристики
• Покрытие - многомерно
• Завершение тестирования невозможно
• Измерение важно. но сложно

Введение в:

• Базовые определения
• Базовые факты о хранении данных, и их обработке
• Разнообразие точек зрения

Улучшение академических навыков

• Инструменты совместной работы: форумы. вики
• Аккуратность при чтении
• Чистая, структурированная коммуникация
• Эффективные отзывы
• Спокойно справляться с формированием оценки

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

{примечание переводчика, то есть меня. Там дальше куча текста про то, как будут организованы вебинары и личные встречи}

Слайд 14
Ок, время поговорить о тестировании.

Слайд 15
Иногда я веду вводный курс в программировании во флоридском техническом. Учебники обычно содержат определение вроде этого: программа это набор инструкций для компьютера. 
Это сумасшедшее определение.

Слайд 16
Это все равно, что определить дом как конструкцию, собранную из материалов согласно чертежу.
У нас есть возможность так определить дом, но этого не будет хватать для того, чтоб понять, что такое дом.
Дом это здание, созданное для того, чтоб в нем жили люди.

Так

Это вчерашний добрый вечер, хех.

Доброе утро

Do you want to play a game?
Например так, Екатеринбург, где это?

Урок 1. Слайды 6-10

Хороший сегодня день. Воскресенье, солнечно, критикал нашел.
Едем дальше:

Сайд 6
У Ребекки Фидлер докторская по педагогике. Она главный дизайнер оналйн версии этого курса.
Если ваш инструктор читает книгу или смотрит этот курс, то он видит работы Беки.

Слайд 7
Тут картинка со списком всех, кому нужно сказать спасибо.
Я главный спикер этого курса и отвечаю за все ошибки. Но еще многие люди заслуживают упоминания. Особенно я хочу поблагодарить Hung Nguyen, Doug Hoffman и Майкла Болтона, которые привнесли массу материала в эти слайды. Многие мои коллеги внесли существенный вклад на протяжении 18 лет создания этого материала, включая более чем 32 инструкторов онлайн версии BBST. Мы получили хорошую обратную связь и ценим ее.

Слайд 8
У вас есть возможность загрузить презентацию с моего сайта www.testingeducation.org/BBST

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

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

Радости пост

Намедни открыл свой велосезон, зимой не катался из за лени, жадности и грязи.

Тестовая покатушка прошла успешно, город вполне себе подсох.

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

Проехался радостно, но позорно медленно, надо стремиться и тренироваться.

Привет из родных мест

Активисты из каменска повесили рекламные щиты:

Жгут чо.
Вот тут увидел.

А музыка звучит

Залип за музыку:
 

Andrea Bocelli — Time To Say Goodbye (Con Te Partiro)

О постановках

Наши постановки достойны того, чтоб у них были эпиграфы:

Человек Номоса

Намедни дочитал книгу Олдей "Одиссей, сын Лаэрта. Человек Номоса".

Это книга очень похожа на то, как все было на самом деле - весь ахейский цикл Олди выдумка, но такая, которая должна быть реальностью, потому как это правильно.

А еще эта книга - о любви:

— Теперь ты будешь меня ненавидеть?
— Нет. Я буду тебя любить. Как раньше. Я умею только любить.
— Наверное, ты действительно сумасшедший, — вздохнул Паламед.
Я не стал ему ничего говорить. Он просто не знал, что такое — любовь. Настоящая любовь.

 И еще немного - о том, как бывает скучно:

Просто вдруг, без видимой причины, ему стало скучно. И некто холодный и бесстрастный, другой, живущий внутри «него» человек, спокойный и расчетливый, лишь изредка поднимавшийся на поверхность из темных глубин души — этот человек, которого звали Одиссей, что значит Сердящий Богов, сказал:
- «Ты сделаешь все, что понадобится. Завтра явишься к отцу — а там посмотрим. Если нужно будет убить — убьешь. Если нужно будет обмануть — обманешь. Если нужно будет предать — предашь. Твой личный Номос важнее предрассудков. Ты справишься».

Заодно неплохо так освежил знания в греческой мифологии.

Урок 1. Слайды 1-5

Вообще этот воркбук по сути - презентация в виде книги.
Слайды, которые не несут полезно информации мне скринить и переводить лень. Полезные буду фотографировать прямо из книги.

Понеслась:

Слайд 1-2
Привет!
Добро пожаловать на курсы по тестированию ПО методом черного ящика.

Слайд 3
Меня зовут Сэм Канер. Я защитил несколько докторских. Я профессор инженерии программного обеспечения флоридского института технологий.

Слайд 4
Также я автор нескольких книг по тестированию ПО. Вы могли бы прочесть больше на сайте kaner.com.
Я не профессионал в создании курсов и редактирую курсы дома, так что в моих видео вы найдете много острых углов.
Работа дома позволяет мне сохранять право собственности на все материалы. которое, в свою очередь, позволяет мне распространять их под лицензией Creative Commons.  Это позволяет свободно копировать и воспроизводить их для других людей.

Слайд 5
Джеймс Бах и я основные создатели содержимого этого курса. Я считаю Джеймса одним из самых ярких людей в нашей области. Вы могли бы узнать больше о его работе на сайте satisfice.com

Урок 1. Обзор и основные понятия. Введение.

Этим постом начинаю перевод книги Foundations of Software Testing Black Box Software Testing WorkBook.
 Книга разделена на уроки, в каждом уроке - несколько слайдов, у каждого слайда - свой текст. Всего 6 уроков и 303 слайда.
Пару уроков переведу точно, а там как попрет. Но вообще, думаю справиться за год.

Настроение - выспался.

 Поехали.


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

Терминология тестирования не единообразна. Одна из причин этого в том, философия тестирования отражает лежащие в ее основе языки, которые также не единообразны. Например, многие люди считают, что тест не является тестом, пока у нас нет оракула (ожидаемого результата, который позволит сказать, провалился тест или прошел). Тестирование без ожидаемого результата слабо. Для них естественно включать ожидаемый результат в понятие "тест". Однако, другие тестировщики рассматривают исследование продукта (которое включает тестирование без знания о том, что должно быть) весьма полезным. А другие считают, что есть много возможных оракулов для каждого теста и умелый тестировщик фокусируется на различных потенциальных ошибках (рассматривает разных оракулов) в разное время. Для этих людей выбор оракула разделен с основной идеей теста. Нет определения теста, которое удовлетворило бы все три группы.

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

Некоторые студенты доказывают, что наши определения неверны и требуют, чтоб мы исправили их. Они доказывают, что вопросы с несколькими вариантами ответов несправедливы, так как вопросы должны считать определения из лекций корректными, даже если (по мнению студентов) определения в лекции неверны.

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

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

Новая книга

Вот такой подгон от родной фирмы Foundations of Software Testing:

Если все пойдет по плану - то первый кандидат на перевод. Судя по всему - книга неплохая.

Профессионализма пост

Давно искал эту гифку:

Вот как-то так и работают профессионалы.

Рутина

Намедни нашел ошибку - едет верстка у одного сервиса, если ввести запрос "ясен хуй".
Другая связана с запросом "Накал промышленные печи".

Программист по этому поводу интересуется, что я ищу в обычной жизни. А я не помню.

Вы видите женщину в красном?
А кто-то видит сниппеты, кодлунщики, острова..

А какой бред обычно ищете вы?

Музыки пост

Почему-то особенно хорошо тестируется под Rammstein.

Для пущего эффекта надо SOD попробовать.

Таски.
No pasarán

Купер о функции переименовать

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

Приложения, которыми я пользуюсь часто:

Ваши версии, почему пункт переименовать отсутствует?

Вот, кстати, версия Купера:

Люди и базы

Купер о базах и людях:

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

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

Первого апреля пост

Подготовку к сегодняшнему дню я начал еще месяц назад.
А идея возникла прошлой осенью.


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

Впрочем, кому это все интересно? Дальше - фото:
В собранном: состоянии выглядит так:

Недели три стоял дома. Иногда празднично так:

А потом просто как вешалка:

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

Социопатам на заметку - гораздо лучше подходит чехол для борда:

Уютненько так:

До нового места проживания доставил без происшествий. Инсталляция выглядела так:

Потом немного сменили имидж:

Ну, этот ежик будет жить с нами:

Медленная хорошая музыка

Elvis Presley — The Girl of My Best Friend