Тести пишуть люди | QA

IT, писати в LinkedIn, сваритися"

Я не знаю, чи це правильно. Але особисто для себе я обрала НЕ сваритися. Бо без доказів такі пости можуть виглядати як хайп. А збирати докази, записувати — у мене би з’їло багато сил. Просто тепер я знаю, у які компанії більше ніколи не піду (Але, звісно, якщо ситуація прям дуже погана — то не слухайте мене й сваріться. Тут все індивідуально)

🟤Якщо у вас є робота, просто продовжуйте вчитися й розвивайтеся

🟤Якщо ви шукаєте роботу, дайте собі час: шукайте, спілкуйтеся, обирайте

🟤Якщо ви мануал, не бійтеся автоматизації. Спробуйте написати 1 тест. Часто чую:

"Я боюся йти в автоматизацію"

Просто спробуйте.

————-
Гарного дня всім! Напишіть, чи погоджуєтеся зі мною і що можна додати до списку.
Тримаємося! ❤️🙏

➡️ЩО РОБИТИ, ЩОБ ЗНАЙТИ РОБОТУ АБО КУДИСЬ РУХАТИСЯ?

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

Одразу скажу:
питання роботи зараз дууужжее складне. Компанії банкрутують, проєкти закриваються. Якщо вас це торкнулося, знайте, що з вами все так. Це просто треба пережити.
Все дуже індивідуально. Напишу просто, що би я порадила, наприклад, собі.
І що робила/роблю я:

🟤Англійська. Хоча б якось використовувати її, потрохи вчити. Говорити з ChatGPT, дивитися фільми.

🟤Мати LinkedIn.Він дуже допомагає в пошуках роботи і загалом бути в курсі IT-новин. Чомусь досі дуже багато людей не ведуть його "бо якось не треба". Моя порада — краще вести. Хоча б мінімально: заповнити інформацію про себе.

🟤Якщо вам цікаво embedded і ви розбираєтеся, то ви дуужже круті. Ідіть у цю сферу, у вас на старті є переваги. Бо багато хто НЕ вміє паяти, не знає законів Ома і просто не має до того схильності. Якщо ви це любите, то у вас багато відкритих горизонтів — розвивайте це.

🟤Розібратися з API тестуванням. Бо воно треба всюди. Не просто почитати — а написати пару тестів. Спробувати потестувати Postman'ом і через скрипт. Відчути для себе різницю. Написати пару тестів на кожен HTTP-метод: GET/POST/PUT/DELETE

🟤Якщо йдете глибоко в API-напрям, спробуйте розібратися з контрактним тестуванням. Це мало хто вміє і знає, і це дуже особливий тип тестування

🟤Обрати для себе напрям: Веб, десктоп, мобайл (Android/iOS) — читати, налаштовувати, дивитися. Качати себе в цьому напрямі, бо вони всі дуже різні

🟤Якщо цікаво Веб - вчити Playwright, трохи глянути Selenium

🟤Для десктопа глянути Appium. Також дуже треба вміти працювати з віртуальними машинами. Бо доведеться тестувати різні версії OS. Часто треба вміти працювати з VMware Fusion

🟤Android: якщо вам цікаво, можна глянути Appium для мобілок. Але краще, якщо є час і можливість: Kotlin чи Java. В ідеалі Kotlin. У моїй бульбашці багато проєктів і компаній для Android взяли Kotlin і кажуть, що це зараз найкраще рішення. Framework Espresso

🟤iOS:треба знати XCTest framework та Xcode. Вчити Swift

🟤Для Android потрібна Android Studio. Дуже багато проєктів під Android, тому якщо ви прокачаєтеся, це буде класна перевага. Подивіться, як поставити додаток на реальний девайс, на емулятор, на свій телефон, планшет, на телевізор?

🟤Розберіться з якимось SaaS-сервісом, який дає браузери та девайси для запуску віддалено. Наприклад - BrowserStack

