Web app testing at QA club meeting #8

У вівторок, 5 червня, QA club Kiev проведе чергову зустріч на тему тестування вебу.
Я готую доповідь, адже розповідатиму про "Selenium як тренд в автоматизованому тестуванні - помилки, яких можна уникнути".

Реєстрація на зустріч ще відкрита, поспішайте;)
http://www.qaclubkiev.com/2012/05/qa-club-kiev-8-web-application-testing.html

SQA days 11. Instead of day 2.

Написати звіт про другий день конференції кортіло ще під час останньої доповіді.

Однак втома взяла гору, а потім почалася довгоочікувана відпустка:)

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

SQA days 11. Day 1. Overview.

Сьогодні хороший день:) І на це є мінімум дві причини: по-перше, приємно бачити оновлений інтерфейс блогспоту (віііііі), а по-друге - саме сьогодні, 21 квітня, пройшов перший день одинадцятої міжнародної конференції спеціалістів у сфері якості програмного забезпечення SQA days в Києві. Було справді цікаво, і день був насичений, - особливо приємно, що кожна доповідь запамяталася, і хочеться згадати про кожну з них, тому далі - я це і зроблю. А поки -

LONG TEXT BELOW

LISTGEEKS- not one of those TODO lists

Для любителів організації інформації у вигляді списків зявився приємний соціально-орієнтований сервіс - http://listgeeks.com. Його можна використовувати як звичайний туду-трекер,  однак набагато цікавіше використовувати для створення особистих рейтингів, а потім ділитися цим з друзями через інші соціальні платформи.

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



Приєднуйтеся:)

Testing Dojo - по гарячих слідах

Сьогодні у як завжди гостинному приміщенні компанії Lohika пройшов перший в Києві Testing Dojo, де пять команд-учасників змагалися та навчалися застосовувати свої скіли дослідницького тестування (exploratory testing) на парі десктопних програм.

Метою dojo було не знайти найбільшу кількість багів (хоча наприкінці саме це визначало переможців), а за час коротких тест-сетів налагодити ефективну взаємодію з іншими членами команди, визначити ролі та, керуючись евристиками  FCC CUTS VIDS  протестувати дві запропоновані програми.

Хоча нічого складного не передбачалося, кожен відчув як труднощі роботи в команді так і переваги планування тестування і визначення ролей. В той час як власне тестувальник тестував програму, один або два спостерігачі не зводили з нього очей, підмічаючи баги, які той пропустив, або продумуючи тест кейси. Особа у ролі реєстратора інтерпретувала усі комунікативні процеси, аналізувала і записувала баги у human readable форматі, що, як показав етап підбиття підсумків, не завжди виходив таким читабельним:)  

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

Закінчився dojo теж яскраво - за кожну знайдену багу командам нараховувалася певна кількість очок, відповідна до типу бага (functional, UI, security). Представники команд за 5 хв презентували свої знахідки та на ходу категоризували їх. 

І навіть після нагородження переможців (нашої команди Crashers - юхуу!), деякі учасники dojo до-досліджували програми, обговорювали знайдені баги та ділилися своїми враженнями від участі заході такого цікавого формату.

Було яскраво:)

Гадаю, не одна я з нетерпінням чекатиму наступного Testing Dojo, так як це реальна нагода перевірити свої скіли приємно провівши час. 

Beautiful testing

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) by Adam Goucher - ця книжка заінтригувала мене своєю назвою, і, прочитавши передмову, я вже було почала сподіватися на своєрідну Cookbook - hot tasty test.
Однак я помилялася. Краса цієї книжки - в її оригінальності. Це не збірка рецептів, це збірка статей більше 20 авторів, згрупованих з благородною метою - не тільки нести світло в маси тестувальників, але й зібрати кошти на придбання москітних сіток для порятунку людей від малярії.
Книжка складається з трьох частин:

• beautiful testers
• beautiful process 
• beautiful tools

