Урок 2. Слайды 87-89

Кстати да. Справа в этом бложике появился бейджик про сертификацию. И еще часть ребят есть тут:

Поехали:

Слайд 87
Другой тип группы тестирования - полностью независимая. Когда мы говорим об аутсорсерах, мы имеем в виду содержание отдельной группы для тестирования, просто обычно аутсорсеры дешевле.

Содержимое слайда:
Изменение контекста: внешняя лаборатория

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

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

Слайд 89
Конец лекции 2.

Урок 2. Слайды 85-86

Хорошая погода радует, а я таки обгорел.

Поехали:

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

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

• Охотники за багами
• Защитники качества
• Поддержка разработки
• Управление релизами
• Уменьшение стоимости поддержки

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

Урок 2. Слайды 82-84

Отличные выходные.
75км туда на велике, друзья. дача, мангал, баня, озеро, 70км обратно на велике.
Видимо, из за того, что отдыхалось хорошо - единственное фото за два дня:

Поехали:

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

Содержимое слайда:
Типичный контекст: задачи во времени.

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

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

Содержимое слайда:
Типичный контекст: редкие задачи

• Написание требований
• Участие в инспекциях
• Сборка продукта
• Руководство тестированием белого ящика
• Написание инсталляторов
• Конфигурирование и поддержка инструментов, связанных с программированием, таких как система контроля версий
• Архивирование ПО
• Исследование багов, анализ исходного кода
• Оценка надежности ПО
• Техподдержка
• Демонстрация продукта снаружи компании

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

Содержимое слайда:
Типичный контекст: редкие задачи

• Обучение новых пользователей использованию продукта
• Оценка рисков
• Сбор статистики от фидбеку
• Создание и поддержка инструментов тестирования
• Оценка продуктов конкурентов
• Оценка маркетинговой ценности различных программных и аппаратных конфигураций продукта
• Юзабилити тестирование
• Организация аудита продукта на соответствие стандартам
• Менеджмент проекта

Урок 2. Слайды 80-81

Разработчик:
- Сифилис по научному трипонема. Хм, так вот откуда слово трипак. А я думал это от слова trip, приключение.

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

Содержимое слайда:
Типичная группа тестирования.
Группа SoftCo включает:

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

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

Урок 2. Слайды 78-79

Поехали

Слайд 78
До сегодняшнего дня мы рассматривали шесть основных концепций.
Мы тестировали, чтоб найти информацию о качестве для заинтересованных лиц.
Мы фокусировали наше тестирование, чтоб быть уверенными в том, что мы достигнем информационных целей. На данном проекте наша миссия состоит в достижении информационных целей, чтоб получить специфическую информацию, которая нужна заинтересованным лицам.
Чтоб выполнить миссию мы разрабатывали стратегию. Главный компонент стратегии - описание техник, которые мы будем использовать, время и способ их применения и то, в какой степени мы будем полагаться на них.
Сегодня мы рассмотрим остальное, то как должны быть организованы работы по тестированию.

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

• тестирование
• заинтересованные лица
• Информационные цели
• Миссия
• Стратегия
• Техники тестирвоания

Дальше:
Как должны быть организованы работы по тестированию.

Слайд 79
Нет единственного способа организации работ по тестированию.
Но позвольте мне начать с довольно типичного примера.
SoftCo создает ПО которое он продает другим людям. Их заказчики покупают  продукт и сервис обновлений. Они могут в любой момент перестать это делать.
SoftCo пишет и тестирует свой код. Программисты, менеджеры, тестировщики, техподдержка и директора работают в одном здании. У тестировщиков есть возможность встретить всех влиятельных людей и вступить в  социальные отношения с ними (прим. перев. - серьезно, он так и пишет).
В компании также есть неформальные митинги и праздники для поощрения общения между сотрудниками. Сотрудники, включая тестировщиков, обедают друг с другом, ходят в кафе и пабы и обсуждают проблемы продукта, проекта, компании. Такие обсуждения делают возможными появление неформальных сетей.
Такие неформальные сети - главная фича американских компаний, особенно компаний, создающих интеллектуальные продукты.

