I know I’ll never feel the same
I know I may never accept the change, but I want…
Happiness…
©

Неймовірно приємною стала новина, що Київ увійшов до гастрольного туру улюбленого гурту IAMX.
Від моменту придбання квитка до концерту була ніби вічність. І от час {X} настав.
Концерт мав відбутись в київському клубі Sentrum о 20:00.
На вчасний початок я не розраховувала, але все ж приїхала на годину раніше… і була в шоці від черги до клубу, яка закінчувалась десь біля ТРЦ Гулівер (тобто це приблизно кілометр черги).
Такого я ще не бачила за весь свій багаторічний досвід відвідування концертів. Зазвичай організатори за годину запускають глядачів, щоб ті спокійно наповнювали залу та касу бару (тим більш у зимову пору, коли стояти на вулиці і морозити собі кінцівк найменше хочеться). Добре, що я зустріла своїл любих рівненських дівчат Аню і Таню (якби не вони, то я певно ще б зайву годину мерзла у тій черзі).

Десь близько 21 вдалось потрапити у сам Sentrum (нагадаю – концерт мав о 20 вже початись(!)). Охоронці “приязно” пояснювали, що якщо хтось буде виявлятизайву активність, то всіх попруть знову на вулицю – це_якийсь_капець_а_не_організація!

Не пройшло й і ще години, як на сцені з’явились IAMX. І так сумарно маємо 2 години затримки.
Але після епічного виходу Кріса Корнера, з пляшкою вина і величезним букетом, всі пробачили і чекання на холоді у черзі і всі інші негаразди.
А далі півтори години чистого музичного кайфу. Енергетика, яку випромінюють музиканти, просто неймовірна. Новий альбом звучить шикарно. Під час Insomnia в мене з’явились сльози на очах. Важко описувати словами всі ті емоції, що переповнюють, коли чуєш настільки сильне виконання пісень, які так любиш.
Наспівалась до хрипу, натанцювалась до болі в ногах.. і як бонус перебування під сценою – масаж ліктями від усіх, хто був поруч))) та то невеличка плата за те, що виконавці були на відстані витягнутої руки.
Це був прекрасний вечір – дякую всім причетним!

Фото Олени Коваленко (Тобто моє).

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

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

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

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

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

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

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

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

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

Приємною несподіванкою стала новина про те, що буде змога знову побачити улюбленого письменника сучасності, Юрія Іздрика в Києві.

21 грудня, в рамках “Тижня літератури” від PinchukArtCentre відбувся презентація нового медіапроекту Юрія Іздрика та Євгенії Нестерович – Summa

“Summa – це путівник для тих, хто потрапив на цю планету випадково, і перебуваючи у перманентному здивуванні, потребує духовної підтримки та інтелектуальних провокацій. Ми – туристичне агентство; жерці порталу; випадкові перехожі, що зустрілися вам на шляху саме для того, щоб ви запитали у нас дорогу. У всіх незрозумілих випадках – відкривайте цей путівник на випадковій сторінці. І буде вам щастя, хоч ніхто й не гарантує вам”. ©

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

Після виступу я підійшла привітатись, та сказати, що я буду на концерті. На що Юрко сказав “Обов’язково приходь – будемо заряджати позитивом!” – ну як тут було не повірити.

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

Як і на презентації зала була повна людей, і це свідчило про цікавість до того нового, що мало бути далі – а мало бути от що – Юрій Іздрик і Таня_Таня виступали в творчому тандемі. Вони зачитували вірші Юрка, під електронні мотиви, що були зкомпільовані Іздриком під час перебування на фестивалі MERIDIAN CZERNOWITZ. На біс публіка вимагала щось з репертуару драмтиатру, але Юрко сказав, що це його репетиція, то ж грати будуть вони те, що він хоче)

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

От таким чином я сходила на концерт і мимоволі прийняла в ньому участь)))

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

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

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

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

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

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

Завдяки IT-клубу 10per, холодним осіннім вечором відбулась тепла зустріч з Романом Савлюковим, представником однієї з компаній-лідерів індустрії відеоігор WarGaming .

