Саме в такий момент Катя Кочерга підкинула мені ідею сходити на таємну вечерю від клубу Funtasty. Зазирнувши на фб-сторінку Funtasty одразу відпали жодні сумніви, щодо того, йти чи не йти. На світлинах з минулих зустрічей були веселі усміхнені люди, що спілкувались та гарно проводили час.

Я зв’язалась з організаторами, щоб дізнатись умови “участі” і все виявилось доволі просто – треба було всього лише заповнити і відправити анкету, перевести кошти та чекати інформації, щодо часу та місця проведення. Ближче до часу події Наталя (одна з організаторів та засновників цих зустрічей) зв’язалась зі мною і здала всі явки та паролі.

В  день події погода вирішила, що весна не весна без снігу… від самого ранку не було ніякого бажання вилазити з під ковдри, але тяга до пригод таки перемогла. Подивившись мапу місця проведення я дуже переживала, що загублюсь)) Але знайти G13 project studio виявилось набагато легше ніж здавалось на перший погляд. Майже біля самого входу на територію заводу і одразу у око впадала нестандартна будівля студії.  

Гості потроху збирались у творчій кухні, де на них вже чекали вишукане вино та домашній лимонад. Час вів до знайомства. Юля ( друга співорганізатор) розказала “правила гри” знайомства – всі стали у коло, та мали назвати своє ім’я та улюблену справу, а також якимось чином цю справу показати) і крім цього, назвати ім’я людини яка представлялась перед цим та показати її хоббі. Хто був у дитячих таборах, тому ця гра була доволі звичною.

Таким чином всі стали вже хоч трошки, але  знайомими.  Як виявилось, в нас підібралась доволі спортивна та творча компанія – гості майже навпіл розділились на любителів йоги, пілатесу, бігу та фітнесу і відданих малюванню, співу та грі на музичних інструментах.

Після легкого ланчу перейшли до літературної частини вечора, так як темою зустрічі були вірші (можливо саме через такий нахил кількість дівчат значно перевищувала кількість чоловіків).
Ксенія Іголкіна, була заявлена, як “гвіздок програми” та декламувала свої власні вірші. Любовна лірика, часом трагічна, часом світла, здобула доволі теплий відгук слухачів. Також Ксенія розповіла, що сама вона з Сибіру, так про те, як їй було не легко “прижитись” в нас в Києві. Після поетичного перформансу, вечір перейшов у формат “відкритого мікрофону” і кожний міг розповісти улюблений вірш чи уривок з книги. Власне, що і зробила наприклад, Марія, яка читала уривок зі своєї майбутньої книги “Слепая жизнь в коробочках”, про звичайні історії незвичайних людей. Також віршами та безпосередньою манерою виконання потішили Поля та Оля. Ну і звісно респект усім іншим, хто не дивлячись на хвилювання таки зважився поділись таким інтимним, як улюблені вірші.  Приємно доповнювала настрій атмосфера зали в якій проходили читання – майже в повній темряві, при світлі свічок… романтика, одним словом.

Та вірші віршами, а обід за розкладом. Як казали організатори вечора – їжа об’єднує людей. Так воно і відбувалось…  спілкуванню сприяв фуршетний формат самої вечері. Вільно можна було курсувати з келихом вина від одної частини гостей до іншої. Поговорити на безліч тем та дізнатись багато чого цікавого, трошки занурившись в плин чужого життя.
Ну а далі було продовження літературної частини, що плавно перейшла до смакуванням десерту та чаювання.
Не залишало відчуття того, що ти в гостях у когось знайомого, в домашній атмосфері з дуже приємними людьми. Також доволі незвичним виявився момент розповіді про себе (коли, ти постійно в одній компанії то всі про тебе все вже давно знають – а тут все починалось з чистого аркуша). Виявляється, що в мене доволі бурхливе життя, коли я про нього почала розказувати іншим. В повсякденні такі моменти майже непомітні, а при знайомстві починаєш згадувати найяскравіші враження чи історії, які тим чи іншим чином, дозволяють відновити в пам’яті позитивні емоції, що з ними пов’язані.
Вечір добігав кінця, усі сповнені гарного настрою потроху прощались… думаю, що то було прощання не надовго, бо після такого прекрасно проведеного часу само собою виникало бажання “на біс”. Тобто ми не прощались а розходились до нових зустрічей. Юля та Наталя, як гостинні  господині, провели усіх гостей, що були безмежно вдячні за всі ті зусилля, що дівчата доклали, щоб ми всі могли так тепло провести цей березневий вечір.

Також додам, що була дуже рада з усіма познайомитись і  величезний респект організаторам!!!

Фото Коваленко Олени (тобто мої) та та одненьке запозичене зі сторінки зустрічі. 

Кнайп-клуб “Купідон” тріщав по швам! Казали, що вже о 16:00 люди прийшли займати місця, то і не дивно, що до початку виступу в залі було, як в годину пік в метро. Мені якимось дивом вдалось потрапити в середину. На вході молода жінка “наїхала” добряче на хлопця, що збирав гроші за вхід (кошти йшли на підтримку АТО).  Аж бридко і соромно було спостерігати цей хамський торг.

Я відверто запитала ту жінку наскільки актуально торгуватись за пару десятків гривень, які підуть на добре діло. Вона зам’ялась і вже через пару хвилин почала знову качати права. Так, з місцем проведення звісно трохи прогадали. Але певно Таня Давиденко не очікувала, що збереться аж стільки людей.

То ж ми утрамбувались і автор почав своє рішуче декламування. Робив він це, як завжди так відверто, що аж мурашки бігали табунами по шкірі. А від деяких віршів стояли сльози в очах. Еміції і енергетика проймала наскрізь.

Шкода, що ноги боліли так, що довго не могла простояти, протрималась тільки годину та зовсім не жалкую!

А на вулиці тим часом творилась справжня зимова казка…

«Мелочь пузатая или Объем тест кейса против его содержательности»

Алексей Лупан
Доклад с Fun ConfeT&QA 30 октября 2013

Видео-запись доклада можно посмотреть ТУТ

Как правильно писать тест-кейсы?

Тестировщики с рождения учатся писать тест-кейсы, потом утверждают, что умеют это делать профессионально, а потом начинают постоянно доучиваться.

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

Что такое тест-кейс?

На этот хороший вопрос зачастую отвечают так:

Самым страшным является объяснение не сути того, что такое тест-кейс, а рассказ какого-то антуража, который связан с тест-кейсами. Вроде «Автомобиль — это когда я еду на работу и мне удобно и тепло»… Это приводит к тому, что когда нам, ещё маленьким тестировщикам, ставят задачу «напиши тест-кейсы», мы начинаем её выполнять, не вникая в детали, а утопая в них.

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