Урок 2. Слайды 76-77

Кстати да. Неделю назад сдал экзамен, ISTQB foundation level.
Фанфары не гремят, фотомодели на шею не вешаются. Я не рассчитывал, конечно, но небольшая надежда была.
Поэтому - возобновляю переводы и надеюсь наверстать отставание.

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

Кот взбешен.

Поехали:

Слайд 76
Джеймс Бах находит удобным говорить о техниках тестирования как будто бы они были рецептами. Так же как рецепты описывают различные ингридиенты и способы их смешивания, техники тестирования описывают различные аспекты тестирования.

Содержимое слайда:
Техники тестирования (Бах)
Техники тестирования обычно описывают как сделать следующее:

• проанализировать ситуацию
• смоделировать тестовый случай
• выбрать, что покрыть тестами
• определить оракулы
• сконфигурировать тестируемую систему
• наблюдать на тестируемой системой
• оценить результаты тестов

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

Урок 2. Слайды 74-75

Утро доброе. но какое-то прохладное.

Поехали:

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

Содержимое слайда
Стратегия и дизайн.
Думайте о дизайне как о применении стратегии для выбора техник тестирования и генерации идей , наборов данных.

• Кто будет проводить эти тесты? (Каковы его знания и навыки?)
• С какие потенциальные проблемы он пытается обнаружить?
• Каким образом он распознает подозрительное поведение программы? (оракул?)
• Что он фактически будет делать?
• Какие инструменты он будет использовать?
• На каких данных проводятся тесты? Хороши ли эти данные?
• Будет ли он создавать документацию или сохранять архивы, чтоб помочь организовать работу будущих тестировщиков?
• Каков результат его работы? Отчет? Лог? Архив? Код?
• Какие аспекты контекста проекта могут усложнить его работу?

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

Урок 2. Слайды 71-73

По поводу скорости перевода - в ближайшее время будет меньше, тут какое-то rstqb намечается. Тем не менее, как-то так:

Поехали:
Слайд 71
По мере развития проекта ваша миссия тоже может меняться. В начале проекта вы будете заниматься охотой на баги. Позднее вы будете помогать менеджеру проекта принимать решение о выпуске продукта. Для достижения этих целей вы будете тестировать по разному. Охотник на баги проводит в областях высокого или неизвестного риска, а не в местах, где риски малы или там нет багов, или если баги найденные там никто не будет чинить. В отличие от охотник, эксперт по статусу продукта уделит внимание всем частям продукта и потратит боль9ше времени на области с низкими рисками.

Слайд 72
Когда ты поймешь в чем твоя миссия. ты пойдешь, как достичь ее цели. основной план достижения целей - твоя стратегия.

Содержимое слайда
Стратегия тестирования
Миссия определена. как мы будем выполнять ее?
Определения:

• стратегия это набор идей, описывающих дизайн тестов
• логистика это набор идей, описывающий работу с вашими ресурсами
• план это комбинация стратегии, логистики и управления рисками

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

Содержимое слайда
Стратегия тестирования
Стратегия учитывает:

• твои ресурсы (время, деньги, инструменты и другое)
• знания и навыки твоей команды
• насколько сложным является окружение продукта
• риски проекта

Для выбора лучшей комбинации ресурсов и техник

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

Урок 2. Слайды 69-70

А это видео с недавнего соревнования в Киргишанах, в котором я не принимал участия.

Наверное, я все-таки куплю goPro. Потом.


Поехали:

Слайд 69
Различные обстоятельства приводят к различным информационным целям. Вот пример:
В первом случае вопрос в том, готов ли продукт к продаже. Это решение принимает не группа тестирования. Но тестировщики могут повлиять на него. Если вы считаете, что продукт в плохом состоянии, у вас есть возможность найти много багов, чтоб продемонстрировать серьезность проблемы. Если вы найдете достаточно серьезные баги, то один из ключевых заинтересованных лиц примет решение о задержке релиза до тех пор, пока баги не будут исправлены. Мы называем такие баги show-stopper.
Во втором случае По было уже выпущено. Оно неплохо работало в бою и группа тестирования работала на адвокатов. Группа не искала show-stopper'ы. Шоу уже шло. Группа искала проблемы ПО, которые помогут адвокатам понять проблемы ПО и объяснить их судье и жюри.

Содержимое слайда:
1 случай:
У массового По близится дата релиза. Группа тестирования считает, что багов слишком много и хорошо проинформированные заинтересованные лица примут решение пока не выпускать его. Эти тестировщики заинтересованы в охоте на серьезные баги, которые помогут принять заинтересованным лицам решение о задержке релиза.
2 случай
ПО засбоило во время эксплуатации и послужило причиной серьезных убытков. Адвокатская фирма наняла тестировщиков, чтоб определить, что вызвало сбой. 
Этим тестировщиков не нужно охотиться на баги. Им нужно определить все возможные причины конкретного сбоя и изучить информацию о качестве от производителя ПО,

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

Урок 2. Слайды 67-68

Сегодня хороший день. Кот с надеждой смотрит в будущее. И немного с опасением.

Поехали:

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

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

• ценность для кого-либо

тестируемого продукта или сервиса

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

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

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

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

Урок 2. Слайды 65-66

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

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

• организация и поиск информации
• активный процесс дознания. Мы задаем сложные вопросы и осторожно смотрим на результат

осуществляемое с целью обеспечения заинтересованных лиц

• лица с законным интересом в успехе тестирования
• лица с законным интересом в успехе продукта

Слайд 66
Когда я говорю информация я имею в виду изучение того, что мы в данный момент не знаем. Karl Popper был один из самых влиятельных философов в науке. Его труды являются обязательными к прочтению для студентов во многих областях, благодаря ясности и чистоте идей. Popper критиковал эксперименты которые являлись обычной демонстрацией. Не проектируйте эксперимент, чтоб подтвердить что-то, что уже знаете. проектируйте его так, чтоб опровергнуть то, во что верите. Проектируйте его так, чтоб он скорее всего провалился, если вы ошибаетесь. Это, говорил Popper, основа исследования.
Многие тестировщики проводят одни и те же тесты снова и снова. Каждый раз, когда программист меняет программу, они возвращаются к старым тестам и программа проходит большинство из них, снова и снова. Это не тестирование. или это не компетентное тестирование. Мы не изучаем ничего, когда программа проходит такой тест.
Люди проводят такие тесты, чтоб подтвердить, что каждая фича, которая уже создана все еще работает. Они называют это лучшими практиками. Они дали этой работе забавное имя, регрессионное тестирование.
Если следовать Popper'у, то мы должны продолжать тестировать старые фичи, но мыв должны использовать новые тесты. Мы должны тестировать каждую фичу с каждым разом все суровей, возможно, на более сложных данных или на разных платформах или в комбинации с другими фичами. Пройдет ли программа эти новые тесты или провалит их - мы узнаем что-то новое. Это - информация.

Урок 2. Слайды 62-64

Мерзкое утро.

Поехали:

Слайд 62
Во многих книгах определение тестирования слишком длинное, так как они пытаются полностью описать сложное понятие.

Слайд 63
Вот мое рабочее определение. Пойдем по порядку.

Содержимое слайда:
Тестирование ПО

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

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

Содержимое слайда:
Определение тестирования
эмпирическое

• мы получаем знания из мира, не из теории (Мы называем это экспериментами, тестами)
• мы получаем знания из многих источников, включая техсапорт. пользовательский опыт и так далее

техническое

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

Урок 2. Слайды 58-61

Отличная трасса найдена мной с подачи Коли:
Примерно 50 км по московскому тракту, машин нет, дорога в целом ок. Я проехал за три часа, но мне еще надо тренироваться.
В далеком идеале - довести время часов до двух.

