Головна подія української QA-спільноти — конференція тестувальників «Бетельгейзе» очікує на тебе вже 18-19 жовтня (онлайн)!

Це 2️⃣ дні, що насичені найцікавішими подіями — від доповідей до дискусій.

➡️ 1 день: доповіді
🟢2 потоки, в кожному з яких 6-7 доповідей
🟢Спікери з різних галузей для обміну досвідом: від Middle QA до керівників відділів та засновників.

➡️ 2 день: дискусії
🟢1 потік, 6 дискусій на найактуальніші теми, серед яких окрема увага до ШІ.

Відвідувачам будуть доступні записи всіх подій.

🔈 Увага! Підвищення ціни з 6 жовтня!

Дивись програму та деталі доповідей на сайті конференції 👈

⚖️ Про результативність та ефективність

#engineering

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

Результативність (effectiveness) - відповідає на питання чи досягли ми поставленої цілі, чи отримали очікуваний результат. Коротко - "робити ПРАВИЛЬНІ речі".

Ефективність (efficiency) - означає чи використали ми наявні ресурси оптимально. Коротко - "робити речі ПРАВИЛЬНО". В ідеалі використати якнайменше часу, зусиль, коштів для досягнення результату.

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

Як ШІ замінить менеджерів

#python #ai

import time
import random

def random_status_prompt():
    prompts = [
        "What is your current status?",
        "Any blockers?",
        "Update your JIRA, please."
    ]

    # Sleep for a random number of minutes (converted to seconds)
    sleep_minutes = random.randint(1, 10)
    print(f"Sleeping for {sleep_minutes} minute(s)...")
    time.sleep(sleep_minutes * 60)

    # Pick a random prompt and display it
    message = random.choice(prompts)
    print(message)

if __name__ == "__main__":
    random_status_prompt()

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

#testing #learning

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

Основна думка була в тому, що ШІ не має тієї інтуїції та того контексту, який має тест інженер, залучений у проєкт. Але що таке інтуїція?

Інтуїція в тестуванні

Серед технік тест дизайну є одна, що називається error guessing, себто вгадування помилок. Вона базується на здатності тестувальника знаходити та передбачувати появлення дефектів на основі досвіду минулих, схожих, помилок в подібних компонентах. Тобто ця техніка передбачає наявність в тестувальника ... інтуїції.

Інтуїція в навичках

Якщо дивитися на модель Дрейфуса, то існує пʼять рівнів володіння навичками: новачок, просунутий новачок, компетентний, вправний та експерт.

👉 Новачкам потрібні чіткі інструкції (можна назвати їх промптами)
👉 Просунутим новачкам теж потрібні інструкції, але вони вже можуть пробувати виконувати щось по-своєму.
👉 Компетентні люди вже можуть досліджувати проблеми та виправляти їх самостійно.
👉 Просунуті - можуть аналізувати роботу інших та виправляти самих себе. Саме тут найбільше застосовуються ті самі фундаментальні знання.
👉 Експерти - працюють на основі інтуїції. А інтуїція будується на досвіді та практиці. Експерти знають різницю між важливими та нерелевантними деталями. Експерт знає на яких з них дійсно треба фокусуватись - бо має розвинуту здатність до pattern matching (співставляння зі зразками)

Тож новачкам (та ШІ) треба давати чіткі вказівки. Вчіться робити ці інструкції точно та зрозуміло. Зважайте на контекст!
А от експерти від таких чітких правил стагнують та страждають.

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

Що ж нам з усим цим робити?

⚡️ Ставайте експертами в своєму продукті та тих навичках, якими володієте.
⚡️ Розвивайте здатність отримувати нові відкриття з багатьох джерел, співставляти факти, застосовувати свій досвід.
⚡️ Щоб мати можливість опиратися на цей досвід - треба вміти цей досвід помічати, записувати, оцінювати та рефлексувати. (Тут знову згадаю про важливість нотаток)

А ось не треба натякати українцям, що останній лимон захований десь на AWS S3 бакеті ...

Чи потрібно отримувати сертифікат ISTQB?

Я й сам не знаю 😀!

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

📅 Коли: 25 жовтня
💻Де: онлайн
💡Скільки коштує: безкоштовно

Не забудьте зареєструватись 👉 https://certifiedunicorns.pro/hot-istqb-conference

Починаю читати свіжачок. Цікаво, що там діди (Michael Bolton & James Bach) написали.

P.S. Огляд та розбір буде згодом.