Чесно кажучи, перша стаття мене не дуже зацікавила - то був твір-роздум на тему "Хто такий тестувальний, що він відчуває і чому він особливий". Однак подальші розділи вже більше поглинали мою увагу.
Як на мене, варто звернути увагу на статтю Лізи Кріспін - Beautiful testing as the cornerstone of business success. У ній вона розповіла про процес становлення Agile процесів у їхній команді, про впровадження автоматизації і про стовідсоткову успішність цієї затії. Дуже надихає.
А загалом - книжка трохи розчарувала. Ці статті зорієнтовані на всіх і водночас ні на жодного. Одні - суцільний код, інші - навпаки, суцільна філософія. На противагу статтям про майндмапи - статті про сервер-сайд тестінг. Якось так - хотіли сказати багато, а кожен сказав, що хотів. Я ж так і не знайшла того, на що очікувала.
Однак кілька цитат, які дозволили уявити профіль "красивого" тестувальника, я все ж таки вихопила:)

• Про якості 
• Testers, however, are  paid to tell you the truth as they know it. Sometimes that means telling your baby is ugly and why.
• Tester is intelligent, analytical and learns fast. ...They are, in fact, always learning.
• Good software testers do not validate function. Their tools do that for them.
• Good software testers supply critical information about value to people who care about the value
• Great software testers make aesthetic judgements about the suitability of the software for various purposes... 
• Про обовязки
• As a dedicated tester (on an agile team), it is your business to zoom around the project looking for high-risk items to investigate.
• Your business is to listen carefully to what is happening around you, advance your own work in that context, but listen especially hard to find the places where a problem might happen soon, and find a way to prevent it if you can.

Five Minutes on Mondays: Finding Unexpected Purpose, Peace, and Fulfillment at Work

by Alan Lurie

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

Алан Лорі - пастор та водночас бізесмен. Книжка насправді є організованою та обєднаною однією їдеєю збіркою лекцій, які він виголошував в різних місцях для різної аудиторії та з єдиною метою - допомогти людям зрозуміти, що таке spiritual bussiness, що можна і треба бути успішним та забезпеченим, і розвінчати стереотип брудного першого мільйона.

Одна з ключових цитат - one person’s gain need not be another’s loss - траплялася мені й у автобіографії Тоні Блера. Як бачимо, є люди, які в це вірять, і які стають красномовним свідченням успіху та бездоганної репутації, що декому здається непоєднуваним.

Як би там не було - книжку я прочитала з великим задоволенням, уникаючи розділів, які розтлумачувати сто разів розтлумачене (на щастя, таких було небагато), і раз-у-раз натряпляючи на цінні думки та цікаві алегорії, ба навіть мяку іронію як от "Most businesspeople have the typical retinue of business books in their offices—such familiar titles as Good to Great, Who Moved My Cheese, Freakonomics, and The Seven Habits of Highly Effective People"

Тож - Five Minutes on Mondays: Finding Unexpected Purpose, Peace, and Fulfillment at Work - нотатки нижче:

• The ideal job combines Meaning, Pleasure, and Strength.

Software breaking mindset

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

Власне мені не раз доводилося переконуватися, що прямолінійне слідування планам та приписам дає тільки ті результати, на які очікували. 

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

До чого ж я веду:

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

Кейс другий - теж не без музики:)

Якось тестуючи нашу ecommerse систему, я слухала улюблені треки. Одного моменту до мене хтось підійшов із запитанням і я почала зменшувати гучність, натискаючи кнопки на панельці навушників. Уявіть собі моє здивування, коли я раптом помітила, що регулювання гучності змінює css веб-сторінки. Тихіше - колір темніший. Голосніше - колір світліший. Humpty-dumpty.

Bussiness value? Аж ніякої.

Цікаво? Атож!

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

Хочеться знати про нього все:) І ласт-фм сумісність в тому числі.