Хэб Схотс "Эвристики для распознания тестировщиков-профессионалов" - перевод

Продолжаю серию переводов статей по тестированию. Статья Хэба Схотса расскажет вам об эвристиках для распознавания тестировщиков-профессионалов. Если вас интересует данная тема, из самого свежего также порекомендую доклад Алексея Лянгузова "Успешный тестировщик. Путь профессионала" на SQA Days-15, о котором я писал в обзоре первого дня конференции.

Ссылка на оригинал  -  http://www.huibschoots.nl/wordpress/?p=1666
Формат текста (выделение терминов, курсив, цитирование) и ссылки на другие статьи из текста взяты с оригинала "как есть".

Helena Jeret-Mae задала вопрос в твиттере: "Какие ваши критерии профессионализма тестировщиков и CDT-комьюнити?" Позже в емейле она уточнила свой вопрос: "Обновленная версия моего вопроса: какие по-вашему мнению существуют эвристики распознавания профессионального тестировщика? Я заменила "критерии" на "эвристики", этот термин менее категоричный. И я оставила термин "профессионализм" на ваше усмотрение - я не знаю точно, что вы подразумеваете под ним".

В своем выступлении "Как стать великолепным тестировщиком" на конференции ContextCopengagen в январе 2014 года я говорил о тестировщиках и их навыках. Я говорил, что многие тестировщики не знают, что они делают, и не могут доходчиво объяснить, какую ценность они вносят в проект. Я повидал много тестировщиков, которые раз за разом используют один и тот же подход. Если я спрашиваю, какие тестовые техники им известны, они называют совсем немного. Если я прошу их объяснить мне техники или показать, как они работают, у них нет ответа. Для меня это шок, и я не могу объяснить, почему тестировщики, называющие себя профессионалами, знают так мало про свое ремесло и совсем не обучаются ему.

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

Но достаточно разглагольствований, давайте я отвечу на вопрос.

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

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

Мои эвристики для того, чтобы распознать тестировщиков-професионалов:

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

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

3. Они постоянно и в первую очередь учитывают контекст.
Чтобы быть эффективным, тестировщики должны выбрать цели тестирования, техники и, в первую очередь, посмотреть  на детали конкретной ситуации. Они признают, что нет "лучших практик", есть только хорошие практики в данном контексте.

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

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

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

7. Они задают вопросы, прежде чем cделать что-либо.
Тестирование зависит от многих вещей, и от видимого нам контекста. Что такое информация, которую мы должны найти? Что такое миссия тестирования? Это можно легко проверить, если дать тестировщику упражение на интервью. Если он или она начинает работу над упражнением или отвечает, не задавая вопросы, это о чем-то говорит.

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

9. Они знают, что эстимации (оценки) - это переговоры.
Обратите внимание на эти статьи в блоге Майкла Болтона:

• Быстрый путь оценки тестирования проекта
• Оценка тестирования - это переговоры
• Почему тестирование занимает так много времени
• Проектные оценки и черные лебеди

10. Они используют тест-кейсы и тестовую документацию с умом.
Контекст определяет, какую тестовую документацию вы должны создать и какой вид документации полезен. Совсем недавно отличная (и объемная) статья Джеймса Баха и Аарона Ходдера была опубликована в Testing Trapeze "Тест-кейсы не тестируют: на пути к культуре производительности тестирования". Также Фиона Чарльз поделилась своими интересными мыслями о тестовой документации в статье "Разрушаем Тиранию Форм".

11. Они непрерывно изучают свое ремесло, много тренируются и практикуют "осознанную практику".
Осознанная практика - структурированная активность с целью улучшения производительности. Андерс Эрикссон выделяет четыре основные компоненты осознанной практики. Она должна быть намеренной, направленной на улучшение производительности, предназначенной для вашего текущего уровня квалификации, сочетающая мгновенную обратную связь и повторения.

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

13. Они любознательны и любят изучать новые вещи.
Тестировщики получают удовольствие от выяснения сути вещей. О любознательном поведении хорошо написал Гай Мейсон: "Любознательный ум можно описать как активный, вовлеченный, пытливый. Такой склад ума часто находится в поисках новой информации, получает удовольствие от исследований того, что есть и наслаждается процессом, сопровождающим процесс достижения этой цели".

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

