Отчет: Школа компьютерных технологий, тема "QA" Сарма 2012

Всю прошлую неделю я провела в «Школе компьютерных технологий» на Байкале, посвященной в этот раз теме "Quality Control Engineer", а в частности тестированию. В этой школе я выступала в качестве эксперта (а нас таких там было трое), и даже провела лекцию посвященную тест дизайну. Но обо всем по порядку..

Поездка до места проведения заняла около 6 часов, и половина времени пришлась на гравийную дорогу или на куски ремонтируемых объездов. Плохая дорога до Байкала для меня не новость, но все же меня хорошенько «растрясло». А разница в климате вообще вывела из строя до следующего утра :)

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

Следующий день был посвящен видам тестирования, и многим уже знакомому примеру с «тестированием карандаша». Для проведения практики студентам предложили различные карандаши и один из предметов обстановки на выбор. Такого энтузиазма я, честно говоря не ожидала, студенты ушли вдохновленные, а вечером из их отчетов мы узнали что они проделывали под видами различного тестирования с предметами. Из особо интересного я пожалуй перечислю это: выворачивание пластикового стаканчика наизнанку около 70 раз, работа под водой и длительное нахождение в среде отличной от воздуха, краш-тесты с использованием живого груза весом около 80 кг, замораживание, поджигание, и даже попытки «потыкать» живого человека для определения степени вредоносности предмета :)

Четверг начался с лекционного занятия по теме «Тест дизайн». Я до сих пор в сомнениях стоило ли давать студентам столько информации. Из нее на практике было использовано 40% в лучшем случае, а остальной материал остался сугубо теоретическим. Так же по финальному анкетированию 45% студентов сочли ее «непонятной». Хотя я их понимаю, я сама не один месяц потратила на понимание того, что пыталась им дать за одну лекцию :)

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

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

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

Так же хочется выразить свою благодарность всем участникам, начиная с экспертов: Алексея Сорокина и Ивана Круглова, организаторов: Анны Балахчи и управления факультета, до студентов. Спасибо, было весело и интересно :) 

Рецепт удачного поиска в Jira своими руками!

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

Рецепт поиска запросов в Jira from Tmrpc

"Психбольница" Алана Купера, личные заметки по главы 9

Глава 9 "Проектирование для удовольствия", наиболее интересна мне лично. В данной главе речь идет о проектировании основанном на персонажах и их потребностях. Персонажи, это гипотетические архетипы реальных пользователей. Предназначены для выявления и работы с их целями в данной предметной области (продукте), которые определяются вплоть до личных сведений.
В разрезе данного явления, проектирование для одного персонажа, это самый эффективный способ удовлетворить широкую аудиторию и получить больше выгоды. Сужая фокус, можно получить преданных клиентов целевого рынка. Примером такого "проектирования" можно считать клейкие бумажки. История изобретения "клейких бумажек", стикеров, довольно проста: инженер отдела клейких материалов, решая свои личные, сугубо специфические задачи, создал, один из самых распространенных и полезных из офисных аксессуаров. Изобретатель пел в церковном хоре и постоянно сбивался, потому что бумажные закладки выпадали из псалтыря. Не желая портить церковную собственность скотчем, он принялся искать лучшее решение. Он вспомнил о клейком материале, над которым работал за несколько лет до описываемых событий. Материал не пошел в производство, поскольку имел низкий коэффициент сцепления. Нанеся этот неудавшийся материал на небольшие квадратики желтой бумаги изобретатель получил удобные и фиксированные закладки.
Одним из постулатов успешного проектирования для персонажа автор считает "гуттаперчевость программы". Программные продукты должны быть таковыми, "гибкими" и "подстраивающимися" под конкретного персонажа, именно программы должны адаптироваться к пользователю и быть для него лучшим инструментом для достижения конкретных целей. Сейчас по большей части мы имеем дело с гуттаперчевыми пользователями, которым приходится "извиваться" и "подстраиваться" под программу. Они согласно убеждениям автора несчастны, так как продукт не удовлетворяет их потребностям напрямую.
Здесь как раз на руку оказывается проектирование для одного персонажа, так как оно позволяет избавится от "гибкости" пользователя в сторону "гибкости" программы. При этом мы должны помнить что персонаж - это воображаемый конкретный пользователь, ведь конкретный "живой пример" может быть замусорен привычным восприятием и личными предпочтениями.   И также следует избегать попыток "усреднить" персонаж, а то получится как в анекдоте: "средняя температура по больнице равна 37 градусам" без учета повышенной и комнатной  температуры тела. Ведь в этом случае следует говорить о трех персонажах: normal, hot, dead. Каждый из этих персонажей имеет место быть, но при этом большую часть составляют персонажи normal, те, у которых уже сбита температура и которые находятся на стационаре. Важность персонажей так же обусловлена тем, что из характеристик и целей будет складываться набор функций, для продукта. Это помогает и программисту и любому другому члену команды понимать суть функции и ее значение для продукта.
Очень важной задачей преследуемой при создании персонажей является и то, что начинает вырисовываться грань между непосредственным "покупателем" продукта и его "пользователем", то есть отделение заказчика от юзера.
Про количество же персонажей автор пишет: каждый проект получает собственный набор персонажей в количестве от трех до двенадцати. Мы проектируем не для каждого из них, но все персонажи полезны для выражения пользовательской аудитории. Некоторые создаются лишь для того, чтобы было ясно, для кого мы не проектируем.
В целом и общем я могу сказать что взгляд Алана Купера является в некотором роде "свод правил" который хорошо знать и в меру применять.
К сожалению в текущий реалиях мы можем довольствоваться лишь частью советов, оттачивая свои умения и в этом нелегком труде.

