Як виявило вчорашнє опитування, 2/3 можуть сказати "хороший" про рік що минає. Вважаємо це добрим знаком, врешті решт, все що було - це досвід :)

🎄 В Новому 2021-му році бажаємо всім нам щоб недоліки 20-го були пофікшені, а його нові, цікаві сторони розкрилися на повну!
Розвитку та здоров'я! 🥂

Modern Testing
#learnit #theory

Новий рік почнемо з нових концепцій.
Багатьом з нас добре знайома фундаментальна теорія тестування та деякі з концептуальних надбудов над нею, обумовлені вимогами сучасності, наприклад: Agile Testing, що до якого ISTQB навіть окремі екзамени має, або ж TestOps, про який ми детально писали тут і на DOU.
Нещодавно відкрив для себе ще одну з відносно свіжих концепцій: Modern Testing.
Її авторами є Alan Page та Brent Jensen. Перший - ведучий автор книги "How we test software at Microsoft", другий - його колега-ведучий в достатньо популярному подкасті про тестування "AB Testing". Давайте коротенько розповім про що вона, та навіщо вона вам.

❓Що:
Modern Testing, це набір принципів.
Пряма аналогія - Agile Manifesto.
Тобто не покроковий рецепт організації тестування, і не опис профілю тестувальника в сучасному світі. Це філософія, основоположні принципи, якими (на думку авторів) мають керуватись спеціалісти для того щоб робити якісний софт.

💡Цих принципів 7:
1️⃣ Наш пріоритет - вдосконалення бізнесу
2️⃣ Ми прискорюємо команду, допомагаючи в пошуку, пріоритезації та запобіганню вузьких місць системи
3️⃣ Ми є рушієм постійного вдосконалення, допомагаючи команді адаптовуватись та оптимізовуватись замість надання сачку для ловлі багів
4️⃣ Ми плекаємо паростки кращої культури якості в команді, тренуємо та ведемо до вищих ступеней її зрілості
5️⃣ Ми віримо в те, що саме клієнт - єдиний хто здатен судити про якість нашого продукту
6️⃣ Ми інтенсивно використовуємо дані, щоб зрозуміти клієнтські сценарії та закрити прогалини між гіпотезами продукту й впливом на бізнес
7️⃣ Ми залучаємо всю команду в тестування, розуміючи що це може зменшити необхідність у виділеному спеціалісті з тестування

🎯 Навіщо:
Modern Testing - це подальша еволюція розуміння ролі тестування та тестувальника в розробці програмних продуктів. Ця концепція вже достатньо часто пригадується в англомовних матеріалах по тестуванню: статтях, подкастах, опитувальниках, і т.д. Послуговуючись принципами Modern Testing разом з TestOps та Agile Testing - індустрія робить кроки "ліворуч" (shift left) для пришвидшення й праворуч (shift right) для покращення якості.
Може це не завжди й помітно, але все це відбувається вже зараз! Й вищезгадані концепції не є візіонерськими, вони лише формулюють базові принципи та цінності того, що відбувається.
Тому, мені здається - важливо розуміти куди все рухається, й де буде наше в цьому місце.

Всім якості!

Тестування нічого не коштує

Привіт друзі і з Новим Роком! Сподіваємось, всі добре відпочили на свята 🥳

Минулого тижня робив оцінку тестування для одного невеликого проєкту і в черговий раз отримав питання від замовника - "за тестування треба платити? окремо? хіба розробники не можуть одразу написати все якісно?" 😄
І хоч як не дивно таке чути від людей, що вже давно працюють в IT, треба бути завжди готовим пояснити, чому тестування оцінюється окремо і чому саме стільки, бо "там же тільки вкінці кнопочки поклацати, щоб нічого не впало". Отже, топ моїх типових аргументів у таких випадках:

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

А чи доводилось вам аргументувати необхідність тестування?

🐞 Вартість низької якості в 2020 💰
#news #linkz

Ми студентам на лекціях розповідали про зростаючу вартість помилок на прикладах досліджень фіг-зна-якої давнини.
Виявляється в Штатах є організація Consortium for Information & Software Quality (CISQ), яка вивчає це питання системно й регулярно. (Пишуть звіт на 46 сторінок кожного року - якщо бути точним :) )

Зацініть цифри за 2020-й:
💲Загалом економіка Штатів через неналежну якість втратила у 2020-му орієнтовно 2.08 трильйона доларів. Ще раз: два трильйона! З них:
💔 Неуспішні IT проекти ~ 260 мільярдів
👨‍🦳 Погана якість в Legacy системах ~ 520 мільярдів
⚙️ Баги в робочому софті ~ 1,56 трильйона

Особливо доставляє те, що сумарна зарплатня всіх 8 мільйонів айтішників в Штатах за 20-й склала меншу суму - "лише" 1,4 трильйона.