Taking Testing Seriously - Огляд (1)

#testing #books

На минулому тижні я прочитав нову книжку від Джеймса Баха та Майкла Болтона під назвою "Taking Testing Seriously".

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

🎓Про що ця книга?

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

📖 Розділ 1 - Why Another Book About Testing?

У першому розділі автори розмірковують - нащо вони написали "ще одну" книжку з тестування.

Спочатку, автори знайомлять нас з різними школами тестування: factory, quality, agile, analytical, context-driven. (А ви чули про такі школи тестування? Якщо ні - можу більше про них розповісти)

💡Rapid Software Testing є методологією контекстно-орієнтованого тестування.

Далі, Джеймс та Майкл починають роздивлятись саме поняття тестування та його аналогії з реальним світом.

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

Також автори зазначають, що використання GenAI та підходів типу vibe coding додає ще більше роботи з тестування. Як розробникам, так і тестувальникам. (З цього приводу напишу окремий пост, бо якраз досліджую це питання).

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

📹 Як обрати собі школу тестування

#testing #video

🏫 Вчора, в огляді на книгу Баха й Болтона, я згадав такі штуки, як школи тестування.

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

❗️І так, ЦЕ НЕ ПРО КУРСИ 😀

📖 Taking Testing Seriously - Огляд 2

#testing #books

Попередні огляди: 1

Продовжуємо огляд книги Джеймса Баха та Майкла Болтона. Сьогодні я коротко розповім про вам про розділ 2 під назвою "Foundation"

💡Що таке тестування (згідно з авторами книги)?

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

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

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

В методології "Rapid Software Testing" існує різниця між тестуванням (testing) та перевіркою (checking). Тестування може зробити тільки досвідчена людина. Перевірку - може зробити машина. Можна провести паралель із програмуванням та компілюванням. Програмують люди, а машина потім компілює код.

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

Так само є тестування із застосуванням інструментів. А є - автоматизовані перевірки. Автори розділяють тестування та перевірку тому, що не існує "автоматизованого тестування".

Чи значить що з ШІ програмісти стануть не потрібні? Відповідь - ні, бо ШІ не несе відповідальності за код, який згенерувало. Це задача програміста інтегрувати та перевірити код, що написаний машиною.

🎭 Різниця між тестуванням та виконанням тесту

Автори відмічають, що

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

А також:

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

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

На цьому все. До зустрічі в наступному пості.

🧰Проблеми з ШІ інструментами з точки зору інженера - Частина 1

#testing #engineering #ai

ШІ повсюди. ШІ вже тут. Стережися ШІ!

Останній рік (чи може трохи більше) помічаю ажіотаж з використання ШІ.

⚡️ Лідери думок говорять на конференціях, що ШІ вже тут та забере наші робочі місця
⚡️ Менеджмент давить на лідів, щоб вони скоріш впроваджували ШІ де тільки можна
⚡️ Курси пропонують “чарівні” таблетки для тестувальників у вигляді підбірки промтів на всі випадки життя
⚡️ Деякі блогери пропагують вайб кодинг - як майбутнє програмування й тестування

❓Але постає питання - а чи дійсно ШІ є тією чарівною пігулкою, що зробить вашу роботи тестувальника чи автоматизатора набагато легше? Чи дійсно ШІ допоможе стати більш ефективним?

🎓Чому мені то цікаво?

Мої колеги та знайомі користуються ШІ кожного дня. Я сам користуюся ChatGPT, Claude, Perplexity, Gemini, Cursor. Пробував також Github Copilot.

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

До того ж - треба вміти користуватися тими інструментами ефективно.

💡 Що таке вайб кодинг?

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

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

Але чим більше розробник вайбкодить - тим більше зростає ризик, що він не перевірить результать ШІ та й зафігачить купу “наче працюючого” коду в мастер гілку.

🕶Проблеми з вайб кодингом та сучасними ШІ (LLM-ками)

Але сила вайб кодингу приходить із відповідальність (а точніше із проблемами ШІ):

👉 Галюцинації. ШІ генерує купу коду, який гарно виглядає, але не факт, що правильно працює. ШІ доволі легко може згенерувати тести на неіснуючі ендпоінти. Або ж зробити ці тести “зеленими” просто прибравши assertʼи.

👉 Надмірна впевненість. Девелопер з часом сприймає будь-які результати ШІ як правильні. Цим грішать навіть досвідчені інженери.

