Awesome Sites To Test On

#testing #automation #resources

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

Пропоную до вашої уваги підбірку сайтів, де ви можете попрактикувати свої навички - як UI, так API тестування.

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

Change Driven Testing або тестування, кероване змінами

#testing #automation #paper

Мої нотатки зі статті про change-driven тестування.

Забуті аспекти навчання та професійного росту

#testing

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

Наприклад
- Підбірка для тих, хто хоче самостійно навчитися більшості тем з Computer Science. Матеріали розбиті на теми. Можна просто брати - й вчитись.
- MIT Challenge від Scott H Young. Челендж полягав у тому, що Scott за один рік хотів самостійно онлайн пройти всю програму MIT з комп'ютерної інженерії. І йому вдалося!

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

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

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

Чому варто вступити в цю спільноту?
1. 💬 Ексклюзивний доступ до закритої групи: Ви зможете спілкуватися з однодумцями, обмінюватися ідеями, розвивати свої знання та ділитися власним досвідом.
2. 🎓 Вебінари та воркшопи: Щомісяця — заходи з провідними експертами, які діляться своїми знаннями, техніками та найкращими практиками в галузі. (Розклад на грудень нижче)
3. 👥 Участь у мастермайнд групах: Можливість брати участь у невеликих групах для обговорення конкретних проблем, обміну ідеями та вирішення складних завдань.
4. 💼 Експертна підтримка: Ви отримаєте доступ до експертів з галузі, які готові ділитися своїм знанням та допомагати вирішувати складні завдання.

Тобто коротко - це не просто черговий чат. Тут буде корисно. Вартість місячної підписки - 2 чашки кави 😌
А підписатись ви можете в спеціальному для цього боті:
@suvoriy_qa_bot

Бажаю Артему створити дійсно круту спільноту, де люди отримують підтримку та розвиваються разом.

⚡️Час покращуватись

Друзі привіт, ми з Олександром та подкастом Testing Minutes пішли у різдвяну відпустку.
Після кожного сезону ми збираємось і робимо ретроспективу, щоб далі покращувати якість нашого подкасту.

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

Якщо у нас будуть уточнення, то ми з вами обов'язково зв'яжемось.

Форма тут
🔻🔻🔻
https://forms.gle/KawbnDMa9MbHXZtX8

Data Quality Score: The next chapter of data quality at Airbnb

#testing #data

Починаємо новий тиждень цікавою статтею від Airbnb про те, як вони оцінювали якість даних.

Оновлення Awesome Blockchain Testing
#testing #blockchain

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

32 Software testing statistics suitable for your presentation in 2024

#testing #trends

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

Інсайти з книги про нотатки - #1

#learning #notetaking #books

Читаю зараз книгу "How to make smart notes". Записів роблю дуже багато. І це ще я намагаюся писати їх своїми словами та коротко (по суті).

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

Ефект Зейгарник або чому важливо записувати свої задачі в To Do

#timemanagement

Життя та робота постійно підкидують нам задачі. Хотілося б усі їх пам'ятати.
Але це просто неможливо. Мозок постійно про ці задачі думає.

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

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

В контексті задач та планів - "Незакінчені задачі займають короткострокову пам'ять допоки не будуть виконані"
А короткострокова пам'ять в людини вкрай невелика.

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

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

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

Чому тестувальники все ж таки потрібні - роздуми розробника

#testing #engineering

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

Питання такі:
- Чому до тестувальників склалося таке "зверхнє відношення" та
- Чи правильний підхід - "звільнемо тестувальників, бо якістю можуть займатись усі потроху!"

Мої короткі нотатки

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

(Додатково це призвело до великого знецінення користі роботи тестувальника).

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

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

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

Хороший скетч про метрики та як з ними працювати

Друзі, доброго ранку!

Нещодавно ми подали з Олександром заявку на першу премію від DOU подкаст Testing Minutes і буду вдячний, якщо ви проголосуєте за нас.

Голосувати тут:
🔻🔻🔻
https://jobs.dou.ua/questionary/dou-award/podcast

Дякую всім 🙏

Всім привіт.
Рома Марінський з QA Club Lviv буде сьогодні у 19:00 проводити вечірню неКаву у Varburger в ДНІПРІ!
Тема - мобільна автоматизація.
Формат - просто неформальна зустріч - розмова.
Хто має час - приходьте.

2023. Підсумки.

Всім привіт. Це Олександр на зв'язку. Сьогодні 31 грудня - то ж саме час підводити підсумки року.

2023 рік у світі тестування та IT
- Ще більше застосування та тестування AI / ML. Google та інші компанії випускають "вбивць" ChatGPT майже кожного кварталу
- ChatGPT, Copilot та схожі системи все більше допомагають в повсякденних задачах
- Playwright стає новим "стандартом" в світі автоматизації Web'y
- У світі блокчейну "ненадійні" та "сірі" проєкти помирають. Індустрія стає більш зрілою. Інвестори цінують зараз не стільки "проривні" технології, як реальне застосування в бізнесі та комплексні продукти
- Мікросервіси перестали бути "гарячою темою". А стали лиш черговою опцією в арсеналі інженера
- Багато команд хоче влаштувати собі shift-left тестування, але стикається з купою проблем. Насамперед - відсутність знань та досвіду людей
- Кібербезпека й раніше була важливою, але зараз стає просто критичною. Кейси Київстару (й не тільки) це тільки підтверджують. Тому якщо вам випадково "нудно" в тестуванні - кібербезпека може бути дуже цікавим напрямком розвитку
- Світовий ІТ ринок пережив продовження звільнень. Ринок праці в Україні - остаточно став ринком роботодавця. Тож тепер треба ще більше вчитись, щоб стати кращим за інших кандидатів. (Навіть якщо ви сіньйор або лід)