🟤Зробіть собі простенький проєкт і налаштуйте CI

🟤Зробіть 1 Docker-файл і спробуйте щось у ньому запустити. Без Docker зараз нікуди. Коли розберетеся з Docker-файлом, зробіть docker-compose файл. Подивіться, для чого він

🟤Якщо є час, подивіться AWS. Зробіть 1 маленький бакет. А краще підійміть 1 сервер. Розберіться, як зайти на цей сервер по SSH.

🟤Будьте критичні до свого проєкту. Задавайте собі питання:

Чи подобається мені цей тест? Чи дає він користь? Якби це був мій проєкт і моя компанія — чи хотіла б я мати для себе цей тест? А скільки мені коштує мій тест? Скільки я витрачаю грошей, щоб він ранився кожен день?

🟤AI - тут спробуйте капнути глибше. Пограйтеся з бібліотеками для створення моделей машинного навчання та для базових алгоритмів ML. Створіть простий AI-проєкт, наприклад, програму, що класифікує зображення (котик або собака).

🟤Якщо ви шукаєте роботу — просто монотонно дивіться вакансії й аплайтеся на те, що вам підходить. Говоріть із рекрутерами, залишайтеся в хороших відносинах, навіть якщо не підійшли, бо дуже часто до вас згодом можуть повернутися, коли буде нова вакансія. Ну і просто це важливо, навіть якщо до вас НЕ повернуться

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

"Катя, напиши на ДОУ, треба писати в *баное.

➡️ЯК МОЖНА ПЕРЕВИКОРИСТОВУВАТИ ТЕСТОВІ АККАУНТИ НА CI?

Хочу поділитися тим, як я зазвичай роблю, можливо комусь буде корисно🫰

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

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

Що часто робила я в такому випадку? - Це pool тестових юзерів.

Тобто:
▪️Тестові юзери створюються заздалегідь (один раз)
▪️Їхній статус відслідковується через спеціальний API чи базу даних.
▪️У тестах "беремо" доступного користувача, позначаємо його як "зайнятого", а після завершення тестів – повертаємо у статус "доступний".

Це може бути любий сервіс, який вам комфортний. У моєму випадку це була AWS Lambda

Приклад запиту для отримання юзера:

Отримати доступного користувача:
curl --silent --show-error --location --request GET \
"https://a2sgsj4bz0.execute-api.ap-southeast-1.amazonaws.com/prod/code" \
--header "x-api-key: $DISPENSER_API_KEY"

Відповідь:
{
"ID": "user1",
"Code": "12345",
"Email": "user1@test.com",
"Status": "in-use"
}

Приклад запиту для повернення юзера:

curl --silent --show-error --location --request PUT \
"https://a2sgsj4bz0.execute-api.ap-southeast-1.amazonaws.com/prod/user/cleanup" \
--header "Content-Type: application/json" \
--header "x-api-key: $DISPENSER_API_KEY" \
--data-raw '{
"user_id": "user1"
}'

Відповідь:
{
"message": "User user1 is now available.",
"updated_user": {
"ID": "user1",
"Code": "12345",
"Email": "user1@test.com",
"Status": "available"
}
}

————

Так ми:

▪️Мінімізуємо витрати на створення нових користувачів.
▪️Уникаємо складних процесів із реєстрацією та підтвердженнями.
▪️Можемо паралелізувати тести
▪️Контролюємо використання тестових ресурсів.

Сууупер важливо пам‘ятати що тестового юзера після тестів треба завжди покласти назад.
Зажди, не важливо, тести пройшли, впали, чи щось інше. Завжди повертаємо юзера - бо інакше, вони в якийсь момент всі «будуть зайняті»

Тому сууупер важливо завжди робити always в кінці пайплайна:

Приклад:
- run:
name: Cleanup Users
when: always

