ДБ: Так, ось ці хлопці..

Дев1: Нє-нє-нє-нє-нє-нє-нє-нє, Девід Блейн, не чіпай нас! Що ми тобі зробили?

Дев2: Відстань, демон!

ДБ: Привіт, хлопці. Я шукаю особливі, ВУЛИЧНІ баги. Хочете побачити вуличні баги? Ось ти, що ти робиш?

Дев1: Форму замовлення обіду, зрозумів? О-БІ-ДУ! Ланчордер нах! Отут вибираєш зі списку що подобається, тиснеш Замовити – і вуаля, завтра тобі його привезуть!

Дев2: Та, Девід Блейн, не мішай нам, тут багів нема, йди звідси. Білд саксес, всьо заїбісь!

ДБ: Білд саксес кажеш.. Ану вибери мені зупку з печериць, відбивну з макаронами і банановий пудинг..

Дев1: От приставучий… Во! На, маєш! Тиснем Замовити… Шо за нах!!!! Зупа молочна  з оселедцем, каша перлова, огірки квашені в сметані! Йо-ма-йо, демон, ти що зробив????!!!!! Де нормальне замовлення????????

Дев2: В рот мну ноги!!! Ти чого ланч-ордер поламав, демон? Фак мій мозг!!!!

ДБ: 0_о

Також тут.

Пакунок – подарунки та сувеніри ручної роботи.

Ви мусите прочитати цю книжку, якщо працюєте з тестувальниками.

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

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

Отримав цю чудову книжку завдяки конкурсу від компанії EPAM – за що їм вельми вдячний

вчені Гарвардського університету, що тестували обчислювальну машину Mark II Aiken Relay Calculator, знайшли метелика, що застряг між контактами електромеханічного реле й Грейс Хоппер вперше вжила цей термін. Знайдена комаха була вклеєна до технічного щоденника, з супроводжувальним надписом: «First actual case of bug being found» (англ. «перший випадок у практиці, коли було знайдено комаху»). Цей цікавий факт став передумовою для вживання слова «баг» у значенні «помилка».

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

Зі святом, колеги!

Отак виглядав перший баг-репорт (зображення із Вікіпедії):

Перший баг-репорт

Інформація з onQA.org.ua.

Трохи про конкурс – звичайний тест на Brainbench‘і на тему Software Testing, хоча для мене така форма тестування була повністю новою. 40 питань по 3 хв на кожне.

По ходу тестування виписав собі кілька невідомих до того абревіатур і прізвищ – буде що почитати.

Чекаю на результати…

Оновлено: Став щасливим власником книжки Lessons Learned in Software Testing

“One way for smart people to be happy is to express themselves, to put out in the world the vast melange of thoughts and feelings whirling in their heads.” Jerry Weinberg (тут)

“Discipline is motivation without reason” James Bach (тут)

“Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it.” Walter Chrysler (тут)

“In theory there is no difference between theory and practice. But, in practice, there is.” -Jan L.A. van de Snepscheut (тут)

37signals про те, як засвітитися: 10 ways to “get ink”

Brian Marick – бути програмістами вже не хочуть: Programming retreats to its niche

Менеджмент@Блог: Закони людської тупості

onQA: Баг vs Фіча в картинках

“You don’t think it’s a coincidence we sold Livejournal to the Russians, do you? The same country that just put Kasparov in jail for daring to suggest the election might have been rigged? Read the press-release. Livejournal is the blogosphere in Russia, and now every bit of data, every single private post is stuck halfway between Putin and the Russian Mob“ – CEO SixApart про продаж LiveJournal

Google Cheat Sheet -можна повісити на стінку і лякати співробітників

The purpose of testing is to collect, analyse and disseminate information. Testers do not write code, they do not put bugs in and do not take bugs out. In this respect, we do not improve quality or add value to the products we test. We are however responsible for providing the most valuable information required by developers (to fix bugs), project management (to understand achievement and product-risk) and stakeholders to recognise business value. In this one respect, testing is all powerful – it is the single source of knowledge of achievement in software projects.

