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

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

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

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

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

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

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

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

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

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

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

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

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

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

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