суббота, 19 июня 2010 г.

Usability- тестирование

Долго писала комментарий к интересной теме, а он потерялся :(
Напишу ещё подробнее и здесь :)

Usability тестирование в сфере разработки ПО - это проверка удобства использования продукта. На эту тему есть как минимум одна интересная книжка:
usability тестирование

Я постараюсь сформулировать своё мнению про юзабилити-тестирование, основанное как на чтении книжек/статей, так и на собственном опыте. Я не претендую на полноту описания и на полноценность списка способов. Отнюдь! Но это - те базовые шаги, которые являются 20% действий по закону Паретто и которые принесут угадайте сколько результата :)

1) Самое главное в тестирование юзабилити - определить его цели. Что будет делаться по результатам тестирования юзабилити? Будут ли исправляться дефекты, есть ли приоритет, направленность проекта/компании в целом на юзабилити? Если нет - Вы попусту тратите время. Почему это пункт 1? Потому что в России такого приоритета зачастую нет. А своё время надо экономить ;)

2) Если всё же смысл в юзабилити-тестировании есть, то следующий важный шаг - узнать Вашу ЦА, целевую аудиторию.
Почему важно понять, кто Ваши пользователи? Приведу пример с общеизвестными продуктами: антивирусами, средствами архивирования, графическими редакторами. Зачастую, приложения для домашних пользователей и корпоративных пользователей имеют идентичный функционал. Но антивирус для домохозяйки имеет все базовые предустановки, и в большинстве случаев ей просто надо нажать на кнопку. Но если это корпоративный антивирус, который настраивают админы, то им нужна панель управления космическим кораблём :)
Функционал один - количество кнопок, настроек, их сложность и т.д. - разные. Найти соприкосновение для таких целевых аудиторий будет сложно.
Аналогично - с графическим редактором. В MS Paint'e есть почти всё, что нужно простому смертному, который испугается менюшек фотошопа. Зато дизайнера явно не устроит MS Paint...

3) Целевая аудитория - это те люди, чьё мнение для Вас важно. Но помимо этого, Вам надо понимать, как обычно используется Ваш софт в "боевых условиях". Говоря простым языком, Вам нужно составить ментальную модель пользователя :)))
Когда ИТ-шники тестируют софт для бухгалтерии, они обычно ориентируются на свои предпочтения и свою специфику отрасли. Запуская одни и те же программы каждый день, мы привыкаем к любому неудобству. Потому, что мы тестируем, а не используем. Это - две большие разницы :) Цель создания ментальной модели - понять, как продукт ИСПОЛЬЗУЕТСЯ, и его тестирование соответствующим образом.
Как Ваш софт запускают? Из каких менюшек куда заходят? Что используют часто, а что - редко? Что важно? Какие проблемы и задачи решает пользователь при помощи Вашего софта?
Один раз я столкнулась с неприятным опытом. В продукте, который я зарелизила, среди прочих был один всем известный дефект, который казался нам непринципиальным. (Нам = 40 тестеров, 60 разработчиков и парочке аналитиков). Мы были уверены, что этот функционал никто не использует.
Как же мы удивились, когда получили массу жалоб и отказов именно из-за этой "мелочи"!
Этот полученный опыт я считаю хоть и негативным, но очень важным. Тестировщики всё же не пользователи. Надо узнавать настоящих пользователей, чтобы "отстаивать их права" :)

Теперь, переходим к процессу и техникам :)

4) Не торопитесь устраивать исследования. Тестируйте сами. В этом Вам помогут знание пользователей, common sence и общепринятые нормы юзабилити. Чтобы их узнать, погуглите usability guidelines. Они бывают для разных ОС, для ВЕБа и т.д. По ним, сначала проверьте сами и оцените, насколько соответствует им Ваш софт и насколько готова Ваша команда править ошибки. Если этот этап пройден успешно - идём дальше!

5) Проводим исследования.
* Ищем ЦА. Не просто "коридорное тестирование", чтобы найти кого-угодно, а конкретных, подходящих людей, которые будут использовать Ваш продукт!
* Мотивируем их. Мы можем предложить более качественный софт потенциальным клиентам. Мы можем предложить деньги подходящим людям. Не надейтесь, что кто-то будет серьёзно расценивать Ваши опыты просто так :)
* Не делайте многонедельных исследований. Это просто долго, и юзтестеры так же замылят глаза, как и обычные тестеры. Юзтестирование должно быть коротким и быстрым.
* Вы можете провести простое исследование, попросив пользователей
- Выполнить ~5 простых основных действий, не описывая ни в коем случае шаги! Только действия. Пусть они сами ищут, как это сделать, и опишут Вам проблемы, с которыми столкнулись.
- Потыкать кнопочки и описать, что понравилось и что не понравилось :)
- Пригласить их к себе и попросить сделать эти самые действия. Понаблюдайте, с чем они сталкиваются. В анкете они не смогут описать всего, с чем столкнулись, так как сами не заметят своих "заминок". Зато, это можете заметить Вы :)
- Используйте специальные средства для записи действий пользователей, которые Вы потом сможете проанализировать в спокойной обстановке.
- И да, я не советую Вам проводить лабораторные исследования и записывать количества движений глаз :) Во-первых, я сама этого никогда не делала, во-вторых, я ещё не работала с софтом, у которого достаточно высокий уровень юзабилити для того, чтобы эти исследования могли быть оправданными.