• Письменные навыки (отчетности, сообщения, краткие сообщения)
• Коммуникативные навыки (умение слушать, рассказывать истории, готовить презентации, умение говорит "нет", устный отчет, умение аргументировать и договариваться)
• Социальные и эмоциональные навыки (эмпатия, умение вдохновлять, нетворкинг, управление конфликтами и консалтинг)
• Навыки решения проблем
• Навыки принятия решений
• Навыки обучения и изучения
• Быть проактивным и уверенным в себе

15. Они великолепно владеют навыками тестировщика:

• Навыки мышления (критическое, латеральное, креативное, системное мышление)
• Аналитические навыки
• Моделирование
• Анализ рисков
• Планирование и оценка
• Умение применять различные тестовые техники
• Исследование
• Проектирование эксперимента
• Наблюдение

В приложении "Динамика исследовательского тестирования" к документу "Быстрое тестирование ПО" вы можете найти списки навыков.

16. Они обладают достаточными техническими навыками.
Есть много технических навыков, которыми должен обладать тестировщик, к примеру уметь использовать тулы, обладать навыками кодирования или желанием изучать техническую структуру приложения, которое он тестирует. Навыки автоматизации, такие как написание скриптов, знание SQL для работы с базами данных, быть способным сконфигурировать и установить ПО. знания и навыки работы с платформой, на которую устанавливается тестируемая система (Windows, Linux, мобайл, и т.д.)

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

Между прочим, я погуглил запрос "кодекс этики тестирования ПО" и обнаружил Кодекс Этики ISTQB для тестировщиков-профессионалов. Мне интересно, знают ли о нем люди, которые сдавали экзамен И, что более важно, используют его в своей практике. А вы используете?

Хэб Схотс, 23 марта 2014 года.

P.S. Для дальнейшего улучшения качества переводов буду рад редакторской помощи: вы получите первым вариант статьи и сможете внести свои улучшения перед окончательной публикацией в блоге. Вы также будете включены в список благодарностей под каждым переводом со ссылкой (если пожелаете) на ваш профайл или сайт.
Если вы обладаете хорошим английским и русским, видите несовершенства данного перевода и желаете сделать будущие переводы лучше - пишите мне - www.google.com/+ЛадутькоАндрей

Роб Ламберт "Продукт, который вы тестируете, может создать и разрушить вас как тестировщика" - перевод

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

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

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

Ссылка на оригинал  -  http://thesocialtester.co.uk/the-product-you-test-can-make-or-break-you-as-a-tester/
Формат текста (выделение терминов, курсив, цитирование) и ссылки на другие статьи из текста взяты с оригинала "как есть".

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

Когда я тестировал продукты, от которых не получал удовольствия, я хотел оставить тестирование. Периодически. Я хотел уйти. Тестирование казалось полным отстоем.

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

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

На самом деле, я чувствовал себя выброшенным на свалку.

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

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

За все эти годы я встречал так много тестировщиков, которые ненавидят тестирование. Или, по крайней мере, так думают.

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

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

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

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

Роб Ламберт, 28 января 2014 года.

Сэм Канер "Неудача Udacity" - перевод

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

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

Ссылка на оригинал  -  http://kaner.com/?p=367
Формат текста (выделение терминов, курсив, цитирование) и ссылки на другие статьи из текста взяты с оригинала "как есть".

Как вы знаете, Udacity - огромный поставщик онлайн-курсов, называемых МООК (Массовые Открытые Онлайн Курсы). Недавно основатель Udacity объявил о том, что он разочарован результатами Udacity в онлайн-образовании, и обратил внимание с массового образования на корпоративные тренинги.

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

Моя заметка - это реакция на 2 статьи:

• http://www.elearnspace.org/blog/2013/11/15/the-failure-of-udacity/
• http://www.fastcompany.com/3021473/udacity-sebastian-thrun-uphill-climb

Udacity предлагает бесплатные или недорогие онлайн-курсы. Как я понимаю, у Udacity процент завершения равен десяти (только десять процентов студентов проходят программу полностью) и процент успешно завершивших курс равен 5. В этом нет ничего удивительного. До того, как появились МООК, похожие цифры были зафиксированы и в других видах онлайн-обучения, в которых студенты сами задавали свой темп обучения или работали, незначительно взаимодействуя с преподавателем. Например, я слышал, что у Открытого Университета (школы, к которой я отношусь с большим уважением) цифры приблизительно такие же.

