В принципе можно «увидеть» в космосе и тот свет, который был испущен условные 13,8 миллиарда лет назад после Большого взрыва — реликт горячего периода появления сегодняшнего мира. Этот «свет от начала времён» так и называется: реликтовое излучение.

Реликт: организм, вещь или явление, сохранившиеся как пережиток от древних эпох, от лат. relictus — оставленный.

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

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

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

А ничего они не знали. Технологии появляются и исчезают, ничего не предсказуемо и не определено (привет опытным разработчикам на Pascal, Delphi, Fortran). И так бывает, что какие-то маргинальные штуки из прошлого становятся сегодня ценными, и их адепты взлетают в спросе. Начинает казаться, что они что-то знали…

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

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

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

Надо уметь ездить на велосипеде вообще, а не только на определенной модели.

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

Смартфоны наши тому примером.

На короткой дистанции выигрывают те, кто игнорирует «как и почему» в пользу «здесь и сейчас».

В долгой гонке выигрывают те, кто зачем-то, из непонятного интереса, отстают, отходят от бегущих, начинают «копать к первоисточнику» и в какой-то момент понимают, как и почему всё устроено. И зачем. Вот им открываются чит-коды, обходные пути и возможность предсказывать перспективные направления. Остальные продолжают бежать.

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

Движение в будущее

А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — садись и слушай. Однажды, давным-давно…

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

Ну, и чо?

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

Когда я сам проектировал тесты, да ещё и для какой-то финансовой аппликухи — приходилось знать/понимать точно, какие тесты покрывают прописанные требования (верификационные), а какие тесты покрывают НЕпрописанные требования (валидационные) и соответственно их разделять по разным сборникам тестов. И это всё стало осязаемым и важным.

Верификационные тесты, с отсылками к требованиям, программисты принимали, не каркая.

А валидационные запросто отклоняли, бо «тестируется сценарий, которые не предусмотрен требованиями».

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

Если в этот момент юзер решит вернуться на шаг назад — он должен передвигаться между экранами только через JS-кнопки «back» и «forward» в приложении (почти каждый современный сайт — приложение). Так написано в требованиях, так реализовано программистами.

А если нажать на кнопку [Back] в браузере — всё поломалось.

Это очевидно для пользователя? Нет.

Пользователь может нажать на кнопку [Back] в браузере? Может.

И получит белый экран, и все данные пропали? Получит. Вот скриншот. Вот видео. Давайте чинить!

Ответ: Declined (out of requirements).

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

А понимал бы я тогда разницу между верификацией и валидацией…

«…я, может, и не женился бы» © бородатый папа дяди Фёдора

Глава вторая, патетическая, в которой шахматист ВНЕЗАПНО понимает, кто придумал защиту Тартаковича

А теперь будет ход конём.

Или про шахматы тоже надо отдельно объяснять?!

Поскольку мы занимаемся только тестированием и игнорируем всю остальную Computer science (нам о ней на курсах не докладывают!), то может показаться, что вся эта верифилидация — сугубо тестерское дело, которое относится только к тест-кейсам.

Нет.

Это всё приходит к нам из предыдущего этапа, на котором кто-то придумывает требования.

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

И нет, тут подразумевается не покрытие требований тест-кейсами (это всё делается позже, как правило, нами), а проверка требований разными аналитическими инструментами.

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

Ещё в прошлом веке человечеству было известно, что сами требования можно и нужно тестировать с помощью — и вот этот ход конём! — тех самых понятий Verification & Validation. Ёпт!

Об этом подробно написано в книге Karl Wiegers „Software Requirements“ (third edition) на стр. 331.

Где взять эту книгу — а проверь свои гигабайты скачанных, но не прочитанных книг, наверняка она там есть. Или глянь Amazon.

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

* Не дёргаемся, это единственно точное слово для описания того перевода.

В той же книге Вигерса на стр. 347 написано про Validating requirements with acceptance criteria. Знакомый термин? Он тоже кажется сугубо тестировщицким? 🙂

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

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

Тестировщику надо уметь прорабатывать требования? Надо.

Для этого надо быть аналитиком? Нет.

Важно уметь не подменять простую логику («я прочитал требования») с той самой аналитикой («я изучил требования»).

Совершенно ненужный эпилог

«Мы считаем сумасшедшими тех, кого не понимаем, и дураками тех, кто не понимает нас.

Поэтому сумасшедшие считают всех дураками, а дураки – сумасшедшими» ©

You know it’s sad but true.

Бен Коллинс — Водить как Стиг

В поезде лежал, книгу читал «Водить как Стиг» Бена Коллинса (второе издание, Альпина нон-фикшн, Москва, 2018).

Высокое качество печати и оформления, отличный текст, но все-таки четыре ошибки в тексте нашел, из них две совершенно нелепые. Глаз в бревне царапает, ну да ладно.

А вот на стр. 155 разверзлись хляби подземельные, и стало ыыыы:

Санитарная проверка

Вах-вах-вах, не может же быть же…

Поискал оригинал… Оказывается, может.

Sanity check

Короче, нет никакого санитарного тестирования.

Само слово Sanity переводится на русский язык проще:

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

Нет там никаких санитаров.

То, что вы называете Sanity, по-сути есть Smoke testing.

Я ещё не знаю, когда эти термины появились, но уже давно ясно, что это два разных названия одного и того же феномена. Просто тестировщики называют это Smoke, а программисты называют это Sanity. Так они привыкли, так оно укрепилось в их литературе.

Судя по моему опыту чтения старых книг для программистов, sanity было первым.

Канер в своей книге Testing Computer Software (1988, у меня второе издание, 1999-го) не упоминает ни про smoke, ни про sanity. Самое близкое к ним есть в главе 3 ‘Test types & Software development‘ на стр. 51, и ВНЕЗАПНО оно там называется «Acceptance testing»:

Each time you receive a new version of the program, check whether it’s stable enough to be tested. If it crashes at the slightest provocation, don’t waste your time on it. This first bit of testing is called acceptance or qualification testing.

На стр. 54 та же тема с уточнениями в разделе ‘Final acceptance testing and certification‘:

If your company developed the program on contract, the customer will ran an acceptance test when you deliver it. In small projects, this test may be informal. For most projects, however, test details are agreed to in advance, in writing. Make sure the program passes the test before trying to deliver it to the customer. An acceptance test usually lasts less than a day. It is not a thorough system test. Beizer (1984) describes the preparation and execution of formal customer acceptance tests. Perry (1986) is, in effect, a customer’s guide to creating acceptance tests. Consider using Perry (1986) to structure your negotiations with the customer when you jointly design the acceptance test.

Цитата на books.google.com

Для тех, кто не может прочитать больше одного предложения в абзаце перевожу:

заранее и письменно согласуйте с заказчиком набор приёмочных тестов. Убедитесь сами в том, что релиз на них не завалится. Ранее об этом писали Бейзер (1984) и Перри (1986).

Это воспринимается странно, бо в наше время «Acceptance testing» объясняется как «Заказчик сам тестирует, как хочет». И да, вероятно, он будет основываться на наших смоук-тестах. Предполагаю, что в наше время этот термин просто истолковывается неверно, но это уже не существенно.

А вот в 2001-ом Канер уже упоминает Smoke testing в «Lessons Learned in Software Testing: A Context-Driven Approach» на страницах xxvi (это предисловие, там сходу заявлены определения ключевых терминов), 41, 121, 162, 163, 169, 141 и 144. И ни разу не упоминается sanity testing.