Щодо мене.
В цьому році ми разом із Артемом Григоренко запустили власний подкаст - Testing Minutes.
А ще, крім роботи, каналу та подкасту - я був ментором - як для починаючих, так і для досвідчених інженерів. У 2024 році буду менторити ще більше.

З Новим Роком, друзі! Дякую, що читаєте! Побачимось вже у наступному році!
Слава Україні! Та величезне спасибі ЗСУ!

Test Engineering Notes: Vol. 9 Про важливість тестування, кар’єрний ріст до Senior та як працює Shazam

#testing #engineering #digest

Новорічні свята вже в минулому. Треба повертатись до робочого настрою.
Сьогодні до вашої уваги пропоную дайджест статей за грудень 2023.

Запам'ятовування vs Розуміння

#learning

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

Питання в тому, що такий підхід не працює саме для розуміння інформації.

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

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

Тож простого читання недостатньо.

"Читання, особливо перечитування, може легко примусити нас повірити в те, що ми розуміємо текст. Це особливо небезпечно через ефект знайомства з текстом - з того моменту, коли ми познайомились з чимось, ми починаємо вірито в те, що вже розуміємо це." (с) Р. Фейнман

Про інтеграційні тести в реальному світі

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

То ж, як розповідають деякі поважні тестувальники - єгиптологи 😀, для успішної автоматизації, рекомендується писати наступні види тестів:
- Unit testing involves testing the smallest testable parts of an application, called units, independently and in isolation from other parts.
- Integration testing focuses on testing the interfaces and interaction between integrated units/modules to expose defects in their interactions.
- End-to-End testing is a technique that tests the entire software application from the start to the end along with its integration with external interfaces.

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

Пропоную сьогодні поглянути на це питання за допомогою аналогій.

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

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

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

Медицина
Юніт тест - це коли вчені експериментують з ліками на рівні окремих клітин.
Інтеграційний тест - це коли ліки перевіряють на рівні окремих органів чи більш складних систем.
е2е тест - це експериментальне тестування готових прототипів ліків на різних групах людей (разом із плацебо)

А які аналогії з інтеграційним тестуванням є у вас?

Приховане перетворення даних в grpcui та k6

#testing #api #tools #python

Ситуація
Для одного з наших gRPC сервісів нам потрібно відправити hash у форматі HEX. Але коли я намагався відправити запит за допомогою grpcui або ж у скрипті навантаження k6 - сервер повертав помилку, що такий хеш не знайдений в нашій базі.

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

Рішення
Як виявилося - обидва інструменти очікують вхідні дані в base64. Потім вони декодують ці дані та надсилають результат на сервер.
В Python з base64 працювати дуже легко. То ж у нагоді стане наступний скрипт.

import base64


def from_b64_to_hex(input):
    binary_data = base64.b64decode(input)
    return binary_data.hex()


def from_hex_to_b64(input):
    binary_data = bytes.fromhex(input)
    return base64.b64encode(binary_data).decode()


base64_string = "LxTKPCw9jAv1U8Xm6lxjhtGlnoZzNPc6I="
hex_string = "2f14ca3c2c3d880653b15e6ea5c6386d1a59e867334f73a2"

assert hex_string == from_b64_to_hex(base64_string)
assert base64_string == from_hex_to_b64(hex_string)

І ще одне
Крім цього скрипта, можна скористатись також безкоштовним онлайн конвертером.

Про задачі на співбесіді автоматизатора

#testing #automation #interview

В одному з ком'юніті минулого тижня ми обговорювали задачі на співбесіді для автоматизаторів.

Які варіанти задач я зустрічав

1. Задачі на алгоритми та структури даних (на обраній мові програмування). Це можуть бути спеціалізовані платформи типу Codility або HackerRank. Якщо це перший етап інтерв'ю - то дають 1-3 простих невеличких задачі на 30 - 60 хвилин. Якщо це частина технічної співбесіди - можуть бути задачі складніші. Плюс інтерв'юер може додавати нові вимоги.
2. Задачі типу "напиши сервіс та покрий тестами". Перевіряються як загальні скіли розробника, так і знання інструментів тестування конкретного фреймворку.
3. Задачі "ось тобі шматок коду - скажи, що він робить та де можуть бути баги". Перевіряється вміння читати чужий код, знання мови програмування та вміння знаходити баги.
4. Задачі "напиши UI чи API тести прямо зараз з нуля. Ось тобі сайт чи API". Тут перевіряється наявність ваших заготовок, вміння швидко писати тести. Якщо ви давно не працювали з бібліотекою чи фреймворком (або якщо ви займались копіпастингом БДД сценаріїв у готовому солюшені) - ви легко можете завалити співбесіду.

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

Окремо про тестові завдання

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

Які варіанти тестових я бачив

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

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

Головне правило роботи з тестовими завданнями - краще зробити менше тестів, але щоб вони працювали, стабільно, додати автоматичний запуск тестів на Github / Gitlab CI, репорти, інші корисні речі та додати README зі зрозумілим описом.
Бо якщо у вас крутий солюшен з усіма паттернами в світі, але він незрозумілий або навіть не запускається локально - то це величезний мінус.

А які варіанти задач на співбесідах зустрічали ви?