Звіт з TestBash Netherlands 2018

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

Багато всякого надавали

Організація

Усі матеріали обіцяли викласти тут: https://dojo.ministryoftesting.com/events/testbash-netherlands-2018
Конференція була невелика як Голландія, до 200 людей. Проходила в приміщенні діючої церкви. Був один потік, все англійською, хоча половина доповідачів були голландці. Cеред відвідувачів голландців теж була, мабуть, половина.
Розклад доповідей був мені незвичниий: 2 доповіді підряд по 30хв кожна, без перерви, потім 30хв перерва, і знову 2 доповіді. 
Обід був 90хв. Бо люди прийшли поспілкуватись!
Насамкінець, після 99-секундних промов усіх бажаючих було пиво у сусідньому барі, а я не пішов, бо мав родинні справи. Але може і на краще. Не все одразу.
Спікерів відрізняло вміння тиматися на сцені та робити всяки рухи. Було цікаво дивитись, часом нагадувало спектакль. Думаю, нашим треба походити на гурток театрального мистецтва. 
Відео записували, але сказали не чекати наступного тижня, і навіть через один. Куди їм там до Selenium Camp 2018!

Спроба класифікації видів тестування

Пояснюючи новим адептам тестування ПЗ, які бувають його види, фази, типи, рівні (чи які там ще слова рандомно використовують недолугі сіллабуси?), мені щоразу приходиться відповідати на питання, накшталт:

- Яка різниця між смоук і юніт тестами?
або
- Пенетрейшн тест - це різновид стрес-тестів?

Звичайно, перед тим як відповісти, я переживаю множинні фейспалми. 
Але доки людина просто не запам’ятає всі ці, інколи зовсім не очевидні, визначення, такі питання неминучі. Можливо, саме через це ISTQB початкового рівня не рекомендують здавати новачкам? Бо у тому трясовинні, яке вони подають як "база знань", годі розібратись навіть із досвідом.

Звіт з мітапу Kyiv Testers Jan.17 + QA Club Kiev #20

Це було дуже круто! Найкращий вечір середи, який можна уявити!
Тут можете глянути трохи фоточок та залишити свої коментарі https://www.meetup.com/Kyiv-Testers-Meetup/events/246707197/
Дуже мене радують київські коворкінги із конференційними залами. За не дуже велику плату можна так круто потовктися в центрі :-) Дякую Часопис-Eduspace!

Завдяки аудиторії з QA Club Kiev нас назбиралася повна кімната (ще пару людей, і комусь прийшлося б стояти, дякую всім, хто не змогли прийти :-) ).

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

Звіт з мітапу Kyiv Testers Nov. 29

По-перше, дякую всім, хто прийшов на нашу зустріч Kyiv Testers' Meetup!
І хоч із зареєстрованих 60+ було лише 19, це дозволило, як сказав Джеррі Вайнберг, "намазувати варення" досвіду товщим шаром.

Хочу одразу перепросити за невеличку затримку з початком. Я думав, що багато людей запізняться. Але свідомі тестери були настільки свідомі, що після 19-30, оголошеного початку, прийшло лише пару людей. Слухачі виявилися організованішими за доповідачів :-)

Першим доповідав про хайпову тему "тестування продуктивності" Макс Войтко. Ось його слайди: Performance for Small Projects і його фоточка:

Відмінності тестування web та desktop

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

Очікування - Вимоги - Реальність

Нещодавно я знову побачив відому діаграму Венна, яку часто використовують адепти школи контекстного тестування (цього разу на презентації на QA Fest 2017. Ilari Henrik Aegerter. What is Context-Driven Testing?).

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

Області 4 + 7 + 5 + 2 - Записані вимоги 

Області 1 + 4 + 7 + 6 - Очікування клієнтів 

Області 6 + 7 + 5 + 3 - Фактичний продукт 

Тільки збільшення областей 6 та 7 додає вартості проекту та задовільняє потреби бізнесу.

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

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

Звіт з події "QA Club Kiev #19 event: ISTQB - to be or not to be"

Вчора відбулася вже друга за місяць подія формату "па́рного змагання" чи дискусії, цього разу за моєї участі.
На цій 19ій зустрічі  QAClubKiev я намагався переконати аудиторію та мого шановного опонента, Олександру Ковальову, що від сертифікації "ISTQB Foundation Level' більше шкоди ніж добра. А вона, у свою чергу, доводила мені та публіці протилежне. 

Добра піраміда - погана піраміда

Разом із усвідомленням необхідності писати автоматизовані тести, програмісти все більше загрузають у болоті тестерської термінології (вони думають, вона є узгоджена >:-E  ).

Просто пірамідки, що обертаються з TUTORIAL 1 - OpenGL Fundamentals http://www.naturewizard.at/tutorial0104.html

 Усі тестери, що починали саме як тестери, намагаючись щось автоматизувати, інтуїтивно хочуть у своїх "авто-тестах" повторювати ті самі кроки, що робили руками до того. Але у певний момент зіштовхуються з проблемою підтримки UI-них авто-тестів. І після болісних ударів долі їм нарешті являється "священна піраміда автотестування", яка їм наказує:

Звіт з QAFest 2017 про тестування та автоматизацію

Із вдячності згадаю, що Svitla Systems повністю заплатила за мій квиточок на QA Fest. Це добре. Всі фірми мають спонукати своїх співробітників до професійного спілкування.


Перша частина мого звіту Про керування тестуванням

Ну і продовжу про інші доповіді, де я встиг побувати.

Jeremias Rößler, ReTest, "Applying AI to Testing"

Звіт з QAFest 2017 про менеджмент

Відгудів QA Fest, відгудів на ньому я, і навіть моя голова після нього вже теж відгула :-) .
Хоч я і не доповідав, але класно потовкся серед розумних людей, а з деякими з них навіть хильнув після першого дня конфи.

Друга частина звіту: Про саме тестування

Організаторам QAFest - величезний респект! Атмосфера була чудова, вдень - QA, ввечері - фест. Відповідно назві!
Для учасників на буклетах були досить забавні тестувальницькі завдання і навіть кросворд! (100 років не розгадував кросвордів) 
За правильні відповіді, а також за фотки зі спікерами давали якісь призи. Тому молоді тестувальниці/ки скажено полювали за доповідачами. Така увага мене остаточно переконала таки піти кудись виступити :-) 

 Їжі було багато.

6 речей, що б повчити тестувальнику в 2017

Якщо ви досить довго перебуваєте в ІТ-спільноті, то Ви, безумовно, помітили нещодавній рекрутерський бум. "Сіньйорам" це здається цілком звичайним "білим шумом", але зараз не тільки в Україні, але й у всьому світі, зростає попит на мідл, і навіть на молодших програмістів, тестувальників та всіх інших людей, які тямлять у розробці програмного забезпеченні.
І це не дивно. Автоматичні виробничі лінії та 3D-друк зробили товари дешевими та доступними на стільки, що вони такими ще ніколи не були. Тож чим менше людей задіяні у виробництві товарів, тим більше людей готує для цього програмне забезпечення.Але зростаючий попит викликає конкуренцію всередині ІТ-ринку праці. Вже ходять легенди про бонуси, що найбільші компанії платять інженерним командам, щоб ті продовжували працювати над продукцією компанії, а не на власний старт-ап. ІТ-фахівці часто відчувають себе (навіть своїми гаманцями) як рок-зірки! Щоб взяти участь у цих перегонах за долари та славу, требатпостійно вивчати та оновлювати свої знання про нові технології та інструменти. Нижче перераховані деякі штуки, які, на мою думку, можуть зробити привабливим Ваше резюме, а професійні рішення - відповідними останнім тенденціям.

Тестатон - Суддівський погляд

Пройшов тестатон TestUAStartUps#6.
А перед ним мене попросили дати настанови суддям. Ось, що я їм казав:

Скоро новий тестатон! І для мене велика честь, що мене знову запросили туди у якості судді. Цього разу я спробую хоча б кілька годин побути і учасником теж: пошукаю й позаводжу баги, "сфокусуюся на головному для користувачів", як я сам завжди раджу учасникам.

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

Але мало просто знайти баг, треба його добре локалізувати, гарно і зрозуміло описати, та правильно визначити важливість. Саме ці три оцінки складають повний бал за баг-репорт. 
 В оцінку опису входить "загальний екстер’єр" баг-репорту та наявність скріншоту чи відео, коли це необхідно. Але навіть добре описаний баг із неправильно виставленою важливістю вже не отримає максимальний для цієї важливості бал. Тому годі сподіватися, що поставивши скрізь Severity = Critical ви наближаєте себе до перемоги. Якщо Critical виявляється Minor'ом, то команда не отримає навіть максимальний бал за Minor. 
Те ж саме стосується локалізації багу. Гарно описаний та правильно зважений баг, що має 7 кроків відтворення замість 3 теж є кандидатом на зниження загальної оцінки.

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

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

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

Сподіваюсь, цього разу побачити багато дуже важливих та ще більше недуже важливих багів, але щоб всі вони були цікаві й непересічні :-)
Наснаги та натхнення!

Техніки Тестування "З Досвіду"

Анлійську версію цієї статті опубліковано на EUROSTAR's Huddle as Experience-based Testing Strategies

 
На різних ресурсах з тестування програмного забезпечення часто згадують деякі загадкові “Experience-Based Test Techniques” (Засновані на досвіді техніки тестування). Для мене це завжди звучало як "от доростеш до наших літ, тоді й узнаєш". Але коли я сам став вчити тестуванню, то не міг нормально пояснити, що воно таке. Бо "досвіду" трохи важко навчити :-). Можна вигадати деякі практичні завдання, зроблені так, що студенти щось вивчають, але неможливо зробити так, щоб вони вивчили точно мій досвід.

Test Design Techniques by learnthebasicsofsoftwaretesting.blogspot.com

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

Чи потрібен текст повідомлення у багрепорті?

Днями розповідав своїм студентам про те, що обов’язково треба вставляти текст повідомлень у Actual Result - наявний результат тесту у звіті про помилку. Ніби все зрозуміло і очевидно. Але потім у завданні кількох студентів побачив опис, що обурив моє почуття прекрасного:

