Alur Kerja End-to-End, Integrasi CI/CD, Etika dan Keamanan: Menggunakan AI secara Bertanggung Jawab — Kecerdasan Buatan dalam Pengujian Perangkat Lunak dan QA

Keuntungan:

Kemampuan untuk merancang peran kecerdasan buatan dan titik persetujuan manusia dalam alur QA ujung ke ujung mulai dari ide hingga rilis dalam konteks CI/CD
Dalam CI/CD, AI tidak diberi otorisasi untuk 'lulus' pengujian secara otomatis, namun menerapkan batasan untuk melindungi data dan kunci rahasia
Kemampuan untuk melakukan pengujian keamanan sesuai kewenangan dan untuk tujuan defensif, serta menerapkan prinsip pengungkapan yang bertanggung jawab dan transparansi etis.

Dalam sepuluh unit sebelumnya, kami menggunakan AI dalam tugas individu: pembuatan skenario, kode otomatisasi, pelaporan bug, analisis cakupan, pengujian mutasi. Unit terakhir ini menggabungkan semuanya menjadi satu alur kerja yang bertanggung jawab. QA modern bukanlah pekerjaan yang berakhir di meja satu orang; Ini adalah proses yang ada di dalam CI/CD (Integrasi Berkelanjutan / Pengiriman Berkelanjutan — saluran di mana kode terus digabungkan, diuji secara otomatis, dan disiapkan untuk dipublikasikan secara sering dan aman). AI dapat menyentuh setiap tahapan proses ini. Namun seiring dengan berkembangnya kekuatan AI, pentingnya penggunaan AI secara bertanggung jawab juga semakin meningkat: privasi, otoritas dalam pengujian keamanan, etika, dan yang paling penting, menjaga kualitas keputusan tetap berada di tangan manusia. Dalam unit ini, Anda akan mempelajari aliran dan batasan ujung ke ujung.

Aliran QA yang didukung AI ujung ke ujung

Peran AI dalam perjalanan fitur mulai dari ide hingga rilis:

1. Analisis kebutuhan. AI menandai ambiguitas dalam persyaratan dan kriteria penerimaan yang hilang ("aturan ini tidak menyebutkan berapa banyak karakter minimum kata sandi").

2. Desain pengujian. Skenario dan rancangan kasus (unit 2), kasus tepi (unit 3) termasuk di antara kriteria penerimaan.

3. Otomatisasi. Draf kode pengujian Unit (6), API (5) dan UI (4); masing-masing dikonfirmasi oleh mutasi ( 10 ).

4. Integrasi CI/CD. Pengujian dijalankan secara otomatis dengan setiap penggabungan kode. AI menyusun konfigurasi pipeline (YAML), merangkum log pengujian yang gagal, dan menyarankan kemungkinan penyebab utama.

5. Keputusan pelepasan. Hasil analisis risiko (8) dan regresi (9) dikumpulkan — tetapi pakar memutuskan apakah ini bisa berhasil.

6. Pemantauan dan umpan balik produksi. Kesalahan dalam hidup menjadi ujian di masa depan; AI mengusulkan kasus regresi dari cacat produksi.

Tip: Siapkan AI sebagai lapisan dalam CI/CD yang “mempercepat draf yang ditinjau oleh manusia” daripada “menulis pengujian dan mengambil keputusan”. Tidak ada pengujian yang dibuat secara otomatis yang boleh dilakukan tanpa ada peninjauan dan persetujuan manusia.

AI dalam CI/CD: dimana ya, dimana tidak

Panggung

AI cocok

manusia itu penting

Draf kode uji

Revisi + mutasi

Draf YAML saluran pipa

Otentikasi + pemeriksaan kunci rahasia

Ringkasan log gagal

Konfirmasi akar permasalahan

Diagnosis tes rapuh

Keputusan solusi permanen

“Bisakah ada versinya?”

tidak

Penilaian dan tanggung jawab ahli

Secara otomatis "lulus" ujian

tidak pernah

—

Perhatian: Jangan pernah memberikan mandat kepada AI seperti "perbaiki agar lulus ujian yang gagal" di CI/CD. Hal ini menggagalkan tujuan pengujian dan secara otomatis menutupi kesalahan. AI dapat menjelaskan kesalahannya, menyarankan koreksi; tetapi "mengecat ujian dengan warna hijau" harus merupakan keputusan seseorang yang sadar dan masuk akal.

