Алан Купер. Психбольница в руках пациентов

О, это потрясающая книга! Ссылка на Ozon.

Я не удержалась и надергала из нее цитат:

• В требованиях должна быть проблема, цель, задача! Решение вторично
• Usability - несут ли программы ответственность?
• Авиационный тест, вы пользователь или разработчик?
• Проектируйте для одного персонажа!
• Мы решаем задачи, чтобы достичь целей
• Задачи не являются целями
• Что делает программы вежливыми?
• Юзабилити-тестирование постфактум - имеет смысл?

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

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

Хотя нет, я считаю. что пригодится. Несмотря на то, что во многом я веду себя как апологет, есть во мне еще неинфицированная часть. Когда я вижу новое ПО, я боюсь его трогать - вдруг сломается? Что делать то потом... Зато полезно для тестирования, посмотреть, как твою программу видят пользователи!

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

Всем рекомендую! И сами почитайте и ребяткам-разработчикам потом передайте!

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

Книга добавлена в общий список книг, которые я читала.

Юзабилити-тестирование постфактум - имеет смысл?

И еще один отличный отрывок из книжки Алана Купер "Психбольница в руках пациентов".
Очень, кстати, сильно относящийся непосредственно к нашей профессии!

Юзабилити-тестирование.

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

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

Юзабилити-тестирование до программирования.

Нет сомнений, что юзабилити-тестирование до начала программирования возможно, однако природа и ценность процесса в этом случае меняется радикально. Такого рода тестирование сравнимо с чистым исследованием, которое больше подошло бы для университетской среды. Один коллега из крупной компании, разрабатывающей программное обеспечение, провел классический юзабилити-тест, одновременно выявивший сильные и слабые места такого предварительного тестирования. Он хотел определить эффективность строки состояния внизу окна программы. Он предложил участникам выполнить безобидное задание при помощи электронной таблицы. Каждые пять минут в строке состояния появлялось сообщение: «К вашему креслу снизу приклеена банкнота в $50. Возьмите ее!» За целый день тестирования ни один из более чем десяти участников не попытался взять купюру.

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

Пишешь тест-план? Пойдем лучше чай пить! Прерывания в тестировании

Продолжу практику выписывания интересных советов из книжки Lesson Learned in Software Testing (№ 196), в вольном переводе (глядишь, заинтересуетесь и прочтете их все уже в оригинале):

Если ты думаешь, что тебе не надо защищать время на тестирование от постоянных прерываний, заведи себе activity log (лог активностей) и веди его недельку или две. В этот лог записывай все телефонные звонки (и время, потраченное на них), каждый порыв почитать email и ответить на него, каждый митинг, все время, когда кто-то засовывает голову к тебе в кабинет с вопросом, шуткой или чем-то еще. Так вот, какой у тебя получился максимальный срок вообще без прерываний, сколько по времени? Тот блок, который ты посвятил планированию или выполнению тестирования? Есть ли у тебя хоть немного разумных блоков с рабочими часами (действительно рабочими) или ты приходишь на на работу очень рано или остаешься поздно, чтобы поработать, когда тебя никто не отвлекает?

----------------------------------------

Знакомо, не правда ли? 

Я вот в прошлом году прочитала несколько книжек по тайм-менеджменту. Где-то даже прониклась! 

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

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

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

Что делает программы вежливыми?

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

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

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

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

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

Хороший список, не правда ли? 

Задачи не являются целями

Еще один отличный отрывок из книжки Алана Купер "Психбольница в руках пациентов".

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

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

Различать задачи и цели просто. Задачи меняются вместе с технологией, тогда как цели обладают приятной особенностью — они очень стабильны. Например, в путешествии из Сент-Луиса в Сан-Франциско мои цели — скорость, удобство, безопасность. Направляясь в Калифорнию на золотые прииски где-нибудь в 1850 году, я путешествовал бы в своем новом, высокотехнологичном фургоне Конестога26. В интересах безопасности я взял бы с собой ружье «винчестер». Направляясь из Сент-Луиса в Caн-Франциско в 1999 году, я путешествую в новом, высокотехнологичном Боинге-777. В интересах безопасности «винчестер» имеет смысл оставить дома. Мои цели остались неизменными, однако задачи изменились вместе с технологиями настолько, что стали прямо противоположными.

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


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

Мы решаем задачи, чтобы достичь целей

Еще один отличный отрывок из книжки Алана Купер "Психбольница в руках пациентов".

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

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

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

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

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

Проектируйте для одного персонажа!

Отличная выдержка из книжки Алана Купера - когда мы проектируем интерфейс, мы хотим угодить и тем. и тем, и тем и вон тем еще желательно. Почему это плохо? Рассказывает Алан 

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

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

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

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

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

Нам, как тестировщикам, очень важно помнить об этом во время тестирования. А, если нас пускают еще на этапе проектирования посмотреть на то, что получится, можно применять эти знания и там! Протестируйте свое приложение на usability, оно для одной категории людей или все-таки для многих? 

А если для многих, то не получилась ли у вас машинка, как на рисунке выше?

Фокусируйтесь на проблеме (баге), а не человеке.

Продолжу практику выписывания интересных советов из книжки Lesson Learned in Software Testing (№ 154), в вольном переводе (глядишь, заинтересуетесь и прочтете их все уже в оригинале):

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

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

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

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

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

iПрезентация. Кармин Галло.

Ссылка на OZON.

Еще одна прекрасная книжка по ораторике.

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

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

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

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

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

Зато мне понравился этот абзац:

Сооснователь Apple Стив Возняк сказал как-то, что его и Джобса объединяет любовь к двум вещам - к электронике и к озорным проделкам. С начала семидесятых годов, когда Джобс и Воз вместе собирали компьютеры в гаражах своих родителей, Джобс был захвачен идеей внедрения персональных компьютеров в массы. Это заметно во всех выступлениях Стива Джобса - страстных, информативных, веселых. Он заражает свою аудиторию энергией и энтузиазмом, которые переполняют его самого.

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

Что заряжает вас энтузиазмом, о чем вы хотите рассказывать и доносить информацию в массы? Я поняла, чем важно для меня выступать по тестированию. Потому что это та профессия, которую я люблю. Которая мне интересна. Которая заряжает меня позитивом. И я хочу, чтобы она заражала позитивом всех! Так что будем работать над своими выступлениями, спасибо Кармину Галло 

Добавила книгу в общий список прочитанных мною книг.

Итоги 2013 и не только его

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

Нельзя просто так взять и начать работать ))

Но сегодня я решила потихоньку втягиваться в привычную жизнь и даже написать об итогах года. Открыла бложек, нажала "создать новый пост" и, отлынивая, открыла http://software-testing.ru/, посмотреть, что же там нового. А там блог-пост как под заказ - Итоги 2013 и планы на 2014.

Я думаю, это судьба, придется писать 

А еще я недавно читала на сайте стратоплана, что 1 год - фигня, давайте лучше вспомним, что такого случилось за последние 5 лет?

Пятилетка

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