Всі (принаймні, молоді тестери) чомусь думають, що поля Наявного (Actual Result, AR) та Очікуваного (Expected Result, ER) результату мають бути спорідненими, заповненими приблизно однаковими словами. Часто навіть бачу багрепорти, де ці поля відрізняються лише присутністю чи відсутністю частки "не". Табличка результатів тестування виходить гарна та однорідна. Я вважаю, що це "шкідлива однорідність". Бо вищенаведені поля мають принципово різну ціль, і мають бути заповнені відповідно до свого призначення, а не "для гарного візерунка".

Чому треба обов’язково додавати повідомлення в Наявний Результат?
Тому що це дозволить програмісту знайти ті місця в коді, де викликається показ саме цього повідомлення; і виправити логіку саме в тому випадку, що описаний у кроках відтворення, звісно якщо це необхідно.

Чому не варто, а часто навіть шкідливо, додавати текст повідомлення в Очікуваний Результат?
Тому, що це багрепорт - повідомлення про помилку - а значить логіка роботи системи потребує зміни. І ми дізна́ємося, які саме зміни були внесені, і яку шкоду покращення було зроблене тільки згодом. Тому зараз, коли ще навіть невідомо, чи це баг, і тим більше не відомо, як і коли його будуть фіксити, не можна диктувати програмістові з майбутнього, якими словами його логіка буде звертатися до користувачів. 
Але навіть тоді, коли логіка виправлення здається дуже ясною, як на картинці вище, багато всього залежить від контексту, який неможливо вмістити в одне речення звіту про баг. 

Звіт із Selenium Camp 2017, про continuous deployment

Якщо хтось ще не помітив, усе рухається в бік Continuous Deployment/Delivery - постійного впровадження, коли ніхто не чекає Релізу, а просто викочує усі зміни на продакшен кожні 11 секунд, як Amazon.
Навіть якщо зараз у вас не так, треба звикати, що все постійно оновлюється і змінюється. Я навіть не здивуюся, якщо скоро випуск і оновлення нових версій мобільних додатків зроблять примусово-обов’язковим, і навіть їм можна буде релізитись що 5 хвилин :-)

Отже, як працюють розробники за Continuous Deployment?

Звіт із Selenium Camp 2017, про метрики

Продовжу писати свої нотатки про Selenium Camp 2017. 

Інші частини:
    Про архітектуру тестів
        Про Continuos Deployment
 

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

Метрика села Северинівка, severyn.org

Що і чим міряють(ся) тестувальники у 2017?

 

Тестування UI сайту

"У нас були зміни лише на UI-ї, повністю регресію проганяти не будемо." - казали вони.

У Джеррі Вайнберга був чудовий розділ про "колиско́ві слова", і "лише" - одне з них. Щоразу як тестер чує "лише" - тестер починає нервувати. Або навпаки, радіти, бо в повітрі запахло багами :-)

Хочу поділитися своїми намітками про те, що треба брати до уваги, тестуючи "лише UI" якогось сайту (не прив’язано до платформи).

Питання на співбесіді: Потестуйте логін-форму

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

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

Тому, на мою думку, першим тестом має бути перевірка від "доступу за дурно", тобто:
1. Спроба логіну із порожніми полями - нема доступу.

Далі, має бути перевірка "недоступу" за неповними креденшелами:
2. Спроба логіну з порожнім паролем та вірним логіном - нема доступу.

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

Сподіваюсь, комусь це пояснення допоможе!

Я особисто стикався з випадками, коли починали тестувати з пункта 3., забуваючи про 1. та 2., і баги, пов’язані з ними, вилазили аж за кілька місяців на продакшені, залишаючи систему вразливою, покладаючись тільки на те, що "злі хакери" не встигли нічого зробити.

Being a Remote Tester

Being a people person, my first priority when seeking a new testing job always was a Team. Moreover, last couple of years I've been working in agile development team, mostly as a Scrum-master, with tight daily collaboration with developers (all sitting next to me) and whole-day-round chatting with a product owner (being remote but always available for any conversation during my working hours). I used to be aware of all processes and conversations going on in the team. I even could give a rough estimate instead of developers. Our team was really cross-functional and agile.

But the projects move in and out, companies grow and blow up.

So it was a time for me to move on. After almost a year of looking for a team/project that would be as good as the previous one, I gave up and accepted a proposal that made me an only team-member on the Europe continent with 10 hours time difference with the rest of the team. At that moment I truly felt what Gerald Weinberg puts in his Secrets Of Consulting: 

Struggling to stay at home can make you a wanderer.
Struggling to travel can make you a stay-at-home.

And I'm surprised how comfortable I am now in my new "stay-at-home" status!

Книга Алана Пейджа "The A word"

Автор - Alan Page (його блоґ: angryweasel.com, твіттер: @alanpage), працює в Microsoft.

Книга невеличка, але чудова (коштує лише 2 бакси на leanpub), не така вже й нова (я її купив ще коли долар був по 8). Можливо, вона мені найбільше сподобалася через те, що думки автора щодо автоматизації збігаються з моїми:
 

You should automate 100% of the tests that should be automated.