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 зі зрозумілим описом.
Бо якщо у вас крутий солюшен з усіма паттернами в світі, але він незрозумілий або навіть не запускається локально - то це величезний мінус.

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

Нотатки з Docker на кожен день

#testing #tools

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

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

// почистити кеш докера
docker kill $(docker ps -q)
docker rmi $(docker images -a --filter=dangling=true -q)
docker rm $(docker ps --filter=status=exited --filter=status=created -q)
docker rmi $(docker images -a -q)
docker volume rm $(docker volume ls)
docker system prune

// копіювати файл з локальної машини на контейнер
docker cp /path/to/local/file.txt my_container:/path/in/container/file.txt

// копіювати файл (або теку) з контейнеру на вашу локальну машину
docker cp my_container:/path/in/container/file.txt /path/to/local/file.txt

// запустити командну стрічку на контейнері
docker exec -it my_container bash

// подитивитись логи контейнеру
docker logs --follow container_name

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

А які улюблені команди чи лайфхаки з Docker маєте ви?

Про історію команд в консолі

#cmd #linux

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

1. Подивитись минулі команди стрілочкою вгору (але то буває надто довго)

2. Подивитись історію за допомогою команди history

history
...
 2000  ls
 2001  cat contractlog.json 
 2002  ls
 2003  ll
 2004  history

// виконати команду знову - !N, де N - номер команди зі списку
!2001

// шукати в історії команди також можливо
history | grep search

Важливо. Кільксть збережених команди в історії обмежена. Конфігурувати цю кількість можна за допомогою змінної HISTSIZE=1000.

3. Виконати пошук команди за допомогою reverse search
- Натисніть Ctrl+R в консолі
- Введіть частину команди
- Оберіть те, що потрібно та натисніть Enter для запуску. Або ж стрілку вправо для того, щоб внести правки в команду
- Якщо ж знайшли не те - повторіть пошук знову з Ctrl+R

 2001  cat contractlog.json 
 2002  ls
 2003  ll
 2004  history
