Сповідь тестувальника

Привіт, мій щоденнику...Ще не так давно як був переконаний, що є попит на поради що до українського контенту, але зараз розумію, що ні. Бо контенту навалом і єдина причина, чому хтось роками повторює, що його немає — він не шукає. А значить, немає справжньої зацікавленості. А значить, поради не змінять ситуацію.Проте, я досі можу ділитися чимось без оцієї мішури — відчуття потреби у моїх порадах. Та й взагалі, це лише допис у щоденнику, чи не так?І раптом хтось прочитає цю сторінку щоденника, то ось:Канал "УТ-2" з низкою різних форматів, серед яких найбільш технічним є mvc. Ведучі різнобарвні, інколи навіть трохи "бісять", але контент відмінний. Інші формати менш технічні, але часто унікально цінні з просто чудовими гостями.https://www.youtube.com/@yt-2Канал "Шо по коду?" напроти — не пропонує нічого не технічного, що легко читається з його назви. Це подкаст з інженерами, які по справжньому люблять свою справу і копирсаються в цікавих (але часто дуже технічних) аспектах технологій, що може бути цікаво навіть якщо слухач не знайомий з ними усіма.https://www.youtube.com/@shopokoduНа мою думку, це приклади українського технічного та навколо-технічного контенту найвищої якості. Це означає, що в цьому випадку "закордонні аналоги" не мають жодної переваги перед ними. Це реально топ.А чи вважати цей допис, що починається з "Привіт, мій щоденнику..." порадою? А у кого я тоді питаю?..

Привіт, мій щоденнику...Дуже популярною помилкою у навчанні тестування, а потім і у роботі є не розуміння різниці між суттю та формою. Яскравий приклад тут — чек лист. Його лаконічна форма не є його суттю, хоча й майже завжди є формою чек листа.Якщо ми просто скоротили тест кейс до одного пункту чи рядка у таблиці, наш тест кейс не перестав бути тест кейсом, не перетворився на чек лист. Чому? Бо ми змінили форму, але не суть.У статті на DOU розглядається це питання, але традиційно — з зазначеною помилкою.Я залишив розгорнутий коментар до цієї статті.Головне: - чек лист не описує перевірку та з нього не випливає очікуваного результату, бо пункт чек листа описує групу перевірок, конкретний список яких та відповідні очікувані результати залишаються на розсуд досвідченого тестувальника.- тест кейс же є буквально тестовим випадком, доволі конкретним, за яким стоять кроки (навіть якщо вони не описані детально) та очікуваний результат (навіть якщо він не формалізований письмово).Тобто, "Перевірити автентифікацію" є пунктом чек листа, а "Перевірити, що валідні логін та пароль дозволяють увійти" є тест кейсом. Останній може виглядати навіть як "Перевірити валідні логін+пароль" — форма схожа на чек лист, але суть залишилося як у тест кейса.В цьому сенсі наявність описаних кроків є також формою тест кейса, але не його суттю. І нехай нікого не бентежить, що у чек листа кроків взагалі ніколи не буває. Тут не працює логіка "якщо у чек листа не буває кроків, то їх відсутність завжди вказує на чек лист". Ні. Просто існують тест кейси різного рівня деталізації.Чому тут не дихотомія (або-або) з кроками? Бо протиставлення тест кейсів та чек листів — штучне, і саме воно заважає правильно сприймати ці дві сутності. Викиньте дихотомію, не протиставляйте їх, й вам стане простіше.

Привіт, мій щоденнику...Світ IT змінюється не лише через активне використання мовних моделей, хоча вони, здається, впливають на все.Вчора NVIDIA релізнули DLSS 4.5 (вже доступно) та 6х Frame Generation (тут лише анонс, реліз навесні). До чого це я? Ось яка схема вимальовується. ШІ-компанії масово скуповують пам'ять, що впливає на роздрібний ринок. Якісна сучасна оперативна пам'ять вже зросла в ціні у три рази. Туди ж тягнуться сучасні ssd. Це спричиняє й дорожчання відеокарт, а що відчутніше — то павзу у випуску нових серій. Висока ймовірність, що у 2026 році їх просто не буде.І ось тепер повертаємося до нових релізів софта від NVDIA. Річ у тому, що DLSS 4.5 та FG 6x обіцяють доволі відчутне покращення якості та продуктивності на вже наявному залізі, хоча й не для всіх серій. Тобто, ринок тепер виглядає трохи інакше. Типу — нащо вам нова модель відеокарти, якщо вчорашня "стара" після оновлення працює як ймовірна "нова"? Або у моделях: навіщо вам нові Ti та Super версії, якщо ми вже наявні моделі покращуємо безплатно?А що до професійного використання, то це оновлення торкається не тільки ігор, але й роботи з локальними ШІ: стосується як генерації зображень, відео та 3D, так і роботи з малими мовними моделями тощо.Останнє особливе цікаво, бо неприємно спостерігати, як користувацький ринок потерпає від дефіциту чипів через ШІ, але ця "плюшка" — наче "Ось, дивіться — ми поділимося з вами частиною того, що відібрали та вклали у розвиток ШІ".Поки це лише моє враження, не бачив у NVIDIA прямих натяків та це. Але враження склалося.

