"Борется за свою славу"

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

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

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

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

Эмоции и наставничество - несовместимы

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

Опечатки

Некоторые заказчики очень прохладно относятся к spelling errors в проекте, хоть программа и является лицом компании. Мне бывает очень смешно читать сообщения, написанные на ломаном английском через ПРОМТ. :)
Так вот, насчет ошибок в надписях, подписях и сообщениях.
Иногда они могут стоить очень дорого,как в примере ниже.
На этом ролике YouTube проигрывается одна из серии популярного шоу "Will it blend?", и в этой серии ведущий задает этот вопрос относительно пластиковых карточек - дисконтных, кредитных, депозитных и тд. В начале ролика он просит женщину достать их все из кошелька и поучавствовать в шоу. Так вот,на 57 секунде, когда карточки начинают превращаться в пыль, на экране появляется надпись - "Please, try this at home!" !!!



По закону за такое можно подать в суд, потому что человек может принять это как руководство к действию и потерять все свои карточки. (Следует сказать,что во всех остальных сериях этой передачи фраза написана как "Please, don't try this at home!".)

Вывод: тестеры всегда должны быть внимательны даже к "незначительным" и "неважным" опечаткам и грамматическим ошибкам.

Игра в быстрые вопросы

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

Так вот, для поддержания и проверки знаний, в последнее время я начала практиковать использование быстрых вопросов своей команде. Суть такова - ни с того, ни с сего (для подопечного, конечно же, у Вас-то все давно продумано!) задаете вопрос члену команды, устно или письменно через асю - неважно. Вопрос должен быть конкретным, чтоб задать его быстро, и быстро услышать ответ. Например, назвать методики сокращения количества тестовых примеров, перечислить виды тестирования и далее в таком духе.
Задали - и наблюдаете.
Если вопрос устный, то смотрим за глазами человека и его движениями, чтобы понять степень подготовленности человека морально и степень знания вопроса. Вывод для Вас, если подопечный не справился, должен быть такой : "дать Васе на самообразование повторить этот материал".
Ни в коем случае нельзя сердиться и нервничать ("Как ты можешь не знать таких элементарных вещей!"), иначе игру можно считать законченной,а менеджера - проигравшим - ему начнут врать. Да и и игра перестанет быть игрой, превратившись в чекпоинт.
Если вопрос письменный, то нужно наблюдать за выражением лица (если это возможно) и следить,чтоб у человека не было возможности\времени открыть Гугл. Остальное все также, как и в случае с устным вопросом.

Как видно, это работает только при возможно установить визуальный контакт.
Игра в быстрые вопросы убивает трех зайцев - освежаем знания (заяц тестирования), привыкаем не теряться, когда задают неожиданные вопросы (заяц психологии) и держим себя и команду в тонусе (заяц боеготовности).

ОБЯЗАТЕЛЬНО необходимо объяснить команде, что это не проверка знаний и не контрольная работа, а просто такая игра, в которой можно очень быстро проверить свои знания в той или иной сфере, чтоб знать, какие знания следует освежить.

Делаем фотографии багов с PicPick

Не так давно открыла для себя новый скриншотер PicPick, который намертво поселился на моем компьютере :)

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

Выбор окружения для тестирования

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

Для мира:
http://www.w3schools.com/browsers/browsers_stats.asp

Для стран СНГ:
http://www.liveinternet.ru/stat/ru/browsers.html?period=month

Для Украины:
http://index.bigmir.net/users?&d=0&y=2

Обратите внимание, насколько отличается статистика мира и Украины :)

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


Вывод: перед тестированием ЛЮБОГО приложения, тестировщику обязательно стоит основательно изучить статистику возможного использования окружения для тестируемого приложения, чтобы максимально ориентироваться на потребителя (здесь следует учитывать регион предполгагаемых пользователей). Также следует периодически мониторить изменение используемого пользователями ПО для эффективного реагирования на изменение нужд пользователей.

P.S. Теперь понятно, почему я вижу эти баги - у Оперы недостаточно процентов использования в мире, чтобы проверять под ней приложения и исправлять ошибки :)

Ограничение количества символов в текстовых полях