Рекс Блэк в «Ключевые процессы тестирования» (2004) упоминает эти два термина одновременно. В русскоязычном издании «Лори» 2006-го года они на стр. 532:

Приемочное тестирование, тестирование на исправность (Smoke Test, Sanity Test). Тестирование, проверяющее, насколько стабильная предлагаемая на тестирование версия, чтобы можно было начинать штатное тестирование. Обычно это подмножество всего комплекта тестов, как правило, автоматизированное, затрагивающее все части системы, по крайней мере, поверхностно. Качественные приемочные тесты обычно довольно долго проверяют работу системы, чтобы проявились серьезные проблемы надежности и работоспособности. Термин “smoke test” (тест на задымленность) взят из электротехники: когда инженер включает цепь, первичный тест проверяет, не дымятся ли компоненты.

Википедия

ВНЕЗАПНО сообщает о том, что сэнити — даже не из мира тестирования, термин существует сам по себе, и применим ко всем аспектам человекодеятельности, от сервировки обеденного стола до запуска ядрённой атомной бомбы на головы мирных жапонцев.

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected. This is often prior to a more exhaustive round of testing.

Огромное, гигантское отличие от smoke test, да?!

ISTQB (скачать файл Glossary all terms 3.1.pdf).

Sanity test объявлен синонимом smoke test (стр. 61).

В канонах ISTQB вы не сомневаетесь, не так ли?!

Толковалка ISTQB

It is a kind of software testing which is done by the testers to ensure that the functionality is working as expected.

Огромная разница со smoke test, да?!

Кто-то сделал почти тот же обзор книг в поисках тех же терминов, что и я: almeln.github.io, и пришел к тем же выводам.

О переводах: «Да, но ведь гугл переводит это слово именно так!»

Google переводит слово Sanity

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

И напоследок. Я предполагал, что ебалайтунг с терминологией присущ нашему, русскоязычному сектору. Например, вон чего на protesting.ru пишут:

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование — это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны.

Но он процветает и на английской стороне. Быстро нагуглилась статья на эту тему с сайта h2kinfosys.com — оба термина представлены как нечто обособленное. Понятия не имею, что это за контора из штата Джорджия (США), но о себе они говорят «H2k Infosys provides world class IT Training, Real-time Live Project to gain hands on experience, and IT Staffing services».

Надо ли возражать людям вообще?

Приоритет показывает степень важности выполнения задачи ДЛЯ БИЗНЕСА.

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

Рекомендуется использовать всего три уровня приоритета:

1. Приоритетно,
2. Не приоритетно,
3. .

Все очень просто, не так ли? Или задача приоритетна, или нет. Tertium, кагбэ,  non datur.

Если еще более по-взрослому говорить, то приоритизация означает не простое «Давайте расположим все по-важности и будем выполнять последовательно». Оно означает необходимость от чего-то отказаться, чтобы выполнить самое важное [подробности], но это уже слишком сложные материи…

В Jira используется аж пять уровней приоритетности. Надо бы меньше, но мы все тут с Jira бесимся, поэтому будем следовать ее визионерству:

Trivial — Lowest priority, punctuation or any very small issues

In ‘Contact us’ Tahoma font displayed instead of Arial.

Nobody else see the difference. In the future this issue may be fixed. Or not, because nobody cares, this doesn’t broke the business.

Minor — Indicates that this issue has a relatively minor impact.

In the ‘Contact us’ form placeholder text in ‘Message’ field is displayed as ‘Italic’ instead of regular text.

This doesn’t broke the business, but it’s a little annoying to write and read all text in ‘Italic’. Please, can you fix it?!

Major — Indicates that this issue has a significant impact.

Sending message from the ‘Contact us’ form works well, but sender email is unknown.

Unanswered emails can lead customers to nervosity, this can affect whole business, so please, fix the problem in the most appropriate time limit.

Critical — Indicates that this issue is causing a problem and requires urgent attention.

‘Contact us’ page is unavailable.

This is a required functionality for the web store, this can have a bad impact on the business, so, Kowalski, fix the problem ASAP!

Blocker — This problem will block progress of the project.

Web store is down. ‘Contact us’ page unavailable.

User cannot open the ‘Contact us’ page, because the whole web site is down, the business is down, Kowalski, don’t panic, immediately grab the monkeys and act like the server, while we will bring him back online!

Severity

Суровость бага (ну, вы же не дураки, чтобы переводить “Severity” как невнятное “Важность” или “Серьезность“? Суровость!) показывает технологическую степень влияния дефекта на всю систему.

Внимание, на ВСЮ СИСТЕМУ, а не только на отдельно взятый сценарий или функциональность.

То есть, если при тестировании Wish List выясняется, что невозможно добавить товар в Wish List, но при этом остальные важные части веб-магазина в принципе работают, то не надо орать, что у тебя Blocker, только потому, что ты не можешь выполнить твой тест-кейсик. Оно блокер, но не для всей системы, а только для тебя одного.

Важно понимать, что реально суровые дефекты в функциях в современных веб-системах сложно обнаружить, бо современные веб-системы не состоят из цельных кусков хрусталя, который можно расколоть одним движением. Вы больше блокеров найдете в MS Word, чем в Joomla, просто потому, что какой-то хитрый баг может тупо закрэшить вам всю вордину, дальнейшие действия становятся невозможными, надо запускать ворд с нуля. А как «положить» интернет-приложение, построенное на микро-сервисах? Сервак раздолбать кувалдой… Или продумать какую-то троянистую шнягу, которая по цепочке пронесет с собой разрушительный скрипт, и всю эту цепочку будет последовательно уничтожать.

Поэтому в большинстве случаев мы используем Severity  = Major, а Blocker’ом величаем разве что какие-то важные и сложно-составные сценарии, которые по каким-то причинам очень важно пройти, но не удается.

Trivial — Minor loss of function, or other problem where easy workaround is present.

‘Contact us’ form text was designed with Arial font 14 size, but I see the Arial font 13 size instead.

This doesn’t affect the functionality at all. Anybody will care about it?

Major — Major loss of function.

User messages from ‘Contact us’ page are not received by Support team.

Everything else works fine, only this particular loss of functionality can severely affect the business issues. Kowalski, fix the problem!

Blocker — Blocks the interaction with the system, production could not run, crashes, loss of data, severe memory leak, everybody dies.

Web store become inaccessible because ‘Contact us’ script overload the server.

Server continuously restarts, nobody can access it, web store became inaccessible. This severely affect all business issues. Kowalski!

Кстати, для Severity лучше использовать побольше нюансов.

Кагбэ, да, но тогда почему это называется «Регрессионное тестирование», а не «Перетестировывание всего заново»?

«Заново всё тестируем» — это не объяснение сути обсуждаемого феномена! Это лишь описание внешних признаков сего феномена. Так ребенок может объяснить, что такое автомобиль, не понимая, как и почему вот это вот всё работает. Вроде «Автомобиль — это когда папа за рулём, он едет на работу, а я в детский сад, и мне удобно в нём сидеть». Всё правильно же?!

Кроме термина регресс еще есть термин регрессия — сам по себе термин неоднозначный. Это бывает и в психологии, и в финансовой аналитике, и это разные феномены ВААПЩЕ.

Значитца, так. В википедии правильно указана суть термина «Регрессионное тестирование» (англ. regression testing, от лат. regressio — движение назад), но дальнейшее объяснение недостаточно адекватно. Дитячее оно.