Проблемы

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

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

Это достаточно логичное, особенно поначалу, суждение.

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

Это приводит не к появлению нормальных документов, на которых можно основывать свое тестирование, особенно в будущем. Это приводит к появлению различных «монстриков».

Вот как выглядит, примерно, каноничный тест-кейс:

У такого тест-кейса есть:
• заголовок;
• некоторые инструкции, которые необходимо выполнить;
• результат.

Шаблон очень общий и вольнотрактуемый.

Например, вот маленький тест-кейс, в котором есть, буквально, два шага:

У него есть обязательные поля:
• ID;
• заголовок;
• указание области, к которой он относится;
• указания его приоритета;
• смысл;
• цели и задачи.

Теперь от каноничного перейдём к тому, как обычно бывает…

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

В вот тест-кейс, который всего лишь разруливает карусельку товаров в интернет-магазинах (это такая цепочка картинок, которые пролистываются влево-вправо). Старательный молодой тестировщик здесь расписал очень точно и детально, что должно появляться после КАЖДОГО клика, который делается по карусельке.

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

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

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

Почему такие проблемы присутствуют поначалу?

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

Когда-то я считал, что с самого начала нужно все объяснять, как правильно делать. Потом пришел к выводу, что не очень то и надо.

Лучше с самого начала дать возможность написать всё, что угодно, и как угодно, чтобы предсказуемо получить ерундовый документ, а потом уже объяснить, как нужно сделать «по-хорошему».

Это приходит с опытом. С опытом приходит, скажем так, усталость и чуть более грамотные вопросы.

Например:
• надо ли считать, что один кейс = одна проверка?
• надо ли каждый раз перечислять все шаги в кейсе или достаточно объявить preconditions;
• можно ли вставлять в тест-кейс картинки? (самый часто встречаемый вопрос у новичков вопрос).

Вот вопросы, которые вообще никто не задает по началу:
• Что означает термин «тест-кейс»?
• Что означает слово «кейс»?
• Зачем нужно писать тест-кейсы?
• Как нужно писать тест-кейсы?

Давайте попробуем ответить на эти самые главные вопросы. Может быть, после этого настанет просветление.

Что означает термин «тест-кейс»?

Вам привет из солнечного Индостана, от тестировщика Прадиипа Саундарараяна!

Он давным-давно написал еще небольшой документик, под названием «Правда о тест-планах, которую вы и так знаете, но не хотите признать искренне». Там был такой пунктик, о том, что 90% тестировщиков (а в Индии много тестировщиков) вообще побарабанисто относятся к тому, что означает слово «кейс» в термине «тест-кейс».

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

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

В тестировании, слово «кейс» следует переводить, как «ситуация»

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

Поэтому верны утверждения о том, что:
• один кейс — одна проверка;
• можно перечислять пошагово все действия, которые необходимо сделать, что бы привести программу в заранее продуманное предопределенное состояние;
• это все можно выносить, в так называемые, preconditions – и это будет тоже нормально;
• это происходит искусственным образом.

Вот определение термина «тестирование», сформулированное Алексеем Баранцевым, еще в начале той эпохи, когда он начал делать вебинары про тестирование:

Тестирование — это проверка соответствия программы требованиям, которая осуществляется путем наблюдения за ее работой в специальных, искусственно созданных ситуациях, выбранных определенным образом.

Если считать, что слово «кейс» переводится, как слово «случай», то чисто семантически, ни о каких искусственно создаваемых ситуациях говорить не придется. Все потому что тестовый «случай» — это когда нужно будет сидеть и ждать пока возникнет та ситуация, которую нужно будет воспроизвести для проведения теста.

Часто конструкция тест-кейсов* выглядит так:
1. Зайти на сайт;
2. Найти пару подходящих товаров;
3. Положить их в корзину.

*Мы подразумеваем, как пример, интернет-магазин.

Всё в принципе правильно:
• каждая строчка являет из себя некий приказ. Поэтому все начинается с глаголов – «зайти», «найти», «положить»;
• каждая строчка под собой подразумевает некое действие.

Поэтому вроде бы все правильно, все пошагово — сделай действие и получи определенный результат.

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

Хороший кейс мог бы выглядеть вот так:
1. В бэкофисе создать два новых товара;
2. Через сторфронт (веб-морду ) положить эти два товара в корзину.

В первом варианте тест-кейса очень много неопределенностей. «Зайти на сайт», мы еще зайдем, а вот «найти пару подходящих товаров» — такое не следует писать. Товары следует создать и очень быстро, для того что бы задействовать конкретно в данном тест-кейсе, а потом положить их в корзину. Или нужно указать товары, которые уже существуют.

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

И в данном случае, содержательность начинает превалировать над объемом. Кейс написан более чем просто. Использовано меньше слов, но содержательности в нем уже больше.

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

Ссылка на авторские размышления на тему по этому поводу — bit.ly/16JP0rQ.

Как нужно писать тест-кейсы?

Для начала сначала ответим на вопрос, зачем их нужно писать.

Однозначно тестировщики не должны их писать, а должны их использовать.

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

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

Как нужно грамотно писать тест-кейсы?

Тест-кейсы нужно писать в несколько приемов:

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

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

Но для того, что бы найти все баги (а это в принципе возможно) нужно сначала знать, что существует в программе, а чего там нет. Вот поэтому документирование будет необходимо всегда. Даже если у нас agile, даже если у нас считается, что все делается на ходу — нет, сначала продумать, потом приступить.

3. Дальше, весь упор нужно делать на идеи. Все что можно в таком реиме продумать это не более чем идеи.
• Будущие тест-кейсы нужно в принципе записать, не задумываясь о том в какие они пойдут направления, не заполняя все эти служебные поля, которые необходимо;
• Нужно сначала работать с идеями. Записанные в блокнот (Notepad в Windows) идеи о том, что можно протестировать, превращаются в отличное поле для рассуждений;
• Некоторые идеи потом можно будет собрать в логические блоки;
• Некоторые идеи отомрут;
• Некоторые, послужат основой для других идей (дополнительные соображения будут появляться всенепременно);
• Те идеи, которые останутся после такой логической работы, будут сами собой, вот уже из ничего, будут представлять нормальный чек-лист, на основе которого уже можно проводить тестирование;
• Идеи, выполнение которых будет очевидно, можно будет оставить в покое. Те, которые потребуют уточнений о том как сделать то, что предложено, можно будет превратить в тестовые сценарии.

И вот вам откровение, истинно говорю, гадом буду — совсем необязательно превращать все тестовые идеи в тестовые сценарии а потом в тест-кейсы.

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

Давайте покажу, как это выглядит в принципе.

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