👉 Цикли перефразування. Коли інженер модифікує промт для досягнення кращого результату від ШІ. А ШІ генерує одні й тіж шматки коду та рішення (можливо виражені іншим чином)

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

Але це ще не всі проблеми. Бо є парадокс когнітивного спрощення. Що це таке - вже в наступному пості.

🪲 Чому впав Cloudflare?

#bugs #sql #rust

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

Але чому це сталося? Чи винні в цьому тестувальники? Чи справа в … коді на Rust?

Відповідь не така проста, як здається.

🎓 Як обробляються запити в Cloudflare

Усі запити на Cloudflare проходять через основний проксі сервер. На цьому сервері є багато модулів, що виконують перевірки безпеки для захисту від DDoS атак. Зокрема, такий модуль як Bot Management.

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

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

🏫 В чому виникла помилка?

За замовчуванням, фічі отримують розподіленим запитом у базу даних “default” у кластері ClickHouse. У користувача був доступ тільки до цієї бази.

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

Зміну в налаштуваннях зробили, але … не перевірили сам SQL запит.

SELECT
  name,
  type
FROM system.columns
WHERE
  table = 'http_requests_features'
order by name;

А цей запит не мав … фільтру по базі даних. Як результат, цей запит повертав фічі як з таблиці “default”, так і з системної таблиці.

То ж файл з фічами для Bot Management мав купу зайвих дублікатів фічей.

🕶 Ну то й що?

Виявляється, що для обробки фічей попередньо резервується оперативна памʼять. Зазвичай, у файлі було десь 60 фічей при максимумі в 200.

Але коли сталася помилка - у файлі фічей було більше ніж 200!

То ж серверу не вистачало памʼяті, щоб обробити ці фічі. Окей, не вистачило памʼяті, це погано - але чому так довго шукали проблему?

А код на Rust, який обробляє ці фічі … не обробляв таку помилку - а просто кидав базовий Error за допомогою unwrap();

    pub fn fetch_features(&mut self, input: &dyn BotsInput, features: &mut Features) -> Result<(), (ErrorFlags, i32)> {
        features.checksum &= 0xFFF_FFF_000_000;
        features.checksum |= u64::from(self.config.checksum);
        let (feature_values, _) = features
            .append_with_names(&self.config.feature_names)
            .unwrap();
        //
    }

То ж код почав видавати дуже загальну помилку.

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

💡 Що можна було б зробити?

👉Більш ретельно обробляти помилки. Rust як мова програмування в цьому випадку не винен.
👉Тестувати запити на тестових серверах (включно з лімітами по памʼяті). Можна було б досліджувати як система обробляє дані великих розмірів.

❗️Більш докладно про збій можна почитати в офіційному блозі компанії.

🕶 Framework vs. Solution

#testing #automation

Часто бачу у кандидатів в резюме та на співбесіді таку фразу - “я маю досвід побудови тестових фреймворків з нуля”. Інколи це правда. Але в багатьох випадках кандидат має на увазі трохи інше, а саме - test automation solution.

Але в чому різниця? Давайте похоліваримо (бо у кожного своє розуміння)!

📖Що нам говорить книга “Test Automation Fundamentals”?

A test automation solution (TAS) is a specific instance of a TAA* and consists of the test environment and its corresponding automated testware. The latter includes automated test cases (which may be grouped into test suites), test data, and specific configuration files. A TAS is therefore not a monolithic tool or framework, but rather a combination of tools, components, and testware brought together for the purpose of automating testing processes.

* TAA - test automation architecture

A test automation framework (TAF) can, however, be used to provide a test environment, tools, test libraries, or additional test frameworks that can then be reused for faster automated test creation and execution.

🌐 Що говорить Wiki?

A test automation framework provides a programming environment that integrates test logic, test data, and other resources. The framework provides the basis of test automation and simplifies the automation effort. Using a framework can lower the cost of test development and maintenance. If there is change to any test case then only the test case file needs to be updated and the driver noscript and startup noscript will remain the same.

❗️Окей, але що з того?

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

Наприклад тестові фреймворки JUnit, TestNG, pytest, Jest - можна використовувати для написання тестів для web, mobile, api та інших систем.

Приклади фреймворків в розробці: Spring, Hibernate в Java, Django, Flask, FastAPI в Python, React, Vue, Angular в JS.

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

💡Солюшен (рішення) - це застосування тестового фреймворку + купи додаткових утиліт, тестових даних, запуск на CICD чи в контейнерах на хмарах, репортинг. Та що найголовніше - набір тестових даних, клієнтів та тестів заточених під конкретний продукт.

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

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

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