Загалом там в звіті багато цікавих цифр, прочитаю детальніше - поділюсь. Сам звіт тут:
https://www.it-cisq.org/cost-of-poor-software-quality-in-the-us/index.htm

Про контекст
#friday

Привіт друзі! Вчора моя кума опублікувала в фейсбук (спочатку написав фейксбук 😁) загадку, варіації якої я ще в школі зустрічав. Цитую:

Ти заходиш в кімнату. На ліжку 2 собаки, 4 коня,1 жираф і качка. Над стільцем літають 3 курки. Скільки ніг на підлозі?

Звісно, ця загадка намагається збити вас з пантелику переліком тварин, але все, на що ви маєте звернути увагу - це ви (той, хто зайшов у кімнату, 2 ноги), стілець (4 ноги) та ліжко (4 ноги). Спойлер: усього 10. Але якщо трохи подумати, все зовсім неоднозначно:
❓ а якщо в мене інвалідність і лише 1 нога, чи стане 9 правильною відповіддю?
❓ не у кожного ліжка 4 ніжки (в мене, наприклад, було ліжко на 10 ніжок, а зараз 6. А в ліжка доньки взагалі нема - там 2 опори)
❓ зі стільцем та ж біда - не у кожного саме 4 ніжки. Більше того, з тексту не очевидно - стілець теж стоїть на підлозі чи може лежить на ліжку і його не варто рахувати
❓ та і взагалі, я б хотів уточнення, чи можна вважати за ноги ніжки меблів 🤓
❓ або чи не звисає з ліжка нога коня/жирафа, торкаючись підлоги 🦒

Ця загадка в черговий раз нагадала мені, скільки контексту треба враховувати, щоб дати однозначно вірну відповідь (читай - зробити адекватний тест).

А ще нагадала мені іншу загадку, яка ще в молодших класах бісила 🤬:

Професор лягає спати о 7 вечора і ставить будильник на 8 ранку. Скільки годин буде спати професор?

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

Але ніт, я не правий! Бо відповідь - 1! 🤯. Бо іди ти до біса, школяр з електронним годинником. В професора - механічний і ти сам мав здогадатись і інші відповіді не приймаються 🤷‍♂️ (дитяча травма, стільки років минуло, а все ще припікає).

Всім добра і розуміння 😺
Напишіть, які загадки бісять вас своєю нелогічністю

Дохід українських тестувальників - зима 2021
#linkz

Якщо ви ще не ознайомились, то саме час це зробити: свіженькі, щойно з печі результати опитування тестувальників від DOU.ua
https://dou.ua/lenta/articles/salary-report-qa-winter-2021/

Трохи спойлерів:
1823 анкети тестувальників, 40% з них - з Києва.
1/3 - жінки, 2/3 - чоловіки.
Середній вік - 29 років.
Manual QA - в два рази більше анкет й приблизно на 25-30% нижчий дохід в порівнянні з Automation QA.
та інша цікава статистика - рекомендовано для розуміння адекватності свого рівня доходів :)

Testing Challenge
#games

Привіт друзі! Якщо у вас виникає питання - "де ми пропали? Чого рідко пишемо?" Не хвилюйтесь, готуємо кілька класних проєктів, вже скоро поділимось деталями 😎

А поки працюю над проєктами, трохи рефлексую, прокрастиную, згадав, як дуже давно, коли трава була зеленіша, знайшов я для себе ресурс із Testing Challenge . Його перше завдання змусило мене в свій час серйозно попотіти - знань з тестування в мене вистачало, а от доменних, в веб тестуванні, ще ні.
Все виглядає просто, на перший погляд, - 1 поле вводу, треба протестувати на різні класи еквівалентності. Навіть відома кількість тестів - 18⚠️

До речі, всі 10 челенджів досить цікаві і можуть розважити, якщо ви теж трохи рефлексуєте. Удачі!

І напишіть, які пройшли легко, а де застрягли

Testing Challenge №1 – solution
#game

Привіт друзі! Минулого тижня опублікував пост з Testing Challenge, тепер дуже хочу опублікувати рішення та розібрати їх з вами. Щоб уникнути спойлерів, повне рішення зробив на сайті. Хто хоче сам здогадатись - не читайте. Також там мої думки з приводу деяких варіантів.

І це був лише перший челендж з 10. Як вам інші? Дивились?

Наші в ютубі
#youtube

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

Говорили про:
- Поєднання роботи та дружби
- Навчання студентів
- Різницю між PM та DM
- ДНК-тестерів :)
та багато іншого :)

Вийшов цікавий діалог імхо, долучайтесь до перегляду!
https://youtu.be/AbdQMGamA-8 (30хв)

Кругообіг брехні
#interview #longread