Вот список идей, что можно протестировать вообще (это примерно то, как происходит работа над идеями):
1. В каталоге навести курсор на иконку любого товара и появится окно QuickView;
2. Сделать поиск по каталогу, и на странице с результатами поиска навести курсор на иконку любого товара — должно появиться окно QuickView;
3. Добавить товар в корзину. В корзине навести курсор на иконку товара — окно QuickView не должно появиться;
4. Проверить содержимое окна QuickView — название товара, цена, цвет, размер, кнопки Add to Favorite и Add to Wishlist, выбор количества товаров, кнопка Add to Cart;
5. Проверить закрытие окна QuickView — по клику на страницу вне зоны окна QuickView;
6. Проверить закрытие окна QuickView — по клику на кнопку Close;
7. Проверить закрытие окна QuickView — по клику на кнопку Add to Cart;
8. Проверить закрытие окна QuickView — по нажатию на клавишу Escapе на клавиатуре.

Некоторые идеи отмирают, некоторые генерируют новые соображения, некоторые становятся основой для тест-кейсов, некоторые тест-кейсами никогда не станут — это нормально, это всего лишь идеи.

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

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

Проверить закрытие окна QuickView — по клику на кнопку Close:
1. Открыть каталог с товарами;
2. Навести курсор на кнопку любого товара — должна появится кнопка QuickView;
3. Кликнуть по кнопке вызова квик вью — должно появится окно QuickView;
4. Кликнуть по кнопке Close — окно должно закрыться.

Должно быть указанно действие и должно быть указанно сразу ожидание.

Можно это дело упростить. Давайте тот же самый текст напишем проще.

Проверить закрытие окна QuickView — по клику на кнопку Close:
1. В каталоге товаров навести курсор на иконку любого товара;
2. Дождаться появления кнопки вызова окна QuickView;
3. Кликнуть по кнопке закрытия окна QuickView.

Но на самом деле можно еще проще тот же текст написать:
1. В каталоге с товарами вызвать окно QuickView для любого из существующих товаров;
2. Кликнуть по кнопке закрытия окна QuickView.

Тот же самый сценарий но расписанный уже в два шага – его проще читать, понимать и осознавать.

Шаг, который называют «ожидаемый результат» — его здесь нет, потому что это сценарий. И к тому же, заголовок говорит о том, что должно произойти.

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

Сначала текст прочитал, осознал, потом его выполил.

Из тестовых сценариев можно делать тест-кейсы.
1. Взять любой тестовый сценарий ;
2. Снабдить его уточнениями и деталями о том, что должно происходить ;
3. Профит.

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

Если тест-кейсы существуют — хорошо, мы их используем.

Если они не существуют, но их кто-то может написать — пускай напишет. Будем юзать.

Если нужно самостоятельно писать, то мы предпочтём вариант работы с идеями, нежели сразу кидаться писать тест-кейсы.

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

Тест-кейсы всегда пишутся итеративно, точно так же, как пишется софт в декларируемых подходах Agile.

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

Писать тест-кейсы не только утомительно, их еще и читать утомительно и рецензировать утомительно.

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

Сначала только кажется, что долго писать тест-кейс по этапам — сначала написать идеи, потом тестовый сценарий, потом собственно тест-кейс.

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

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

Тест-кейсы, на самом деле, не приносят контроль над ситуацией (то, что ожидают тест-менеджеры). Тест-кейсы приносят ощущение контроля.

Именно из-за того, что мы нелогичные, эмоциональные существа.

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

Уметь записывать быстро это важно!

Одна идея — одна проверка — один кейс.

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

Последнее соображение постоянно цитируется за авторством Брюса Ли. Я, к сожалению, не нашел источник этой цитаты, тем не менее мне она очень нравится:

Ответы на вопросы.

— Что делать, если документации нет вообще?

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

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

Тот кто:
• не умеет находить требования;
• не умеет общаться с программистами;
• не умеет общаться с менеджерами
• или тот, кто поставлен в ситуацию, когда невозможно общаться…
…ну тогда примите это как мужики, и — идите топитесь!

— Действительно ли можно все баги найти?

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

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

В принципе, это можно сделать, если напустить на калькулятор какого-нибудь робота — это раз.

Второе — если считать заранее, что невозможно учесть все варианты использования итд итп в каком-нибудь обычном веб-магазине, то это значит, что некоторые серьезные вещи могут пройти мимо сознания тестировщика, мимо сознания разработчика, мимо сознания всех тех, кто что-то делает. Но обязательно могут появиться там, где появятся пользователи. Или же появится тестирование со стороны заказчика. Заказчик не будет заморачиваться по поводу требований, заказчик просто начнет класть товар в корзину и как-то его там оформлять. Баги могут посыпаться откуда угодно.

Поэтому если тестировщик изначально знает, что нельзя все предусмотреть — топиться! Топиться, пока не придет соображение о том, что можно все предусмотреть, если спокойно и детально и внимательно ко всему этому делу подготовиться.

Однако, если готовиться ко всему этому делу с точки зрения написания тест-кейсов — это опять же будет повод для утопления.

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

— Как ты относишься к пасхальным яйцам? Если учесть, что все баги можно найти, то, что делать с пасхальными яйцами?

— Когда я работал в компании GlobalLogic, у нас там был очень грамотный программист, ахиграммотный. Он как-то на кухне сказал, что – «я вас не понимаю, я очевидно в каком-то простом месте делаю маленькую ошибку, которую вы очевидно должны найти. Тестировщики ее не находят, а находят вообще такое, что мои пасхальные яйца просто кукожатся от страха.» Поэтому все нормально, подумаешь, пасхальные яйца…

— Как соотносятся тест-кейсы и чек-листы? Одно заменяет другое? Как их вообще использовать — вместе, по отдельности?

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

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

Тест-кейсы, в принципе, необходимы для описания каких-то ситуаций, которые необходимо проверять ПОСТОЯННО. Т.е. это основа для регрессионного тестирования.

В контексте регрессионного тестирования не всегда необходимо проверять абсолютно всё. Поэтому возможно использовать необходимый задел проверок, которые будут расписаны в виде тест-кейсов — это будет отдельная документация.

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

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

— У вас, лично, где хранятся тест-кейсы? Вы пришли к чему — в гуглдоках храните или вы отошли от них?

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

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

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

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

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

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

Помните в книге «Пролетая над гнездом кукушки» Макмёрфи попытался психам показать, что можно сдвинуть с места чугунный умывальник (все знали, что это невозможно сделать), он попытался — у него не получилось. Он сказал “ну я хотя бы попытался в конце то концов”. После этого вождь (был такой персонаж, постоянно молчащий, огромный, сильный, но духом слабый индеец) все-таки понял, что это можно сделать и вырвал этот умывальник с места и бросил его в окно.