“Тестування webApp на мобільних пристроях” - так називалась доповідь Романа.

Сама тема одразу мене зацікавила, так як частково перетинається з напрямком моєї роботи. Я сподівалась на те, що Роман стане променем світла в світі секретів та специфічних нюансів роботи тестувальника, на долю якого випав моніторинг роботи веб-сайтів на мобільних пристроях.

Мої сподівання не були марними, а бонусом став приємний тембр голосу доповідача так що, поєдналось приємне і корисне)))

Трохи тезисів, які були озвучені Романом:

•  Для естимації та побудови тест-кейсів важливо знати конфігурацію сайту, який буде тестуватись. Зазвичай конфігурації веб-сайтів діляться на три категорії:

1. Ті, що мають окремий url для мобільної версії  (Mobile.example);
2. Responsive – ті, що мають адаптивний дизайн;
3. Гібриди.

•  В структурі сайтів з адаптивним дизайном є окремі папки з JavaScript та CSS, для роботи сайтів на мобільних пристроях та десктопних версіях браузерів;
•  Завдяки емулятору в Chrome, що відкривається через консоль браузера, можна побачити, як виглядатиме сайт на тому чи іншому пристрої;

Ось так, наприклад, буде виглядати мобільна версія сайту imdb.com, якщо емулювати відкриття цього сайту на Iphone 6 plus:

Браузер відправляє інформацію на сервер через user agent. Сервер отримує інформацію про те, звідки користувач відкриває сайт (версія браузера, дані про пристрій та інше).

Наприклад:

• Для сайтів типу Responsive набір ресурсів один і той самий для мобільної і веб-версій;
• Також, для сайтів з адаптивним дизайном, задається окремо положення елементів, що буде залежати від того, на пристрої з якою роздільною здатністю сайт буде відкрито;
• При запуску сайтів  гібридного типу, на мобільних пристроях, спочатку завантажуються ключові елементи сайту, які в першу чергу мають відкриватись на мобільній версії.  Це, в першу чергу, зроблено в цілях оптимізації роботи сайту в умовах використання мобільного інтернету;
• Сайти, що мають гібридний тип, не настільки поширені, як наприклад, сайти з адаптивним дизайном.
• Для визначення вибірки пристроїв, на яких буде проводитись тестування, краще використовувати аналітику по відвідувачам сайту. Таким чином можна визначити преференції цільової аудиторії сайту до певних операційних систем, пристроїв, браузерів тощо;
• Тестування на мобільних пристроях дає кращі результати, ніж використання емуляторів.

Особливості тестування.

• сайти з окремим  url для мобільних версій потрібно тестувати повністю, як на десктопних версіях браузера, так і на мобільних пристроях – так, як можна вважати, що це окремі два сайти з різним кодом, то ж і помилки в них теж різні можуть виникати;
• Для сайтів з адаптивним дизайном, тестування краще починати з десктопних версій, а потім переходити до тестів на мобільних пристроях. Це пов’язано з тим, що помилки знайдені в десктопних варсіях гарантовано будуть дублюватись і на мобільних. Також треба проаналізувати, які елементи однакові для десктопної і мобільної версій, а які різні (зазвичай цю інформацію можна отримати у розробників);
• Треба не забувати, що клік в десктопній версії і тап\свайп в мобільній версії – це різні функції. Тому треба тестувати з особливою ретельністю всі випадаючі списки, меню, роботу з буфером обміну, радіо-кнопки, динамічні елементи сайту та їх “реакцію” на клік\тап\свайп;
• Одним з нюансів, при тестуванні мобільних версій є взаємодія компонентів сайту з екранною клавіатурою. То ж треба обов’язково перевіряти, як себе поводить сайт, коли на екрані з’являється клавіатура;
• Ще важливо тестувати сайти на предмет поведінки елементів при зміні положення екрану (горизонтальне\вертикальне положення);
• Паралельне одночасне проведення одного і того самого тест-кейсу на різних пристроях допоможе зекономити час, що йде на тестування і одразу візуалізує різницю у відображенні сайту;
• Для того, щоб спростити ввід довгих посилань, можна використовувати сервіс Goo.gl, який генерує короткі посилання;
• При розрахунку часу, який буде відведено на тести, треба брати до уваги, що на тестування на мобільних пристроях буде йти вдвічі більше часу, ніж на тестування десктопних версій сайтів.  Це частково пов’язано з витратами часу на створення та обробку скріншотів, які ще й треба передавати з мобільного пристрою на комп’ютер.

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

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

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

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