Я не уверен, что 10% (или 5%) это плохой показатель. Если результат в том, что тысячи людей получают возможность, которая в противном случае у них бы не появилась, это весомый аргумент - даже если только 5% находят время, чтобы эту возможность полностью реализовать.

Вообще-то я фанат открытого образования. Когда я проводил интервью с профессорством в Florida Tech в 1999-м году, я представил свою цель создания открытых курсов по тестированию ПО (и по программированию). NSF был основан в 2001-м году. В результате появилась серия курсов BBST, которая используется во всем мире в коммерческих и академических курсах.

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

Мы собираемся обсудить этот вопрос на семинаре по обучению тестированию ПО  (WTST 13, Январь 24-26, 2014). Семинар направлен на обучение продвинутым курсам в тестировании ПО. Кажется, из предварительных обсуждений, эта тема должна стать трамплином для обсуждения основных возможностей.

Но вернемся к МООК.

Udacity (и другие) нажили себе недоброжелателей в учебных сообществах. Выделим несколько типов раздражителей:

• Некоторые сторонники МООК продвигают идею, что МООК устранит большинство преподавательских должностей. В конце концов, если вы можете получить курс от одного из лучших учителей в мире , зачем соглашаться на "второго после лучшего"? Проблема состоит в предположении, что обучение = лекции. Для большинства студентов это не так. Студенты учатся, когда делают что-то и получают обратную связь. Когда пишут эссе и получают обратную связь. Когда пишут код и получают обратную связь. Когда проектируют тесты и получают обратную связь. Студенческие активности - обучение, практическая тренировка, критическая оценка работ студентов, предложение последующих индивидуальных мероприятий - трудно масштабируемы. На этой неделе я потратил около 15 часов на персональные встречи с отдельными студентами, обучая их статистическому анализу или тестированию ПО. На следующей неделе я потрачу около 15 часов на персональные встречи с местными студентами и Skype-сессии с онлайн-студентами. Это тяжелая работа для меня, но мои студенты говорят мне, что узнают многое на наших встречах. Когда люди отвергают ту громадную работу, которую хорошие учителя выполняют для создания и поддержки обратной связи со своими студентами, особенно когда это люди, которых нанимают, чтобы заработать деньги, убеждая клиентов и инвесторов, что эта работа не имеет значения - это приводит в ярость хороших учителей.
• Некоторые сторонники МООК, политики и новостные обозреватели пролоббировали идею, что МООК-образование может заменить академическое. В конце концов, если вы не можете обучить миллион студентов в то же время (с одним из лучших учителей в мире, не меньше), то зачем нужно идти в безжизненные каменные университеты? Именно эта идея терпит неудачу перед аргументом, что 95% студентов бросают или не выполняют программу. Но я полагаю, что ситуация еще хуже, если принять во внимание, что именно выучили эти студенты. Насколько сложны тесты, которые они проходят, или задания, которые они выполняют? Как тщательно оценивается их работа , а не только, насколько точна система оценок, хотя это, безусловно, может быть большой проблемой с компьютеризированной классификации, - но также, насколько информативна обратная связь исходя из полученной оценки ? Студенты обращают внимание на то, что вы говорите им об их работе. Они учатся многому, если вы дадите им, то чему нужно учиться. У меня сложилось впечатление, что многие из тестов / экзаменов поверхностны и что большая часть обратной связи ограниченная и механическая. Когда преподаватели вузов дают обратную связь такого качества, то студенты жалуются. Они знают, что обратная связь должна быть лучше, чем та, которую они получали в школе.
• Сторонники МООК склонны игнорировать или отрицать социальную природу образования. Студенты учатся многому друг от друга. Когда-то я обратил внимание на учебно-исследовательскую литературу, прочитал исследования, в котором было написано, что проходящие обучение студенты узнают больше друг от друга, чем от профессоров. В большинстве (почти всех? всех?) МООК есть дискуссионные форумы, но те, что я видел и про которые мне рассказывали, крайне редко или вообще никогда хорошо не модерируются. Квалифицированный инструктор поддерживает обсуждения в форуме, переносит сообщения не по теме в другой форум, задает вопросы, оспаривает слабые ответы, предполагает литературу для чтения и последующие шаги. Я не видел и не слышал о том, чтобы это происходило в МООК.

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

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

