⚡️ Епізод 31: Де тестувальник думає, чи можна працювати без нього / неї

Всім привіт! Ми повертаємось з новим, четвертим сезоном!

Чи можна випускати софт без тестування? Чи виживуть команди та продукти, якщо в них не буде тестувальників? Як боротися зі страхом стати непотрібним - коли всі настільки класно тестують без вас? Ці питання Артем та Олександр будуть обговорювати в черговому випуску подкасту.

Для тих, хто полюбляє слухати:
🔸 Youtube
🔹 Spotify Podcast
🔸 Apple Podcast

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Software Testing as a Social Science (Caner) - частина 1

#testing

В одній з книжок я знайшов посилання на презентацію Кема Канера з тестування (2006 року). Було дуже цікаво прочитати слайди. Наче й все зрозуміло, але подача інформації зовсім інша - відрізняється від сучасних книжок та стандартів. Наведу декілька нотаток зі слайдів.

Про соціальні науки

Тестування більше схоже мікс психології, економіки, бізнес менеджменту - ніж на програмування.

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

Про програми

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

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

Про тестування та помилки

"Quality is value to some person" (c) Jerry Weinberg

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

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

"A bug is something that bugs somebody" (c) James Bach

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

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

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

Продовження - у наступному дописі.

Software Testing as a Social Science (Caner) - частина 2

#testing #caner

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

Про техніки та контекст

Техніка тестування - це рецепт по створенню тестів. Сюди входять тестування домену, ризиків, сценаріїв, та ін. Канер зазначає, що існує близько 150! різних технік. (Варто пошукати той перелік технік. Чи це тільки маркетинговий трюк?)

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

(Тут варто нагадати, що Кем Канер - один з творців "школи" context-driven software testing.)

Про тестування на основі сценаріїв

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

Звідки брати ідеї створення сценаріїв?
- Згадайте життєвий цикл обʼєктів в системі
- Запишіть та проаналізуйте можливих користувачів та їх мотивацію
- Перелічіть список можливих та неможливих системних подій
- Взнайте в користувача про типові кейси взаємодії з продуктом
- Подивіться на подібні системи в конкурентів (а також звернення користувачів з проблемами)
- Шукайте послідовності: люди (або система) зазвичай виконують завдання X у заданому порядку. Які найпоширеніші послідовності завдань у досягненні X?

(Хтось взагалі користується scenario-based testing усвідомлено?)

Виявляти помилки - не просто.

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

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

Навіть, якщо ми покрили весь функціонал тестами, додаткові побічні ефекти (дані, ресурси та час) стають новими причинами для проявлення принципу Гейзенберга. (Взагалі принцип Гейзенберга - цікава тема. Знайшов декілька дослідницьких робіт. Частково, це повʼязане із flaky тестами).

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

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

Цікаво, чому Канер вимірює ефективність тестувальника у вмінні описати баг. Чи згодні ви з таким твердженням?

На цьому все. До нових зустрічей!

Ось що буває, коли образив штучний інтелект ...

Щоб добре працювати, треба добре відпочивати. Це мені сказали друзі з DOU і попросили гукнути вас на DOU Day Picnic.

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

Ще з важливого: 100% вартості квитків йдуть на збір DOU та “Повернись живим”. Ось так можна і задонатити, і взяти квиток на пікнік.

https://dou.ua/goto/I0PB

⚡️ Епізод 32: Де тестувальник взаємодіє з SRE (разом з Романом Подолякою з Google)

Якби ви знали слухачі, що роблять SRE вночі ... Хто такі SRE інженери? Чим вони займаються? Як вони забезпечують надійність систем в Google? Та найцікавіше - чи є тестувальники в Google? Про все це сьогодні в епізоді ми поговоримо з Романом Подолякою.

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Engineering Principles for Building Financial Systems

#engineering

Хороші поради для тих, хто створює (й тестує) фінансові системи. Базові штуки, та речі, на які варто звернути увагу.

Новий погляд на "старий" продукт

#notes

Кожного дня ми вчимося. Ми вчимось, коли читаємо книги, дивимось відео, проходимо курси. Ми вчимося навіть коли читаємо пости в телеграмі.