Я проводжу співбесіду.
Ти проводиш співбесіду.
Він/вона/воно 😄 проводить співбесіду.

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

✅ Звісно ж, ми хочемо бути привабливими для потенційних роботодавців, для цього пишемо в резюме якомога більше знань та навичок, якими ми володіємо. Коли був студентом і писав своє перше резюме - так само робив. До абсурду - встановив сам убунту -> впевнений користувач Linux. Було 2 лаби по C++ -> вмію програмувати. Соромно, коли на співбесіді питають відповідно, а відповісти нічого. Але справжній сором, це коли ти не студент, а досвідчений спеціаліст з 3+ роки досвіду. Я помітив, що останні роки, коли планово оновлюю резюме, я більше видаляю пункти, ніж додаю нові - наприклад колись писав автотести на C# у Visual Studio, але це було 6 років тому - краще видалити і не ганьбитись, якщо буде потреба - все одно вчитись прийдеться майже заново. Краже похвалитись в резюме сильними сторонами. Іноді навіть смішно, коли в мене (з 13 роками досвіду) резюме уміщується в одну сторінку А4, а джуніор з 2 роками має резюме на 7-10 сторінок. Хто то все читає? 🤷‍♂️

✅ Легко обвинувачувати одну сторону - а що в нас з вакансіями. Мені знайома ситуація, коли деякі компанії завищують вимоги, щоб відсіяти слабких кандидатів. Чи додають заздалегідь нелогічний список вимог: "потрібен тестер з 3+ роки досвіду, має вміти у фулстек розробку на C#, Java, C++, а ще девопсити на AWS, Azure, GCP, а ще писати вимоги на 5 мовах та перезаправляти картриджі принтерів". Кандидати ж не дурні - розуміють, що вимоги завищені, трохи додають собі скілів в резюме і все рівно відправляють. Я, зазвичай, при формуванні вимог до вакансії, намагаюсь зменшити список - виділивши тільки must have навички - якщо їх нема - нема сенсу навіть гаяти час.

✅ Для мене співбесіда схожа на екзамен - за короткий час треба дізнатись, чи людина "в матеріалі". До екзамена зазвичай готуються навіть ті, хто добре все знають. Диво дивне - до співбесід - чомусь ні. Хоча самому почитати резюме та перечитати ключові моменти у вказаних собою ж технологіями - гарна ідея. Щоб потім не "тупити". І теж саме для себе - якість моїх співбесід виросла в рази, коли я став витрачати 20 хв перед співбесідою, щоб прочитати резюме, сформувати список питань та погуглити про технології, що там написані а я про них мало що знаю.

Напишіть в коментах про ваш досвід - що ви зустрічаєте частіше: нечесні резюме чи завищені вакансії? Хто більше винен? Та чи пішли читати своє резюме?

Підбірка інженерних "законів"
#linkz

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

Ось деякі, що напряму стосуються тестування:

Теорія розбитих вікон
Якщо перефразувати по нашому:

де більше багів - там більше багів

Закон Брукса

Додавання людей в проект що запізнюється не прискорює його, а ще більше вповільнює. 

Він ще добре відомий у формі приказки:

Nine women can't make a baby in one month

Закон Каннінгема
Універсальний :)

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

Закон Галла
Завдяки цьому закону ми працюємо по Agile, а не Waterfall

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

Закон Хофстадтера
Невмируща класика про те, що з естімейтами ви все одно налажаєте :)

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

Закон Кернігана
Люблю його розробникам цитувати :)

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

Ну й там ще багато невмирущої класики. Enjoy!
https://github.com/dwmkerr/hacker-laws

Вебінар: Performance Testing with Locust
#news #event

Привіт друзі! Вже давно планую написати курс по тестуванню навантаження. Маю купу чернеток з матеріалами, але не маю часу, щоб оформити їх в такому форматі, щоб не соромно було поділитись з іншими та дати на самостійне опрацювання.
І тут дуже вчасно мені запропонували провести вебінар в Quality Assurance Group.

Для мене - це гарна нагода зібрати до купи всі ідеї, поділитись ними та, якщо пощастить, ще й фідбек зібрати 🤓
Для вас - дізнатись про тестування навантаження і поспілкуватись (якщо буде така нагода).

Всі деталі за посиланням. Запрошую відвідати, участь безкоштовна! 😺

Feature branch
#linkz #git

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

Скажу чесно, в мене ніколи таких проблем не було. З іншого боку, ніколи не писав автотести в команді з 20+ людей.

✅ Тож перше, що ми їм запропонували - робити feature branch. Я думав, штука очевидна, але може не для всіх. Ідея в тому, що коли ви беретесь автоматизувати свої тести, ви робите в репозиторії окрему гілку (branch) - і всі зміни робите в ній. Коли ваші зміни готові та протестовані, ви забираєте всі останні зміни з мастеру та мерджите в свій бранч. Вирішуєте конфлікти, тестите ще раз і лише після цього готовий код мерджите назад в мастер. Все. Фіча готова. І нічого не ламає. Ваші колеги, в свою чергу, роблять те саме. PROFIT