«Глядач» нічого не відповів і панувало те саме незручне мовчання, про яке казала Міа, одна з героїнь тарантінівського кримінального чтива.

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

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

- Ну то що? Ти такий варіант розглядала? Ти певно сама все розумієш, ми ж дорослі люди, правда? – Він широко посміхається, але його погляд зовсім не іронічний.

- Я, звісно, можу просто відвезти тебе додому, дорогою розповідаючи історії зі свого минулого, але в мене є краща пропозиція. Сядь трошки ближче… - і якою б Вона не була впевненою , у своїй витримці… і як би твердим не було рішення, не піддаватись на провокації (в першу чергу провокації своїх власних бажань), але цей його наказовий тон робив свою справу… Вона виконувала те, що він їй казав, ніби передчуваючи, що будучи «хорошою дівчинкою», Вона отримає все, чого забажає. І перше бажання вже почало здійснюватись…

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

Алексей Лупан
Доклад с 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 расписано. Мы по ним тестирование проводим регулярно, багов там уже практически нет. Баги начинают появляться там, где заказчик без всяких тест-кейсов просто ковыряется у себя в сайте и начинает обнаруживать проблемы.

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

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

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

Чим більше заглиблююсь у нетрі матеріалів, які вивчаю, тим частіше виникають цікаві аналогії – певно це так підсвідомість намагається вкласти отриману інформацію в потрібні “комірки”. Ну а на фоні вирує життя, з’являються нові знайомі, старі знайомі відкриваються з нових сторін, світ не стоїть на місці. Іноді деякі фрагменти інформації чітко складаються до купи, як фрагменти пазлу.
Ось трошки моїх спостережень:

1. “Якщо хочеш, щоб чоловік проявив до тебе інтерес – полиш його в спокої!” (для чоловіків, відповідно «Чем меньше женщину мы любим, тем больше нравимся мы ей», як сказав класик).
А паралельно я читаю про витік пам’яті при роботі програмного забезпечення. Наприклад, якщо відкривати і закривати firefox (навіть з пустою сторінкою без контенту), то на певній черговій ітерації він “зжере” до біса пам’яті і система підвисне.
От воно і в житті так, чим менше смикаєш людину, тим кращим буде ваше спілкування потім. А постійне нав’язливе вкорінення в повсякдення може викликати бажання цьому всьому зробити hard reset і втікати подалі.
Так що, майте в усьому міру і буде вам щастя.

2. Деякі думають, що якщо система підвисла то 100500 кліків вирішать проблему. В такі моменти фантазія малює дуже зосереджену людину, в голові якої чиняться мозкові процеси, йде обміркування вирішення важкої задачі.. а поруч сидить хтось і постійно штурхає в бік “ну що ти, живий? Ти взагалі там щось думаєш? Давай швидше!”. В такому випадку всім зрозуміло – щоб дійсно було швидше, то треба, як мінімум перестати штурхати. Але коли справа доходить до роботи з програмним забезпеченням та обладнанням, то чогось деякі забувають про цю логіку.

3. Ще одна ситуація з життя – ставимо якийсь софт на комп, ну наприклад Intel® Hardware Accelerated Execution Manager (Intel® HAXM), а при інсталяції він тобі видає: “This computer does not support intel virtualization technology (vt-x). haxm cannot be installed”. Ну що робити, так склалось. В haxm свої вимоги, які твій комп не задовільняє.
Ну а наприклад вам відмовляє людина, яка вам подобається – одразу якось нєпріятнєнько стає. Думаєш “та блін, що ж не так?!”, виникають образи, настрій псується, депресняк і всє дела… а паритись нема чого, просто в вас конфігурації не зійшлись. Ну що тепер – не жити далі?) Ну так, все не зовсім як ви собі планували, хоча в Release Notes.txt чорним по білому було прописано системні вимоги, але ж надія помирає останньою от Він теж казав, що любить струнких блакитнооких блондинок, але “ну а раптом” все одно варто було спробувати.