Привіт, мій щоденнику...Ось тест на адекватність згенерованого «ШІ» коду. Він полягає у питанні: «Чи дозволили б ви, що хоча б частину ПЗ, що керує вашим серцевим стимулятором, написав би "ШІ"?». Чи готові ми віддати створення такого коду «ШІ», чи вважатимемо надійнішим код та алгоритм, який первинно виник в голові людини та далі пройшов всі етапи перевірки якості, які також керовані людиною? З відповідальністю, що цілком лежить на людях, що були залучені у процес?Цей тест не має на меті переконати, що ми повинні негайно припинити генерувати код за допомогою «ШІ». Він пропонує тверезий погляд на якість коду та всього програмного забезпечення. Варто сказати, що це призведе нас до підходу, який ми вже використовуємо в роботі. Адже ми постійно йдемо на компроміси перед релізом та допускаємо певну кількість ймовірних багів. Ми оцінюємо ризики й вони увесь час різні в різні періоди життя продукту. Різні для різних продуктів. Отже, я не пропоную нічого нового. Це гарний підхід, який довів свою ефективність. Це коли ми давали частину роботи фахівцям одного рівня, а іншу частину — фахівцям іншого. Тобто йдеться про правильний процес розробки. А отже, при використанні «ШІ» нам варто так само оцінити ризики та не боятися прийти до того, що певну роботу ми ніяк не можемо віддати йому. Принаймні на даний час.А питання про код для серцевого стимулятора допоможе тверезо дивитися на якість та знаходити правильний баланс у використання «ШІ»-інструментів. Пригадаємо часи, коли розробники з Індії масово закидували нас своїм кодом. Його було багато, частина з нього працювала добре, але велика частина — ні. Вони брали кількістю, не якістю. А ще низькою ціною. Нічого не нагадує? Адже ми й раніше просто повертали поганий код до колеги з Індії й він переписував його ще і ще, поки код не проходив рев'ю. А тепер нічого не нагадує?Звісно, таке порівняння доволі грубе і не претендує на наукову суворість. Але воно непогано підкреслює певні принципи взаємодії з генераторами коду.

Привіт, мій щоденнику...Подумав про життєздатність тези "Тепер фахівці мають перевіряти за ШІ, а не робити самі". Це напрям, в якому рухають "ШІ" компанії, що розробляють мовні моделі, а отже варто подумати, як ми будемо працювати у майбутньому.Першим в приціл потрапляють тестові артефакти, насамперед такі, як чек листи та тест кейси. А якщо казати про автоматизацію, то майже увесь код. Нам кажуть, що ми більше не маємо робити це власноруч, а лише перевіряти, наскільки коректно зробила цю роботу модель.Поки залишу без уваги чек лист, який для мене серйозніший документ, ніж тест кейси, бо сильно залежить від експертизи як його творця, так і його виконавця. Це не спрощена версія тест кейсів, не те що ми робимо, коли не маємо часу на повноцінні тест-кейси. Залишимо в стороні зараз.Повертаємося до тези про те, що "ШІ" робить, а ми перевіряємо. Розкриємо механіку процесу. Якщо казати про час "прямо зараз", то йдеться про те, що в галузі повно досвідчених фахівців, які мають достатню експертизу для такої перевірки. Гаразд, припустимо, ми спробуємо працювати в такому стилі. А інші? Що до новачків у галузі, які мають замінити нас? Вони не мають такої експертизи, отже не можуть й перевірити роботу мовних моделей.І тут ми підходимо до ядра — освіти та навчання. Який тренд на разі в освіті, особливо у "епоху ШІ"? Як казав класик: "Забули? Я вам напам'ятаю!". Тренд наступний. Навіщо вчитися "по старому", особливо коли йдеться про "рутину"? А рутиною є створення тестової документації та коду для автоматизації. Коло замкнулося. Адже це саме те, що нам пропонується більше не робити, як фахівцям. А молоді фахівці більше не хочуть цьому вчитися. Вони хочуть одразу генерувати таку роботу моделями. Вони довіряють моделям. А який у них вибір, якщо дві такі важкі тези давлять?Випишу окремо1. Багато роботи є "рутиною" та люди мають припинити робити її та віддати "ШІ"2. "Старий стиль" освіти та навчання поганий, бо багато чого тепер робить "ШІ" (який, на думку, наприклад, Сема Альмана, вже перевершив інтелектом доктора наук)То що виходить? Знову звернуся до класика: "Не кожен може у завтрашній день сматрєть".Друзі, запропонована нам схема не є життєздатною, вона зламана. Чи існують інші схеми, до яких особисто я ставлюсь позитивніше? Так, я маю кілька (адже критика не дорівнює заперечення). Але подібних схем я (майже) не бачу в інфопросторі, особливо від засновників ШІ-компаній. Зараз я бачу, що досвідчені фахівці використовують "ШІ"-інструменти зовсім не так, як новачки. Тобто, це розділення вже відбувається. І всі, всі фахівці погодяться зі мною, що саме їх експертиза, їх освіта дозволяє їм "витягувати" з "ШІ" те, що вони витягують та помічати важливі помилки й знаходити кращі підходи до використання "ШІ" в роботі. Без "старомодних" людських знань ви не зможете професійно користуватися "ШІ" ані зараз, ані у майбутньому.