Давайте объясняться по-взрослому.

Есть понятие Прогресс.

Есть же…

А есть понятие Регресс — обратная сторона прогресса.

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

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

Любая ERP-система развивается по тому же принципу — все больше информации собирается и учитывается по каждому чиху. Отчёты все красочнее, объемнее, в запросах все больше ЕСЛИ и НО НЕ и КРОМЕ.

Однако увеличение функциональности незаметно приносит и увеличение взаимосвязей между функциями.

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

Это и есть регресс.

Чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование.

И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения.

Со стороны это выглядит как «Внесли новый функционал — обязательно перетестировываем всё!» Словно тестировщики в тысячный раз прогоняют уже существующие тесты, вот и всё.

Не всё. Этого недостаточно.

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

Смысл просто гонять старые тест-кейсы, если они были написаны без учета новых ситуаций?

Со временем старый функционал начинает плотно пересекаться с новым — и надо заново расчехлять аналитику, заново выявлять новые ситуации, которые могут возникнуть, заново писать тест-кейсы, которые затрагивают уже не столько функциональные, сколько интеграционные аспекты…

А «в интеграции» бытуют такие баги, о которых и не догадаешься, рассматривая функцию логина по-отдельности от остальных функций…

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

В любом проекте с какого-то момента начинается уже не улучшение продукта, а борьба за «чтобы оно всё еще продолжало работать, как раньше«… с постоянным выяснением, а не наступил ли регресс из-за усложнения системы.

В начале проекта ВООБЩЕ нет необходимости думать про регрессионное тестирование. В начале проекта даже тест-кейсами особо заморачиваться нет смысла.

Но чем дальше влез в лес…

Ещё в тему

Regression is my profession!

А дело в том, что функциональное требование это ‘A description of a behavior that a system will exhibit under specific conditions‘.

Продумывать ситуации, в которых может оказаться программа, и предусмотреть, как она должна из этих ситуаций выкручиваться — это ли не задача тестировщика?

Это.

На очень высоко абстрактном уровне все требования делятся на четыре слоя:

• бизнес-требования,
• пользовательские требования,
• функциональные требования,
• всё, что угодно, что попадает под понятие «нефункциональные требования».

Дальше начинается преданье, дальше начинается ересь от «По-моему, под функциональными требованиями подразумевается, что…» до «Шо вы мине голову морочите вашими требованиями, возьмите и напишите их себе сами, если они вам так нужны…»

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

В алфавитном порядке толкование самых толковаемых терминов:

Business requirement

A high-level business objective of the organization that builds a product or of a customer who procures it. Это «Хотелки», которую ещё нужно правильно отобразиться в функциональных требованиях (коих может быть больше, чем одно), которые в свою очередь должны превратиться в спецификации.

Неприятность в том, что хотелки дают ответ только на вопрос «Зачем нужно что-то делать?», а большинство считает, что «Чё там валандаться по одному порошку в день, ох, тьма египетская в глазах…», и подразумевают, что хотелки будут рассказывать и зачем, и как это надо реализовать. Как же, читай потом этих доку-монстров…

Business rule

A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.

Constraint

A restriction that is imposed on the choices available to the developer for the design and construction of a product.

Feature

One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. И попробуй теперь пересказать это своими словами, слабак.

Functional requirement

A description of a behavior that a system will exhibit under specific conditions. Ключевое слово — «ситуация».

Nonfunctional requirement

A description of a property or characteristic that a system must exhibit or a constraint that it must respect. То есть, нужно учитывать.

То есть, дураком буду, если скажу, что нон-фанкшынал рекуайрментс — это же не требования, бо есть же слово «нон».

Quality attribute

A kind of nonfunctional requirement that describes a service or performance characteristic of a product. Кто это учитывает?

System requirement

A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. Как такие требования пишутся?

User requirement

A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute. Не надо ждать, что пользователи придут, и предъявят свои требования. Будет очень плохо, если пользователи придут с требованиями.

© «Software Requirements» by Karl Wiegers and Joy Beatty, Third Edition, PUBLISHED BY Microsoft Press, ISBN: 978-0-7356-7966-5

Подогнался мне давеча рассужденьческий мотив от какой-то невиданной ранее дівчини. Её, кагбэ, полагается считать всеизвестной в украинских масштабах, но я её не знаю ни в упор, ни на отдалении. Сынам виноградных холмов это простительно — у нас свои знаменитости. Та же поподвижущаяся Шакира, например. Итак, слово достигшей большой светлости:

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

Представьте, припекло вам в туалет. Унитаз — цель. Вы бежите к нему сразу, не думая, получится, не получится — надо. Вы же не советуетесь ни с кем — а стоит ли, не собираете мнения — с…ть или не с..ть.

Почему нельзя так во всем остальном — если хочется чего то, просто идти к цели, мечте?»

Оно, конечно, удивительно, чего люди делают с унитазом, когда до него добегают…

Ок, принимаем идею о том, что всё зависит от мотивации. И от потребности.

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

Ооооо! Так теперь понятно, на Луне откуда пятна почему некоторые люди никогда не будут предпринимателями!

Оооо, теперь понятно, почему существуют вечные «люди-обслуга», которые подряжаются бегать рядом с владельцем бизнеса, но не способны бегать самостоятельно!

Теперь вообще всё просто и понятно!

В таком контексте становятся смешными всякие несущественные оправдания типа:

• нет времени сходить в туалет.
• да, конечно — завтра схожу…
• я не верил что смогу добежать.
• ну, конечно. Он то добежал. У него ноги вон какие длинные…
• я постучался в туалет — но мне не открыли…

То есть, тем, кто таки добежал, все преграды на пути к цели кажутся несущественными. И бегущих подбадривают, мол, давай, пацан, давай! Я бы на твоём бы месте бы не стерпел бы, бы! Двигай попой, оправданий нет! Я же стал тренером тестировщиков! И любой болван может им стать! Давай, жми педальки!

Ох…

Обобщение — зло, но упрощение — ещё хуже.

Дело в том, что всё зависит не только от мотивации и от потребности.

Всё зависит и от мотивации.

И от потребности.

И от понимания того, что до «туалета» вообще возможно добежать.

Достаточно просто осознать, что «бежать можно». Но дальше следует собираться, принимать решения, рисковать?

Это же очевидно глупо — рисковать, страдать, бояться, брать на себя больше необходимого, планировать невозможное, даже если результат обещается быть прекрасным…

Как же появляется понимание того, что бег не напрасный, и «можно добежать»?

Как «безрассудство и отвага» вообще может стать мотиватором?

Обращение с унитазом достигается за счет тренировки. Мы же в младенчестве не советовались ни с кем, что нам делать — с…ть или не с..ть, сразу всё делали, по-необходимости. А потом начали тренироваться и в сдерживании, и в беге, и в обращении со сложным гением сантехнической мысли.

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

Хотя, скорее, из случаев, которые формируют систему ценностей.

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

Большинство этого этапа были лишены, поэтому не верят. Как, например, ребенок не верит в то, что «чайник горячий» — обязательно надо руку сунуть, в кипяток.

Вообще, лучше всего бегают и устремляются и добегают не те, у кого есть потребность в туалете. В конце концов, туалет не является постоянной необходимостью. Это просто эпизод. Добегают те, кто УЖЕ бегают.

То есть, вознаграждаются те, для кого бег сам по себе является процессом, который ведёт к цели.

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

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

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

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

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