(reverse-i-search)`cont': cat contractlog.json
cat contractlog.json

Можна шукати за допомогою інших інструментів, але про них - наступного разу.

Запис - Що таке блокчейн та як його тестувати?

#testing #blockchain

В цю п'ятницю хочу поділитись записом мого минулорічного виступу на QA Party Hard у Львові.
Про блокчейн, що воно таке, як його тестувати та чи потрібно воно вам взагалі.

Навіщо ми тестуємо?

#testing

Головна мета тестування - це дати команді (менеджменту) інформацію про поточний стан продукту (білду) та про можливі ризики при релізі.
Як потім цією інформацію користуються - це вже питання менеджменту.

З автотестами - те ж саме. Ваші тестові репорти повинні "розповідати історію" - тобто подавати інформацію про стан продукту на мові, зрозумілій менеджменту. Якщо це складно - подумайте, як переробити ці репорти або ж додати якийсь зведений окремий репорт тільки для high-level менеджерів.

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

Тож тестування - це не тільки про "проходити тести" чи "писати автотести". Це - про дослідження, виявлення проблем та надання інформації. Саме тої інформації, що потрібна, а також вчасно.

Про якісне виконання роботи

#testing

Почну з історії.

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

А тепер питання - чи винен лікар, якщо людина проігнорує призначення та не буде лікуватися взагалі?

Буде лікуватись людина чи ні - лікар проконтролювати не може. (За винятком, коли лікування проходить саме в лікарні - стаціонарі).
То ж якщо людина свідомо обирає НЕ лікуватись - то вона сама бере на себе відповідальність за можливі ризики для свого здоров'я.
В такому випадку, людина не може сказати, що лікар "не забезпечив якісне лікування".

Те саме й в розробці софту.

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

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

Де взяти практичні навички з програмування?

#automation #engineering

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

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

Наведу декілька збірок та сервісів, де можна знайти безліч ідей для втілення. Від найпростіших до створення аналогів відомих вебсайтів чи додатків.
- project-based-learning
- build-your-own-x
- projectbook
- codecrafters.io
- devchallenges.io

Питання про QA Vision

#testing #leadership

Читаю зараз одну книжку з тестування. (Обрав її досить випадково, але виявилась доволі цікавою).
Коли в книзі розповідають про те, як краще формулювати vision тестування, наводять наступні приклади.

Ось так не рекомендують писати:
"To ensure that our customers and users receive software that meets or exceeds their expectations of quality."

А ось так - набагато краще:
"To help the software development and maintenance teams deliver software that meets or exceeds our customers’ and users’ expectations of quality."

Питання - чому перший варіант гірший, ніж другий?

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

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

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

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

#testingminutes | @a_grygorenko | Test Engineering Notes

Selenium Vs … blog posts

#testing #automation

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

Про ідеї та простір для обміну

#learning

Продовжую ділитись своїми думками після прочитання книги "How to take smart notes". Сьогодні - про ідеї.

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

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

Приклади:
- Наприклад раніше, нові літературні ідеї виникали в окремих кафе, де збирались поети та письменники та вели дискусії
- В контексті досліджень це може бути лабораторія чи учбовий кампус університету
- На роботі - це можуть бути ті самі community of practice, гільдії та інше.

Саме тому, форуми, конференції та ком'юніті - вкрай важливі. Як для розвитку окремої людини, так і для індустрії в цілому.

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

І ще одне.
Чим більше у вас досвіду та знань, тим складніше отримати "нові ідеї". Чергові розмови можуть здаватися повторенням одного й того ж.
Щоб такого не сталося - шукайте різні ком'юніті. Спілкуйтесь з різними експертами. Не тільки в тестуванні, а й в інших інженерних (та й не тільки) напрямках.

P.S. Краще спілкуватись менше, але якісніше. Та не забувайте робити нотатки.

Для тих, хто готується до технічної співбесіди

#automation #interview

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

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

⚡️ Епізод 22: Де тестувальник приймає участь в ретроспективах

Не всі можуть дивитися в завтрашній день. А як щодо минулого?

В цьому епізоді подкасту Артем та Олександр розбираються з ретроспективою.

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

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

А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️
Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏

#testingminutes | @a_grygorenko| Test Engineering Notes

Як тестувальник створює цінність

#testing

Цінність інженерів

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

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

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

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

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

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

Цінність зворотнього зв'язку

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

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

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

Цінність коду й тестів

Робочий автотест на локальній бранчі має меншу цінність, ніж той, для якого створений PR. Автотест у процесі код рев'ю - має меншу цінність, ніж той, що вже в головній гілці. Але тест, що вже вмерджений в develop гілку та ганяється кожен день - має найбільшу цінність.
Тест кейс, тільки-но доданий в TMS приносить менше користі, ніж той, який вже використовується, як частина чекліста.

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

Цінність автоматизованих тестів

Автоматизація сама по собі не приносить цінності користувачеві. Це просто один з інструментів, щоб отримати інформацію та прискорити фідбек. Так само, як юніт тести чи автоматизований CI/CD пайплайн. Або ж canary релізи.

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

Як тестувальник може підвищити свою цінність

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

Keeping Tests Valuable: Social Testing at the Heart of Software!

#testing #engineering

Чи знаєте ви, в чому різниця між solitary та sociable модульними тестами?
Якщо ні - маю для вас одну з найкращих нещодавних статей на цю тему. У статті - купа практичних прикладів та пояснень.
Рекомендую.

🎙 «Питання якості». QA Podcast #14. Як тестувальнику приборкати ШІ та фейли, які траплялися з новими ведучими

Друзі, сьогодні рівно 2 роки з моменту створення нашої тестувальницької спільноти 🎉 Дякуємо, що ви з нами!

І сьогодні, у нас для вас прем’єра нового сезону подкасту «Питання якості». Нові ведучі, нові погляди на робочі та не тільки моменти, а також багато чого цікаво зі світу тестування.

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

Випуск подкасту «Питання якості» #14 на нашому YouTube 👉 https://youtu.be/1UzIrUJEkxg

А обговорюємо — на форумі. 
💬 https://dou.ua/goto/mCUc