суббота, 12 октября 2013 г.

Usability - несут ли программы ответственность?

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

Программы не несут ответственности.

Диалоги подтверждения - один из наиболее распространенных примеров некачественного проектирования; они спрашивают, "уверены ли мы", что хотим выполнить то или иное действие. На заре компьютеризации рабочих мест программы выполняли необратимые действия в ту же секунду, когда пользователь вводил команду. Команда "erase all" (стереть все) делала именно это, причем немедленно и необратимо. Как только первый пользователь непреднамеренно стер все содержимое жесткого диска, он, несомненно, пожаловался программисту, и программист добавил адекватный, с его точки зрения, уровень защиты. Пользователь набирает команду "erase all", и теперь, прежде чем компьютер ее выполнит, программа просит пользователя подтвердить команду на удаление.


Все очень логично и совершенно неправильно.

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

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

Да, конечно, я согласна, что вездесущее окошко "уверены ли мы?" уже всем порядком надоело и обычно подтверждается не глядя, просто по привычке.

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

А иначе пришлось бы переоткрывать, терять на это время - некоторые программы минуту прочухиваются. Конечно, тут можно просто бросить камень в огород "так давайте делать программы быстрее", но все равно, иногда, хоть и редко, я даже благодарна этому навязчивому окошку Smile :)

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

Но мне не нравится подход к команде "erase all". Имхо, стереть все - это избавиться, и избавиться навсегда. Без возможности восстановления. О какой ответственности за отмену тут может идти речь?

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

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

Тогда почему компьютер должен нести ответственность за восстановление данных, которые хотели уничтожить, не удалить, а уничтожить?

Меня, честно говоря, не сильно радует политика Windows восстанавливать все, даже удаленное из корзины (ну, тут, конечно, недостаточно быть простым смертным и надо хоть что-то в компьютерах понимать, но все же - это возможно!).

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

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

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

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

А вот окошки да, их число можно и уменьшить Smile :)

вторник, 8 октября 2013 г.

В требованиях должна быть проблема, цель, задача! Решение вторично

Требования - вещь такая... То они есть, а то их и нет. Зависит от проекта.
Ну а если они вдруг и есть, то обычно описывают те функции, которые умеет выполнять продукт.



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

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

Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
  1. Двигатель внутреннего сгорания.
  2. Четыре колеса с резиновыми покрышками.
  3. Трансмиссия, связывающая двигатель с ведущими колесами.
  4. Трансмиссия и двигатель смонтированы на ходовой части.
  5. Рулевое колесо.
На этот момент времени каждый слушатель уже записал, что это автомобиль,


но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:

6. Быстро и легко срезает траву.
7. На этом удобно сидеть.

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


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

Ну что, тестировщики, кто правильно угадал продукт по одним только функциям?
Wink ;)

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

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

Да даже если мы тестируем свою, техническую, документацию. Все равно. Остановитесь и задумайтесь - а кто наш пользователь? А как он будет с этим работать? А что ему вообще нужно, какие проблемы он будет решать при помощи нашего ПО? Есть в доке хоть слово об этом? Уже хорошо!

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

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

воскресенье, 6 октября 2013 г.

TEST IT. Какие методики тестирования используете вы?

Коллеги, всем привет!! На связи TEST IT! Smile :)


И сегодня с Вами снова я, сменная ведущая Киселева Ольга. Конечно, наша рубрика ушла в отпуск на какое-то время, но надо же когда-то отдыхать, правда?

И вот, мы решили вернуться! Сегодня у нас вопрос из группы в ВК

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

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

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

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

У разработчиков есть любимый принцип "Тесты проходят? Значит, все хорошо!". Поэтому, когда где-то внезапно всплывает баг, "нету теста = нет проблем". Его надо локализовать (что делают вообще все тестировщики), а потом пойти в тот модуль, который сломался и написать автотест. Или проверить уже существующие, есть среди них такой или нет. Как только наш тест сломался - можно идти к разработчикам.

Часто такие ситуации встречаются на других работах? Я думаю, не очень Smile :)
Именно по этому, увы и ах, "серебрянной пули" нет. То, что использую в своей работе я, далеко не факт, что пригодится кому-то еще.

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

Если брать конкретную задачу, то тоже - смотря какая задача.

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

а) автотесты не падают;
б) функциональность работает (смотрим вручную);

А если задача - провести регрессию? Включаем мозг Smile :)
Прикидываем, что надо проверить ручками, что не покрыто тестами и проверяем. Смотрим на задачи из релиза и прикидываем, как они могли повлиять на те модули, которые напрямую не затрагивают. И проверяем. А еще протыкиваем пользовательский интерфейс, вдруг что-то отвалилось?

Честно говоря, не совсем понятна подоплека вопроса. Вопрос от новичка, который никогда не занимался тестированием и не знает что учить? Учи тест-дизайн, всегда пригодится!

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

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

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