✅ Друга рекомендація була - ставити теги. Замість того, щоб створбвати новий репозиторій для кожної нової версії проєкту, можна ставити для кожного релізу тег з версією, наприклад 1.3.127 (що може відповідати версії продукта, щоб ви знали, яка версія тестів до якої версії продукту відноситься). Після чого можна продовжувати працювати зі своїм репозиторієм.

До речі, якщо почитати патерни управління вихідними кодами - то їх є багато. Якими користуєтесь ви? Чи були у вашій практиці цікаві (та не дуже) історії (як от в моєму минулому - залочив розробник файли на зміну в TFS та пішов у відпустку...)

P.S. А ще хочу похвалитись - купив собі графічний планшет, буду намагатись малювати ілюстрації до постів самотужки. Як вам?

П'ятничний баг: Clubhouse 80-х
#bugseverywhere

Чесно кажучи сам не в курсі що таке клабхаус, але всі навколо про нього тільки й марять, тому ось вам цікава п'ятнична історія про баг, завдяки якому став можливим такий собі клаб-хаус у 80-х роках :)

Якщо коротко, то особливість АТС дозволяла дзвонити на непідключені номери, й замість відміни виклику або гудків "зайнято" відбувалось з'єднання з цілою групою абонентів, які також подзвонили на цей номер.
Ця вразливість АТС призвела до появлення цілої суб-культури "ефірщиків", які влаштовували ефіри (по суті аналоги сучасних голосових чатів) на різні тематики, від "спекулянтських" та "дозвілля на ніч" до "інтелектуальних".
Феномен, спричинений багом на АТС проіснував аж доки ці АТС не були замінені на нові, тобто майже до 2000-х років.

Кому цікаво, деталі тут:
https://tjournal.ru/340295

А у 1987-му році про цей феномен навіть фільм зняли: https://youtu.be/bX2UQhxArJg

А ви там як, чатитесь в клабхаусі? ;)

Postman Intercept
#tools

Привіт друзі. Бувало у вас таке - користуєтесь тулом декілька років, навіть знаєте такі фічі, які ніхто окрім вас і не знає, напевно. А потім самі дізнаєтесь про фічу, яку всі вже давно використовують. В мене така історія сталася з Postman.
Коли почав активно його використовувати, передивився весь інтерфейс, дізнався як, наприклад:
✅ створювати API типу OpenAPI в форматі yaml
✅ генерувати колекції тестів з його допомогою
✅ створювати мок сервіси з ваших API та тестів
✅ створювати API документацію майже як в свагер, абсолютно безкоштовно!

А от оновив його минулого тижня і абсолютно випадково дізнався, що постман має, як мінімум, ще:
✅ Monitors - екран для періодичного запуску колекцій для perforrmance тестування
✅ Proxy - HTTP proxy, що може перехоплювати та зберігати всі запити!
✅ Interceptor - фіча, що мене вразила! Ставиш плагін в хром, активуєш перехоплювач, і всі запити браузеру зберігаються в колекцію (все це без використання проксі). Більш того, кукі теж перехоплюються. Тобто, якщо є потреба - можна залогінитись в додаток, що ви тестуєте - Postman перехопить та збереже сессію, після чого можна тестувати в Postman, не оновлюючи хедери. Краса!

Як вам? Я дійсно останнім дізнався?
Про інші фічі теж хотів написати, та все руки не доходять. Вам буде цікаво?

Make documentation great again! Doc to markdown wiki.
#tools

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

В ході цих досліджень мені знадобилось перевести всі проектні вимоги з формату Word doc у формат wiki markdown. Оскільки word документ це найпоширеніший формат для роботи з документацією загалом та вимогами зокрема, а різні проектні wiki або confluence зазвичай "ближчі" до проектної кухні, то цілком припускаю що в когось з вас також може з'явитись така потреба - конвертнути doc в wiki markdown (або ж навпаки).

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

https://pandoc.org/

Performance Test Webinar
#news

Привіт друзі! Нагадую, сьогодні о 19:30 за Київським часов буде вебінар з тестування навантаження. Заходьте, буде цікаво!
link

Performance Testing Webinar Record
#linkz

Привіт друзі! Вчора відбувся запланований вебінар. Хто хотів послухати, але пропустив - ось посилання - Performance Testing with Locust

Мені дуже сподобався подібний формат - поговорити, поділитись досвідом. Я б ще щось цікаве розказав, що б вам цікаво було послухати?
До речі, якщо у вас залишились питання, чи виникли нові після перегляду - пишіть!