На цьому певно варто зупинитись, поки не виникла остаточна плутанина між чоловіками, софтом, блондинками та іншим вищезгаданим.
Зрештою, кожен бачить те, що хоче бачити.
Та ці пазли, ще раз нагадують, що деякі “закони” однаково діють, як в IT, так і у відносинах між людьми.

А кому влом це все читати подивіться, як прикольно хропе колібрі

А тепер про мою спонтанну подорож. Про конференцію для тестувальників Файне.QA я дізналась ще місяць тому, але фінансових можливостей поїхати в мене тоді не було, то ж нічого собі такого не планувала. А от коли до конференції лишилось 2 дні, мені знову на очі трапилась інформація про цей івент у стрічці друзів. Виявилось, що мої знайомі Олексій Зволінський та Влад Бабенко (про яких я писала ТУТ і ТУТ), були в складі доповідачів.

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

О 4-й ранку ми рушили з Києва у напрямку файного міста і об 11-й вже були на місці.

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

Місцем проведення організатори вибрали Тернопільський національний педагогічний університет імені Володимира Гнатюка. В стінах навчального закладу певно усім згадались студентські роки.



Сама програма конференції була наступною:
11:30 – Реєстрація
12:00 – Вступне слово
12:10 – Сергій Болгов та Дмитро Вітвер – Testing VS QA (FORTÉGroup)
12:50 – Володимир Войтович – Usability Testing (eMagicOne)
13:30 – Олексій Зволінський – From Manual QA to Automation (Ciklum)

14:00 – Coffee & Cookies

15:00 – Владислав Бабенко – TestLab (DOOR3)
15:40 – Михайло Дубінський – Microsoft’s Latest Software Testing Tools (Eleks)
16:20 – Марта Пастернак – QA Education (Quality Assurance Group)
17:00 – Заключне слово, Q&A

Приємно вразила велика кількість людей, що прийшли – аудиторія де проходили виступи була заповнена майже повністю. Але певно це і не дивно, бо Файне.QA є першою конференцією в Тернополі на подібну тематику.

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

А ось виступ Олексія Зволінського “From Manual QA to Automation”:

Ну а це – Влад Бабенко з доповіддю “TestLab”:

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

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

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

Після конференції ми вирішили відвідати ресторацію Ковчег, а потім поїхали в Бункермуз, де відбувалась основне AfterParty. Під вечір вже майже не було сил, бо все таки ми майже не спали в дорозі, то ж до ранку ми не гуляли

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

Погода тішила сонечком і теплом. Поснідавши в Старому Млині, ми з Мар’яном, який був нашим гідом, рушили до ставу (ну а куди ж ще).

Нафотографувались, випили кави в Кармі, пройшлись центром, пообідали в ресторації “Файне місто Тернопіль“ (до речі, там дешева Бехерівка та Єгермейстер. Я зміксувала непоганий коктейль з Єгермейстером та лимонадом місцевого виробництва) та рушили на Київ.

За кермом була Юля, яка впевнено керувала машиною і терпіла той балаган, який був в салоні всю дорогу – ну а що… ми жваво обговорювали методики тестування, Льоша мені розказував про Continuous Integration, Влад – про типові питання, які він ставить на співбесідах.. все це змішувалось з веселими жартами (іноді на межі фолу) – сумувати не доводилось))) Ну і як бонус Юля підкинула аж додому (чому про це завше пишу – бо живу я у віддаленому куточку Києва, тому це неабияка послуга – довезти аж в ті краї, тим більше після такої довготривалої подорожі).

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

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

Фото Коваленко Олени (тобто мої) та Івана Панасенко.