Щодо самих порад, то їх кілька:

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

Оригінал статті Джеррарда.

Про те, звідки ж тестувальникам отримати інформацію про тестований продукт – Міхаіл Єличєв (Михаил Елычев) на IT4B

Матеріали SQA 2 стали доступними в мережі.

Тепер хочу звернути увагу на інший аспект цієї, а також інших конференцій. Спершу маленький вступ.

Ще студентом, беручи участь в організації проектів в рамках діяльності львівського представництва міжнародної молодіжної організації AIESEC, я помітив одну особливість: з великої кількості організованих проектів багато було проведено на хорошому рівні, тобто цілі були досягнені, учасники і організаційний комітет задоволені тощо, але дуже мало було по-справжньому вдало завершені. Я маю на увазі не стільки останній день чи закриття конференції чи проекту. Я маю на увазі те, що мали би зробити (і зробили чи не зробили) організатори після закінчення проекту. Чи були надіслані подяки спонсорам; чи було зроблено обіцяний адрес-бук і розіслано учасникам; чи було проведено оцінку проведеному заходу (SWOT хоча б…), чи проводився моніторинг преси тощо.

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

27-28 вересня відбулася конференція Quality Assurance: Management & Technologies. Сьогодні 2 жовтня. На офіційному сайті останні зміни датуються 29-им червня (“Last change 29 June 2007“). Заклики відсилати заявки на участь тощо… Жодного відгуку про перебіг конференції. Попробуйте пошукати:) Лише згадки на сторінках організаторів та партнерів, і то анонси.

Я відчуваю, що приділяю цій конференції забагато уваги, але це дуже показова ситуація – щось зробити і залишити недоробленим. В процесі конференції мав запуститися spin-ua.org. На момент написання цих слів він все-ще закликав відвідати QAMT 2007…

Знову напрошується питання: навіщо проводити такі конференції?

В першій (Test Developers Shouldn’t Execute Tests) автор аргументує свою думку щодо того, чи потрібно тест девелоперам виконувати тести. На його думку, команди тестувальників повині бути чітко поділеними на тих людей, які пишуть автоматичні тести (тест девелопери), і на тих, хто їх виконує. Тобто обов’язок виконання тестів не повинен лежати на його творцях. Ось причини:

• За умов, коли тест девелопери витрачатимуть значну частину свого часу – нехай 15% – на те, щоб інсталювати машини, налаштовувати тестові середовища, виконувати тести, з’явиться велика кількість людей, які захочуть бути не тест девелоперами, а програмістами. Такий стан справ, за яких тест девелопери виконуватимуть роботу тестувальників, звузить коло тих, хто захоче писати автоматизовані тести.
• Крім того, написання коду вимагає довгих відрізків часу без відволікаючих факторів. Відтворити баґ, прогнати BAT-тест – все це відволікає і знижує ефективність основної діяльності – написання автоматичних тестів.
• Багато тестів простіше виконати вручну, аніж автоматизувати. Якщо людина буде відповідальною за виконання тесту і за його автоматизацію, з’явиться спокуса просто виконати тест вручну (бо так швидше). Але, витрачаючи більше часу на ручне тестування, в тест девелопера залишається менше часу на автоматизацію, що в свою чергу веде до збільшення часу на виконання тестів…
• В кінці кінців, є питання спеціалізації. Чим більш спеціалізованими є люди, тим більш продуктивною є їх робота.

Найпоширенішими запереченнями до описаного підходу є наступні:

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

Один із коментаторів до цієї статті, керівник проекту testingReflections.com Antony Marcano, серед іншого запитав у своєму коментарі, чи потрібна тоді взагалі така роль як тест девелопер на проекті? Чи не варто залучити програмістів до написання автоматичних тестів?