Що головне?
Колись ми взяли дівчинку на позицію Junior QA в команду. Все було поспіхом, ніхто нічого не встигав. Ми не зробили їй хорошого онбордингу.
Це був той самий випадок, коли кажуть: «Кинули людину, яка не вміє плавати, у воду, щоб вона сама якось навчилася»

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

Потім відбувся мітинг: я, наш менеджер і ця дівчинка.
Вона сказала:

«Мені дуже шкода, що я не побачила ті помилки й не завела баги. Я наче помічала, що щось дивно, але не була впевнена й баги не завела. Мені дуже шкода»

Мій менеджер відповів їй так:

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

Що мені важливо, і що я дійсно вже побачив, — це включеність і залученість. І те, що тобі “не все одно”,

— це головне, і я очікував саме цього».

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

Тому головне — це залученість.

«Я прийшов вам допомогти. Так, у мене мало досвіду, але я швидко навчуся»

— як афірмація.

Хочу додати ще зі свого досвіду:

1️⃣Колись, років 9 тому, ми взяли в команду junior QA automation. Тоді ми ще всі працювали разом в офісі. І була задача – покрити API автотестами. Завдання було досить складним, але цікавим. Наш junior QA сказав на дейліку вранці:

«Я спробую зробити»

Через кілька годин я запитала, як справи і чи потрібна допомога. У відповідь почула:

«Я не робив, бо зрозумів, що це займе супер багато часу, і ти зробиш це значно швидше»

Мені це було дивно чути.
Я йому сказала:

«Давай спробуй»

, бо це єдиний шлях до зростання. Він робив, але без ентузіазму, довго. І на дейліках казав:

«Я не розумію, чому мені дали таку задачу, це нелогічно, що я витрачаю стільки часу»

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

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

Помилка №1:
Не брати на себе відповідальність і не копати. Не робіть так.

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


————————————————

2️⃣Колись, років 10 тому, на 1:1, мій junior QA, який пропрацював у нас півроку, сказав:

«Катя, я подивився зарплати на ДОУ, зрозумів, що я отримую значно менше. Тому давайте домовимося, що я не буду робити задачі по Jenkins і по налаштуванню VM – бо мені це складно, а я не отримую такої зарплати, щоб мати мотивацію на таке складне»

Я тоді просто втратила дар мови. Незабаром він перейшов в іншу компанію на більші гроші. І ми його навіть не тримали.

Порада №2:
Одразу, коли починаєте кар’єру, оберіть для себе комфортну суму.

Щоб, коли ви почали працювати, у вас не було відторгнення і не змішувалося все в купу: робочі досягнення та зарплатні очікування.

А також, якщо ви починаєте з якоїсь маленької, некомфортної суми в компанії, АЛЕ бачите можливості для росту і хочете там працювати, – на самому початку запитайте у HR, ще ДО підписання контракту:
🔹Як буде змінюватися винагорода?
🔹Чи заплановані підвищення згодом і як часто?

Чому це краще запитати на старті? Щоб не було ситуації, коли через пару місяців ви втратили мотивацію, вам не вистачає коштів, і вам не цікаво залишатися в компанії. А компанія вас уже навчила, команда вклала в вас час і сили. Це про вашу репутацію

🙏🙏

➡️Частинка друга
Що часто приводить до того, що автоматизація не дає користі і по трохи вмирає (ніхто не дивиться на тести, вони червоні і з часом фреймворк видаляється)?💔🥺

🔴Автотести не зменшують мануальне тестування і регресія мануальна як була так і лишилася без змін.

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

🔴Коли не налагоджений процес із flaky тестами, коли все постійно червоне. Коли ніхто за тим не слідкує і чутно фразу:

«Та воно там постійно щось падає»

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

🔴Коли фреймворк обростає декораторами і складною конфігурацією. Коли тести складно запустити — це часто red flag і початок кінця

