List of 2024 Leap Day Bugs

#testing #bugsinthewild

Тестувальники не потрібні!

Ми пишемо код без багів!

В нас серйозний продукт та покриття коду майже 100%

А баги з високосним роком все ще актуальні, як ніколи. Навіть в 2024 році!
Приніс вам цілу підбірку таких випадків.

Test Engineering Notes — Vol. 11. Про ШІ в тестуванні, поради для інтерв’ю та UI-тести в Netflix

#testing #engineering #digest

TLDR, або Що у випуску:

- тренди тестування та автоматизації у 2024 році;
- чому не треба панікувати через ШІ та які інструменти можна застосовувати прямо зараз;
- тестування GraphQL, gRPC та circuit breaker-ів;
- новий фреймворк для UI-тестів від Netflix;
- внутрішня магія Git;
- покроковий реверс інжиніринг девайсу для розумного дому;
- поради для проходження інтерв’ю.

⚡️ Епізод 28: Де тестувальник шукає першу роботу разом з Аміною Олійник

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Баг чи фіча? Заводимо таску на тестування цін квитків DOU Day 😏

Зараз там один квиток за повну ціну, а другий видає за 50%. Пропозиція діє до 11.03, відповідно тестувати треба якнайшвидше 👉🏻 https://dou.ua/goto/Tb7A

Test Like Google & Facebook: Simon Stewart

#testing #automation #video

Трошки інсайтів користування Selenium в Google / Facebook від Саймона Стюарта.

Настав час стати QA Leader 💡

Приєднуйся до менторської програми "Шлях до QA Leader", яка створена моїм колегою по подкасту - Артемом Григоренко (QA Coach з десятирічним стажем роботи в різних компаніях від аутсорсу до продуктових).

Що тебе чекає, окрім якісного навчання?

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

всі деталі тут

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

Якщо б архітекторам прийшлося працювати так, як розробникам

#engineering #fun

Переклав оригінальний пост (аж 1997 року!) українською, для того, щоб показати як насправді виглядає розробка софту.

Шановний пане Архітектор!

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

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

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

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

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

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

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

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

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

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

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

P.P.S.
Можливо, мені потрібен зовсім не будинок - а трейлер. Будь-ласка повідомте мене якомога швидше, якщо це так.

Автентифікація у Web - невеличкий посібник

#security

Час від часу читаю та слухаю матеріали з кібербезу (бо цікаво).
Ось натрапив недавно на гарний посібник з багатьох аспектів автентифікації у Web.
Плюс - є навіть підбірка гайдів від OWASP (там просто купа корисного!)

Чому не треба зловживати ChatGPT та іншими AI інструментами для резюме

#interview

Вчора прочитав цікаву статтю від Ben Hoyt з Cannonical. І хочу поділитись головними тезами з неї.

Не зловживайте ChatGPT

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

Не користуйтеся "квітчастою" прозою

Резюме - це не роман чи оповідання.
То ж не треба застосовувати тут усю свою літературну майстерність (залиште це для IELTS / TOEFL чи власного блогу).

Автор наводить приклад:

- had a profound mastery of Java (they’re not James Gosling)
- their journey commenced (they’re not Bilbo Baggins)
- they skillfully constructed programs (they’re not Stradivarius)
- they extended their expertise (not only an expert, but an extended one)
- they crafted Lambda functions (I prefer artisanal Lambdas)
- they leveraged Spring Boot (or did they just use it?)
- they swiftly adapted (this is getting old)
- they meticulously read documentation (good, I will hire them as a proof-reader)
- they embraced object-oriented programming (like everyone in the 90’s)
- and they brought forth robust experience (but do they bring robust Forth experience?)

Тому концентруйтеся саме на суті та пишіть простіше.

- I’m experienced with Java
- I started
- I built
- I learned
- I wrote Lambda functions
- I used Spring Boot
- I adapted
- I read the docs
- I use object-oriented programming (or drop that entirely)
- I gained experience

Не узагальнюйте

Наприклад, на питання "Як би ви описали процес додавання нових фічей на продакшн", кандидати часто пишуть так, наче скопіювали з книги:

Designing and implementing new software starts with gathering requirements, writing a specification, seeking feedback from stakeholders, and then a quality implementation. After it’s implemented, automated testing and manual QA are important. Then we deploy the software and make sure to monitor it properly.

Своїми словами можна описати це так:

I really like succinct specs and some up-front planning. When I was designing the new auth service, for example, I wrote a 3-page spec that included an architecture diagram and a brief denoscription of the API endpoints. Before deploying to production, I think it’s important to load test a real server, so I set up a similar staging environment and measured how many concurrent requests it could serve. Once in production, monitoring is crucial: I’ve used Datadog as well as open-source tools like Prometheus to detect and diagnose issues.

Висновок

Cannonical навіть додали застереження від застосування AI інструментів для резюме в свою форму подачі.
Користуйтеся інструментами обережно.

Тест план за п'ять хвилин, або техніка RCRCRC

#testing

Чи бувало у вас так, що забігає менеджер та каже - "Треба швидко релізитись, у вас є 5 (10, 30, 60) хвилин - тому швиденько перевірте цей білд та йдемо на прод!"

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

А можна - застосувати техніку RCRCRC, яку придумала Karen N. Johnson. Та створити тест план за 5 хвилин.

Що таке RCRCRC?

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

- Recent. Нові фічі та частини продукту, що були змінені в останньому релізі. Можна подивитись також git diff
- Core. Головні та найбільш використовувані фічі. Можна визначити за допомогою статистики та моніторінгу юзерів на продакшені.
- Risk. Найбільш ризиковані частини продукту. Там, де більше багів, або ж там, де cyclomatic complexity коду - найбільша.
- Configuration-sensitive. Фічі, які найскладніше налаштовувати.
- Repaired. Частини функціональності, де були останні баг фікси.
- Chronic. Частини продукту, які найчастіше ламаються.

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