🎓Висновки

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

Але якщо ви написали аналог pytest чи JUnit - тут ви безперечне написали фреймворк.

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

А ви пишете фреймворки чи солюшени?

🧰 Проблеми з ШІ інструментами з точки зору інженера - Частина 2

#testing #engineering #ai

Продовжую роздуми про те, які є проблеми у використанні інструментів ШІ в роботі тест інженера.

🧱Проблеми вайб-кодингу

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

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

Чому це погано?

👉 Новий код може бути дублікатом існуючого
👉 Новий код може додавати зайві рівні абстракції
👉 Новий код може погано інтегруватись з іншими наявними системами та API

Але крім цього є інша проблема …

🎓Парадокс когнітивного спрощення

Andrew Stellman розповідає про парадокс та наводить приклад того, як різні інженери застосовують ШІ.

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

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

Сінйьори за допомого ШІ:
- роблять швидкі прототипи
- генерують "фреймворки" для автоматизації
- досліджують та оцінюють різні варіанти імплементації алгоритмів
- автоматизують рутинні задачі

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

👨‍🔬 Так що робити?

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

Це все не означає, що не треба користуватись інструментами ШІ. Це також не означає, що треба вчитись як “діди” - без ШІ, без гугла - та писати код виключно на листочку.

Просто треба навчитись як користуватись ШІ без ризику втрати розуміння.

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

Просто знайдіть кнопку "Manage subnoscriptions" в меню зліва.

🤖 Ефективна робота з ШІ із Sens-AI фреймворком

#testing #engineering #ai

📚Сьогодні я розповім про підхід до роботи з ШІ, який пропонує Andrew Stellman в книзі “Critical Thinking Habits for Coding with AI”.

👉 Andrew називає цей підхід - Sens-AI framework. Цей фреймворк дозволяє інженерам користуватись та вчитись з ШІ не маючи проблем із парадоксом когнітивного спрощення.

Фреймворк складається з:

1️⃣ Контекст. Переконайтеся, що ваші промпти дають найповніший контекст для ШІ.

2️⃣ Дослідження. Робіть додаткові самостійні дослідження, якщо перші відповіді від ШІ занадто поверхневі або ж ви стикнулись з циклом перефразування.

3️⃣ Формулювання проблеми. Переформулюйте проблему, коли відповідь від ШІ не відповідає меті або ж занадто заплутана.

4️⃣ Удосконалення. Покращуйте результати відповідей від ШІ ітеративно.

5️⃣ Критичне мислення. Регулярно ставьте під сумнів відповіді ШІ, наче це код від менш досвідченого інженера.

Фреймворк цікавий, але на мій погляд є доволі очевидним. А ви як думаєте?

📖 Taking Testing Seriously - Огляд 3

#testing #books

Попередні огляди: 1, 2

Сьогодні поговоримо про цікаві моменти з книги Джеймса Баха та Майкла Болтона. А точніше - “Chapter 3 - How to Do a Test”.

🔬Суть тестування та міссія тестувальника

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

Автори зазначають, що в тестуванні ми також користуємось науковим методом пізнання.

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

В контексті тестування, автори пропонують користуватись трохи іншими термінамиЖ простір оцінювання та простір продукту.

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

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

💡Що таке хороше тестування?

Джеймс та Майкл також розповідають про універсальний процес хорошого тестування:

1️⃣ Збирайте та досліджуйте докази поведінки та атрибутів продукту

2️⃣ Досліджуйте можливі пояснення цих доказів та те, як вони повʼязані з вашими існуючими переконаннями

3️⃣ Рухайтесь вперед та назад - розглядаючи пояснення на основі доказів або ж шукаючи докази вмотивовані вашими переконанннями

4️⃣ Зосередьтеся на ризиках цінності продуту, бо це є однією з цілей тестування

5️⃣ Розповідайте історію про продукт та тестування - собі, своїм клієнтам й отримуйте від них зворотній звʼязок

6️⃣ Вирішуйте чи завершили ви оцінку продукту на основі наявних доказів. Рішення спочатку приймає тестувальник. Але на вищих рівнях - тільки клієнти зможуть прийняти фінальне рішення.

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

Шо там по ЗП?

DOU проводить зимове зарплатне опитування. А работодавці в Україні доволі часто користуються зарплатними віджетами щоб зрозуміти актуальні гілки.

То ж пропоную заповнити форму опитування тут. Це допоможе усім зрозуміти поточний стан речей.