Мир программного обеспечения полностью без ума от автоматизации. Возможно, благодаря DevOps, мания возрастает. Некоторые компании исключают роль тестировщика в пользу мастеров-инструменталистов с опытом программирования, которые могут создавать фреймворки; иногда это называется «продуктивность разработчика». Язык, который используют эти компании, является одним из замен; отбрасывать людей в пользу машины.
Я хотел бы предложить другой язык: язык дополнения, где мы признаем, что тестирование и программирование различны, что автоматизация решает определенные типы проблем и создает другие. Для лучшего результата нам нужны оба.
Давайте начнем с того, что расскажем о различиях между тестированием и автоматизацией.
тестирование
Я провел последние несколько лет в хорошей компании, борясь с определением « тестирования программного обеспечения» . То, что тестеры программного обеспечения делают на практике, сильно отличается от того, как мы обычно слышим слово «тест», которое происходит из школьной системы. Для большинства людей, с 5 лет до некоторого момента в наших ранних двадцатых, тест — это вещь с ответами, которые являются правильными или неправильными. Преподаватели и преподаватели собирают группы вопросов, обычно с несколькими вариантами ответов или ответов на вопросы в эссе, чтобы узнать, помним ли мы, что они говорили в классе и о содержании учебника.
В науке и в программном обеспечении тестирование — это другой зверь. Когда я тестирую программное обеспечение, я выполняю эксперименты на программном обеспечении и тщательно наблюдаю. Таким образом, тестирование — это производительность, выполненная с умением, которая включает в себя не только разработку этих экспериментов, но и изучение и изменение нашего плана на основе результатов последнего теста. Тестирование домена , например, хороший способ узнать информацию о типах данных , которые могут или не могут работать на переменной. Часто, однако, самая важная информация обнаруживается как-то с удачей.
Часто я обнаруживаю, что исследую какой-то аспект функции, и замечаю что-то интересное. Это «что-то интересное» помогает мне сформировать представление о том, что происходит в определенных условиях, и определяет мои решения о том, что делать дальше.
Тестирование — это исследование, наблюдение, изучение вашего окружения, принятие решений и суждение о вашем опыте.
проверка
Проверка — это слово, которое Майкл Болтон и Джеймс Бах используют для действий, выполняемых большинством инструментов тестирования, которые мы используем. Созданное ими определение: «Проверка» — это процесс проведения оценок путем применения правил алгоритмического решения к конкретным наблюдениям за продуктом. Я хотел бы немного упростить это, сказав, что проверка — это вопрос о программном продукте, на который можно ответить «да» или «нет». Инструменты тестирования отлично подходят для выполнения проверок, фактически это все, что они могут сделать.
Вот пример, который вы можете увидеть при автоматизации пользовательского интерфейса:
Navigate to ebay.com
Log in with $user and $password
Assert you are returned to ebay.com
Assert text (“Hello ” + $firstname + ” !”) is displayedКаждый раз, когда вы видите слово Assertв этом примере, это означает, что проверка будет выполнена. Инструмент должен сравнить и принять решение «да» или «нет» на вопросы «Вернулся ли я на ebay.com?» и «меня приветствуют на домашней странице после входа в систему?» Проверки точно смотрят на вещи, которые вы идентифицируете, и они полностью игнорируют все остальное. Проверка не наблюдает, не исследует, не учится и не судит. Он просто возвращает подтверждение того, что условие, которое вы ожидали, было выполнено или нет.
Иногда мы пытаемся воссоздать это действие проверки, используя контрольные списки и очень подробные контрольные примеры.
стабильность
Одной из самых больших причин, которые я вижу при создании проверок, которые могут выполняться на уровне объекта, в пользовательском интерфейсе или между ними, является возможность повторять один и тот же сценарий и набор вопросов столько раз, сколько вы можете выполнить. программа. Или, по крайней мере, до тех пор, пока программное обеспечение не попытается проверить изменения, достаточные для того, чтобы проверка стала бесполезной. Создание среды, сценариев заполнения базы данных и создание тестов может занять много времени. Но когда вы там, повторение теста обычно тривиально.
Повторяемость обычно также делает маловероятным поиск новой информации о продукте.
Брайан Марик описывает это через идею минного поля. Представьте, что перед вами заложено минное поле , которое взрывается, когда вы наступаете на определенное место. Вы не знаете, где сейчас находятся мины, и есть только несколько очень специфических путей, которые вы можете выбрать. Когда вы идете этими путями, вы найдете пару мин и удалите их (надеюсь, не взорвавшись). Каждый раз, когда вы идете по этому пути после первого, вряд ли вы снова найдете мины в тех же местах.
Люди довольно плохо повторяют шаги точно. Когда я работал в компании, которая в значительной степени опиралась на подробные тестовые сценарии, у меня был постоянный удивительный взгляд и разум, хотя миссия состояла в том, чтобы следовать сценарию и пытаться быть похожим на робота. Это нужно отклоняться, это хорошо. Выходить из сценария, когда это уместно, означает подвергать себя новой информации.
Идея минного поля поддерживает идею, что люди должны исследовать и тестировать, чтобы находить новую информацию в дополнение к повторяющимся проверкам, проводимым для подтверждения того, что мы думаем, что знаем.
Время инвестиций
Время, необходимое для получения информации из теста, происходит в спектре. В конце спектра «так быстро, как вы можете напечатать», так называемые быстрые атаки . Быстрые атаки — это стиль тестирования, который практически не требует настройки или планирования. Вы можете просто выполнить их и наблюдать, что происходит. Это может показаться тривиальным, но они мощные, потому что вы можете запустить их так быстро, и они имеют тенденцию приносить хороший урожай ошибок. Мэтт Хойссер, мой коллега в Excelon Development, любит подчеркивать, что «обученный» программист с высокой степенью зрелости, особенно работающий в парах, может найти большинство этих ошибок самостоятельно. Это, конечно, правда, насколько это возможно. Большинство компаний, с которыми я работаю, нанимаются, потому что у них не совсем высокая зрелость… пока.
Помимо быстрых атак, существует множество методов, которые требуют более детального анализа требований, платформы и иногда кода. Эти методы «другого конца спектра» требуют времени для разработки, особых условий данных и часто условий настройки, прежде чем мы сможем запустить тест и получить результаты.
Автоматические проверки сами по себе требуют много времени на настройку; кто-то должен написать код или хотя бы записать и проверить с помощью инструмента. Я бы осмелился сказать, что самое быстрое, что вы можете пройти от идеи до информации с помощью чека, — это почти то же самое, что вы можете сделать с человеческим тестом. После того, как проверки созданы, если вы хотите запускать их более одного раза, вам придется беспокоиться о том, чтобы синхронизировать их с вашим продуктом. Использование инструментов для создания чеков часто похоже на создание программного проекта параллельно с тем, который вы продаете.
Occasionally, I see tool-aided testing used as a reason to reduce or get rid of all together the test department. If you aren’t spending a lot of time refactoring into a component architecture where you can turn features on and off quickly, and creating elaborate monitoring systems to notice when something is going wrong, a check heavy strategy probably isn’t for you. Even if you are, context matters and there are plenty, life critical systems for example, where I wouldn’t take the risk.
You’ll notice the subtle idea of substitution wormed its way into the conversation again here. It’s powerful. But I think we can do better. If a test requires a great deal of setup that can be scripted, and we want to run it many atimes, then we can do that in code, or with a too—making the re-run cheap. We can also use the check to drive us to an interesting place—two users that have identical names, for example, or to edit a page while we are trying to edit it ourselves, testing for concurrency issues. Michael Larsen calls this «Taxi Cab Testing;» that the script drives us to an interesting place faster than a human can, then we jump out and test.
Black Swans
When all you see your entire life are white swans, you don’t think of the arrival of a black one. This idea, that the presence of only white swans does not disprove the existence of black ones, was an example in Medieval logic classes… right up until Willam De Vlamingh found black swans in Australia in 1697.
«Black swan events» surprise us. They seem obvious in hindsight but are hard to predict up front. Things that we could not have imagined, like a storm knocking out the power to Amazon’s main data center or worse, a tsunami wave following a major earthquake creating a nuclear disaster, can have a massive impact.
Checks that run repeatedly ask the same questions over and over. They’ll be unable to find black swans almost by definition. Testing is a strategy for putting people in a position to discover black swans, sometimes on purpose. Things get a little complicated here. Checks can be embedded inside of a test. What that means, is that a check can be run and then a person can use the results of that check to learn something interesting and go off and investigate—like our Taxi Cab example. So, even though the check can’t discover a big important problem, a person reviewing the results of that check might get the information they need to discover the problem.
How To Talk About This
The terms «check» and «test» were carefully selected, but the topic is very much rooted in philosophy and social science. Specifically the work of Harry Collins in his books The Shape of Actions, and Tacit And Explicit Knowledge. The reading came come off a bit dry and academic. Yet there are practical implications that can be used in day to day work. Software testing performed by people is a strategy used to discover new and important things about a product.
Checks might help these people to some degree, but on their own are only answering yes or no to simple questions.