Окно раскрылось — индеец ушел на свободу.

Попередньо склавши собі програму доповідей які  хотіла б почути, я позбавила себе “мєтаній по мєсту дєйствія”.

Сама конференція була розділена на 4 потоки, які проходили в конференц-залах Президент-готелю.
Милі дівчата зустрічали всіх і допомагали в отриманні бейджів і всякого_різного_рекламного.
Також на “ранніх” пташок чекали ранкові пригощання.

Я не буду переказувати змісту кожного виступу, який я почула, лише опишу тезисно те, що запам’яталось/зацікавило.
Програма для мене почалась з доповіді Оксани Тканко, яка працює на позиції Software Engineer в компанії Skype.

Оксана розповідала про модульне програмування в JavaScript.

Як і анонсувалось, була розкрита тема Asynchronous Module Definition (AMD) API, який визначає асинхронний механізм завантаження модулів та їх залежностей.  Оксана порадила не змішувати синхронний та асинхронний код і показала на практиці чим загрожують таке міксування, що зазвичай виникає, при частковій переробці сайтів. Також було наявно показано наскільки зручним у використанні є модульний підхід та робота з окремими невеличкими файлами.

Усі свої тези Оксана підтверджувала одразу практичними прикладами, а як бонус, уся презентація була “оздоблена” котиками))) *ну куди ж без них*.

Після доповіді я зрозуміла скільки ще мені ще треба вчити.. вчити і вчити… Ну як видно з фото, до Оксани після доповіді, була ціла черга охочих поставити запитання. 
Наступною я відвідала доповідь Олександра Ремінного, який має за плечима багаторічний досвід в розробці програмного забезпечення та вже 2 роки займається автоматизованим тестуванням. Тема презентації була - “Від архітектури системи до приймальних автоматичних тестів, або тестування нефункціональних вимог”

Олександр розказував, що собою являє власне архітектура системи та вплив розробок Carnegie Mellon Software Engineering Institute. Ті хто відвідав цю доповідь змогли більш детально почути про критерії оцінки цілей S.M.A.R.T.

Якщо вірити Олександру, то достатньо 10 Quality Attributes для побудови архітектури та конкретизація кожної вимоги – *це якщо коротко.. дуже коротко*. Ну і не забудьте почитати про Gherkin language (мова бізнес сценаріїв).

Наступною в моїй програмі була доповідь Сергія Шельпука “How to take over the world with artificial intelligence”

Тут вже ніяких котиків) тільки Термінатор, тільки хадкор
Сергій вже два роки очолює створену ним одну з перших в Україні data science групу в компанії SoftServe та працює над розвитком і популяризацією аналізу даних та штучного інтелекту в ІТ комьюніті країни.

За словами Сергія, в захопленні світу головне Perception|Planing|Control.  Ми почули більше про Google driverless car та історію про створення вертольота, яким керував штучний інтелект навчений по методу Reinforcement learning.  Також Сергій розказав про особливості Markov decision processes (MDPs) та A* search algorithm.

Мені сподобалась тема про обладнання, що “навчене” в емуляторі та може самостійно контролювати запуск віртуальних машин при зміні навантаження на “систему”.
Ну і як резюме Сергій додав “А взагалі ви не можете контролювати світ, що навколо вас.. ви навіть не можете контролювати свою дівчину!” і розказав, що фіг зрозумієш, чи дівчина зрадіє квітам, чи по обличчю цим букетом зарядить.. то ж незрозуміло, коли варто дарувати, а коли – ні.

Тепер стало зрозуміло, чому чоловіки рідко дарують квіти – вони просто залякані якимись істеричними неврівноваженими жінками

Далі усіх чекав смачний обід. З бонусів – перша приватна броварня пригощала пивом, а “три медведі” морозивом. айтишникам пиво, дитям мороженое

В перерві зустріла Льошу Зозуленко, з яким знайома по твіттеру. Як виявилось, він працює QA Team Lead’ом. Поговорили про біль мого пошуку роботи та і взагалі про те, як зараз складно бути джуніором без досвіду.

А далі я пішла на виступ Слави Панкратова - “Як домовлятися із керівником та замовником: обираємо потрібний протокол спілкування”.
Слава спочатку трохи всіх привів до тями після обіду простою (але дуже веселою) математичною задачкою, а вже потім перейшов безпосередньо до основної теми доповіді. Усім були роздані листочки з характеристиками, по яким люди в залі мали вибрати ті, які на їх думку найкраще їх характеризують.

В кінці, кожен отримав певну цифру, яка відповідала кольору, а за кольором вже Слава розказував основні “ключі” підходу до кожного з психологічних типів. От так на прикладі було показано одну з інтерпретацій визначення типу з чотирьохсекторної поведінкової моделі, для дослідження поведінки людей в певному оточенні або в певній ситуації (DISC)
Якщо ви ніколи не бачили виступи Слави Панкратова – то  отримайте малесенький семпл:

Шкода, що по часу не все влізло в доповідь, що було анонсовано. Але враження від виступу найкращі, та і сама тема була найбільш близькою для мене, бо “яжеменеджер” по попередньому 6-річному досвіду роботи і нюансів взаємодії з керівництвом та клієнтами мала вище даху.

Далі в моєму розкладі було послухати, як Роман Сенів (в минулому – Agile та Lean консультант в SoftServe) розкриває тему “Doing Agile vs. Being Agile”.

Презентація була розділена на три логічні розділи:
1. We failed because vs. We succeeded despite – “как корабль назовете..”. Про те, як треба позиціонувати себе в робочому процесі. Кому потрібні фейлери та факапери? саміпонімаєтє.
2. Plan-Act-Inspect-Adapt vs. Think-Act-Inspect-Adapt – про негнучкість коли є планування (запланували від початку, але помилились, але вже важко відмовитись бо довго ж планували. А краще б подумали, спробували примінити, що підійшло взяли в повномаштабну роботу, а що не підійшло – викинули та забули, як страшний сон. Якнайшвидший перехід від гіпотез до їх верифікації. Але не все в житті так просто – зазвичай керівництво та замовники вимагають чіткого планування. То ж приходиться якось балансувати.
3. Methodology vs. Empirical Knowledge – *в цей момент презентації я примудрилась порізати руку краєчком блокноту, то ж уся моя увага була зосереджена на тому як зупинити кров, от тому я додам тільки фото зі слайдом, а ви додумайте самі ;)*