Privasi, data, dan keamanan: batasan yang tidak dapat diubah

Privasi. Dalam lingkungan pengujian, data pelanggan aktual, salinan database produksi, kunci API, dan informasi sistem internal bersifat sensitif. Jangan berikan ini ke alat AI publik. Data pribadi tunduk pada KVKK dan peraturan serupa; Log topeng dan tangkapan layar. Gunakan data pengujian sintetik (fiksi) sedapat mungkin.

Pengujian keamanan — bersifat defensif dan resmi. Tes keamanan yang dipelajari dalam modul ini (tes otorisasi/IDOR, batas unggah file, validasi input) hanya untuk menguji produk Anda sendiri dalam otorisasi tertulis dan cakupan yang ditentukan. Menggunakan AI untuk mengakses sistem orang lain tanpa izin, mempersenjatai kerentanan nyata, atau melakukan pengujian di luar cakupan adalah tindakan yang tidak etis dan ilegal. Ketika Anda menemukan kerentanan keamanan, patuhi prinsip pengungkapan yang bertanggung jawab — menjaga kerahasiaan kerentanan dan melaporkannya kepada pihak terkait agar dapat diperbaiki.

Etika dan transparansi. Jangan menampilkan tes yang dihasilkan oleh AI sebagai karya Anda sendiri; Menyatakan bahwa Anda menggunakan AI dalam tim adalah transparansi. Anda bertanggung jawab atas ketidakakuratan keluaran yang dihasilkan AI — “AI yang menulisnya” bukanlah sebuah alasan.

Perintah lemah / Perintah kuat

Lemah: "Siapkan jalur pengujian untuk CI."

Kuat: "Draf YAML alur kerja CI untuk Tindakan GitHub: jalankan pengujian unit + API pada setiap PR, buat laporan cakupan, jalankan pengujian mutasi (Stryker) setiap minggu. Jangan sematkan rahasia dalam kode; gunakan referensi rahasia saja. Blokir penggabungan jika pengujian berwarna merah. Ini adalah DRAFT; Saya akan meninjau dan mengedit langkah-langkah validasi dan pengelolaan kunci rahasia. JANGAN TAMBAHKAN langkah 'perbaikan' atau 'migrasi' pengujian otomatis."

Perintah yang kuat; Ini memberlakukan batasan pada kerahasiaan, tinjauan manusia, dan "tidak ada pengujian otomatis".

Empat templat yang dapat disalin

1) Rencana pengujian ujung ke ujung:

Peran Anda: pemimpin QA senior. Draf rencana pengujian menyeluruh dari ide hingga rilis untuk fitur berikut: [fitur + kriteria penerimaan]. Fase: analisis persyaratan (ketidakpastian), desain pengujian, lapisan otomatisasi (unit/API/UI), integrasi CI/CD, kriteria keputusan rilis, pelacakan produksi. Tentukan peran poin persetujuan AI dan MANUSIA di setiap tahap secara terpisah.

2) Garis besar saluran CI/CD:

Draf CI YAML untuk [GitHub Actions/GitLab CI/Azure Pipelines]:- Uji unit + API + cakupan di PR- Mencegah penggabungan dalam uji merah- Nilai rahasia hanya dengan rahasia; menyematkan kodeIni adalah draf; Saya akan meninjau langkah-langkah manajemen dan persetujuan utama. Menambahkan langkah tes koreksi otomatis/lulus.

3) Analisis log pengujian yang gagal:

Dalam cetakan CI itu, tesnya berwarna merah. Periksa lognya; kelompokkan kegagalannya, bedakan kemungkinan akar penyebabnya dan MANA yang merupakan kegagalan sebenarnya dan mana yang mungkin merupakan masalah pengujian/lingkungan yang rapuh. Jika ada data pribadi, tutupi. Keputusan dan koreksi ada di tangan saya. Catatan: [tempel]

4) Pemeriksaan awal keamanan/privasi:

Sebelum data/log pengujian ini dikirim ke alat AI, periksa: apakah data/log tersebut berisi data pribadi, kunci API, alamat sistem internal, data produksi? Buat daftar area mana, jika ada, yang perlu ditutup/dihapus. Memproses apa adanya. Konten: [tempel]

tiga kasus mini