Была организована неустанная (и хорошо финансируемая) обработка и политическое давление для того, чтобы заставить университеты выделить кредит на курсы на Udacity и подобных платформах. Некоторые школы поддались давлению.

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

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

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

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

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

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

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

Беки Фидлер и я организовали Kaner Fiedler Associates с целью поддержки следующего поколения курсов BBST. Мы начали курсы BBST  с МООК-подобного видения структуры, которая предлагает что-то для практически ничего. Наше понимание эволюционировало вместе с тем, как мы создавали новые поколения открытых курсов.

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

Сэм Канер, 23 ноября 2013 года.

Куда уходит все время - перевод статьи Майкла Болтона

На прошлой неделе отзвучали сладкие ноты онлайн-конференции по тестированию ПО Chief Confet&QA. Как всегда, были очень интересные доклады, ценные мысли, а главное - дополнительный заряд мотивации действовать и развиваться. Чуть подробнее свои мысли по докладам я напишу в одном из следующих постов.

А сегодня я подготовил перевод статьи Майкла Болтона "Куда уходит все время" (Michael Bolton - "Where Does All That Time Go?"), о которой я рассказывал на своем конфетном докладе о тайм-менеджменте в тестировании. Статья очень интересная и поучительная, поэтому рекомендую к прочтению.

Ссылка на оригинал  -  http://www.developsense.com/blog/2012/10/where-does-all-that-time-go/
Формат текста (выделение терминов, курсив, цитирование) и ссылки на другие статьи из текста взяты с оригинала "как есть".

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

- Все это отнимает столько времени. Когда мне нужен лист бумаги для заметок, я обязательно должен заполнить соответствующую форму. Боже, спаси меня, если формы вдруг закончатся!
- Сколько времени ты тратишь на подобную работу каждую неделю? - спросил я.
- Около часа в день. Иногда два. Встречи... Скажем, полтора часа в среднем.
- Вау, это ощутимая часть этой недели. У меня есть идея.
- Давай изобразим это, - сказал я и достал мой верный молескин. Я предпочитаю вариант в клеточку для таких случаев, как этот. Я нарисовал прямоугольник, 20 клеточек в длину и 2 - в ширину.

- Итак, ты тратишь в среднем полтора часа в день на согласование (C - compliance stuff). Полтора умножить на пять, или семь с половиной часов в неделю. Давай округлим до восьми. Напиши С в восьми клетках.

Петр так и сделал.

- Хорошо. - сказал я, - А теперь напрягись и вспомни, сколько ты потратил времени на борьбу с тестовым окружении.

Глаза Петра загорелись.

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

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

- В самом деле?! - воскликнул я. - Двадцать восемь часов в неделю, разделенные на пять дней - это более пяти часов в день. Ты серьезно?
- Абсолютно - вздохнул Петр. - Это занимает большую часть, иногда весь день. Это скучно. Что в самом деле меня убивает, так это то, что я не ощущаю, что занимаюсь тестированием.
- Я не шучу. На это нет времени. Остаются только четыре клеточки в неделю. Плюс, то, о чем ты уже говорил - тонны багов, которые не относятся к настройкам и целенаправленному тестированию.
- Это так. Когда дело доходит до тех вещей, которые на самом деле нуждаются в тестировании, в них тоже находится множество багов. Таким образом, мое время на тестирование - не чистое тестирование. Это в основном время, потраченное на то, чтобы воспроизвести и задокументировать баг.
- Да. В сессионном тестировании, это исследование и документирование бага - Б-время. И оно прерывает время на дизайн и выполнение теста - Т-время - которое создает актуальное покрытие тестами и позволяющее изучить, что в самом деле происходит в продукте. Так, сколько занимает Б-время?

Петр поставил букву Б в три из четырех клеток.

- И, наконец, Т-время?

У Петра осталось только место для одной буквы Т в правом нижнем углу.

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