Do We Still Need Test Developers? є відповіддю на це питання. І відповідь Стіва Роу є: “Так, нам потрібні тест девелопери”. І ось чому:

• Тест девелопери, попри те, що використовують ті ж засоби, що і програмісти, думають по-іншому. Якщо програмісти восновному концентруються на позитивних аспектах продукту, який розробляється, то тест девелопери звертають увагу на негативні варіанти: крайові умови, неправильний тип вхідних даних, нетипова операція тощо.
• Тест девелопери фокусуються на інтеграційних тестах, які є складнішими в автоматизації і потребують іншого підходу, аніж юніт-тести.
• Існують підходи, специфічні для тестувальників (model-based testing, data-driven testing, класи еквівалентності, pairwise testing), які не знатимуть програмісти. Тест девелопери їх знатимуть або матимуть стимул вивчити.
• Крім того, наявність окремої групи розробки автоматичних тестів в межах команди тестування може певним чином убезпечити останню від урізання бюджету (як в грошах, так і часі, виділеному на тестування)

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

Вирішив я подивитися, що ж відбувається найближчим часом недалеко від Львова. Вибираю регіон “Європа”, і що я бачу? Серед списку міститься… конференція в Україні! І не коли-небудь, а в найближчі вихідні!

Називається це чудо – Quality Assurance Management & Technologies, QAMT, (офіційний сайт) і відбуватиметься в Києві 27-28 вересня. 2007 року звичайно ж.

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

“первая украинская международная конференция в области качества и тестирования программного обеспечения, QA – аутсорсинга, современных QA-менеджмента и QA-технологий, а также других сопутствующих направлений международного IT-сотрудничества в Украине, России, странах СНГ, Европе и США.”

… угу…

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

Далі – більше:

“Тематика QAMT насыщенная: стандарты качества, методики тестирования ПО, риск-менеджмент, новые возможности на новых IT-рынках, CMMI сертификация, инструменты для автоматизации тестирования и многое другое. Участникам QAMT Ukraine 2007 будут представлены широкие возможности общения между собой. QAMT Ukraine 2007 широко освещается в средствах массовой информации. Ведущие профильные издания в Украине выступают информационными спонсорами Конференции.”

Які це такі профільні видання? Ага, одним із організаторів є bettersoftware.eu. Цікаво, дивимося програму… Програма рясніє заголовками типу CMMI Certification чи ASDP, також трапляються теми і не такі глобальні… Ага, ще й якусь сертифікацію проводять… Гм… Що ж, можна з’їздити, хоча вікенд вже був розпланований, але чого не зробиш задля підняття професійного рівня І тут стається найважливіше: я бачу ціну участі.

180 ЄВРО.

З людини. За два дні.

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

Натомість зберуться керівники компаній, топ-менеджери, поговорять, познайомляться/зустрінуться ще раз… Ну ще якість адепти сертифікації приїдуть пройти черговий екзамен…

Ось чому не було чути про цю конференцію на моєму рівні. Ось чому такі люди як я не будуть там присутні. І ось чому, як на мене, жодного впливу така конференція на стан тестування ПЗ як галузі не матиме. Тоді навіщо її проводити взагалі?

p.s. В рамках конференції планують запустити Ukrainian SPIN – Software and Systems Process Improvement Network. Цікаво буде глянути…

• Стів Роу (Steve Rowe) написав дві статті про тест девелоперів: Test Developers Shouldn’t Execute Tests та Do We Still Need Test Developers?
• 450.org.ua – Рейтинги депутатів за результатами голосувань у Верховній Раді – знайди близького по духу депутата чи фракцію. Плюс цикл “Професійний виборець” від Отара Довженка
• На testingfaqs.org відкрилася сторінка з розкладом QA-конференцій

А що там у Вас?

