Service validation and testing

Testing answers two questions: did we build it right (verification), and did we build the right thing (validation)? Service validation and testing checks both, before problems reach users. It covers not just features, but performance, security, usability and whether the service can be supported.

Pengujian menjawab dua pertanyaan: apakah kita membangunnya dengan benar (verifikasi), dan apakah kita membangun hal yang benar (validasi)? Service validation and testing memeriksa keduanya, sebelum masalah sampai ke pengguna. Cakupannya bukan hanya fitur, tetapi juga kinerja, keamanan, kemudahan penggunaan, dan apakah layanan bisa didukung.

Key ideasKonsep kunci

• Verification and validation. Built to specification, and actually useful for users.
• Many kinds of tests. Functional, integration, performance, security, usability and user acceptance testing.
• Test early. Defects found in design cost far less than defects found in production.
• Test automation. Repeatable tests run on every change; people focus on exploratory testing.
• Test against acceptance criteria. Clear criteria make "pass" and "fail" objective.

• Verifikasi dan validasi. Dibangun sesuai spesifikasi, dan benar-benar bermanfaat bagi pengguna.
• Banyak jenis pengujian. Fungsional, integrasi, kinerja, keamanan, kemudahan penggunaan, dan user acceptance testing.
• Uji sejak dini. Cacat yang ditemukan saat desain jauh lebih murah daripada yang ditemukan di production.
• Test automation. Pengujian berulang dijalankan di setiap perubahan; manusia fokus pada pengujian eksploratif.
• Uji berdasarkan acceptance criteria. Kriteria yang jelas membuat "lulus" dan "gagal" bersifat objektif.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

1. Plan testsBased on requirements and risk.
2. PrepareTest environments, data and cases.
3. ExecuteAutomated and manual tests.
4. Record resultsLog defects with clear steps to reproduce.
5. AcceptUsers and operations confirm readiness.
6. ImproveLearn from defects that escaped.

1. Merencanakan pengujianBerdasarkan requirement dan risiko.
2. MenyiapkanLingkungan uji, data, dan skenario.
3. MenjalankanPengujian otomatis dan manual.
4. Mencatat hasilCatat cacat dengan langkah reproduksi yang jelas.
5. MenerimaPengguna dan tim operasional mengonfirmasi kesiapan.
6. MemperbaikiBelajar dari cacat yang lolos.

How to measure itCara mengukurnya

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

1. L1InitialTesting is ad hoc, often done by users after go-live.
2. L2RepeatableSome testing happens before release, mostly manual and based on individual knowledge.
3. L3DefinedTest plans based on requirements and risk, with defined environments and user acceptance testing.
4. L4MeasuredTesting is measured, largely automated, and escaped defects are analyzed.
5. L5OptimizedContinuous testing across the pipeline, including performance and security, with fast feedback.

1. L1InitialPengujian bersifat ad hoc, sering dilakukan pengguna setelah go-live.
2. L2RepeatableSebagian pengujian dilakukan sebelum rilis, sebagian besar manual dan bergantung pada pengetahuan individu.
3. L3DefinedAda rencana pengujian berdasarkan requirement dan risiko, dengan lingkungan yang ditetapkan dan user acceptance testing.
4. L4MeasuredPengujian diukur, sebagian besar terotomasi, dan cacat yang lolos dianalisis.
5. L5OptimizedPengujian berkelanjutan di seluruh pipeline, termasuk kinerja dan keamanan, dengan umpan balik yang cepat.

Assess service validation and testing in the wizardNilai service validation and testing di wizard →

Using AIMemanfaatkan AI

• Test case generation from requirements and user stories.
• Test data creation that is realistic but contains no real personal data.
• Self-healing tests that adapt to small interface changes.
• Testing AI features for accuracy, bias and harmful outputs.

• Pembuatan test case dari requirement dan user story.
• Pembuatan data uji yang realistis tetapi tanpa data pribadi asli.
• Pengujian yang memperbaiki diri dan menyesuaikan dengan perubahan kecil pada tampilan.
• Pengujian fitur AI untuk akurasi, bias, dan keluaran yang merugikan.

Real-world example: a payment app before RamadanContoh kasus: aplikasi pembayaran menjelang Ramadan3 min3 menit

A payment app plans a new bill-splitting feature before Ramadan, when group dinners peak. Previous releases were tested by developers only, and users found bugs in the first hour.

Sebuah aplikasi pembayaran merencanakan fitur patungan tagihan menjelang Ramadan, saat acara buka bersama sedang ramai. Rilis sebelumnya hanya diuji oleh developer, dan pengguna menemukan bug di jam pertama.

This time the team writes acceptance criteria, automates regression tests, runs a load test at five times normal traffic, and invites 200 staff to a two-week beta. Twelve defects are fixed before launch, and the feature handles the first weekend smoothly.

Kali ini tim menulis acceptance criteria, mengotomasi regression test, menjalankan load test hingga lima kali lalu lintas normal, dan mengundang 200 karyawan ke beta selama dua minggu. Dua belas cacat diperbaiki sebelum peluncuran, dan fitur tersebut berjalan lancar di akhir pekan pertama.

Common pitfallsJebakan umum

• Testing only at the end, when fixes are expensive.
• Using real customer data in test environments.
• Testing only the "happy path".
• Skipping performance and security testing.

• Menguji hanya di akhir, saat perbaikan sudah mahal.
• Memakai data pelanggan asli di lingkungan uji.
• Hanya menguji skenario ideal ("happy path").
• Melewatkan pengujian kinerja dan keamanan.

Related practicesPractice terkait