Kasus 1 — Kecepatan aliran ujung ke ujung. Sebuah tim menangani fitur “perpanjangan langganan” baru dengan alur end-to-end yang didukung AI: ketidakpastian persyaratan ditandai di awal, pengujian tiga lapis dirancang dan divalidasi mutasi, dikaitkan dengan CI. Fitur ini mengurangi siklus pengujian, yang pada proses tradisional memakan waktu 5 hari, menjadi 2 hari; namun persetujuan manusia dipertahankan pada setiap tahap, dan ketidakpastian persyaratan (apa yang terjadi jika penyegaran gagal) ditutup sebelum siaran langsung.

Kasus 2 — Kembali dari kebocoran kunci. Seorang pengembang meminta AI menghasilkan CI YAML, dan AI tersebut menyematkan kunci API yang tampak nyata ke dalam YAML sebagai contoh. Langkah “pemeriksaan awal keamanan/privasi” menangkap hal ini; kunci dikonversi menjadi referensi rahasia. Tanpa langkah audit, kuncinya akan bocor ke kontrol versi (riwayat git).

Kasus 3 — Batasan kewenangan. Seorang anggota tim ingin menerapkan tes IDOR yang dia pelajari ke sistem live mitra bisnis karena "Saya penasaran." Pemimpin QA berhenti: melakukan pengujian keamanan pada sistem lain tanpa izin tertulis dan cakupan yang ditentukan adalah ilegal. Pengujian hanya dilakukan di lingkungan pengujian produk mereka sendiri, dengan otoritas; Pihak yang bertanggung jawab secara terbuka diberitahukan kepada tim terkait.

Kesalahan umum

Membuat AI mengambil keputusan rilis. Mengajukan pertanyaan “Apakah bisa dilepas?” ke AI dan meletakkan jawabannya di tempat tanda tangan.
"Lulus" tes otomatis. Di CI, AI akan mengecat tes dengan warna hijau; menutupi kesalahan.
Memberikan data/kunci rahasia kendaraan. Berbagi data produksi, data pribadi, atau kunci API tanpa pengawasan.
Pengujian keamanan tidak sah. Penyerang menguji sistem lain tanpa cakupan dan izin.
Memperkenalkan pengujian ke dalam pipeline tanpa peninjauan. Jalankan sketsa AI secara otomatis tanpa persetujuan manusia.
Menyalahkan AI. Mempertahankan keluaran yang salah dengan mengatakan "AI yang menulisnya".

Singkatnya

QA ujung ke ujung adalah proses yang mencakup persyaratan hingga pelacakan produksi dan berada dalam CI/CD; Di setiap tahap, AI membuat draf, merangkum log, dan menyarankan akar permasalahan. Namun batasannya tidak dapat diubah: manusia membuat keputusan pengujian dan mengeluarkan persetujuan; AI tidak pernah diberi wewenang untuk “lulus” ujian secara otomatis; data dan kunci rahasia tidak masuk ke dalam kendaraan; Pengujian keamanan dilakukan hanya pada produk Anda sendiri, dalam otorisasi tertulis dan cakupan yang ditentukan, untuk tujuan defensif, dan temuan dilaporkan dengan pengungkapan yang bertanggung jawab. Bersikaplah transparan saat Anda menggunakan AI; Anda bertanggung jawab atas keakuratan hasilnya. AI berakselerasi; Anda menjamin kualitas dan etika.

Tugas aplikasi

Buat draf rencana mulai dari ide hingga rilis dengan templat “rencana pengujian ujung ke ujung” untuk fitur dari proyek Anda sendiri; Tandai peran AI dan titik persetujuan manusia secara terpisah di setiap tahap. Kemudian buat YAML dengan “garis besar pipeline CI/CD” dan terapkan “pemeriksaan awal keamanan/privasi” ke YAML ini untuk memeriksa data kunci/rahasia yang tertanam. Terakhir, tuliskan semua poin “keputusan manusia” dalam rencana Anda dan jelaskan dalam satu kalimat mengapa keputusan tersebut tidak dapat didelegasikan kepada AI.

daftar periksa

[ ] Saya mengaitkan keputusan pelepasan dan pengujian dengan persetujuan manusia; Saya tidak menyerahkannya kepada AI.
[ ] Di CI/CD saya tidak memberikan izin kepada AI untuk "lulus/mengoreksi" tes secara otomatis.
[ ] Saya memeriksa dan menutupi data rahasia, data pribadi, dan kunci sebelum mengirimkannya ke kendaraan.
[ ] Saya hanya mempertimbangkan pengujian keamanan pada produk saya sendiri, dalam izin dan cakupan tertulis.
[ ] Saya mengatasi kerentanan yang ditemukan dengan prinsip pengungkapan yang bertanggung jawab.
[ ] Saya secara transparan menyatakan bahwa saya menggunakan AI dan menganggap diri saya bertanggung jawab atas keakuratan hasilnya.