- М-да, я никогда не смотрел на эту проблему таким образом. И затем, - Петр остановился. - Они спрашивают меня, почему я не обнаружил этот баг?
- Хорошо, -  сказал я, - учитывая заблуждение, в котором они, скорее всего, находятся, вопрос небезосновательный.
- Что ты имеешь в виду? - спросил Петр.
- Что написано у тебя на визитке?
- Тестирование ПО.
- Что написано у тебя на двери твоей тестовой лаборатории?
- Тестовая лаборатория - ответил Петр.
- И они называют тебя...
- Петр.
- Нет! - я улыбнулся. - Они говорят, что ты ... кто?
- Тестировщик.
- Итак, с того момента, как ты тестировщик, на двери у тебя написано "тестовая лаборатория", на визитке - "тестирование", они полагают, что тестирование - это все, что ты делаешь. Это заблуждение, которое Джерри Вейнберг называет проблемой укрупнения. Все из перечисленных активностей - административная работа, установка, исследование и документирование бага, проектирование и выполнение тестов, - для них это одна большая идея. И я нарисовал ее Петру.

- Это заблуждение менеджмента. С того момента как, в их воображении, у тебя есть сорок часов на тестирование в неделю, и для них это нормально - спросить, почему ты не обнаружил этот баг.
- Хммм... Так и есть. - согласился Петр.
- Когда в реальности они получают это. И я нарисовал для Петра.

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

Несколько дней спустя, я показал эту страницу из блокнота Джеймсу Баху.

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

А как обстоит дело у вас?

Майкл Болтон, 30 октября 2012 года.

Тестирование и проверка - перевод статьи Майкла Болтона.

У меня для вас очередной сюрприз - я представляю вашему вниманию свой перевод очень известной статьи Майкла Болтона "Тестирование и проверка" (Michael Bolton "Testing VS checking"). Работа оказалась довольно продолжительной, но очень интересной и насыщенной, богатой новыми впечатлениями и получением нового ценного опыта.

Большое спасибо моей сестре Лизе Ладутько - за помощь в переводе и придание ему более литературной формы :) Если вы не читали статью - рекомендую восполнить этот пробел прямо сейчас, если читали и знакомы - буду признателен за ваши отзывы - баг-репорты и улучшения, которые помогут сделать перевод качественнее.

Ссылка на оригинал  - http://www.developsense.com/blog/2009/08/testing-vs-checking/
Формат текста (выделение терминов, курсив, цитирование) и ссылки на другие статьи из текста взяты с оригинала "как есть".

Эта статья раскрывает тему моего блиц-доклада на конференции Agile 2009. Я выражаю огромную благодарность Арлу Бельши (Arlo Belshee) и Джеймсу Шору(James Shore) за помощь в воплощении идеи в реальность. Также я хочу сказать «большое спасибо» программистам и тестировщикам за огромную поддержку моего доклада и моей идеи. Особую благодарность я выражаю Джо Рейнсбергеру (Joe (J.B.) Rainsberger). Распространите этот мем!