За сим откланиваюсь. До встречи, ребята! 
Мы ждем ваших писем - пишите на sprosi.testera@gmail.com, задавайте вопросы, рассказывайте истории, грустные и не очень, делитесь опытом - мы рады всем!

Пока, увидимся через неделю (надеюсь)!

суббота, 5 октября 2013 г.

Джобс: Империя соблазна


Я редко пишу отзывы на фильмы, хотя и часто их смотрю Smile :)

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

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

Но гении - они такие. С ними всегда тяжело в личной жизни.

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

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

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

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

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

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

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

пятница, 4 октября 2013 г.

HFLabs - компания мечты!

Пруфлинк, а точнее, пруфролик Smile :)
Коллеги рассказывают, что конкретно им нравится в нашей работе!

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



PS - И кстати да, мы ищем ведущего тестировщика! Так что, если вы хотите решать интересные задачи, общаться с интересными людьми и готовы внести вклад в нужное дело - you are welcome!

вторник, 1 октября 2013 г.

Что такое не везет и как с этим бороться...

Никуда без приключений, как говорится...

Вечер вторника, хочется кушать, а домой еще нескоро...

Решаем заказать пиццу.
Открываю сайт, нажимаю "заказать" и оп-пачки...


Вообще говоря, там такой оригинальный рисунок "6+" каждый раз при переключении закладок отрисовывается. Но потом открывается нужная закладка. Обычно, ага.

Однако заказать с 1 раза у меня не получилось, вкладка просто повисла на этом переходном состоянии.

Решила больше не рисковать и просто позвонила.

Почему-то коллеги ничуть не удивились Smile :)
Ладно-ладно, в следующий раз сами заказывать будут...

А Вы говорите - классы эквивалентности, хитрые комбинации... Куда уж хитрее, если периодически падает основной позитивный сценарий??

PS. special for Rina и иже с ней - это хром, не IE Smile :)

PPS. Добавила пост в общую копилку багов.

Осенняя линейка ConfetQA

Закончилось лето, закончился сентябрь. Холодает...

Но разве это повод прекращать обучаться? Конечно же, нет! Особенно, когда для развития никуда не надо ехать, не надо мокнуть под дождем и толкаться в транспорте. Зачем? Когда есть серии онлайн конференций ConfetQA?

И списки докладов первых 2 конференций тоже уже сформированы. То есть можно посмотреть, какие доклады будут представлены и принять взвешенное решение - нужна конференция или нет. Хотя какое тут может быть решение? Только да, только "нужна"! Smile :)

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

Онлайн-конференция для тест-менеджеров Chief ConfeT&QA пройдет 14-16 октября с 17-00 до 19-00 по московскому времени. После онлайн выступления все доклады будут выложены в закрытый форум, где еще в течение недели будет идти обсуждения как с докладчиками, так и с другими участниками конференции.

Список докладов конференции
Тестирование в Scrum и Kanban, Игорь Лукашов (Россия)
Организация времени в тестировании: от слов к делу, Андрей Ладутько (Беларусь)
ПБО: ПротивоБаговая Оборона, Наталья Руколь (Россия)
Impact Mapping – карта и компас в проектном лесу, Елена Саламаха (Украина)
Быстрый рост отдела тестирования, Артём Чаплыгин (Россия, Новосибирск)
Тестировщик на мушке, Анна Удалова (Россия, Барнаул)
Модернизация и инновации в тестировании, Андрей Мясников (Россия, Москва)
С чего начинается тестирование? С людей!, Алексей Петров (Россия, Москва)
Кейсы по сплочению команды тестирования, Владимир Кривенко (Беларусь, Минск)
Стратегия тестирования на основании эвристической модели Баха , Андрей Дзыня (Украина, Киев)
Ключевые параметры тестирования, Сергей Мартыненко (Россия, Москва)

Онлайн-конференция для ручных тестировщиков Fun ConfeT&QA пройдет 28-30 октября с 17-00 до 19-00 по московскому времени. После онлайн выступления все доклады будут выложены в закрытый форум, где еще в течение недели будет идти обсуждения как с докладчиками, так и с другими участниками конференции.

Список докладов конференции
Баг не воспроизводится… Что делать?!, Алексей Баранцев
Управляемое исследовательское тестирование, Наталья Руколь
Мелочь пузатая, или Объем тест-кейса против содержательности, Алексей Лупан
Вестники тестирования. Цели и польза, Алексей Петров
Юзабилити анализ интерфейса с карандашом в руке, Николай Москаленко
Гадкий я. Или как не попасть в “ловушки” на пути к успеху, Рина Ужевко
Мы не Баги! Или как научить программистов тестированию, чтобы не было мучительно больно, Ирина Винокурова
Как взглянуть на свою работу под другим углом, Татьяна Андреева
Как посчитать время на тестирование так, чтобы все поверили, Евгений Ефимов