У виступі Романа мені особливо сподобався його артистизм, іноді мені здавалось, що я не на конференції а у театрі ім. Франка. Але ця “награність” не дратувала, а навпаки гармонійно вписувалась в загальну стилістику виступу. Глядачі/слухачі зосереджено слухали і внємалі.
Роман підкреслив, що дуже часто невірне трактування книжок і термінів призводить до того, що отриманий результат значно відрізняється від очікуваного. Треба не сліпо слідувати запропонованим схемам, а підлаштовувати їх під свої задачі та отримувати свої індивідуальні варіанти вирішення.

Переходячи до зали, де мала бути наступна доповідь, можна було побачити, як Jason Beres (Sr. Vice President, Developer Tools, Infragistics) відповідає на запитання після свого виступу.

Далі виступав Simon Moores (Managing Director, Zentelligence (Research) Ltd), з доповіддю “Ера можливостей, вікно у часі”. Після виступу можна було знову задуматись про те, як швидко плине час,  як стрімко розвиваються технології. Життя не стоїть на місці,  в найближчому майбутньому можна буде навіть  очікувати інтеграцію девайсів в організм людини (сприятиме найпершим чином цьому – розвиток технологій у медицині). На Саймоні були google glass і він повідав, що планується випуск зменшених версій на кшталт контактних лінз.

На початок наступної доповіді я трошечки запізнилась, але це не завадило перейнятися темою.
Олексій Єгошин (Senior Delivery Manager, Luxoft), людина з понад восьмирічним досвідом роботи в IT на керівних посадах, розказував про “Успіхи проектного управління у кроманьйонців”.
Ось декілька тез, в хронологічному порядку:
– треба завжди озвучувати те у що ти віриш;
– на початку випуску нового продукту треба завойовувати групу новаторів та їх послідовників (ті, хто завжди люблять все нове і купують заради того, щоб спробувати), а далі буде стрімкий зріст продажів;
– інформацію треба доносити так, щоб самому хотілось досягти того, до чого агітуєш;
– команду профі від команди джуніорів відрізняє вміння самоорганізованості;
– варто прочитати книгу “The Art of Possibility” Бенжаміна Цандера;
– недовіра в колективі породжує значну втрати енергії кожного. Ця енергія витрачається на оборону від тих, кому ти не довіряєш, а це значно зменшує ефективність роботи;
– кількісні показники зазвичай негативно впливають на робочій процес і зазвичай викривлюють його – Скажи що треба проект здати до 19-го числа і менеджер душу продасть, щоб це зробити, не дивлячись на можливі нюанси, які потім негативно вплинуть на подальшу долю проекту. Зате за своєчасно виконане завдання він отримає бонус.

Як десерт, організатори SoftServe-IT-Weekend залишили виступ Alistair Cockburn (Agile Guru та співавтор Маніфесту Agile). Доповідь була більше для бізнес аналітиків, власникам проектів, керівникам продуктів. А на завершення – Алістер показав відео, на яких він стрибає з мосту/скелі/літака – от такий він екстремал, виявляється.

Далі в програмі значилась невелика перерва.  Потім вручення почесної нагороди “IT Awards” – перерва трохи затяглась, бо важко було людей відлучити від фуршету)))


Але якимось дивом волонтерам таки вдалось направити всіх до конференс-зали.

Ось нагородження переможця в категорії Quality Assurance:

А так от  виглядали усі щасливі цьогорічні переможці всеукраїнської незалежної нагороди “IT Awards”.

А далі знову продовження фуршету, на якому я зустріла знайомих по QA Road Map - Влада Бабенко, Олексія Зволінськогота та Івана Панасенко (ще постійно стикалась з Валентином Коряко, але все не було змоги підійти привітатись).

Олексій розказав про свої далекоглядні наполеонівські плани,  про свій довгий шлях у пошуку роботи в свій час, і іще багато чого цікавого. Дуже натхненна вийшла розмова.

Та і взагалі вся конференція мені сподобалась – на гарному рівні була як організація так і змістове наповнення. Великий респект організаторам… і тим, хто дочитає цей звіт до кінця

На жаль в п’ятницю, я встигла тільки на закінчення виступу гурту “Хамерман знищує віруси“. Вперше про цей гурт я дізналась, ще коли навчалась в школі . Але тоді, пісні аля “Пишу стіхі а хулі толку” мене не вразили), а от зараз це був самий цимус. Вже зрозумілим став весь стьоб і пародійний сарказм. Це певно той виключний випадок, як з Подерев’янським, коли нагромадження ненормативної лексики не викликає відрази, бо ти вкурюєш тему. Цей їх виступ ХЗВ був анонсовано, як бенефіс. Крім солістів були ще цікаві комбінації – я потрапила тільки на виступ з трубачами і аккордионістом Сергієм Топором, який був в чудернацьких чоботах.   Костюми солістів теж були епічні до неможливості. А усі сценічні рухи, разом з текстами пісень, викликали посмішку, яка не сходила з вуст протягом усього концерту.

Фрагменти виступу гурту:

На наступний день я вже приїхала вчасно. Зустріла Анічку Невірковець, яка приїхала на фест з Рівного. Не буде сюрпризом, те що хедлайнерами цього фесту, особисто для мене, був гурт DRUMТИАТР. Дуже рада була бачити Юрка Іздрика, одразу підійшла привітатись, попитати про житєйскі діла. Пораділа їхньому з Грішею приїзду, бо з минулої зустрічі чимало часу пройшло.

А тим часом на головній сцені виступав гурт @TRAKTOR [Attraktor], two piece rock band, фронтменом якого є Олександр Піпа – для мене було відкриттям, що він ще продовжує творчу діяльність та ще й в такому музичному жанрі.

Фрагменти виступу гурту @TRAKTOR [Attraktor], two piece rock band:

Далі свою програму презентував гурт  Vinipuz Mob - вони потішили джазовими мотивами. Я, як завжди, мліла від звуків саксофону. Фрагменти виступу гурту Vinipuz Mob:

До вечора ще було багато часу і я вирішила поблукати по території арт-простору  на Іллінській 16. І чого там тільки не побачиш. Але на те він і арт-простір.     Потім я зустріла Таню Давиденко та Дарину Важинську. Таня була з незвично невеличким фотоапаратом, але це їй не завадило зробити класний фотозвіт.

Ну а далі був той концерт, на який я чекала увесь вечір.  Цього разу DRUMТИАТР виступали з драмером. Єдиним мінусом була та задуха, що царювала в залі, де проходив виступ. KONTRAPUNKT перетворився на сауну (при тому, що головна сцена на вулиці в цей час була пустою – незрозумілий хід організаторів). Всі мокли і пріли.. але не дивлячись на це невтомно танцювали і підспівували. 

Візуальне доповнення було просто шикарне – все в тему, ритмічно і психоделічно. Разом з голосом і музикою це все занурювало в якийсь транс, коли сам ставав єдиним цілим з цим візуально-музичним потоком.