Тут следует поставить не точку, а ЖЫРНУЮ запятую, ведь ориентирование только на процесс является таким же вредным, как и ориентирование только на цель, но кто ж досюдова дочитает-то…

Лучше послушаем хороший джазовый стандарт

Это прекрасная тема для обсуждений и трепа на ДОУ в любом приличном обществе. Каждому понятны плюсы и профиты подобного ревью.

Ведь правда же?

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

Нетрудно представить это полотно Айвазовского: офис (плюс регионы) переполнен креативными, талантливыми людьми, которые постоянно хотят развиваться и постоянно эту свою хотелку развивают, но когда эти стремления предлагается письменно зафиксировать как долгосрочное соглашение между компанией и развивальщиком…

Например, небывалые сложности вызывает вопрос «Какие свои навыки в тестировании ты именно планируешь развивать на протяжении следующих шести месяцев?»

Сложно, да?

Попробуем по-другому: «Чего ты вообще хочешь? Кем ты хочешь стать?»

Ыыыыыы… 😉

Нередкий ответ: «Ну, я хочу прочитать книгу про нагрузочное тестирование…»

— А нафига оно тебе?

«Нуууу, я хочу стать более профессиональным тестировщиком, чем сейчас…»

— А в функциональном тестировании ты уже все Джомолунгмы покорил? И как часто ты будешь заниматься нагрузочным тестированием на своем проекте? Оно у вас вообще применяется?

«Нет, не применяется, но…»

Ладно.

Есть отличный рецепт.

Ложись на кушетку, один час стоит $300, приступаем.

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

Пересчитай свою наличность.

300 гривен?

Гуд.

Отложи 10% (от щедрот наших оставим тебе немного на такси).

Что ты хотел написать в своем плане? «Прочитать книгу про нагрузочное тестирование».

Гуд.

За твои 270 гривен я выполню любую задачу из твоего перформанс плана.

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

Было написано «прочитать книгу про нагрузочное тестирование…» Отлично — вот, я ее прочитал. Условие выполнено. Давай 270 гривен из твоего личного правого кармана.

Прозреваем?

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

Следует же записать явную задачу: «хочу сделать нагрузочное тестирование нашего проекта; для этого мне надо научиться делать нагрузочное тестирование; для этого я прочитаю такую-то книгу (к такому-то сроку)».

А для этого надо понять, чего ты в действительности хочешь…

Если твоя цель стыкуется с потребностями компании, то все будет ок, записывай ее в перформанс план.

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

Профит понятен?

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

«А почему тогда некоторые компании развивают?»

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

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

Понятно?

Гуд.

Очистить кушетку, пригласить следующего.

Повсюду под предложением «Expected: alert» подразумевается, что ответ должен быть отрицательным, но система должна как-то сигнализировать юзеру о причине проблемы.

Регистрация нового пользователя

1. Зарегистрировать нового пользователя с логином new_user. Expected: можно.
2. Зарегистрировать нового пользователя с логином new_user_test. Expected: можно.
3. Зарегистрировать нового пользователя с логином new-user. Expected: можно.
4. Зарегистрировать нового пользователя с логином new1234user. Expected: можно.
5. Зарегистрировать нового пользователя с логином new@user. Expected: alert.
6. Зарегистрировать нового пользователя с логином newuser и паролем newuser (полное совпадение). Expected: alert.
7. использование только ASCII символов в логине – Expected: alert.
8. регистрация пользователя с логином, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
9. регистрация пользователя с паролем, содержащим пробелы или состоящим из одних пробелом – Expected: alert.
10. регистрация пользователя с логином содержащим XSS или SQL injections. – Expected: alert.
11. а можно ли зарегистрировать пользователя «admin», и пользователя «аdmin» (где а – из русской расскладки)?
12. В некоторых случаях разработчики проверяют пользователя в базе с помощью LIKE, и не обрабатывают user input. Поэтому нужно проверить комбинацию %%%/%%% (знак % повторяется 3 раза, чтобы обойти валидацию на минимальную длину).
13. Логин под существуюшим пользователем — смена пароля:
    1. Создать аккаунт с максимально возможным числом символом в логине
       1. Попробовать залогиниться
       2. Попробовать сменить пароль
       3. Причина: возможно несовпадение максимумов между строками ввода нового пароля, ввода пароля, смены пароля, и в БД.
          1. Дополнительно: проделать те же шаги, но с количеством символов макс+1
          2. Дополнительно: проделать те же шаги, но
             1. с макс. количеством разрешенных символов + пробел (и другие безобидные);
             2. с макс. количеством разрешенных символов + 1 запрещенный.
    2. Создать аккаунт с максимально возможным числом символом в пароле
    1. 1. Попробовать залогиниться
       2. Попробовать сменить пароль (а может — и сам логин?)
       3. Причина та же: возможно несовпадение максимумов между строками ввода нового пароля, ввода пароля, смены пароля, и в БД.

Ввод некорректных данных