Поехали:

Слайд 58
Добро пожаловать на вторую лекцию курса основ тестирования ПО.

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

(прим. переводчика - список литературы на слайде соответствует списку во введении)

Слайд 61
Итак, давайте начнем с определения тестирования.
Я считаю, что определение Глена Майерса наиболее популярно среди тестировщиков - мы все рассматриваем себя как охотников за багами.
Я предпочитаю определение Джеймса Баха, так как оно ведет к более важной мысли. Каждый тест это вопрос. Если вы уже знаете ответ, то это демонстрация, а не тест.

Содержимое слайда:
Что такое тестирование ПО?

• процесс выполнения программы с целью поиска ошибок. Глен Майерс (1979, с.5) Искусство тестирования ПО
• допрос программы для ее оценки. Джеймс Бах

Урок 2. Введение.

Третьего дня прогулялся по старым и не очень друзьям и знакомым.
С помощью планирования, пары заказов такси и добрых друзей, которые подбросили до синих камней - за сутки - с 00:00 до 23:00 я увиделся с девятью людьми, которых я не видел... в среднем по полтора года каждого.
Максим, Тёма, Настя, Алексей, Оля, Костя, Саша, Оля, Наташа - спасибо вам большое.

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

Еще спасибо за то. что помогаете мне понять, что людей нужно и важно - любить. И за то, что сами того не зная, помогли составить список людей - спасибо.

Поехали:

Урок второй. Стратегия.

Это вводная лекция контекстного тестирования:

• Цель, лежащая в основе подготовительных примеров и списка литературы состоит в том, чтоб подготовить ваш мозг к огромному разнообразию ролей тестировщика. Если же у вас нет предрассудков о тестировщиках и их ролях, то вы узнаете кое-что новое, что может помочь вам пройти первое собеседование на должность тестировщика. Если вы попали на этот курс с уже ограниченным взглядом о ролях тестировщика и группах тестирования, то этот урок будет вызовом вам, чтоб расширить свои взгляды.
• Эта лекция определяет тестирование как сервис для заинтересованных лиц. В частности это эмпирический поиск релевантной качеству информации о продукте от имени заинтересованных лиц. Ключевые заинтересованные лица часто имеют разнообразные потребности в информации. Чтоб соответствовать этим потребностям, тестировщики приспосабливают свое тестирование (то, что они делают, инструменты, которые они используют, как они приоритезируют свое время).
• Тестировщики также должны приспосабливаться к реалиям проекта, таким как бюджет, план, навыки персонала, доступность инструментов.

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

Список литературы
Следующие статьи обязательны к прочтению:

• Kaner C. Управление соотношением тестировщиков и других разработчиков http://kaner.com/pdfs/pnsqc_ratio_of_testers.pdf

Следующие статьи рекомендуются к прочтению:

• Bach J. Эвристическая модель стратегии тестирования http://testingeducation.org/BBST/foundations/Bach_satisfice-tsm-4p-1.pdf
• Kaner C. Найм тестировщиков ПО http://kaner.com/pdfs/qaijobs.pdf
• Kohl J. Как я создаю ценность своим тестированием? http://testingeducation.org/BBST/foundations/Kohl_Blog_CreateValue.pdf

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

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

• Какие сервисы предоставляет ваша группа?
• Попробуйте одним коротким предложением описать, какую самую важную ценность предоставляет или должна предоставлять компании?
• Перед кем отчитывается менеджер вашей группы? (Какова его роль? Он сфокусирован на поддержке клиентов? Разработке продукта? Маркетинге? Обеспечении качества? Другие задачи?)
• Насколько большая у вас группа и как соотносится с количеством разработчиков? Есть ли баланс в этом соотношении?
• Каковы ключевые организационные проблемы вашей группы? (Когда мы говорим о организационных проблемах мы имеем в виду роли, бюджет, возможность тренингов, влияние решений маркетинга)
• Чем вы отличаетесь от обычной группы тестирования?
• Как вы будете менять все это?