Як на мене, то виступ був досить короткий, хоча… інакше ми б всі там задушились від нестачі кисню і передозу щастя.

Вперше наживо почула покладені на музику “Не вір (Ш) суботі“ та Predator. Прозвучала і “Києве мій” – квінтесенція столичного життя))) і лірична “Де ти літаєш“.

Після концерту мала ще змогу трохи поспілкуватись з Юрком та Грішею і подякувати за класний концерт. Ми трохи посиділи в імпровізованій лаундж-зоні за головною сценою, яка “оформлена” під совковий домашній інтер’єр – старий килим, сервант та крісло. Періодично заглядали фотографи, чим розвіювали псевдо домашню атмосферу. Хоча я і сама не без гріха – попросила Танічку сфотографувати мене з Юрком. Бо, блін, не кожного дня видається спілкування з батьком сучасної української літератури… і моїм улюбленим письменником. Щоб було потім що онукам розказати

І все було б супер, якби не треба було їхати додому (жевріла слабка надія на останню маршрутку – але, як потім виявилось, все було марно).

На душі лишилось приємне тепло від зустрічі з гарними людьми та насичення улюбленою музикою. Добре, що в Києві зараз відбуваються такі нестандартні події, які хоч якось відривають від щоденних новин, від яких може розвинутись суцільна депресія. Для того, щоб далі жити, треба натхнення – яке можна отримати з мистецтва, а в цьому випадку – від нестандартного експериментального мистецтва.

Фото та відео Коваленко Олени, тобто мої

Я учора скористалась цим методом “2 в 1″ і відвідала виступ Метью Олдріджа, що відбувся в Sky Point (“піднебесна” офісу компанії Ciklum).  Попередньо заявлена тема звучала як – «Побудова успішних розподілених команд», що обіцяла багато інформативного для Тім Лідів (Team Leads) та Проджект Менеджерів (Project Managers) в IT індустрії.

Сам Метью з Англії, має 16 річний досвід роботи в IT,  зараз працює в компанії Whatever Mobil. Перша частина доповіді була присвячена діяльності та філософії роботи цієї компанії, а друга частина – запитання з зали до доповідача.

Я не буду переказувати всю доповідь, лише виділю тезисно те, що особливо мені сподобалось та привернуло особливу увагу (це все нібито банальні і зрозумілі усім речі, але варто про це не забувати). Так от,  в  роботі команди всі мають намагатись: 

- бути максимально чесними - раз ти сказав, щось пообіцяв, то маєш виконати або “пацан сказал – пацан сделал!”

- терплячими, бо зайвий стрес і емоційність дуже заважають роботі і знижують, як мотивацію, так і якість результату;

-  бути відданими ідеї і філософії компанії. Якщо  працювати виключно заради грошей/віддавати пустопорожні вказівки/виконувати усі забаганки керівництва “бо вони ж мені за це платять” – цей шлях веде усю команду в нікуди. Треба отримувати задоволення від роботи, кайфувати від процесу та результатів! (уявляю, як зараз глибоко зітхнули песимісти/реалісти “улюблена робота.. угу, як же.”);

- постійно контактувати з членами робочої команди – щотижневі зустрічі, наради, обговорення, змістовне спілкування, яке допомагає бути всім “на одній хвилі”. Дуже важливим, за словами доповідача, є особисте спілкування, особливо, коли команди розкидані по різним куточкам планети. В такому разі треба проводити виїзди “на рідні землі” працівників – такий собі тімбілдінг.

До речі, в команді Метью працюють декілька киян, а також гамбуржці – тому часто влаштовуються зустрічі команди у різних містах (в тому числі і в Києві).

На запитання, як воно, працювати з українцями, Метью не приховуючи емоцій, сказав, що українці просто неймовірні – в них стільки енергії, бажання досягти успіху і поставленої мети. Українці більш активні ніж німці, які мають і гроші і високий рівень життя. Німці більш розслаблені, в порівнянні з українцями, які постійно в пошуку нових знань і досвіду.  Дуже приємно було чути гарні слова про своїх співвітчизників від профі IT сфери.

Також було питання – “наскільки важко чи легко інтегрувати Agile в роботу деяких компаній?”. На це Метью відповів, що зміни це завжди важкий і болісний процес, але потім, коли люди бачать результат, розуміють – все це було не марно.

Щодо теми звільнення з роботи персоналу, то тут недостатньо просто помахати ручкою і сказати гудбай! Важко приймати це рішення і ще важче про таке повідомляти. Але цьому, загалом безрадісному процесу,  Метью додав позитивного емоційного забарвлення. З одної сторони, звільняючи ти робиш добро самій людині (бо звільняєш від обов’язку,  який не по силам),  а з іншої сторони – ти робиш добро компанії (бо на місце звільненої людини може прийти хтось, хто буде працювати ліпше і любитиме те, чим займається).

Взагалі Метью склав дуже приємне враження розкутої та впевненої в собі людини, професіонала, яка віддана своїй роботі та має гарне почуттям гумору.

Резюмуючи, можу додати  – Keep calm and work like a boss!

Є така давня традиція у роллерів – Роллер-Ямакасі – “це зустріч сходу сонця, на яку кожен роллер самостійно або маленькими групками добирається до місця збору, для зустрічі того самого сонця.”

Моя перша така покатушка була 9 травня 2010 року, схід сонця  планувалось зустріти біля оглядового майданчику у парку, що недалеко від Меморіалу Вічної Слави.

Ми собі зібрались разом, зустріли схід сонця, попили чаю.. і тут до нас підійшли представники міліції і в грубій формі попросили поїхати, бо вдень біля меморіалу має бути урочиста подія, а ми забруднюємо роликами територію (брєд сівой кобили). Ну ми не конфліктні, пофоткались та поїхали.

І потім, вдома, добряче виспавшись після ночі, з новин я дізналась, що урочисті дійства на тому місті таки пройшли… і Януковича, на тій урочистій події, прибило вінком. Думаю ви всі добре знаєте про той інцидент. Якщо ні, то можна освіжити в пам’яті – відео ТУТ. От такий життєвий збіг.

Але менше з тим… повернемось до світанкового Києва.

На минулому тижні я вирішила приєднатись до ямакасі, тим більше, що не працюючи можна собі дозволити спокійно віддати одну ніч для катання нічним містом, а потім пів дня спати. З дому я виїхала о 2:30 ночі. Приблизно через годину ми вже більш менш великою групою прямували через Труханів острів до пункту призначення, яким був оглядовий майданчик на Володимирській гірці.