Ujian Modul

1. Bagaimana 'pass palsu' didefinisikan secara paling akurat dalam konteks QA?

A) Meskipun tes berubah menjadi hijau, tes ini tidak mengkonfirmasi perilaku apa pun; ✔ Tidak berubah menjadi merah meskipun kodenya rusak
B) Tes berjalan sangat lambat dan waktu habis.
C) Tes mendeteksi kesalahan nyata dan berubah menjadi merah
D) Pengujian hanya berjalan di lingkungan produksi

Penjelasan: Lulus semu adalah ketika tes mengatakan 'lulus' tetapi tidak benar-benar memastikan sesuatu yang berarti; Tesnya berwarna hijau, tetapi meskipun perangkat lunaknya rusak, tes itu tidak akan menangkapnya. Ini adalah risiko AI nomor satu dalam QA karena AI cenderung menghasilkan pengujian yang terlihat rapi namun hampa.

2. Apa posisi kecerdasan buatan yang paling akurat dalam proses pengujian dan QA?

A) Kecerdasan buatan dapat memutuskan apakah versi tersebut dapat dirilis tanpa persetujuan manusia
B) Kecerdasan buatan adalah asisten yang menghasilkan rancangan dan ide; Keputusan dan tanggung jawab 'apakah siap dipublikasikan' ada di tangan ahli ✔
C) Kecerdasan buatan hanya menulis teks dan tidak dapat menangani kode pengujian sama sekali
D) Kecerdasan buatan selalu menulis tes yang lebih benar daripada manusia, jadi peninjauan tidak diperlukan

Deskripsi: Kecerdasan buatan adalah asisten pengujian, pembuat rancangan, dan pengganda ide; menghasilkan skenario pengujian, kode otomatisasi, dan draf laporan. Namun, tanggung jawab dan persetujuan akhir atas keputusan kualitas seperti 'apakah perangkat lunak ini siap untuk dipublikasikan' atau 'sudahkah pengujian ini lulus' adalah milik ahli yang kompeten.

3. Berdasarkan fakta bahwa kesalahan paling banyak terjadi pada nilai ambang batas, teknik desain tes manakah yang menguji anak usia 17, 18, dan 19 secara terpisah untuk batas usia 18 tahun?

A) Tes transisi keadaan
B) Tabel keputusan
C) Analisis nilai batas ✔
D) Pengujian eksplorasi

Penjelasan: Analisis nilai batas didasarkan pada pengamatan bahwa kesalahan paling sering terjadi pada batas dan menguji nilai ambang batas (tepat di bawah, tepat di atas, dan tepat di atas batas) secara terpisah. Ini adalah teknik ampuh yang melengkapi kelas kesetaraan.

4. Pendekatan manakah yang sebaiknya dipilih dalam pemilihan elemen untuk mengurangi kerapuhan dalam kode otomatisasi pengujian UI yang dihasilkan dengan kecerdasan buatan?

A) Menggunakan jalur XPath terpanjang yang mungkin
B) Memilih elemen sesuai dengan posisi pikselnya di layar
C) Menggunakan penyeleksi berdasarkan nama kelas CSS
D) Menggunakan atribut stabil (data-testid) yang ditambahkan untuk pengujian ✔

Penjelasan: Jalur XPath yang panjang dan nama kelas CSS sangat bergantung pada struktur dan desain halaman; Itu rusak pada perubahan antarmuka sekecil apa pun. Atribut stabil yang ditambahkan khusus untuk pengujian (misalnya data-testid) tidak terpengaruh oleh perubahan desain dan membuat pengujian menjadi kuat.

5. Mengapa pengujian API hanya memeriksa kode status HTTP (misalnya 200) saja tidak cukup?

A) Karena data isi dengan kode status yang benar mungkin rusak dan pemeriksaan status saja tidak akan menangkap ini (kepercayaan semu) ✔
B) Karena kode status tidak dapat diandalkan sama sekali dalam pengujian API
C) Karena pemeriksaan kode status sangat memperlambat pengujian
D) Karena kode status tidak pernah dikembalikan dalam pengujian API

