Home

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Mission Critical: Visualize, Personalize, Humanize

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

Что значит мыслить критически? Целью критического мышления являются обоснованные, бесстрастные, тщательные и точные оценки и суждения. Эти оценки основываются на детальных наблюдениях, старательном сборе и взвешивании свидетельств, распознавании значимых сходств и различий, осведомленности о предубеждениях и «слепых пятнах»(и устранение их в максимальной возможной степени), непрерывном повторном применении полученных знаний. Критическое мышление требует от нас рассматривать объект мышления в контексте. А также необходимо изучать, подвергать сомнению и улучшать сами способы размышления и наблюдения.

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

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

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

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

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

Я не знаю, на самом ли деле это работало у него в проектировании интерфейсов (

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

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

Люди, мыслящие критически, заимствуют идеи и методы из смежных дисциплин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда вы тестируете приложение, спросите себя: Что пользователь может сделать случайно? Какой уровень подготовки пользователя вы не учли – от новичка до эксперта? О каком типе пользователей вы могли не вспомнить? Чем отличаются условия, в которых работает пользователь, от тех, в которых вы тестируете? Кто может дать вам полезные советы и рекомендации при моделировании пользователей? Чьи и какие предположения могут заставить вас пропустить важные проблемы и увести в неправильном направлении?

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

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

Об авторе

Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software (где и была впервые опубликована вышеприведённая статья) и ведёт замечательный блог о тестировании http://www.developsense.com/blog.shtml