Який же прекрасний Труханів острів перед світанком. Напередодні, в вечері, як раз пройшов дощ і повітря було неймовірно свіжим. Потроху прокидались пташки і починали свої ранкові пісні. Хоча це більше було схоже на перекличку.  Якби кожна пташка, яка починала співати, в той момент підсвічувалась пульсуючими променями, як маячок, то увесь ліс потроху зайнявся б природною світло-музикою. А загальна мелодія була б ніби світловий шлях, що простирається від одної пташини до іншої… от така світло-музично-природна психоделіка народжувалась у думках, поки я їхала ідеальною асфальтованою дорогою через Труханів острів, жадібно вбираючи легенями його свіже вологе ранкове повітря, десь на 20-му кілометрі свого маршруту. На зворотньому шляху я вирішила знову проїхати тим самим маршрутом.

Промені сонця, що ледве пробивались крізь хмари, потроху осяювали обриси міста. Знову сходи до пам’ятника Магдебурзькому праву, але краще сходи, ніж долати цей шлях по Володимирському узвозу. А далі – пішохідний міст, де у цей ранковий час можна було зустріти багато дивних нетверезих осіб, спілкування з якими краще уникати, надаючи перевагу спогляданню світанкового неба.

Також, тільки на зворотньому шляху, звернула увагу на дивну споруду. Як виявилось, це занедбаний, ще в радянські часи, ресторан “Відпочинок”. Раніше він виглядав ТАК.  А тепер він от такий: Більше про нього інформації я не знайшла, на жаль. Взагалі, для мене залишається дивною тенденція будування подібних розважальних закладів на тому місці, де загинуло стільки людей (зокрема в часи другої світової війни). Може тому, доля цього ресторану саме така – стояти занедбаним багато десятків років. Але дивно, що його ніхто ще  не привласнив і не взявся перебудовувати.  Зовнішній вигляд споруди викликав бажання скоріше знову повертатись до лона Труханівської вулиці з її зеленню та природністю, бо цей пострадянський індастріал навіює сум і журбу.

То ж знову насолоджуючись поїздкою я прямувала в сторону дому… Попереду було ще приблизно 15 кілометрів шляху і багато часу, щоб подумати над усім, про що не думається в інший час.  За це я і люблю такі київські світанки, коли місто і ти разом з ним, стаєте трохи інакшими. Таке враження, що свідомість відкривається, щоб сприйняти те, про що раніше навіть і не міркував. 

А як ви любите зустрічати світанки? 

Фото Олени Коваленко, тобто мої.

Отримавши запрошення на Мореквартирник від Аліни Цвєткової я не сумніваючись погодилась. Минулого разу Аліна організовувала квартирник з DRUMТИАТР‘ом, після якого я познайомилась безпосередньо з Юрієм Іздриком (незабутній вечір, про який можна почитати ТУТ).

Квартирник був приємним продовженням дня, який почався з відвідин відкриття другого сезону арт-пікніка Слави Фролової (окремий звіт ТУТ).

Префікс “море-“, в назві заходу, був не просто так - на сцену проектувалось відео з морським прибоєм, що чергувалось з фотографіями (звісно, теж на морську тему). І все це, разом з інтер’єром закладу створювало неймовірну атмосферу. Такий собі ефект присутності на морському узбережжі. Ми з Олею (яка спонтанно вирішила скласти мені компанію, за що їй окрема подяка ) одразу знову згадали нашу подорож в Одесу, з якої ми повернулись за тиждень до цього.

Програму вечора розпочала вже знайома по минулому квартирнику Mr.Light з гітаристом. Дуже приємно було почути в її виконанні знайомі пісні.

Потім зі своїми віршами виступала Катерина Бабкіна. ЇЇ поезія гарно доповнили вже створену ліричну атмосферу. Деякі з віршів зачіпали ледь не до сліз. Катя зізналась, що твори на квартирник вибирала по пошуку (Ctrl+F), за словами “море” і “океан”. Хочу зазначити, що добірка прекрасна вийшла.

Навіть Катін образ був дуже романтичним – довга сукня, підібране волосся… все як треба. Вірші поєднувались зі звуками морського прибою, але потім його вимкнули за проханням Бабкіної, бо трохи “укачувати” почало (але залишився відеоряд, то ж атмосферність не була порушена).

Далі нас чекала знову музична частина – своїм виступом потішила Тетяна Гаврилюк зі своїм авторським проектом “Tanya Tanya” (я Таню більше знаю, як одну з учасниць фрік-кабаре Dakh Daughters, на виступ якого я ніяк не можу потрапити вже рік як).  Смугаста грайлива Таніна сукня теж добре гармоніювала з темою вечора.  Я вперше була на живому виступі Тані, то ж кожна з пісень була для мене новою. І всі вони мені дуже сподобались.

За бездоганне виконання публіка, що зібралась того вечора, щедро віддячувала оплесками. Також після пісні про ляльку, ми почули страшну історію про Анатолія Москвіна, яка раптово закінчилась актуальним і всім відомим слоганом про Путіна (і пісню і історію можна побачити ТУТ).

Про Москвіна реально було страшно слухати – уявіть, вечір, ми в такому специфічному закладі, що по суті знаходиться в старому будинку, приглушене світло і ця прекрасна дівчина розказує нам про дядька, який трупи викопував на цвинтарі… Жесть, одним словом.

Але менше з тим… також Таня виконала пісні на слова Бродського та Шевченка, і пісню про Крим. В кінці всього виступу всі аплодували стоячи, по крикам  “браво/біс” видно було, що ніхто не хоче відпускати Таню. Разом з тим, хотілось, щоб цей вечір тривав ще…

Взагалі квартирник вийшов прекрасний! Справдились усі очікування і навіть більше! Повний ефект присутності моря, майже домашній затишок, приємні емоції…

Завдяки тому, що в мене було натхнення знімати відео, більшу частину виступів Катерини Бабкіної і Тетяни Гаврилюк ви можете побачити на моєму youtube-каналі (який я нарешті довела до пуття).

То ж ті хто був на мореквартирнику – зможете знову згадати, як то було. А хто не зміг прийти – побачите, що ж ви пропустили.

Я навіть спрощу вам справу
ТУТ відео з виступу Каті
ТУТ відео з виступу Тані

Одразу прошу пробачення за якість відео, “я нє волшебнік, я только учусь”

Ще раз велика подяка організаторам Мореквартирника – це було неймовірно душевно і атмосферно! 

Аліна і Саша, дуже була рада вас обох побачити

Фото Олени Коваленко, тобто мої.
Афіша взята ТУТ

…кличеш на допомогу “Ну де ти, де ти, де?!”, а тебе рятують зовсім не ті, на кого ти розраховував. І порятунок, як виявляється, полягає зовсім не в тому, що тобі здавалося порятунком, а чимось набагато кращим.