Оракули в тестуванні

#testing

Кожного дня ми тестуємо. Деякі з нас також пишуть автотести.
Але як зрозуміти, що той результат, який ми отримали - саме очікуваний? Для цього ми всі користуємося оракулами. Навіть, якщо не знаємо, що таке ті оракули.

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

Які бувають оракули?
- Вимоги. Перше та найважливіше джерело інформації для тестувальника. Вимоги можуть мати багато форм: від офіційної документації до негласного спільного розуміння системи між інженерами.
- Стандарти (міжнародні чи соціальні). Стандарти залежать від індустрії. Соціальні норми чи базові фізичні виміри - це те, що ми або знаємо або можемо відносно легко поміряти. Наприклад знання, що в одному метрі - саме сто сантиметрів.
- Інші схожі продукти. Це може бути загально прийняті норми для користувацького досвіду - де та в якому порядку розмістити базові елементи навігації.
- Логи та системи моніторингу з продакшену. Можна порівняти логи від реальних користувачів з логами, зібраними під час тестування.
- Історія та власний досвід. Чим більше ви працюєте в домені чи над конкретним продуктом - тим більше досвіду ви накопичуєте та можете помітити помилки, які звичайний користувач легко не віднайде.
- Дослідницькі роботи. Якщо ваш софт створюється на основі однієї чи декількох робіт - то вимогами стають саме ці документи.

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

Головний принцип роботи з оракулами - це узгодити їх з усією командою. То ж у випадку різних спорів - “чи бага це чи ні” - ви мали б можливість посилатися на документ.
Але здоровий глузд авжеж ніхто не відміняв.

А якими оракулами користуєтеся ви?

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

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Про важливість репортів

#testing

Читаю зараз книжку “Software Testing Strategies” та натрапив на важливу інформацію про репорти. Хочу поділитися нею з вами.

Одна з ключових навичок (про яку часто забувають) - це вміння доносити до менеджмента результати тестування (test summary report).

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

Які рішення треба прийняти менеджеру?

- Чи можна вже релізитись?
- Якщо зараз не можна, то коли можна буде релізитись?
- Шо треба пофіксити, щоб вийти в продакшн в стані “good enough”?
- Чи готова ця фіча для демо? Чи можемо ми викатити конкретну фічу?

Тестувальник, особливо контекстно-орієнтований - це дослідник та інформатор, але ніяк не людина, що приймає рішення.
Тому хороший тестувальник не говорить “Тестування завершене". Він чи вона говорять - “Я протестував оці ризики, знайшов оці проблеми та не бачу користі в подальшому тестуванні цієї фічі зараз”.

Що включає в себе хороший репорт:

- Репорт представляє менеджменту варіанти. “Можна зробити це, можна - інше. А можна - взагалі щось третє”. Коли ви даєте тільки один варіант - ви позбавляєте людину вибору. З двома варіантами - менеджмент має дилему. З трьома - керівник відчуває, що має контроль.
- Репорт включає в себе невеличкий список найкритичніших багів та чому саме вони є критичними.
- Репорт розповідає що саме ви НЕ протестували. Менеджмент зможе прийняти рішення, базуючись на тому, які баги вже є - чи потрібно далі тестувати ту чи іншу фічу додатково. Бо якщо ми не будемо фіксити наявні баги - нащо поглиблюватись далі та витрачати час.

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

How to lead projects from start to finish as a software engineer

#management

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

P.S. В пості є чимало посилань на корисні шаблони документів.

Testing Machine Learning: Insight and Experience from Using Simulators to Test Trained Functionality

#testing #ml

Для тих, хто хотів би подивитись, як воно тестувати machine learning проєкти - знайшов невелику, але цікаву статтю. З прикладами дослідницьких робіт на цю тему.

А тим часом нас вже більше 3000 людей в цьому каналі! Дякую, що підписуєтесь та читаєте! Про що б ще цікаво було б почути на каналі?

У нас вийшов новий випуск QA подкасту « Питання якості»!

Обговорюємо самостійне навчання у тестуванні, оцінку процесів та важливість впізнаваності тестувальника. Дивіться разом з нами! 👉🏻 https://dou.ua/goto/7Xkx

Про навчання 1: Пам'ять комп'ютера vs пам'ять людини

#learning #tips

Минулого тижня відбулася конференція "QA - Magic Meetup 5.0". Одна з доповідей була від Аміни Олійник - про те, як краще вчитися.

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

Пам'ять комп'ютера

Як працює пам'ять в комп'ютері? Ми записали якусь інформацію (послідовність бітів). А потім, коли вона знадобилася - знайшли та зчитали її.

Пару важливих моментів про дані на комп'ютері:
- Читання інформації - не змінює її.
- Нема різниці скільки пройшло часу між записом та зчитуванням.

Пам'ять людини

Людьска пам'ять працює в режимі "read-and-update". Коли ми дістаємо шось з нашої пам'яті - ми покращуємо знання, але можемо їх також змінити. Це називається - реконсолідацією. Тож чим більше ми згадуємо інформацію - тим краще ми її пам'ятаємо.

Інший цікавий концепт - це spreading activation.

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

Spreading activation погано впливає саме на пам'ять, але позитивно - на вміння вирішувати задачі.

Через spreading activation інформація, яку ми згадуємо, може змішуватись з іншими ланцюжками - та ставати неточною або хибною.

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

"Software Testing Strategies: A testing guide for the 2020s"

#books #review

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

Книжка свіжа та варта Вашої уваги.