Крім того, ми вчимося на роботі. Це може бути документація про нові фічі чи інструменти. Але також, ми можемо навчитись чогось нового навіть про ті фічі, які здавалося б вже протестовані.

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

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

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

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

Бо автотести не приносять гроші компанії. А робочий продукт - приносить.

📚Що б почитати: Agile Testing

#testing #books #whattoread

Час від часу хочу ділитись з вами своїми книжковими рекомендаціями.

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

Це вже свого роду класика - книги за авторством Лізи Кріспін та Джанет Грегорі.
- 📕 Agile Testing
- 📕More Agile Testing

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

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

Ви можете сказати: "так це старі книжки, діду!" Але то тільки на перший погляд.
Процеси та підходи за ці 10-15 років сильно не змінилися. (Деякі організації тільки-но починають шлях в agile)
Плюс - краще читати ці книжки, ніж починати з Савіна.

⚡️ Episode 33: The one where the test engineer explores holistic testing with Lisa Crispin

Багато хто читав "Agile Testing". Але після цих книг постає питання - чи можливо подивитись на тестування ще ширше? Чи потрібно тестувати лише до виходу в продакшн? Як щодо тестування моніторингу чи навіть ідей? Тут допоможе новий підхід - holistic testing. А що це таке та як реально його застосовувати ми поговорили з Лізою Кріспін, що й придумала цей підхід.

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

🛠 Про інженерну роботу в часи розквіту AI 🦾

#engineering

Глобальний ІТ ринок змінився.

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

AI прискорює та полегшує роботу кваліфікованих інженерів. Разом із тим - AI робить неефективних інженерів дуже вразливими до звільнень.

Кент Бек у своєму твіті минулого року підкреслив цей факт. Він заявив, що ChatGPT зробив 90% наших навичок вартими 0$, але збільшив цінність інших 10%. (Але яких саме - Кент не розголошує).

В світі AI виживуть інженери - професіонали, які прагнуть розвиватись, адаптуватись та рости.
Успіху досягнуть навіть вже не T-shape, а M-shape спеціалісти - ті, що можуть швидко вчитись та розбиратись навіть в тих дисциплінах "які поза межами зони відповідальності".

Будьте готовими до нового порядку речей.
Вчіться. Вже. Зараз. 🧑‍🎓

How SQL Query works? SQL Query Execution Order for Tech Interview

#engineering #howitworks #interview

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

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

Test Engineering Notes — Vol. 16

Як провести bug bash в компанії та чи можливо протестувати все в межах спринта, історія створення Git та як працюють SQL-запити, як планувати свою карʼєру та брати максимум від 1-1 зустрічей та багато інших цікавих тем читайте в новому дайджесті від Олександра Романова 👉 https://dou.ua/goto/2EmP

⚡️ Епізод 34: Де тестувальник залишається технічним без вміння писати код

Дуже часто тестувальників оцінюють лише за вмінням написати код. Вмієш - крутий, не вмієш - ганьба тобі! Але сьогодні в епізоді Артем та Олександр покажуть декілька прикладів, як можна бути технічним спеціалістом (майже) без вміння читати та писати код.

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

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

Куди рости в тестуванні?

#testing #career

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

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

Плюс, шлях може бути не обовʼязково лінійно вгору. Можна пробувати різні варіанти та переходити з гілки на гілку.
На цю тему рекомендую гарну статтю - Deltas to the Global Maxima: Better Career Conversations

А який ваш шлях?

Корисні "трюки" в Python

#python #tricks

Сьогодні дозвольте поділитись прикладами трюків з книги "Python One-Liners".
Користуйтесь ними для навчання, або будьте готові отримати шось подібне на співбесіді (зустрічав таке).

1. У вас є строка з багатьма рядками. Перетворіть її на масив масивів слів в кожному рядку, якщо слово має більше трьох літер.

text = '''Call me Ishmael. Some years ago - never mind how long precisely - having  
little or no money in my purse, and nothing particular to interest me  
on shore, I thought I would sail about a little and see the watery part  
of the world. It is a way I have of driving off the spleen, and regulating  
the circulation. - Moby Dick'''

Очікуваний результат:

[['Call', 'Ishmael.', 'Some', 'years', 'never', 'mind', 'long', 'precisely', 'having'], ['little', 'money', 'purse,', 'nothing', 'particular', 'interest'], ['shore,', 'thought', 'would', 'sail', 'about', 'little', 'watery', 'part'], ['world.', 'have', 'driving', 'spleen,', 'regulating'], ['circulation.', 'Moby', 'Dick']]

Рішення:

w = [[x for x in line.split() if len(x)>3] for line in text.split('\n')]

2. Прочитайте файл, видаліть для кожного строки непотрібні пробіли та збережіть це все в лист.

Рішення:

print([line.strip() for line in open("readFile.py")])

3. Маючи словник з даними щодо компаній та заробітних плат співробітників, поверніть список компаній, що платять менше ніж 9$ на годину.

companies = {  
    'CoolCompany' : {'Alice' : 33, 'Bob' : 28, 'Frank' : 29},  
    'CheapCompany' : {'Ann' : 4, 'Lee' : 9, 'Chrisi' : 7},  
    'SosoCompany' : {'Esther' : 38, 'Cole' : 8, 'Paris' : 18}
} 

Рішення:

illegal = [x for x in companies if any(y<9 for y in companies[x].values())]

P.S. Трюки корисні, коли ви та ваші колеги розумієте як вони працюють.

⚡️ Episode 35: The one where the test engineer searches for testability with Rob Meaney

Testability. Здається, що цей термін дуже простий та зрозумілий. Багато хто говорить про це, але дуже мало хто знає точно, що таке testability та як конкретно покращувати цю властивість у софті. Тому ми з Артемом звернулися про допомогу до Rob Meaney, який знає про testability дуже багато (навіть книжку про це написав).

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

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes

Карʼєрні супер здібності, що допоможуть у важкі часи

#testing #career

У часи постійних скорочень та тижнів (місяців) пошуку роботи, в голові постійно виникають одні й ті ж питання:

- Шо я роблю не так?
- Чому я не можу знайти роботу?
- Чи цінні мої навички?

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

Вміння навчатися

Щоб підвищити шанси в пошуку роботи - треба навчитися вчитися новому. Таке навчання може мати різні форми - від опанування окремого інструменту до навчання нових підходів та процесів в нових для вас доменах.

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

Вміння адаптуватись

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

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

Не думайте, що навички, які ви здобули 5-10-20 років тому так само потрібні зараз.
Більшість з них потребують постійної практики, а може - й заміни.

АйТі постійно змінюється. То ж нам треба змінюватись разом із ним.

Готові стати QA Leader? 💡
Запрошую на четвертий потік с̶у̶в̶о̶р̶о̶г̶о̶ групового менторства QA-Lead, де ви дізнаєтеся все про цю посаду та отримаєте інструменти для успішного вирішення завдань після підвищення.

Що у програмі?
- Допрацьована програма після трьох потоків, відшліфована і покриває все, про що ви писали у відгуках 🔥
- Практика на реальних кейсах
- Інтенсивні домашні завдання: підготуйтеся витратити від 10 годин на тиждень
- Запрошені експерти: майстри з надання фідбеку, ораторського мистецтва та найму
- Щотижнева рефлексія, групові мастермайнди та індивідуальні сесії

Які новинки підготував для вас цього разу:
- додатковий формат, що дозволить самостійно навчатися (пожиттєвий доступ і коштує дешевше, що приємно 😉)
- з'явилися туторіали по інструментах
- деталізована програма
- гнучка оплата частинами від 4-х банків
- а ще такі топові сертифікати для випускників, які неможливо ховати у шухляді
- залишилися питання? Пишіть одразу мені @artem_grygorenko

📅 Старт: 16 вересня

Як потрапити на навчання?
Приєднуйтеся в бот - тут буду розказувати активно і багато про новинки на навчанні, оновлену програму, знижки й покажу новий сайт 😉Тут вже можна забронювати місце на курс.

P.S. Ціна раннього бронювання діє тільки до кінця серпня! 👀

⚡️ Епізод 36: Де тестувальник шукає баги в мисленні

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

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️

Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko | Test Engineering Notes