Юрій Андрухович

31 травня погода у Києві дуже нагадувала львівську і це було дуже символічно, в контексті того, що мало відбутись того вечора в Мистецькому Арсеналі.

В стінах древньої зали мали розгорнутись події, що відбулись у Львові 1641-го року, навколо Альберта Віроземського, якого було привселюдно спалено посеред львівської площі Ринок.

Коли всі місця були заповнені глядачами (а їх прийшло чимало), погасло світло і почалося дійство… Це була мультимедійна вистава «Альберт, або Найвища форма страти», яка створена на основі неопублікованого оповідання Юрія Андруховича.

Ольга Михайлюк, як режисер, поєднала на сцені декілька стихій – текст, музику і візуальний ряд. Зробила вона це досконало і професійно. Спробую розкласти по компонентам:

Юрій Андрухович, як автор-оповідач смакував кожне своє слово та демонстрував не аби яку артистичність разом з неймовірною харизматичністю. Багатогранний тембр голосу та манера викладення історії – це ті “інструменти”, якими Юрій володіє досконало!

Уляна Горбачевська, з неймовірним голосом,  який проймав кожну клітинку. Її спів створював таємничу та містичну атмосферу, підсилював образи, які змальовував текстом автор. А ще, мене захоплювала її майстерність виконання – це ж не просто спів, це чисте виконання своєї “партії”, в паралельному звучанні з контрабасом, фоновими звуками та читанням тексту.  І додайте до того всього пластику танцю і акторську гру. Коли Уляна зображує перемовини львів’ян під час страти, то ти чітко уявляєш, що все так і було.. і жодних сумнівів, бо це львівський темперамент, львівська говірка, львівська аура (не дивлячись на те, що справа йде про львів’ян далекого XVII століття).

Марк Токар, вводив у естетично-музичний транс своєю грою на контрабасі та читанням тексту. Його було не тільки цікаво слухати, а й спостерігати. В цій постановці Марк на сцені був музикантом, актором і співаком. З Уляною вони утворювали шикарний тандем. Музику, яку видобував Марк зі свого інструменту була ніби четвертим учасником всього дійства. Це вам не записи, що зроблені завчасно – це справжня жива музична стихія, яка охоплює і не відпускає від першої і до останньої хвилини. 

Тоді, якщо музика була четвертим учасником дійства, то п’ятим компонентом цієї алхімічної суміші мистецтв, був візуальний ряд, що проектувався на полотно позаду акторів. Автором майстерної візуалізації п’єси є Анатолій Бєлов, талановитий київський художник. Художня анімація, скомпільована vj-group «CUBE» та звукове обрамлення, професійно зроблене Віктором Новожиловим, передають тонкі переплетіння сюжету з деталізацією елементів. Характерним йде почерговість переваги в візуальному наповненні чорного та білого кольорів.

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

На створення історії, що лягла в основу сюжету постановки, Юрія надихнули записи про Альберта Віроземського, знайдені в хроніках кримінального світу Львова, як говорить сам автор. То ж ми маємо ніби класичні протистояння добра та зла, чорного та білого, релігії та містики.. але не дивлячись на це розвиток сюжетної лінії досить непередбачуваний.

Треба також зазначити, що Ольга Михайлюк вже не перший рік співпрацює з Юрієм Андруховичем у різноманітних проектах. Так, наприклад їх творчий тандем отримав перемогу на Міжнародному конкурсі відеопоезії «CYCLOP» в Києві, з роликом “Ніж та Ніжність“ на вірш Андруховича. Марк Токар і Уляна Горбачевська також мають спільний проект Ultramarine, з яким вони виступали на чималій кількості фестивалів. А робіт vj-group «CUBE» взагалі не перелічити.  То ж Ольга Михайлюк не дарма об’єднала саме цих людей в роботі над постановкою “Альберта” і не прогадала. 

Після закінчення, ще довго лунали оплески і вигуки “Браво!”, що є найкращим показником успіху вистави! Від себе також хочу подякувати усім причетним до цього неймовірного дійства і можу тільки уявити наскільки феєричною була вистава напередодні у Львові.

Моя вам порада – якщо в вашому місті буде йти “Альберт, або Найвища форма страти” не вагайтесь ні секунди – йдіть за квитком, як це зробила я! Не пожалкуєте!

Фото Олени Коваленко, тобто мої.
Афіша запозичена з сайту http://ye.ua/news/news_15163.html

31 травня в Мистецькому Арсеналі відбулась творча зустріч: “ШАКЕСПЕАРЕ: ГРА З КЛАСИКОМ. Зустріч з Юрієм Андруховичем, Іваном Малковичем та Владиславом Єрко“.

Андрухович з Малковичем читали уривки з “Гамлета” (книга 2008 р. видавництва А-БА-БА-ГА-ЛА-МА-ГА, що отримала Ґран-прі на 15-ому львівському книжковому форумі). Була озвучена також інформація про перевидання, за участю талановитого ілюстратора  Владислава Єрко.

Іван Малкович, власник і директор видавництва«А-БА-БА-ГА-ЛА-МА-ГА»,  повідомив, що вже є готовий переклад Шекспірівської трагедії “Ромео і Джульєтта“, але є ще деяка заковика… заковика – це сам Єрко, що ніяк не може зробити до неї ілюстрації. Дуже кумедно було, коли Малкович і Андрухович привселюдно просили Владислава Єрко, щоб той вже швидше доробляв свою роботу, а той ставав на коліна і казав, що все обов’язково зробить. Вийшла така собі комедійна постановка, яка не дисонувала з гарним теплим настроєм, що панував у залі. По закінченні зустрічі, можна було придбати ілюстрації Владислава з автографом автора (спочатку ціна була 80 грн, але через те, що не було чим давати решту, то вартість знизили до 50 грн). Звісно, що Юрія Андруховича не оминула автограф-сесія.

Публіка на цій зустрічі була дуже різноманітною. Біля мене, наприклад сіли дідусь з бабусею, яким було на вигляд не менш як по 80 років, а на ряд далі були дівчатка підлітки. Якраз переді мною сиділа письменниця Катерина Бабкіна з Ольгою Жук, що є куратором Міжнародного фестивалю “Книжковий Арсенал“.

Взагалі зустріч була дуже приємною і залишила по собі лише позитивні враження та надії на те, що найближчим часом нова книга побачить світ – книга, яка дозволить насолодитись класичним твором Шекспіра в українському перекладі Юрія Андруховича.

А далі нас чекав спектакль, про який я писала на початку…

Фото і відео Олени Коваленко, тобто мої.
Афіша запозичена звідси