Simply Bedulz!

Testing Strategy January 11, 2008

Dapat pertanyaan tentang testing strategy dari Nodeen bikin nyengir juga. Bukan apa-apa, tapi mostly dari setiap project yang pernah saya kerjakan kok ya belum pernah bikin yang namanya test strategy. Apa mungkin karena saya kurang informasi atau justru test strategy tersebut sudah tercantum di dokumen-dokumen yang pernah saya bikin?

Well, di usia kehamilan yang sudah lima bulan ini akhirnya saya bisa maksain diri juga untuk ‘ngintip’ kompie. Hehe, maklum efek kengerian akan radiasi dari elektronik kok bikin saya parno banget di awal-awal kehamilan ya?

Eniwe, lanjut tentang test strategy. Akhirnya saya jadi tergelitik untuk mencari-cari tentang test strategy ini. (Thanks to Nodeen once again to asked this ) di wikipedia, saya search memang tidak menemukan tulisan yang pasti plek ngejelasin tentang test strategy. Tapi dari beberapa yang saya tangkap yang dimaksud dengan test strategy saat mengerjakan suatu project adalah hal-hal yang intinya harus didiskusikan lebih lanjut dengan developer, SA/System Analyst dan PM-nya jika perlu. Karena hal ini berkaitan erat dengan apa yang harus diselesaikan dengan tepat.

Ribet ya? Hehe, saya sendiri baru nyadar setelah di project yang sedang saya lakukan ini test plan saya banyak yang tidak sesuai dengan apa yang sudah di develop oleh tim developer. Tentunya, balik lagi ke urusan schedule.

OK, hal-hal apa saja sih yang harus di diskusikan dengan tim Dev, SA dan PM ini?

Pertama, bikin diagram/tree atau schedule dengan MS.Excel/MS.Project/Gantt chart yang mendeskripsikan hal-hal apa saja yang harus di test (Scope & coverage). Set siapa-siapa saja tester yang akan terlibat di masing-masing task. Abaikan dahulu waktu testnya. karena biasanya development itu molor dan ujung-ujungnya waktu test juga molor.. hehe

Terus identifikasi resiko-resiko yang mungkin terjadi pada saat testing, dan prioritas task-task apa saja yang harus didahulukan untuk di test. Kemudian tentukan tingkat kedalaman testnya (test depth) dari masing-masing task dan koresponden test level.

Mungkin yang jadi pertanyaan adalah, seberapa penting sih bikin test strategy ini?
Untuk sebagian orang bisa jadi tidak penting dikarenakan (bisa saja) waktu yang kurang. Tapi kalau ada waktu yang cukup tidak ada salahnya juga kok untuk bikin. Tujuannya biar kita bisa tahu dan share informasi tentang high level risks (project, product, requirement). Kemudian kita jadi bisa menganalisa resiko dan requirement tersebut sehingga (mudah-mudahan) bisa membuat solusi yang jitu dalam pelaksanaan testing. Lalu yang paling penting bisa correctly focusing test effort dan melakukan best possible job dengan limited resources.

Oya, kalau suatu saat saya buat dokumen ini, saya tidak akan mengajukan ke client karena pasti akan ada banyak perubahan dalam proses development dan testing dan ini sungguh suatu resiko yang cukup bikin deg-degan kalau client tahu tentang dokumen ini.

Mudah-mudahan mengerti ya Nodeen.