Penjelasan: Meskipun server mengembalikan kode status yang benar, server mungkin mengembalikan data yang rusak di isi (tipe salah, bidang hilang, nilai dihitung salah). Ujian yang hanya melihat keadaan tidak dapat melihat hal tersebut dan memberikan keyakinan palsu. Jadi validasi skema/kontrak dan aturan bisnis juga harus ditambahkan.

6. Mengapa penting untuk memberi tahu AI untuk 'menghitung secara manual nilai yang diharapkan sesuai dengan aturan penerimaan, jangan mereferensikan keluaran fungsi saat ini' saat mencetak pengujian unit?

A) Karena penghitungan manual menjalankan pengujian lebih cepat
B) Karena jika tidak, pengujian menerima perilaku kode saat ini (mungkin bermasalah) sebagai 'benar' dan mengonfirmasi bug tersebut ✔
C) Karena kecerdasan buatan tidak dapat menghitung angka desimal sama sekali
D) Karena aturan penerimaan tidak pernah digunakan dalam pengujian

Penjelasan: Jika AI memperoleh nilai yang diharapkan dari keluaran fungsi yang diuji, AI akan membuat pengujian 'lulus' meskipun fungsinya salah; Artinya, apa pun kode yang dihasilkan, pengujian tersebut dianggap benar. Menghitung nilai yang diharapkan secara independen dari aturan penerimaan memastikan bahwa pengujian adalah penjaga gerbang aturan, bukan cerminan kode.

7. Manakah dari berikut ini yang merupakan fitur yang paling membedakan laporan bug yang bagus?

A) Menjadi sepanjang dan teknis mungkin
B) Ditulis oleh kecerdasan buatan
C) Berisi langkah-langkah reproduksi deterministik yang dapat diikuti oleh pengembang secara mandiri dan menghasilkan kesalahan ✔
D) Itu hanya tangkapan layar

Penjelasan: Nilai sebenarnya dari laporan bug adalah pengembang dapat mereproduksi bug tersebut tanpa bantuan Anda. Langkah-langkah reproduksi yang deterministik dan dapat dilacak dari awal memastikan hal ini; Jika langkah-langkah ini tidak dilakukan, laporan sering kali ditutup karena 'tidak dapat diproduksi'.

8. Ekspresi manakah yang paling akurat untuk hubungan antara tingkat keparahan dan prioritas dalam kesalahan salah mengeja nama perusahaan di halaman beranda?

A) Intensitas dan prioritas harus selalu memiliki nilai yang sama
B) Tingkat keparahan dan prioritas kesalahan ini jelas rendah
C) Keparahan dan prioritas adalah konsep yang sama, satu label saja sudah cukup
D) Intensitas teknis mungkin rendah namun prioritas bisnis (reputasi) mungkin tinggi; Keduanya dievaluasi secara berbeda ✔

Penjelasan: Tingkat keparahan adalah dampak teknis dari kesalahan (kesalahan ketik secara teknis rendah), prioritas adalah seberapa mendesak kesalahan tersebut harus diperbaiki (tinggi karena merupakan elemen reputasi yang dilihat setiap pengunjung). Keduanya tidak selalu menuju ke arah yang sama; Contoh ini adalah situasi dengan tingkat keparahan rendah dengan prioritas tinggi.

9. Interpretasi mana yang paling akurat dari rangkaian pengujian dengan cakupan garis 90%?

A) Ini menunjukkan bahwa garis-garis tersebut dieksekusi tetapi tidak membuktikan bahwa garis-garis tersebut berperilaku benar; ✔ coverage yang tinggi dapat memberikan rasa percaya diri yang palsu
B) Secara meyakinkan membuktikan bahwa 90% perangkat lunak bebas bug
C) Ini adalah ukuran pasti dari kualitas tes yang sangat baik.
D) Menunjukkan bahwa tidak perlu lagi menulis tes tambahan

Penjelasan: Cakupan baris menunjukkan bahwa hanya baris yang dieksekusi; Itu tidak membuktikan bahwa itu memberikan hasil yang benar. Bahkan dengan pengujian yang tidak disengaja, cakupan 90% dapat dicapai. Cakupan adalah peta 'tidak pernah melihat ke mana pun', bukan jaminan 'semuanya telah diuji'; perlindungan sebenarnya diukur dengan pengujian mutasi.