Скажу зразу – базою зарплат від ДОУ користуюся більше року, тоді як сервісом від IT4B почав користуватися менше місяця назад. Тому порівняння не буде точним і на об’єктивність не претендує в будь-якому випадку. Також порівнюватиметься та функціональність, яка має цінність для фахівця QA, який працює в Україні.

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

Пройдемося по кроках, які пропонує IT4B:

1-Визначення регіону:
на ДОУ я маю можливість вибрати місто де працюю (“Львов“), а не абстрактне “Украина (кроме Киева)”

2-Визначення професії:
в it4business є “Тестировщики ПО“, в ДОУ: “менеджер по качеству“, “менеджер по тестированию“, “тестировщик“.

3-Визначення посади:
в розділі “Тестировщики ПО” є вибір з п’яти посад спеціалістів із тестування, що з одного боку робить звіт по зарплатах більш специфічним, а з другого боку впирається в наступну проблему – я, до прикладу, не можу точно сказати, чи я є суто “Тест-дизайнер“, чи “Тестировщик ПО: ручное тестирование“, чи “Тестировщик ПО: автоматизированное тестирование (функциональное и нагрузочное)“. Хоча це знову ж таки суто моя проблема – десь же мусять бути люди, які 40 год в тиждень складають тесткейси . Погляд в майбутнє – більша специфічність по посадах може зробити базу зарплат на it4business точнішою.

Описані три кроки – все, що пропонує нам (можливо наразі) проект it4business. В доу в запасі ще є:
- “Технологии” (для QA цікавими варіантами будуть “Rational“, “RUP“, так само як і “Ruby” чи “Perl“. Плюс можна додати свій варіант)
- додаткова інформація про компанію (все-таки є різниця між роботою в компанії з 3-4 людей і з кількох сотень)
- додаткова інформація про працівника (вік/стаж/стать/освіта)

Це щодо анкети.

Тепер про звіти – на it4business я вибірок з бази зарплат не бачив – можливо просто зараз замало даних. На доу щорічно пропонуються вибірки по технологіях, посадах, регіонах, індустрії або мовах розробки (ну останнє для QA великої цінності не має). Власний звіт можна згенерувати наразі хіба у вигляді “тестувальник, 2 роки роботи на посаді, не Київ” Знову ж, не ідеал, але “маємо те, ще маємо” .

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

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

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

•  Зарплаты специалистов по тестированию в Украине (кроме Киева) – проект it4business теж вирішив рахувати гроші українських тестувальників (на мою думку, база зарплат на ДОУ стоїть на голову вище)
• Synthesize Your Test Data  - в тестуванні тестові дані мають важливе значення
• A Testing Career in 3-D та A Tester’s 4th Dimension – Management – про якості хорошого тестувальника і чи вистачить їх для керівника групи тестування (by Danny R. Faught)
• ще одне слово про управління тестувальниками: Scrum Meetings for Test
• і про управління загалом – Clarity: The Most Important Management Deliverable? (обидві статті by Steve Rowe)
• How To Automate UI Testing – від того ж Steve Rowe – “The better way is to not test the UI”
• і под кінець викладені в мережі матеріали двох конференцій - O’Reilly Open Source Convention та РИТ (тут навіть про юзабіліті говорили!)

А що там у Вас?

[ENG] Keep Your BVTs Clean – про BAT тести. Коротко і по темі.

[ENG] What is working software? -трохи прикладної філософії.

• Ultimate List of Free Windows Software from Microsoft – у M$ теж пишуть безплатний софт (сторінку краще відкривати експлорером, моя опера чомусь мала з нею проблеми)
• Automation Stack – про процес автоматизації тестів. Багато, детально і розумно.
• “Too Much Testing”. Grrr!

І на останок – еволюція дизайну продуктів Apple (jpg).

І для львівських романтиків, а також усіх, в кому ще не вмерла дитина – планується викид позитиву в атмосферу!

Так що можете забігти, шановні колеги, якщо будете в тих краях Мені до Києва задалеко

Увага: всі дві презентації вестимуться російською.