В своей работе каждый тестер сталкивается с тем, что нужно ограничивать максимальное количество введенных символов. У нас в компании практикой уже выработаны некоторые стандартные значения длины. И вот, читая блог, я обнаружила список самых длинных названий, доменов и т.д.
Я сделала вывод, что нужно пересмотреть наши стандартные значения длины полей - нам-то нетрудно сделать поля длиннее, а короткие поля, как оказалось, могут принести неудобства определенной (хоть и маленькой) части пользователей.

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

Одни из самых длинных улиц России = 80 символов без указания дома
улица 1-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 9 домов
улица 2-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 34 дома
улица 3-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 61 дом

Самый длинный домен из Украины = 239 символов (не знаю, как сейчас, а когда я писала, то не могла к нему доступиться)
http://www.public-organization-capital-of-the-world.which-establishes-world-records-welcomes-all-inhabitants.of-the-planet-and-invites-them-to-visit-our-ancient-city.yours-faithfully-chairman-of-government-anatolij-kosjanchuk.epak.infocom.lviv.ua

Киррилические домены
http://президент.рф/
правительство.рф

Самый длинный почтовый домен = 68 символов без учета имени пользовтеля
@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com

Самая длинная аббревиатура
«SKOMKHPHKJCDPWB»
Самая длинная аббревиатура в России = 55 символов: НИИОМТПЛАБОПАРМБЕТЖЕЛБЕТРАБСБОРМОНИМОНКОНОТДТЕХСТРОЙМОНТ

Самое длинное название = 132 символа
«Кафедра гигиены, эпидемиологии, медицинской полиции, медицинской статистики, учения об эпизодических болезнях и ветеринарной полиции»

Самое длинное название города = 179 символов
Бангкок. На тайском языке: «Krungthepmahanakhon Amornrattanakosin Mahintharayutthaya Mahadilokphop Noppharat Ratchathaniburirom Udomratchaniwetmahasathan Amonphiman Awatansathit Sakkathattiyawitsanukamprasit», что в переводе означает «Город ангелов, великий город, резиденция изумрудного Будды, неприступная крепость, великая столица мира, одаренная девятью драгоценными камнями и изобилующая великолепными королевскими дворцами, напоминающими райские жилища, из которых правит олицетворение Бога, Город, дарованный богом Индрой и построенный Висанукамом».

Самая длинная фамилия = 43 символа
Если написать ее по–русски: «АИЙИЛЬЦИКЛИКИРМИЦИБАЙРАКТАЗИЙАНКАГРАМАНОГЛУ» (в переводе «Сын героя знаменосца флага с полумесяцем и звездой»).

UI баги blogspot.com

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

Номер раз. Форма входа, язык интерфейса - Украинский.

Номер два. Метки "облаком" (нижнего скроллбара на экране нет, текст просто обрезан).

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


Длинные слова тоже выходят за "рамки дозволенного" :)


И отсутсвует нотификация об окончании загрузки файла в блог.

P.S. У меня Opera 10.

Priority & Severity

Пока в нашей компании жизнь была спокойной и налаженной,я искренне недоумевала, зачем дублировать информацию, имея, кроме поля Priority, еще и обязательное поле Severity. Но теперь, имея массу тикетов перед релизом и не имея поля Severity в кастомерском багтрекере, я понимаю, что мне его не хватает :)
Priority - это приоритет, а Severity - "строгость","жесткость". Я, наконец-то, столкнулась с такой ситуацией, когда приоритет ошибки гораздо выше, чем ее строгость, и наоброт - строгость выше, чем приоритет ошибки.
Например, ГУИ баги у нас обычно имеют низкую строгость и, зачастую, низкий приоритет, однако, перед релизом приоритет внезапно растет, в то время, как строгость остается прежней. :)

Радуюсь тому, что взгляды меняются, причем вполне обоснованно :)

UPD: Сегодня добавила в багтрекер поле Severity.
Столкнулась с тем, что отличие между полями не все понимают, и мне предлагают перед релизом менять приоритет, который у нас ранее обозначал нечто среднее между строгостью и приоритетом. На мой взгляд, ошибка не может изменить свою строгость с течением времени,а вот приоритет вполне может быть изменен и будет меняться.
Поэтому отвоевала оба поля, посмотрим, что выйдет :)

Как заставить людей развиватсья?

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