6) Анализируем результаты.
* Не пытайтесь исправлять всё, на что пожалуются юзтестеры. Некоторые из них такие марсиане, что их комментарии окажутся бесполезными для всех остальных пользователей. Ищите золотую середину и не забывайте про common sence.
* Найдите способ подтвердить, что исправления полезны. В принципе, это следствие из предыдущего абзаца :)
* Выработайте критерии критичности юздефектов. Невозможность найти опцию и лишний клик - это разные весовые категории.
* Не пытайтесь компенсировать юзтестированием недостаток изначального анализа. Это будет выстрел пушкой по воробьям.

пятница, 11 июня 2010 г.

Когда полезен тест-дизайн?

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

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

Чек-лист - это перечисление областей/действий, которые надо протестировать, без описания шагов.
Чек-лист

Свободное тестирование - неограниченное рамками тестовых спецификаций творческое тестирование.
Эксплоративное тестирование

Чтобы ответить на вопрос, что и когда нужно делать, надо сначала понять, что и зачем нужно :)
Зачем пишутся чек-листы?
- Чтобы ничего не забыть
- Чтобы оценивать масштабы работ
- Чтобы иметь возможность приоритезации проверок
- Для подспорья неопытным сотрудникам
- Чтобы иметь возможность приблизительно отслеживать, что работает, а что - нет

Зачем пишутся тест-кейзы?
- Чтобы ничего не забыть
- Чтобы по ним можно было учить новых сотрудников
- Чтобы точно знать, что работает
- Чтобы иметь детальную отчётность
- Чтобы иметь возможность точного планирования
- Чтобы в работу можно было подключать не выскококвалифицированных сотрудников

Получилось приблизительно такая схемка:


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

Минусы чек-листов:
- Непонятно, что именно было протестировано
- Нужно некоторое (небольшое) время на их создание

Минусы тест-кейзов:
- Большие затраты на их создание
- Необходимость поддержки в случае изменений в продукте
- Эффекти пестицида (кейзы со временем перестают находить ошибки)
- Скука со стороны тестировщиков (не всем нравится гонять одно и то же)

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

среда, 9 июня 2010 г.

Тренинги в Питере - 15 и 16 мая 2010

Я уже 3 недели хочу написать о результатах поездки в Питер.
И вот, я добралась :)
ПИТЕР
О город, я люблю тебя :) Кафешки, мини-юбки, ощущение портового города. Класс, но работается плохо :))
ДОРОГИ
О питерские дороги, спасибо вам! Теперь я считаю, что московские дороги - супер :) Всё познаётся в сравнении!
Тренинг 1: 15.05, Управление персоналом:
Так нервничала, что забыла про пару упражнений :)) Тренинг прошёл на четвёрочку, обычно - лучше. Группа подобралась экстраинтересная, и несмотря на ночь за рулём перед тренингом, до вечера моя батарейка была 100%. Придумала пару новых "фишек" для тренинга, внедрю в следующий раз. Главное не забыть :)
Тренинг 2: 16.05, Управление тест-дизайном:
Тренинг прошёл на пятёрку с минусом. Группа была ещё интереснее. Здорово, что многие участники после тренинга обращались по почте с конкретными вопросами, которые мы и разбирали. Всё же, упражнения для примера и реальное использование каких-либо инструментов - "две большие разницы". А раз народ начал их использовать и даже задавать вопросы - то это щастье для тренера :) Но, этот тренинг я решила переделать почти полностью и уже это сделала :)) Пусть будет ещё круче.
Офис Yota
Как и обычно, помещение предоставила Yota, за что ей огромное спасибо!
И если бы это был просто офис! Это было много-много этажное здание с роскошным видом из прозрачных лифтов. Ух я и накаталась на них!
Но самое классное в офисе Yota - это пингвины :)
Ваня
Про Ваню можно говорить много и долго. Но честнее будет просто сказать, что он лучший :) Познакомившись на прошлогоднем тренинге, чрезвычайно этому рада.
Офис, Ваня, город - и всё на одной фотке:


Питер, до встречи!