Обмен опытом внутри компании

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

Философии пост

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

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

Блог заморожен на неопределенное время

За 2 года я так и не решилась написать сюда ни разу, возможно это связано с кризисом, а возможно и с тем, что я не смогла определиться с тематикой.
Если мое решение изменится, то блог разморожу и снова начну писать. Или не начну :) :) :)

Отчет: Школа компьютерных технологий, тема "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 рейхсмарок (год выпуска они конечно же перепутали), и дело то в том, что она изготавливалась только из серебра. А серебро это не магнитный материал, так что либо Магнито не магнитный, либо они физику плохо знали.
Эх, заказала себе такую же монету, буду теперь смотреть на нее как на баг в фильме :)

SQA Days 10, или Как это было

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

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

Мой стендовый доклад начинался в 11.50 я решила не рисковать и пойти в стендовую секцию, чтобы посмотреть, как будет проходить первый доклад и самой немного подготовиться. К сожалению доклад Алексея Лупана перенесли на следующий день, и я немного занервничала, это был мой первый опыт выступления на стенде и я совсем не знала чего ожидать. Тут мне на помощь пришел Стас Фомин который и объяснил что и как делать. Как выяснилось на стендовой секции отсутствовал микрофон что означало что говорить придется громко, а в моем случае просто на пределе возможностей :) Надеюсь что я справилась, осталось только уточнить будет ли доступна видеозапись хоть в каком то виде для работы над ошибками. 

После доклада я поняла что мне надо немного расслабиться, и тут мне очень пригодилось "нереальное тестирование" от innova. Супер конкурс: сравни сайты и получи баллы, лучшим - призы! Здесь есть ссылка на он-лайн версию, поторопитесь - в доступе только до 15.12. 

Отдохнувшая и потренировавшаяся я отправилась на доклад Марсела Янки "Постоянное тестирование интеграции", затем на Сергея Мартыненко "Приоритизация методов верификации" и на обед :)  В качестве обеда был фуршет, а после него доклады Романа Юферева "О чем мы забываем в QA или Знакомьтесь Manageability", Юлии Нечаевой "Команда где каждый лидер", Станислава Косарева "Как изменить мир или взять в команду тестировщика от Бога", и наконец 2 самых живых доклада на которых я побывала: Татьяны Зинченко "Вредные советы для тестирования юзабилити" и Натальи Руколь "Полезные фишки для построения успешного процесса тестирования".
После докладов прошло награждение от innova и вечер плавно перетек в ресторан с развлекательной программой и Теодоррой-скрипачкой (надеюсь я правильно ее имя написала). 

Начало второго дня я немного пропустила, и поэтому попала только на послеобеденные доклады, в том числе на круглый стол "сообществ тестировщиков". Несмотря на слегка неконструктивные отзывы в twi-ленте мне было интересно послушать цели, средства и действия различных сообществ. Пришедший под конец круглого стола Александр Александров в конец разбил оппозицию и диаметрально изменил мнение в twi-ленте. Его следующий доклад был в этой же секции А "оценка трудозатрат на тестирование в проектах сопровождения" был так же принят на ура. Затем на стендовой секции прошел доклад Станислава Фомина "Идеальный бесплатный скринкастер для тестировщиков". Ну и под конец конференции в секции А зажигали Александр Орлов с Вячеславом Панкратовым, их самолетики и "Жизненный цикл коммуникативных дефектов" были на высшем уровне, а взбодрившаяся аудитория отвечала им в полную силу своих возможностей. Закрытие конференции было с подарками, и сразу обозначилось место следующего проведения конференции. Как оказалось из нашего далекого Иркутска я прилетела не одна, еще был Маньковский Андрей - с ним мы знакомы с продолжения круглого стола тестировщиков Сибири, прошедшего этой осенью в Иркутске.  

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

В г. Иркутске состоялась первая встреча тестировщиков.

21.10.11 прошла первая встреча тестировщиков Иркутска.

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

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

Мини-отчет по круглому столу на Geekfest'е 2011.

Geekfest 2011, Dev Day.

После обеденного перерыва в малом конференц-зале начался "круглый стол" под руководством организаторов Geekfest, Сообщества тестировщиков Сибири и нескольких активистов :)

Во главе стола сидели эксперты: Павел Сташевский(ДубльГис), Сергей Егоров(Parallels), Александр Бацуев (AnyChart), Татьяна Писчасова (ДубльГис), Дмитрий Терехов(ISPsystem), и Тамара Прокопьева(ИЦ Аптекарь). Дмитрий Пиликов (ДубльГис) тоже принимал участие в роли эксперта, по максимуму на сколько хватало его времени, т.к. он при этом еще и готовился к выступлению с докладом.

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

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

Фото есть тут, и тут (фото Степана Легачёва), и тут (фото Александра Сидорова).

PS: Приношу всем участвовавшим, организовавшим и сочувствовавшим большую благодарность :) 

Впечатление от БИФа 2011

Долго же я собиралась написать про БИФ 2011, и вот наконец добралась :) Вечером допишу :) .... Вы не поверите как долго я собиралась написать)) В общем если кому то реально интересно - то в комменты :)

Стырено с отзывов на чужую заметку:

Даешь бывало юному падавану калькулятор с тремя кнопками - "2", "+", "=".
Говоришь: - Протестируй.
Он его грызет, окунает в воду, прыгает на нем, норовит перепрошить.. Отбираешь истерзанный ресурс и интересуешься: - А сложить 2 и 2 он может или нет?
А бывает и наоборот: 2+2 сложил и счастлив безмерно... так как считает, что все протестировал.

Впечатления от "опроса про нехватку" и последующих 3х разборов.

Не стану особо говорить про сам опрос "чего не хватает тестировщикам ПО?", т.к. уже три разбора по нему записали. Просто проведу небольшое исследование на тему сути ответов опроса.
Вариантов было 6: Умение программировать, Умение доводить дело до конца, Умение составлять удобные и простые тестовые сценарии, Понимание целей и задач процесса тестирования, Квалификация и опыт в основных вопросах тестирования,
Умение коммуницировать и договариваться.
Из них два на личностные характеристики, один на доп. скил, один на опыт и два только чисто по схеме тестирования. Итак, нашего героя первым делом ударили по больному месту по самому тестированию. Потом двойной шот по личности&доп.скилу и контрольный по тестированию.
Но, я готова поспорить что лидер рейтинга "Понимание целей и задач процесса тестирования" просто вообще случайно затесался в этот список, видимо нужно было четное количество вариантов :) Привожу доводы:

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

Стоило только зарегистрироваться и началось...

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