З власного досвіду: я бачила проєкт, де було 50 сторінок опису, як запустити тести.
50 сторінок, де через абзац уже застаріла інформація. Запустити тести у мене зайняло десь 2-3 тижні.
Просто запустити.

Через рік ми цей фреймворк видалили.

🔴Про паралелізацію варто думати на початку. Чим далі, тим складніше буде це зробити.

🔴На мою особисту думку, 2 ретраї — це вже багато. Один ще ладно. Але два — вже забагато. Найбільше я бачила 4 ретраї.

🔴Недотримання тестової піраміди і написання лише UI-тестів.

🔴Відсутність метрик і звітності.

🔴Репорти, де дууууже часто 2 крайнощі: або дуже мало інформації про тест, або занадто багато логів

Якщо коротко, то ось так🫰🙏

-——-

Друзі, нагадую, що у нас є посилання на Тайного Санту, де можна зареєструватися для участі до 23 грудня 🎅

Якщо раптом ви відчуваєте, що хочете трохи новорічної активності, доєднуйтеся 🙏🫶

Привіт! Хочу лишити це тут🙏
І завтра допишу другу частинку.

—————————————

➡️Дуже популярні помилки в автоматизації - ЧАСТИНА ПЕРША

(частковий витяг з нашої дискусії з Бетельгейзе з Володимиром + мої думки)

1️⃣Коли на CI не видно червоного статусу після того, як якісь тести падають

Чому так може бути?
Команда, яка запускає тести, не повертає свій статус-код, і в результаті CI завжди показує "зелений" статус.

Приклад помилки:
pytest test_example.py | exit 1
Так робити не можна - оскільки команда завжди завершиться з кодом 1 через exit 1, незалежно від того, чи пройшли тести.

Як правильно:
Команда для запуску тестів повинна бути простою і повертати свій власний статус-код
pytest test_example.py

Це дозволить CI відобразити реальний статус тестів.

2️⃣Коли ми перевіряємо елементи списку, але не перевіряємо, чи список не порожній

Чому це важливо?
Якщо список порожній, ми можемо пропустити важливу проблему. Наприклад, якщо пошук поверне 0 елементів або викличе помилку, тест не зайде в цикл, і проблема залишиться непоміченою.

Приклад помилки:
for element in some_elements_to_validate:
assert validate_element(element) # Перевірка коректності елементів

Якщо some_elements_to_validate порожній, перевірка ніколи не виконається

Як правильно:
Спочатку перевірте, що список не порожній:
assert some_elements_to_validate, "Список порожній! Можлива проблема в пошуку."

for element in some_elements_to_validate:
assert validate_element(element), f"Елемент {element} некоректний."

3️⃣Відсутність прав на CI і байдужість до цього

Чому це проблема?
Якщо тестувальник не має прав на налаштування CI, він не може:
🔹Розуміти, як налаштовані пайплайни
🔹Вносити зміни в тестову конфігурацію
🔹Ефективно реагувати на проблеми.

Це може призвести до нестабільної автоматизації, де тестувальник залежить від DevOps або розробників.

Як діяти:
Тестувальник повинен:
🔹Наполягати на отриманні прав доступу до CI
🔹Розуміти, як працює пайплайн (від запуску до генерації звітів)
🔹Поліпшувати процес, не перекладаючи відповідальність на DevOps

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

Приклад:
Тестувальник має розуміти і мати доступ до конфігурацій пайплайнів, наприклад:
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Run tests
run: pytest test_example.py --alluredir=./allure-results

І тестувальник повинен мати змогу налаштовувати такі параметри.

Пасхалки - продовження

Чи писали ми на це тест кейси і тестували потім пасхалки? Ні.
Це була логіка, про яку просто всі знали, але це ніяк не тестували і не чіпали. Просто вона собі була. І її було не дуже багато.

Десь за увесь час ось 4 випадки згадала:
🔹2 пташки (різні)
🔹Дельфін
🔹«Ти зможеш»