10. Dalam pengujian berbasis risiko, bagaimana risiko suatu fitur dihitung untuk mengarahkan upaya pengujian terbatas?

A) Hanya berdasarkan jumlah baris kode
B) Dengan mengalikan kemungkinan kegagalan dan akibat yang akan terjadi jika rusak ✔
C) Hanya sesuai urutan pengembangan fitur
D) Memprioritaskan hanya fitur yang paling mudah untuk ditulis pengujiannya

Penjelasan: Dalam pengujian berbasis risiko, risiko dievaluasi sebagai probabilitas = probabilitas (kemungkinan kerusakan) × dampak (kerusakan jika rusak). Domain dengan probabilitas tinggi dan berdampak tinggi (pembayaran, autentikasi) layak mendapatkan pengujian paling intens, sementara domain rendah×rendah menerima pengujian ringan.

11. Apa risiko utama menambahkan percobaan ulang pada pengujian yang terkadang lolos dan terkadang gagal (rapuh/tidak stabil) meskipun kodenya tidak berubah?

A) Mempersingkat waktu berjalannya tes
B) Mengurangi persentase cakupan
C) Menutupi kesalahan konkurensi sebenarnya atau akar permasalahan dan menekan gejalanya ✔
D) Mengubah nama tes

Penjelasan: Coba lagi adalah alat diagnostik, bukan pengobatan. Keragu-raguan sering kali berasal dari kondisi ras atau kecanduan yang sebenarnya; Membuat tes 'lulus' dengan mencoba lagi menutupi kesalahan nyata ini dan dapat menyebabkan masalah serius dalam siaran langsung. Akar permasalahannya harus ditemukan terlebih dahulu.

12. Bagaimana cara kerja pengujian mutasi, metode paling jujur untuk mengukur apakah rangkaian pengujian benar-benar melindungi?

A) Dengan mengukur kecepatan lari tes
B) Dengan menghitung berapa baris kode yang ditulis
C) Dengan menjalankan pengujian dalam urutan berbeda
D) Dengan sengaja membuat jeda kecil pada kode dan mengukur apakah pengujian menangkapnya ✔

Deskripsi: Pengujian mutasi menghasilkan distorsi kecil (mutasi) yang disengaja pada kode sumber; Rangkaian pengujian yang baik akan menangkap distorsi ini dan berubah menjadi merah. Mutasi yang tidak tertangkap (bertahan) menunjukkan bahwa pengujian tidak mempertahankan perilaku tersebut. Skor mutasi merupakan ukuran kualitas yang jauh lebih jujur dibandingkan cakupan persentase.

13. Apa batasan utama yang harus diikuti saat melakukan pengujian keamanan (misalnya pengujian otorisasi/IDOR)?

A) Ini hanya boleh dilakukan pada produknya sendiri, dalam izin tertulis dan cakupan yang ditentukan, untuk tujuan defensif ✔
B) Dapat diterapkan secara bebas pada sistem kepentingan apa pun
C) Dapat dicoba pada sistem langsung mitra bisnis tanpa izin
D) Setiap kerentanan yang ditemukan harus segera dipublikasikan ke publik.

Deskripsi: Tes keamanan yang dipelajari dalam modul ini hanya untuk menguji produk Anda sendiri untuk tujuan defensif, dalam izin tertulis dan cakupan yang ditentukan. Mengakses sistem orang lain tanpa izin atau melakukan pengujian di luar cakupan adalah tindakan yang tidak etis dan ilegal; Setiap kerentanan yang ditemukan dilaporkan melalui pengungkapan yang bertanggung jawab.

14. Wewenang apa yang tidak boleh diberikan kepada AI dalam pipeline CI/CD?

A) Meringkas log pengujian yang gagal
B) Wewenang untuk secara otomatis 'lulus' tes yang gagal (merah) atau mengecatnya hijau ✔
C) Menyarankan rancangan kode pengujian
D) Penyusunan file YAML saluran pipa

Deskripsi: AI dapat menghasilkan kerangka kode pengujian, pipeline YAML, dan ringkasan log di CI/CD; namun, kemampuan untuk 'lulus/memperbaiki' pengujian yang gagal secara otomatis tidak boleh diberikan. Hal ini menggagalkan tujuan pengujian dan secara otomatis menutupi kesalahan. Melukis ujian dengan warna hijau harus menjadi keputusan seseorang yang sadar dan masuk akal.