1. Ввeсти корректный логин и корректный пароль. Expected: успешно залогинен. Разлогиниться. Почистить кэш и куки (открыть/закрыть браузер?).
2. Оставить оба поля пустыми. Нажать на Login. Expected: alert.
3. Оставить пустое поле login. Нажать на Login. Expected: alert.
4. Оставить пустое поле password. Нажать на Login. Expected: alert.
5. Ввeсти корректный логин и некорректный пароль. Expected: alert.
6. Ввeсти некорректный логин, но корректный пароль. Expected: alert.
7. Ввeсти некорректный логин и некорректный пароль. Expected: alert.
8. В поле логина ввeсти корректный пароль, а в поле пароля ввести корректный логин. Expected: alert.
9. Ввeсти логин <script>alert(123)</script> и корректный пароль. Expected: alert.
10. Ввeсти в поле логина SQL запрос (‘ or ‘a’ = ‘a’; DROP TABLE user; SELECT * FROM blog WHERE code LIKE ‘a%’;)   — структура запроса зависит от DB.
11. Ввeсти в поле логина скрипт (<script>alert(«Hello, world!»)</alert>, <script>document.getElementByID(«…»).disabled=true</script>)
12. Ввeсти в поле логина html-теги (<form action=»http://live.hh.ru»><input type=»submit»></form>)
13. Ввeсти в поле логина сложную последовательность символов вроде «♣☺♂» , «»‘~!@#$%^&*()?>,./\<][ /*<!—«», «${code}»;—>
14. Ввeсти в поле логина текст состоящий из одних пробелов;
15. Ввeсти в поле логина правильный логин, начинающийся с нескольких пробелов, и правильный пароль. Expected: alert.
16. Ввeсти в поле логина правильный логин, после которого следуют нескольких пробелов, и правильный пароль. Expected: alert.
17. Ввeсти корректный логин и корректный пароль. Нажать на кнопку «Назад» в браузере. Expected: непонятно — или The page should be expired, или увидеть те же поля. Если второе — ввести в поля снова логин и пароль. Перейти. Залогинен?
18. Ввeсти корректный логин. Указать пароль с использованием букв РАЗНОГО регистра.
19. Ввeсти логин с использованием букв РАЗНОГО регистра. Указать корректный пароль.
20. Зарегистрировать пользователя с логином VasEA. Expected: можно. Попытаться залогиниться, используя в логине буквы только одного регистра (vasea). Expected: можно.
21. Зарегистрировать пользователя с логином petea/iZMaIL. Expected: можно. Попытаться залогиниться, используя в пароле буквы только одного регистра (petea/izmail). Expected: alert. Алерт должен указать на причину?
22. Проверить ограничение на длину логина и пароля при регистрации? Ввести  qqweqweqweqweqweqweqweqweqweqweqweqweqweqwe / qqweqweqweqweqweqweqweqweqweqweqweqweqweqwe
23. Ввести логин/пароль Aa!@#$%^&*()-_+=`~/\,.?><|b / PaSSword!@#$%^&*()-_+=`~/\,.?><| Есть ли ограничения на допустимые символы?
24. Ввести логин/пароль Иван/Болван Возможно ли создание имени/пароль с например кириллицей, если да — то как потом эта форма отрабатывает?
25. Ввeсти логин ksjdksbdshdoueywfgjwevflwjeyfvowyecsydcvsldc (несуществующий в базе), оставить поле пароля пустым. Expected: such user doesn’t exist.
26. Открыть первый бразуер. Залогиниться валидным юзером. Открыть второй браузер. Залогиниться тем же самым валидным юзером. Expected: можно. Разлогиниться в первом браузере. Expected: можно. Перейти во второй браузер. Сделать что-нибудь, что может сделать только залогиненный юзер. Expected: можно.
27. Открыть браузер. Ввести в поля валидные данные. Нажать на кнопку Login. Отключить интернет. Получить «страница недоступна». Подключить интернет обратно. Зайти на сайт. Expected: не залогинен.
28. Блокируется ли акаунт/IP того, кто введет n-количество раз не правильный пароль?
29. Установить фокус на поле логина. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на поле пароля. Ввести текст. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на галочку «remember me». Нажать кнопку Space на клавиатуре. Expected: появилась галочка. Нажать кнопку Tab на клавиатуре. Expected: фокус перемещается на кнопку Login. Нажать кнопку Enter на клавиатуре. Expected: процесс пошёл.
30. User should be a registered user with his/her account expired.    Clicks on the Login button.
31. A message should appear stating ‘Your account has been expired’.
32. Проверка на ‘Remember me on this computer’. Заполнить поля валидными данными. Чекнуть галочку Remember me. Залогиниться. Закрыть браузер. Открыть бразуер. Открыть страницу сайта. Expected: логин для входа не требуется.
33. Ввести логин существующего пользователя, обрамив его уголками: <userlogin>. Причина: иногда валидатор вырезает запрещенные символы и проверяет остаток, однако после прохождения проверки передает дальше оригинальную строку.

Смена/удаление логинов

1. В базе или настройках сайта указать, что срок годности определенного логина истек. Залогиниться под этим логином. Expected: Alert.
2. Залогиниться под корректными логином/паролем. Сменить пароль. Залогиниться под новым паролем. Expected: пароль сменен, можно зайти.
3. Смена пароля и заход под старым
   1. запомнить пароль
   2. войти в систему
   3. поменять пароль
   4. разлогиниться
   5. залогиниться обратно со старым паролем. Expected: не пускает.
4. Залогиниться под корректными логином/паролем. Переименовать аккаунт. Перегрузить браузер. Залогиниться под старыми логином/паролем. Expected: не пускает. Залогиниться под новым логином/паролем. Expected: пускает.
5. Залогиниться под корректными логином/паролем. Удалить аккаунт. Перегрузить браузер. Залогиниться под старыми логином/паролем. Expected: не пускает.

Особые случаи

1. Ввeсти корректный логин и корректный пароль. Скопировать полученный url и вставить его в другой браузер. Expected: It should not display the user’s welcome page.
2. Подумать об обработке операции «вставить», т.е. рассмотреть различные способы ввода данных.
3. Как формируется запрос к серверу с данной формы (get/post)? Как передается пароль — в виде хэша или плэйн-текстом в теле ПОСТа?
4. Если данные передаются в адресной строке браузера в виде «login=bla-bla&password=bla-bla»
   1. — применить все варианты некорректных данных, включая запрещенные символы, и пограничные значения;
   2. — передать ещё какой-нибудь параметр из существующих, напр. «login=bla-bla&password=bla-bla&state=update»

Без картинок, но с линками и отступлениями.

Думал и писал долго.

Дочитал книгу «Secrets of a Buccaneer-Scholar» (How Self-Education and the Pursuit af Passion Can Lead to a Lifetime of Success) by JAMES BACH.

Книга не о тестировании as is, она о корнях и истоках того, что называется «исследовательское тестирование». ИссТест.

Уместный анекдот, в котором заключается вся суть исследовательского тестирования:

— Бэрримор, что это хлюпает у меня в ботинке?

— Овсянка, сэр!

— Но что она там делает?

— Хлюпает, сэр.

Что такое Исследовательское тестирование по SWEBOK

it4business.ru

Это одновременное обучение, проектирование теста и его исполнение.

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

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

wikipedia.org

Cem Kaner, who coined the term in 1983, now defines exploratory testing as «a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.»

Exploratory testing is often thought of as a black box testing technique. Instead, those who have studied it consider it a test approach that can be applied to any test technique, at any stage in the development process. The key is not the test technique nor the item being tested or reviewed; the key is the cognitive engagement of the tester, and the tester’s responsibility for managing his or her time.

Давно-давным, при первом знакомстве с этим термином, я подумал, что речь идет о разновидности dumb monkey testing (открой сайт и бессистемно кликай, авось, найдешь ошибку), подходом, который я не люблю, но в котором в какое-то время даже преуспел.

Случайно я нашел однозначный способ резко и безапелляционно закрэшить какую-то из версий «Reuters Xtra 3000»*, и достиг этого именно потому, что внимательно, но достаточно бестолково переходил по линкам и заполнял поля каким-то подходящим по смыслу бредом. Нечем гордиться.

* Гигантская софтина для трейдеров международных товарных бирж.

Потом понял, что ошибся, и посчитал ИссТест «тестированием без четкого плана и целей, но логичным». Плюс изучение продукта в ходе взаимодействия с ним. Это было ново и круто. Вместо того, чтобы сперва изучить матчасть и правила дорожного движения, предлагается сразу сесть за руль и поехать, нарабатывая знания на ходу…

Потом понял, что снова ошибся, и назвал это «тестирование по плану, но с возможностью вариаций; плюс изучение продукта в ходе тестирования».

Потом понял, что (настоящих тестировщиков неоднозначность и разное толкование профессиональной терминологии уже не удивляет!) это даже не вид тестирования, а вообще ПОДХОД. А подход подразумевает шиииииирокое поле самостоятельной деятельности. И что этот подход — дитя agile…

Тут стало туманнее — ведь agile у каждого свой 🙂 И в беседах про agile обязательно надо уточнять, что именно визави подразумевает под тем или иным термином.

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

Знаю, не знаю — делов-то… Надо — изучу. Не надо — ну и не надо.

Я очень люблю Error guessing. Искать «слабые места» в софте я предпочитаю более логически, нежели интуитивно. Уметь «вычленять» проявление багов в определенных, труднодоступных местах, умение предупреждать места их нахождения, а затем действительно суметь их найти, обосновать, указать на точную причину проблемы — это круто. Очень круто. Это круче и ценнее, нежели «Вот вам скриншот, вот подробные шаги — разберитесь сами». Хоть и дольше и затратнее.

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

Поэтому — микс органичен!

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

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

В agile я поначалу не понял, что именно следует делать мануальному тестировщику — кругом все носятся с автоматизацией…

Потом понял, что если программа предназначена для использования людьми — без мануального тестирования не обойтись. Проблема только в организации такой работы — привыкшим к последовательным этапам и подробным тест-кейсам бывает сложно переориентироваться. Но именно тут и работает это самое «исследовательское»! Ну, оно же и родилось в agile и для agile.

Тогда я стал искать теорию и практику иследовательского тестирования, чтобы не изобретать горный велосипед с подогревом, и поскучнел, бо НЕ НАШЕЛ теорию исследовательского тестирования. Нашел только блогосферные огрызки толкований отдельных аспектов этого подхода.

Собственно, какая там теория, если это просто подход, а не методология…

Учеба «по-блогам» — это круто (я сам ее продукт), но в принципе у такой учебы есть большие проблемы.

Учеба по-блогам

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

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

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

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

Он думает о том, как расположить и структурировать информацию… Он думает о том, что «вот сделаем каталог, и это, вероятно, будет способствовать продажам.

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

Куда там…

К чему приводит такая учеба: когда-нибудь ученик все равно захочет увидеть стройную систему в своих знаниях. Захочет «силлабус». Если найти систему сложно — придется строить ее самостоятельно. Придется делать обобщения и выводы, а они могут существенно отличаться от реального положения дел.

Примеры пагубного воздействия учебы «по-блогам»

Девчонки, я мыла лицо мылом с яблочным ароматом. И у меня исчезли прыщи. Мой вам совет — чтобы прыщи сошли, используйте «яблочное» мыло!

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

Я сто раз ходил «на дело», и попался только потому, что меня сдали подельники. Мой вам совет — на дело надо ходить только в одиночку.

Ученик не знал о том, что «если воровал, значит — сел» при любом раскладе, и что подельники — просто совпадение. Но вывод уже сделан, и возведен в степень системы.

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

Ученик не знал о том, что одновременно со сменой домена у него на странице «Контакты» кто-то приписал телефоны его офиса, и убрал безликую форму «Обратная связь», которая никак не сообщала, куда пойдет письмо и дойдет ли вообще. Ну, не знал он, что телефон в продажах через интернет — один из серьезнейших стимулов доверия к магазину, и что при покупке через интернет телефон используется чаще, чем написание емайлов. Но вывод уже сделан.

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

«Ваш Карузо ужасно фальшивит! Я его лично не слышал, но Рабинович мне кое-что напел».

Моя проблема с исследовательским тестированием была в том, что я знакомился с ним по-блогам. Впечатление получилось неполное, неточное, неясное. И каждая новая статья приносила путаницу в стиле Алисы в стране чудес («Чтобы стоять на месте — надо быстро бежать!»)

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

Мне все кажется, что надо знакомиться с этим подходом по статьям «о сути», когда можно самостоятельно прикинуть и определить собственную подходимость к ИссТест.

Я рад, что смог полностью прочитать «Secrets of a Buccaneer-Scholar». Оказывается, этот подход ИссТест — серьезная, фундаментальная система жизнеобразования. Exploratory — это не столько стиль тестирования, сколько стиль жизни отдельно взятого Джеймса Баха. И подход «исследовательское тестирование» — следствие его рутинной жизнедеятельности.

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

(Не) бросай на фиг школу!

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

«Бросай нафиг школу!

Не ходи в университеты!

Учись самостоятельно!

Это может сделать каждый!»

Ничего подобного.

Среднему индивиду прямая дорога в школу, затем в вуз, затем на работу, затем на кладбище — удобрением был, удобрением и остался.

Самообучение сродни мастерам в agile – для того, чтобы быть «Гибким», надо сперва стать крайне собранным, огранизованным, самостоятельным, сильным духом. Иначе тебе будет нужен постоянный менеджер, который будет давать тебе работу, зарплату, пинок под зад, затем ты начнешь искать себе следующего менеджера… А дракона нужно убивать в себе.

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

Многое, очень многое мог бы сделать и до этого момента, если бы на пути оказался бы кто-то, кто помог избавиться от страхов вроде «Надо учиться только в вузе, ведь без диплома меня никто не возьмет на работу…» Ну, наверстаю. Сам.

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

Может быть, мне просто повезло?

Дык вот, тема доклада было не обо мне, а о трудностях исследовательского тестирования. Трудности тут такие: если не знать и/или не видеть систему этого подхода к тестированию, можно скатиться в его неверное толкование, а следовательно — и ошибочное внедрение.

И скатиться очень легко. Начнем хотя бы с «Надо бросить школу».

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

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

Бах считает, что пойти «его путем» может каждый. Точнее, он призывает попробовать. В самом начале книги есть знаковый диалог между ним и типичной учительницей:

«Mr, Bach, I want you to know that I will recommend against you speaking at our school again,» she said. «Your message is dangerous for children to hear.»

She was almost right. It was dangerous, what I said — dangerous for her. To maintain a docile herd of students, her school needs them to accept certain truths:

* You must study what we tell you. What we say is the only thing that matters.

* You must pass our tests. Our tests measure the only important things about you,

* You must attend school. Only through schooling can you hope to enjoy a good life.

This is what I call schoolism — the belief that schooling is the necessary and exclusive way to get a good education. Musf and only!

«I told them about myself,» I said, «and how I came to be here, I told them the truth.»

«It may be true for you,» she replied. But these kids aren’t super smart like you. They don’t come from well-off families. They’re barely staying in school, and you just told them that they don’t need to be here. They do need to be here!»

«Yes they could be successful if they put in the work,» she conceded. «But I don’t think they heard that part of your message. I’m barely holding on to some of these kids as it is. I’m afraid you’ve made my job much harder, Mr. Bach. Some of them are going to take a ‘what the hell’ attitude instead of applying themselves.»

«So what if they do?» I replied. «This is America. They probably won’t starve. They probably won’t be eaten by wolves. If they don’t care about education, they may be forced to 14 work at low-skilied jobs they won’t enjoy, such as fast food or house cleaning. However bad those fates may sound, they are neither fatal nor permanent. Or perhaps they will accidentally educate themselves by starting a new business, building things, or doing theatre, music, or sports. Are you worried they’ll turn to crime? Then show them more options, not fewer. They will learn and grow from anything that happens, unless they believe there is no hope. Your job is not to make them huddle quietly in a corral, but to help them get out there and seek their fortunes. Show them a way!»

Ближе к концу книги он вообще говорит:

A typical public school in the United States is all about honoring the herd. The students are supposed to be sheep, but too many of the teachers are just older and fatter sheep. Schoolism is a herd mentality.

Прошу учесть, что фраза высказана в определенном контексте. Вырывать ее не следует.

Итак, Бах считает, что пойти «его путем» может каждый. Логично предсказать, что заниматься исследовательским тестированием может каждый?

Не может.

Нужно быть реально предрасположенным к такой деятельности.

Нужно уметь учиться «на ходу» НЕ ТОЛЬКО в процессе тестирования. Это должно быть нормой жизни. И умение это заключается не только в постоянном чтении блогов, it4business форума или статей с Software-Testing.ru.

Нужно уметь самостоятельно решать, что нужно изучить для дела, а что нет. Сам Бах руководствуется собственным интересом — где ему становится интересно, там он и «копает» углубленно. И ищет он, конечно, системность.

Вот как Джеймс учит историю:

Roman Empire fell on some date. What was it? 476? That is not interesting history to me. I care about why Rome fell, not whether it fell on a Tuesday.

What authentic problem motivated my questions? My need to make sense of the world. I wanted to understand human events on a millennial global scale, as well as a household daily scale. At the time, I thought that having the ability to analyze society and history in terms of the questions on my syllabus would help me be more comfortable even within the confines of my own life experience.

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

По плану у нас записано «Причины падения Римской империи».

Знаете причины?

Ну, рабов у них было слишком много, и вот, ослабли…

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

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

Однако умение учиться самостоятельно доступно многим.

Вот как Джеймс учится «для работы»:

One day a lawyer called me with a proposal: «We’d like to hire you to find if a software product infringes our patent. Is that the kind of testing you do?»

I said, «Yeah!» (I had never tested a product for patent infringement before. But I could test for anything.)

She asked, «Do you know the technology behind network switching in Windows?» I said, «Yeah!» (I didn’t know what she was talking about. But I could learn it.)

Then she asked me to read the patent and examine the product. Look at the first claim in that patent:

«1. A method for dynamically routing data over multiple dissimilar parallel wireless networks that are each monitored for status information, the method comprising: maintaining a priority of each wireless network, the priorities indicating a most preferred path; determining availability of each wireless network based upon status information associated with each wireless network; indicating a current most preferred network from the wireless networks determined to be available, the indication being based upon the network priorities; switching from a current network, which is dissimilar from the current most preferred network, to the current most preferred network during a transmission, at least one of the current network and current most preferred network being time continuous; and remaining connected to the current network for a period of time after switching to the current most preferred network.«

Did you read it through? If not, you’re in good company: me. According to the Flesch-Kincaid Index, which measures reading difficulty, that text is written at a sixtieth grade level. I found it terribly confusing, at first.

This was a high-pressure learning challenge.

How do you think I felt when I finally forced myself to read all those words? I was being paid three hundred dollars per hour. My client expected me to read the patent and understand it. I didn’t understand it. Was I intimidated?

No. By the time you finish this book, you won’t feel intimidated by complex and obscure text, either.

Complexity and obscurity are illusions. They are figments of mind-shock. For a buccaneer mind-shock is no cause for alarm. It is a temporary condition, a big wave coming over the bow. There’s a splash. I get wet. But steady on the helm, there. She’ll pull through.

On first reading, I wasn’t sure I was qualified to do the project. The expert on the other side of the case, a professor at a well-respected university, was taken aback to discover his intellectual opponent was a high school dropout.

Guess who won the case.

By the time we went to trial, I had become a wizard of the patent. I wrote a program to separate and index each sentence, clause, and word. I memorized most of the three patents involved, analyzing them over hundreds of hours. I absorbed a dozen books on networking technology. I constructed a dedicated test lab. I studied the underlying instructions that comprised the product, and used a variety of hacking tools to analyze its operation. I was better prepared than the professor. He spent two or three days testing it. I devoted nearly four hundred hours to testing it. I brought in a video crew to film me testing it. I tested it inside out and sideways.

The jury noticed.

The facts were on our side, of course. That helps when you need to win a lawsuit. But here’s my point: the reason I plunged into this project, even though I didn’t know whether I was smart enough to complete it, was because I knew I was smart enough to start. Starting is what matters. I’ll be smarter by the finish.

That’s one of the benefits of being a buccaneer-scholar. With a nonstop education you are in a position to attack opportunities that sail your way, instead of steering clear with «Sorry, I’m not qualified.»

When the lawyer first called me, I was in the midst of writing the key elements of my buccaneering method for this book. That case became a fifteen-month interruption.

Круто.

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

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

Computer science

1. Опишите различия между нитью и процессом.
2. Опишите основные принципы работы Virtual Memory. Какой максимальный объем виртуальной памяти доступен процессу на 32х битных системах?
3. Что такое функции высшего порядка? Опишите алгоритм работы функций высшего порядка — map и fold (также встречается под названием reduce).
4. Какая сложность у процедуры вставки в простое бинарное дерево поиска в среднем случае? Какой сложностью обладает алгоритм, проходящий по одному простому бинарному дереву из n элементов, и вставляющий эти элементы в другое простое бинарное дерево из m элементов?
5. P=NP? Перечислите самые известные NP задачи.
6. Опишите различия static и dynamic typing. А что такое слабая типизация?

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

Это Джеймс, понимаете, Бах лениво встанет, спросит «What a feeglee-meeglee?», и убежит обратно в США. А большинство пойдут неспешно домой, утрут слезки, и будут зубрить, чтобы на следующем интервью не «опозориться». Зубрить, а не учить алгоритмы…

Тема скользкая, но…

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

А уж каким ужасающим было мое первое интервью в тестировании… 🙁

В GlobalLogic, поскольку компания большая, есть особые, ежегодные митинги оценки знаний каждого работника в отдельности. На одном таком митинге-оценке меня спросили «Какие виды тестирования ты знаешь? Давай, перечисли как из пушки…» Но вместо «пушки» я сделал паузу, затем меня пробило на странное «хи-хи», и ответ не получился. Скомкался.

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

Я получил оценку «as expected» и пошел продолжать тестировать нашу сложную, многомиллионно стоящую софтину. И выпил изрядно квасу, бо вспотел. Ведь если бы оценка в итоге получилась бы ниже «as expected», и я не потдвердил бы свой высокий статус software engineer…

Если кто не знает, квас в GlobalLogic — БЕСПЛАТНЫЙ и вкусный.

Забивай себе «чердак» лично

Если смотреть на учение Баха поверхностно (первое впечатление), то получится, что чему-то специально учиться не стоит. Учиться надо только тогда, когда есть необходимость. И только тому, чем нужно оперировать прямо сегодня и сейчас.

Неверный вывод.

Я уверен, что и сам Бах не хотел бы подразумевать именно такую интерпретацию. Хоть он постоянно прикидывается ленивым обжорой, он намного умнее этого «изображения себя».

На эту тему вспомнилась сцена знакомства Холмса с Ватсоном в «том самом» сериале. В самом начале есть такой диалог:

Сыщик берет в руки увесистый фолиант.

— Мистер Ватсон!

— Да!

— Это роман?

— Да!

Холмс обескуражен.

— Вы что, читаете романы?!

— А вы хотите сказать, что не читаете?.. Это Диккенс.

— Не читал, не читаю и не собираюсь читать… Я вообще не читаю беллетристику.

— А история, философия?

— История, философия – в руки не беру!

— Ну, а как же Аристотель, Жанна д’Арк… Коперник?!

— «Коперник»? Знакомая фамилия… Что он сделал?

Ватсон фалломорфирует.

— Боже мой!.. Так ведь это же он открыл, что Земля вращается вокруг Солнца! Или этот факт вам тоже не известен?

— Нну-у… мои глаза говорят мне, что, скорее… солнце вращается вокруг земли… Впрочем, может, он и прав ваш этот… как его? Коперник!

— Простите меня, Холмс. Вы человек острого ума, это сразу видно. Вы превосходно знаете химию… Как же вы не знаете вещей, которые известны каждому школьнику?!

— Ну, когда я был школьником, я это знал, а потом основательно забыл!

— Так вы что – хвастаетесь своим невежеством?!

— А вы, Ватсон!? Вы можете отличить грязь на Риджин-стрит от грязи на Пикадилли?.. Или пепел гаванской сигары от пепла манильской? Или можете мне сказать – что написано в третьем параграфе уложения о наказаниях Британской Империи? Можете?!

— Но ведь… я говорю… об элементарных вещах, которые знает каждый!..

— Но я ведь – не каждый!! Ватсон, поймите… Человеческий мозг – это пустой чердак, куда можно набить всё, что угодно. Дурак так и делает – тащит туда нужное и ненужное. И, наконец, наступает момент, когда самую необходимую вещь туда уже не запихнёшь. Или она запрятана так далеко, что её не достанешь… Я делаю по-другому. В моём чердаке только необходимые мне инструменты! Их много. Но они в идеальном порядке и – всегда под рукой! А лишнего хлама мне не нужно.

— Учение Коперника… по-вашему, хлам?

— Хорошо. Допустим, земля вращается вокруг солнца.

— То… то есть как, допустим?!

— Земля! Вращается вокруг солнца… Но мне! В моём деле! Это не пригодится.

Ватсон окончательно фалломорфирует.

— Как ужасно было бы жить в мире, где не с кем было бы поговорить о поэзии… о живописи… о политике… Где каждый знает только то, что ему нужно для дела…

— Мистер Ватсон, я могу вас утешить. Дело в том, что таких людей, как я, в мире очень немного… Может быть, даже я такой один.

Обе стороны в этом диалоге неправы. Но обе представляют определенные подходы к учебе, и этим интересны.

Ватсон знает и ценит ВСЕОБЩЕСТЬ образования. Знать, кто такой Коперник, знать философские разности — это круто.

Холмс знает про всеобщесть, но не ценит ее. Он ценит точные знания, полученные в определенное время для решения определенных задач.

Неправильность заключается в следующем — оба представляют и, как бы, отстаивают правильность своей позиции, не делая скидок и попыток смиксовать оба подхода. В действительности ведь Холмс может не знать, кто такой Коперник, но НЕ может не знать о том, как и почему сменяются день и ночь. Иначе он не смог бы делать выводы. Дедукция не сработала бы. Это не дедукция — принять смену дня и ночи как данность.

А без умения самообучаться его дедуктивный метод так и не развился бы. Если кто помнит, Холмс развивал свой метод целенаправленно, и не видел в своих способностях ничего необычного.

За необычность следует благодарить Ватсона, который ВИДИТ то же, что и Холмс, но не НАБЛЮДАЕТ (пример с количеством ступенек к его двери — Ватсон видит их ежедневно, но ни разу не утрудился их сосчитать).

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

Кстати, подсчет количества ступенек — лишняя информация в чердаке Холмса 🙂

Подход Ватсона тоже слишком всеобщий — он ценит ВСЕОБЩЕСТЬ знаний выше, чем их специализацию. Но, например, лично меня кормит именно специализация, которая построена на большой пласте знаний, не связанных с тестированием. В детстве под одеялом с фонариком я читал отнюдь не Майерса и Бейзера… 🙂

Подход Баха такой же — знать всё невозможно, но и не нужно. У него есть и бумажная, и электронная версия Британской энциклопедии, но это не сделало его умным (сам так пишет). У нас сейчас есть еще и википедия — ну, и что?

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

Догадайся по капле воды о существовании океана…

Способность решать возникающие проблемы (неважно — в тестировании или в приготовлении суши).

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

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

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

Но как вы догадались, что я не «Холмс», мистер Холмс?

Стать таким, как Холмс, сможет не каждый. Им не стать — им надо быть. К Баху это относится в той же мере.

Холмс или ЛСЭ (логико-сенсорный экстраверт)

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

Один из наиболее выдающихся изобретателей (Томас Эдисон).

ЛСЭ собирает множество фактов, относящихся к его роду деятельности. Не случайно, его можно назвать прирожденным разведчиком — сбор информации проходит вполне естественно. Здесь можно вспомнить легендарного Рихарда Зорге.

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

Выполняя работу, ЛСЭ иногда опасается, что делает её несвоевременно, поэтому старается опередить события.

Лично я интроверт, да еще и инуитивно-логический. Я не Холмс. Я не Бах. Мне не стать настоящим буканиром?

Стать.

Просто мне не стать лично Джеймсом Бахом.

Кем Канер, по определеннию Баха, тот еще буканир. Но одновременно — еще и один из самых «систематически образованных» людей:

Cem has a doctorate in psychology and a law degree, as well. He’s one of the most systematically educated people I know, and yet one of the most humble about what he knows. His studies are deep and his papers are heavily footnoted. Cem inspired me to study the philosophy and ethics of science.

Я могу сделать микс… И если мне суждено не подавиться собственным изобретением, то дела идут отлично.

Хотя, есть определенная прелесть в том, что ему мною тоже никогда не стать, и я могу подумать о самостоятельном методе самообучения 🙂

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

Избранные цитаты из книги «Secrets of a Buccaneer-Scholar»

1

If I can find the one person in a hundred who value what I am and pay for it, the other ninety-nine won’t matter.

2

I don’t know how to talk about things that don’t matter.

3

My public status comes from

— my reputation,

— Reputation is the story other people tell about me.

— my portfolio,

— My portfolio is the part of my work available for review.

— and how I do on life’s tests.

— A test is any opportunity to demonstrate my knowledge and skill.

For instance, I’m attracted to software testing as a job because testing problems have no fixed solution. Every testing problem is a learning challenge. Testing always seems fresh to me, and it rewards ingenuity. It’s a game where the rules are sometimes murky and mysterious, and for me, that’s part of its charm. Perhaps the secret to happiness is finding the games we love to play, instead of learning how to win at games we hate.

4

Of course I read every testing book I could find. I discovered software testing standards and studied those, too. I studied most evenings and weekends.

At first I thought I would learn a lot from the other testers. There were more than four hundred of them in my building. But talking to them revealed a startling truth: nobody cared.

Almost nobody. In the first six months I worked at Apple, out of all the testers in the software testing division, I met maybe ten who were also reading testing books. The rest muddled through without much ambition to master their craft. It was clear that catching the college kids would not be difficult, after all.

GREAT SECRET

Most people, most of the time, don’t try very hard.

5

The pattern I experienced at Apple would be confirmed almost everywhere I travelled in the computer industry: most people have put themselves on intellectual autopilot. Most don’t study on their own initiative, but only when they are forced to do so. Even when they study, they choose to study the obvious and conventional subjects. This has the effect of making them more alike instead of more unique. It’s an educational herd mentality.

6

What this means for success is simple. Knowledge workers succeed, not based on what they know, but rather how they learn. It’s the difference between a pantry and a supermarket. I don’t stock my pantry with a year’s supply of every kind of food. Even if I did, the food wouldn’t be fresh. Instead, I go to the supermarket when I need something. The market has an amazing variety of anything I could want, whenever I want it. I keep myself from starving by living near a system that provides me with food, and by knowing how to use that system.

The supermarket of learning is online, a Google away. Or it’s embodied in the minds of my colleagues, whom I email when I need emergency tutoring. It’s in my personal pantry of books}1& two thousand of them, most of which I haven’t read—they are standing by in case I need them.

Узнаем подход Холмса с его «чердаком»? Еще бы…

7

At first he (его брат Джон Бах, впоследствии работал тестировщиком в Microsoft) didn’t believe he could be a tester, because he had no training in computers. Like most people, lack of self-confidence is the first barrier to get over.

«You don’t need computer training, Jonny, but you do need to start learning,» I told him. «That’s under your control. You can learn anything you want about computers, starting now.»

I lectured him and I drilled him in the ways of examining technology to uncover its deficiencies. I stood him in front of a whiteboard and made him practice explaining his methods and results. Slowly he lost his fear.

[vodpod id=Groupvideo.3369521&w=425&h=350&fv=id%3DgFupCdM3pqaO%26linktarget%3D_self]