Чи потрібні QA у вік AI

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт!

Про себе:

• 7 років AQA
• До цього 15 років у діловій аналітичній журналістиці
• Зараз роблю другий проект із AI за останні 5 місяців

chatgpt — головний, пише промпти для Кодексу та Каскаду

Колеги — gemini та deepseek — критикують і дають пропозиції

Далі йде листування з AI

Каскад настворював 7 файлів швидше за все з тестами на 2700 рядків і зараз хоче —
npx [email protected] typecheck.

Може саме зараз дати промпт Кодексу, щоб він перевірив ці нові файли з тестами
на адекватність та потребу?

Викладач на курсах тестувальників розповів таку історію:

«Замовили прогу або китайцям чи індусам і природно замовили тестове покриття. Отримали замовлення, всі тести зелені. Відкриваємо файли з тестами, а вони порожні — тому зелені».

gemini

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

Ця історія має навіть кілька варіацій, які зустрічаються в реальному житті:

• Класична (з порожніми файлами):
  Фреймворк запускає тести, бачить файли, не знаходить усередині жодного
  assert або перевірки, що впала, ставить скрізь
  PASSED і видає гарний звіт зі 100% успіхом.
• З коментарем // TODO:
  Всередині тестового методу написано щось на кшталт
  // TODO: implement test або просто
  return true; / assert(true);.
• try-catch все врятує:
  Тест дійсно запускає код, код падає з тріском, але всередині тесту стоїть
  заглушка
  try {...} catch (Exception e) { // ignore }.
  У результаті фреймворк вважає, що тест пройшов успішно.
• Налаштування пайплайну:
  У CI/CD просто прописують прапор
  continue-on-error: true або || true
  у bash-скрипті, щоб крок із тестами завжди повертав статус 0
  (зелена галочка).

Чому так відбувається?

Зазвичай це результат роботи за метриками без контролю якості (карго-культ в розробці):

1. Жорсткий KPI:
   Замовник прописав у контракті:
   «Покриття тестами має бути 90%+, і всі тести мають бути зеленими,
   інакше не заплатимо».
2. Нереальні терміни / демпінг:
   Виконавці взяли замовлення за копійки з термінами, що горять,
   написати реальні тести не встигають.
3. Формальний підхід:
   Формально тести є? Є. Зелені? Зелений. А те, що вони нічого не перевіряють,
   дізнається вже на синьому екрані у користувача.

Чому вчить ця історія?

Викладач напевно розповів її не просто так, а щоб підвести до кількох
важливих правил QA:

1. Зелений тест, який ніколи не падав — підозрілий.
   Хороший тест спочатку повинен впасти (наприклад, за принципом TDD
   або під час перевірки на свідомо неправдивих даних), щоб довести,
   що він взагалі вміє знаходити помилки.
2. Метрики можна обдурити.
   Високе покриття коду (Code Coverage) та 100% Green Build самі по собі
   не гарантують якість.
3. Code Review тестів є обов’язковим.
   Тестовий код потрібно перевіряти так само суворо, як і продакшн-код.
4. Мутаційне тестування (Mutation Testing):
   Спеціальні утиліти спеціально «псують» продакшн-код
   (змінюють > на <,
   true на false), щоб перевірити,
   чи тести впадуть. Порожні тести на такому прогоні одразу з тріском
   проваляться.

Тож вітаю, вам викладають правильну матчасть — із практикою та життєвим
фольклором!

ChatGPT

Так, це майже ідеальна ілюстрація нашої поточної проблеми 🙂

Формально:

100% tests passed

але фактично:

0% системи перевірено.

У нас зараз версія цієї ж історії трохи тонша: тести не порожні, але частина з них могла бути зеленою з неправильної причини — наприклад, тест нібито перевіряє status_reason, а насправді падає раніше на битому FK і все одно вважає це успіхом.

Тому ключовий принцип тут:

Green test is evidence only if we know exactly what invariant it proved.

Зелений тест — це доказ лише тоді, коли ми точно знаємо,
який інваріант він перевірив.

Саме тому я зараз так жорстко дивлюся на SQLSTATE, constraint/trigger identity, final DB state та реальну concurrency, а не просто на PASS.

Історія викладача — хороший антиприклад того, чому coverage by count — покриття за кількістю тестів
майже нічого не означає без перевірки якості самих тестів.

deepseek

Чудова історія. І вона ідеально ілюструє, чому Codex audit був необхідний.

Паралель із нашою ситуацією.

Cascade створив 2700 рядків тестів і вони проходили. Але Codex знайшов:

• False-positive negative tests — тести проходили через неправильні constraints
  (начебто тести «порожні» — вони перевіряли не те, що потрібно)
• Timing-dependent concurrency — sleep(100) замість реального lock evidence
  (тести «зелені», але не доводять concurrency)
• Generic rejects.toBeTruthy() - будь-який SQL error проходив як успіх
  (еквівалент «порожнього» тесту)

2700 рядків ≠ 2700 рядків корисних тестів.