Привіт, мій щоденнику...Залишилося непомітною думка Александра Ембірікоса, який очолює розробку Codex (агент для програмування від OpenAI). Ця думка є доволі небезпечною та заходить у царину тестування, принаймні первинного тестування коду, як мінімум.Пан Ембірікос вирішив подивитися на проблему колаборації людини та ШІ-агентів радикально та звинуватив у гальмуванні продуктивності... людину. Мовляв, людина заповільно або друкує на клавіатурі, або перевіряє код — все це дуже повільно та не дає ШІ-агентам працювати на всю міць.Який вихід пропоную Абрикос? Тобто, Ембірікос (це ж жарт у щоденнику та його ніхто не побачить, адже так?).Він каже, що треба звільнити людей від необхідності писати підказки та перевіряти роботу "ШІ".Ще раз: людина не має перевіряти роботу "ШІ" за думкою розробника агента для написання коду.А хто має перевіряти? Відомо хто — інший ШІ-агент. І тут у мене почало витягуватися обличчя. Тобто, ми ж таким чином визнаємо, що агенти для генерації коду потребують перевірки цього коду. Розуміємо, що ітерація за ітерацією таких агентів не розв'язує глобально цю проблему, як ми не намагаємося.Ми визнаємо, що генерація гарного та комплексного коду важко дається агентам.Чому якийсь інший агент має побачити недоліки у такому коді, якщо агенту-творцю це не під силу? Чому не поєднати їх в один "правильний" агент?Висловлювання тих, хто зараз керує розробкою "ЩІ"-штук стають чим далі, тим більш не логічними. Не всі, звісно. Але відсоток дивних думок збільшується.І перманентно для мене стоїть одне питання, на яке нікому не цікаво відповідати. Чому ми так гарячкувато та хворобливо-несамовито бажаємо створити штучну людину, по суті, та відібрати у живих людей роботу? Мені дійсно цікаво, що думають про це люди, бо в статтях та інтерв'ю про це ані слова.

Привіт, мій щоденнику...Як там наша славетна увага до деталей?Дивлюсь я відео одного пана про "ШІ", звісно ж. І бачу графік, що демонструє перевагу нової моделі Opus 4.5 від Антропік. Й помічаю у лівому нижньому кутку графіка цікавий символ, до якого я придивився. Бачу, що вертикальна шкала починається лише з 70%, а отже частину графіку від нас приховали.Це графік з офіційної новини Антропік, якщо що, я перевірив.При чому цікаво, що пан на відео каже, цитую "він вирвався на 10-15 відсотків від своїх конкурентів", хоча це не так ані по цифрах, ані візуально. По цифрах — значно менше, візуально — значно більше. Ну, прикинув "на око", ну ось таке в нього око. Яка різниця, правда? Олекса нудний, чіпляється до несуттєвого.Але ж це і створює у більшості людей хибне уявлення про реальність, в нашому випадку про моделі для програмування.Я створив власні графіки, при чому вони обидва використовують ті ж дані, вони реальні. Але я також "погрався" з вертикальною шкалою, щоб наочно показати, як буде змінюватися візуальне сприйняття ОДНАКОВИХ цифр залежно від представлення.Графік 1 показує реальні показники та візуальну різницю між моделями, бо починається від 0%, отже ви бачите всю "вагу" метрики.Графік 2 драматизує візуалізацію зі звіту Антропік, бо починається від 74%, що робить найнижчий показник зовсім крихітним, а закінчується на 81%, що робить найвищий показник таким, що височить над іншими.То як у нас з увагою до деталей? Річ у тім, що вона є дуже некомфортною для повсякденного життя, бо ми не можемо жити з постійним відчуттям недовіри до інформації, що оточує нас. Далі ми переносимо таку звичку й у професійне життя і все менше аналізуємо, все більше віддаємося емоціям та довіряємо тим, кому просто хочемо довіряти.Це вбиває у фахівці інженера.То що там показники? Ну, різниця між двома лідерами становить 3%.