Впечатления от "Психбольницы" Алана Купера.

Начало книги, отзывы рецензии и прочее - мотивируют ее не читать :)

Я довольно долго и мучительно пыталась понять, зачем нужна реклама книги когда я ее уже начала читать? Но видимо это выше моего понимания. А начиная с первой главы книга меня покорила. Я читала ее по несколько глав в течении двух месяцев, и хочу перечитать через пол года.

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

Многое описано с точки зрения человека который знает что такое процесс разработки, и знает где там подводные камни. Несмотря на то, что я тестировщик, мне многое знакомо и более чем интересно.

По главам:

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

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

2.3. "Управление, ориентированное на крайние сроки сдачи". Закон Паркинсона, готовность продукта, торги за функции и многие другие реалии разработки описаны в этой главе. 

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

2.5. "Отсутствие лояльности клиентов и чем это грозит". Примеры компаний Novell, Мiсrоsоft, Apple и Wintel. Фантастические финансовые вложения, отсутствие аналогов и крупных конкурентов на рынке приводит кампанию в ловушку "самолюбия" и не умения критически оценивать свои промахи. 

3.6. "Нечего думать - трясти надо!" В разрез с поговоркой "Что посеешь то и пожнешь". Какова цель продукта, почему планировать нужно заранее.

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

3.8. "Культура программирования". Повторное использование кода, шаблоны, связь программиста и его детища. Индивидуальность кода и сострадание к загруженным процессорам.

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

3.10. "Результат и достижение цели". Задачи - они не цели, персонаж существует, потому что у него есть цели, а цели существуют, чтобы придавать смысл персонажу. А как все это сделать хорошо и красиво - это задача, часть технологии производства. Личные, практические и ложные цели пользователей. 

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

3.11. "Сценарии и адаптирующийся интерфейс". О вечных средняках на примере продукта Logitech Scanman (по для работы со сканером).

3.12. "Юзабилити тестирование". Интеграция юзабилити тестирования и отличие его от проектирования взаимодействия. Пример про наждачную бумагу "если вы делаете стул - она поможет сделать его гладким, но она не сделает из него стол". А так же почему красивое оформление (дизайн) сложного продукта не делает его более желанным. Стратегия Мiсrоsоft основанная на изморе, и почему мелким компаниям так лучше не делать. 

3.13. "Кто должен влиять на продукт". Менеджер, маркетолог или сам клиент? Почему губительно влияние клиента на разработку? Потому что ему плевать на интересы компании, и он не представляет что именно он хочет и как это делать.  Где искать ответы для построения идеального продукта: Прогнозирование, Принятие ответственности, Затраты времени, Удержание управления, Поиск основы, Семь раз отмерь и Документирование.

3.14. "Пример из жизни: Sun Healthcare Systems, Inc.". Позитивная и мотивирующая заключительная глава. 

Внимание к деталям бывает полезным

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