P.S. На протяжении многих лет люди неверно истолковывали эту статью как отказ или от проверки, или от регрессионного тестирования, или от автоматизированного тестирования. Вдобавок к этой статье, для лучшего понимания вам также необходимо прочитать (http://www.developsense.com/blog/2009/11/merely-checking-or-merely-testing/ ).

P.P.S. С момента публикации прошло довольно много времени, этот пост достаточно старый. В течение последующих нескольких лет после того, как он был опубликован, я дополнил мои исследования данной темы, в основном благодаря сотрудничеству с Джеймсом Бахом. Наши размышления на эту тему появились в блоге Джеймса, а я разместил свой ответ здесь. В усовершенствовании процессов нам помогли вопросы и комментарии коллег. Мы просим вас прочитать их комментарии и оставить свои (Апрель 2013).

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

Проверка – это подтверждение.

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

Тестирование - это исследование и изучение.

Тестирование – это то, что мы делаем с целью найти новую информацию. Тестирование – это процесс поиска, открытия, исследования и изучения. Когда мы настраиваем, используем и исследуем продукт с целью оценить его или с целью опознать неожиданную проблему, мы занимаемся тестированием. Мы тестируем с целью обнаружить границы и ограничения продукта и его дизайна, и когда нами движет вопрос, на который до этого момента не было ответа, или который вовсе не поднимался. Как говорится в наших с Джеймсом Бахом группах «Быстрое тестирование классов программного обеспечения», суть тестирования заключается в изучении всего, что важно, чтобы знать, как программа работает и при каких условиях программа может не работать.

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

Проверка даёт бинарный результат – «истинно» или «ложно», «да» или «нет». Проверка задаёт и в то же время отвечает на вопрос «Это утверждение истинно или ложно?». Для этих простых утверждений достаточно использование компьютера, и такие утверждения нейтрально оценочные.

Тестирование содержит открытый результат. Тестирование задаёт и в то же время отвечает на вопрос «Есть ли здесь проблема?». Ответ на такой вопрос требует большого количества наблюдений человека в сочетании с большим количеством оценочных суждений.

Когда проходит проверка, мы не знаем, работает ли программа, мы знаем только то, что она работает в границах наших ожиданий. В программе могут быть серьёзные проблемы даже если проверка успешна. Перефразируя Дейкстру, можно сказать, что "проверка может показать наличие ошибок, но не их отсутствие". Машины могут распознать несоответствия и проблемы, на которые они были запрограммированы для распознавания, но не новые проблемы. Тестирование также не отвечает на вопрос, работает ли эта программа – оно не способно отвечать на такие вопросы – но тестирование может давать основу для весомого заключения для ответа на вопрос: «Есть проблема или ее нет?».

Тестирование, в свою очередь, отвечает на вопрос «Достаточно ли хорошо была проведена проверка?». Когда в процессе тестирования мы обнаруживаем ошибку, единственным разумным решением здесь будет написать одну или несколько проверок, чтобы убедиться, что эта же проблема не появилась снова.

Будем ли мы автоматизировать процесс или нет, если бы мы могли сформулировать вопрос так, чтобы машина смогла задать и ответить  на него через утверждение, это почти точно будет проверка. Если же для проведения этой работы необходим человек, если эта работа интеллектуального характера, это, скорее всего, тестирование. В самом начале своей статьи  «Разумные процессы», Джеймс Бах сказал «Я занимаюсь тестированием программного обеспечения. Я слышал от многих людей, что они занимаются тем же делом, что и я. Иногда, после того, как эти люди говорят об автоматизации тестов, мне начинает казаться, что они занимаются не тем же делом, которым занимаюсь я. И это так, потому что, на мой взгляд, то, что делаю я, невозможно автоматизировать в самом полном значении этой фразы. И я спрашиваю сам себя: «Какого черта они что-то автоматизируют?!». И тут же отвечаю «Они автоматизируют проверки».

Когда мы говорим о «тестах» на каком бы то ни было уровне, в которых мы делегируем решение "Да или Нет" машине, мы говорим об автоматизированных проверках. Я предлагаю называть «модульные тесты» "модульными проверками". По этой же причине, я предполагаю, что автоматизированное приемочное тестирование (Рон Джеффрис ссылается в своём блоге в статье Автоматизация историй «тестами») должно быть известно как "автоматизированные приемочные проверки". Это предложение появилось, чтобы оживить группу опытных программистов и тестировщиков на воркшопе конференции Agile 2009, о чем я расскажу вам поподробнее в следующем посте блога.

Тестирование - это не контроль качество, проверка - может быть.

Вы можете подтвердить качество чего-либо, над чем у вас есть контроль; это означает, что вы можете предоставить некоторый уровень качества - соответствие некоторым требованиям, и вы можете взять ответственность на себя, если продукт не удовлетворяет этим требованиям. Если у вас нет прав, чтобы изменить что-либо, вы не можете гарантировать качество, хотя вы можете оценить уровень качества и сообщить о найденной проблеме (см. страницы 6-7 этой статьи, в которой Сэм Канер объясняет различие между тестированием и контролем качества и ссылается на отличный набор вопросов от Джоанны Ротман, который поможет вам обнаружить различие между ними). Тестирование - это не контроль качества, но действует в его интересах; мы предоставляем информацию программистам и менеджерам, которые наделены полномочиями принимать решения.

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

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

Проверщикам нужна спецификация, тестировщикам - нет.

Тестировщик, по словам Джерри Вайнберга, это "кто-то, кто знает, что вещи могут отличаться" (things can be different (c)). Как тестировщики, наша работа - поиск инорфмации, которая зачастую представляет разницу между тем, как думают люди и тем, что верно на самом деле. (определение тестирования Сэма Канера включает в себя вышесказанное: "Тестирование - это эмирическое, техническое исследование продукта, выполняемое заинтересованными сторонами с целью выявления информации про качество такого типа, который они ищут".)

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

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

Тестирование VS Проверка - это дырявая абстракция.

Джоэл Спольски назвал закон о ценных движениях системы Законом Дырявых Абстракций ("Все нетривиальные абстракции, в некоторой степени, дырявые.") В процессе разработки продукта мы можем быстро переключаться между тестированием и проверкой. Различие между ними находится непосредственно в нашей мотивации. Давайте рассмотрим несколько примеров.

• Программист, который пишет новый код и исследует новое проблемное поле. В его понимании, есть ситуация, которую нужно обработать. Он пишет утверждение - проверку. Затем он пишет код, чтобы утверждение прошло успешно. Утверждение не проходит успешно, тогда разработчик переписывает код. Проверка все равно не проходит. Программист обнаруживает, что его первоначальное предположение о проблеме было неполным, поэтому он меняет утверждение, и дописывает код. В этот раз проверка проходит успешно, что означает, что утверждение и код приложения согласованы. У него появляется идея - дописать еще код, и он снова повторяет свой алгоритм - сначала пишет проверку, затем - код, для того, чтобы проверка прошла успешно. Он также удостоверяется в том, что предыдущая проверка также работает. Затем, он видит, как код может "упасть", если ввести другое значение. Он уверен, что код пройдет успешно, но он пишет новую проверку, чтобы удостовериться в этом. Проверка проходит успешно. Он пробует другие входные значения - тест падает, и программист вынужден исследовать проблему. Он сознает свою ошибку, и использует полученное знание для новой проверки; затем он пишет функциональный код, чтобы исправить проблему и чтобы проверка прошла успешно. Таким образом, данный процесс - в значительной мере, исследование. Несмотря на то, что она продолжает использовать проверки для продолжения процесса, его фокус направлен на изучение, исследование проблемного поля, обнаружение проблем в коде и разбор  этих проблем. В этом смысле, он тестирует и программирует. В конце этого всплеска разработки, он получил работающий код, который пойдет в версию продукта. В качестве положительного побочного эффекта, у программиста появился кусок кода, который поможет ему выполнить автоматические проверки, если функциональный код будет изменен. Марк Симпсон, программист, с которым я беседовал на конференции Agile 2008, сравнил этот циклический процесс с расчисткой тропы в зарослях, прорубанием нового пути через проблемное поле. Есть множество путей, по которым ты можешь пойти, и ты расчищаешь заросли неопределенности вокруг себя в попытке добраться туда, куда направляешься. Исторически, этот процесс называется "разработка через тесты" (Test Driven Development, TDD),  с маленькой поправкой - в разработке через тесты, "тесты" - на самом деле, проверки. Хотя это может быть трудно, и даже несправедливо, доказывать, что в общем-то, весь этот процесс, в большей мере, не исследование. У программистов, работающих по TDD, есть цель, но путь к этой цели не всегда очевиден. Если вы знаете точно, куда идти и как вы намереваетесь идти, вам придется исследовать.  Название "разработка через поведение" (Behaviour Driven Development, BDD) отчасти наводит порядок в этой неразберихе, но оно еще не получило широкое распространение. Разработка через поведение использует проверки в форме "(Программа) должна...", но процессу разработки необходимо тестирование идей по мере их формирования.
• Затем наш программист просматривает код и обнаруживает, что имя одной из переменных не "говорящее", что одна строка кода должна быть более читабельна и сопровождаема, если ее переписать в две строки, что группа из трех строк можно переписать более красиво и понятно, используя цикл. Он решает отрефакторить код и обращается к решению этой проблемы - запустить проверки после каждого изменения. Его цель при запуске этих проверок - не исследование, а подтверждение, что ничего не было сломано. Он не пишет новые проверки, он вполне уверен, что старые справятся с этой задачей. В этом случае, она не тестирует продукт, она проверяет свою работу.
• Большинство книг по традиционному "тестированию" утверждает, что "тестирование" это процесс валидации и верификации, как будто мы уже заранее знаем, как должен работать код. Хотя тестирование включает в себя проверку, программа, на которой были выполнены только проверки, скорее всего, недостаточно протестирована. Большинство литературы по тестированию фокусирует внимание на корректности - которая может быть проверена - и игнорирует тот факт, что необходимо задавать более глубокие вопросы о значениях, которые должны быть протестированы. Например, то, что называется "тестирование граничных значений" - обычная "проверка граничных значений". Классический пример программы, которая проверяет сложение двух двузначных целых чисел, в котором значения находятся в допустимом интервале от -99 до 99, а все значения вне пределов интервала отбрасываются. Классический совет, как "протестировать" такую программу, направлен на граничные условия, звучит как "Попробуйте -99 и 99 чтобы убедиться, что допустимые значения обрабатываются, и попробуйте -100 и 100, чтобы проверить, что недопустимые значения не обрабатываются. " Я бы хотел поспорить, что эти "тесты" настолько слабы, поэтому должны называться "проверками"; они крайне очевидны, они направлены на подтверждение, они направлены на исход, а не на результат, и могут быть легко автоматизированы. Если вы хотите протестировать подобную программу, сам следует настроить, поработать, рассмотреть продукт внимательно, с учетом и других рисков, включая не совсем очевидные, которые могут оставаться незамеченными, пока не проявят себя. Вы должны быть готовы рассмотреть все, что может повлиять на ценность продукт - проблемы, связанные с производительностью, инсталляцией, удобством использования, тестируемостью и другими критериями качества. Вам следует изменять свои тесты, а не повторять их. Вам следует быть любознательными, и выполнять некоторые тесты, не связанные с вашей текущей моделью рисков и угроз, с целью обнаружить непредвиденные риски. Вы можете использовать автоматизацию как помощник в исследовании; например, для генерации данных, для отслеживания покрытия, для разбора лог-файлов, просматривать реестр файловой системы для поиска непредвиденных последствий. Даже если вы используете автоматизацию с целью нажимать клавиши за вас, вам следует использовать автоматизацию для исследования, вы должны быть готовы изменять направление исследований и тактику, когда тест вам выдает неожиданный результат.
• Исследовательское мышление использует вопросы наподобие "Что, если...?", "Мне интересно, ...?", "Как эта вещь...?", "Что произойдет, если я...?" Даже если мы тестируем программу, используя строгий подход к исследованию, мы дополнительно задействуем новые идеи, как это должно работать. "Если я нажму кнопку Отмена, диалоговое окно закроется", "Это поле запрашивает ЗИП-код в США, следовательно, это поле должно позволять вводить как минимум 5 символов", "При двойном клике по "foo.doc", файл должен открыться в программе Microsoft Word". Тестировщики-профессионалы использует эти и другие утверждения как сами собой разумеющиеся. Мы даже можем их сознательно не называть проверками, но мы подсознательно проверяем во время своего исследования и изучения программы. Если одна из проверок выполнится с ошибкой, мы наверняка получим подсказку в поиске новой информации, или если поведение программы кажется правильным, мы изменим наше представление о том, как программа должна работать. Это эвристический процесс (подверженный ошибкам означает, что при решении проблем или принятии решений, мы обучаемся, и эвристика обычно работает, но может и не работать).
• Также на конференции Agile 2009, Крис МакМахон показал презентацию "История большого проекта автоматизации с помощью Selenium". Он описал подход с использованием тысяч автоматизированных проверок (он называл их "тестами") с целью обнаружить проблемы в приложении с помощью тестирования. Как описать разницу? Опять-таки, различие - это одна из мотиваций. Если вы запускаете тысячи автоматизированных проверок с целью показать, что у вас сегодня все работает, как и вчера, вы проверяете. Хотя, вы можете использовать тысячи автоматизированных проверок другими способами. Если вы пытаетесь ответить на новые вопросы, например "что случится, если мы запустим наши проверки на 30 машинах одновременно, чтобы нагрузить сервер?" (мы выполним стресс-тест), или "что может случиться, если мы запустим все проверки на другой платформе?" (мы выполним тестирование совместимости), или "что будет, если мы запустим автоматизированные проверки 300 раз подряд?" (тестирование последовательности), проверки помогут нам в тестировании (что будет замечательно в этих ситуациях).

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

Майкл Болтон, 29 августа 2009 года.