Software Lifecycle: Waterfall

CI-CD

• CI-CD merujuk pada proses automatisasi sistem/aplikasi/source code untuk proses build, testing, release/deployment secara aman dan langsung, tanpa harus di-invoke secara manual satu per satu oleh developer

Continuous Integration (CI)

• Continuous integration (CI) adalah pengintegrasian kode ke dalam repositori kode kemudian menjalankan pengujian secara otomatis, cepat, dan sering.

Continuous Deployment/Delivery (CD)

• Continous delivery atau continuous deployment (CD) adalah praktik yang dilakukan setelah proses CI selesai dan seluruh kode berhasil terintegrasi, sehingga aplikasi bisa dibangun lalu dirilis secara otomatis.

Tools

Jenkins

• Jenkins bersifat open source dan menggunakan bahasa pemrograman Java.

Software Testing

• Bagian dari software development lifecycle untuk memastikan sistem/software berjalan tanpa ada masalah dengan mengetahui sumber masalah lebih awal dengan melakukan testing

Software Testing Lifecycle

Requirement Analysis

• Mengumpulkan informasi mengenai software, document terkait software, dan informasi seperti functional dan non-functional requirements
• Identifikasi dan verifikasi ambigu yang ada agar testing terarah, bertanya ke product manager, developer, stakeholder untuk mengumpulkan informasi

Test Planning

• Definisikan tujuan dan scope testing, urutan prioritasnya, strategy untuk melakukan testing, technique-technique-nya, dan kita akan melakukan testing menggunakan apa, tools-nya, apakah automated atau manual
• Definisikan kriteria seperti input dan output, estimasi waktu eksekusi testing, cost-nya, resources requirement

Testing Technique

White Box Testing

• Pengujian dengan memiliki akses/melihat source code atau dilakukan untuk memeriksa struktur logika dan code internal

Black Box Testing

• Pengujian dilakukan terhadap fungsionalitas luar sistem, berdasarkan input dan output tanpa melihat alur logika dan tanpa melihat kode

Gray Box Testing

• Tester memiliki sebagian informasi atas sistem dan kode sistem, tapi mengetes dari perspektif user (fungsionalitas sistem, black box testing)
• Kombinasi white box dan black box

Testing Purposes

Functional Testing

Unit Testing

• Testing individual function, class, module, secara isolated (masing-masing).
• Digunakan untuk memeriksa masalah di tahap development

Integration Testing

• Memverifikasi modul yang digabungkan/bekerja bersama dapat bekerja dengan baik
• Memastikan integrasi dan komunikasi antar modul/services berjalan

System Testing

• Test keseluruhan aplikasi/sistem secara lengkap, verifikasi seluruh fungsionalitas dari sistem/aplikasi

User Acceptance Test (UAT)

• Dilakukan oleh user/stakeholder untuk memastikan software/sistem berjalan sesuai dengan proses bisnis yang diharapkan.
• Biasanya final testing sebelum deployment

Smoke Testing

• Pengujian terhadap functional paling penting/critical functionality
• Dilakukan untuk memastikan aplikasi cukup bagus untuk melanjutkan testing di tahap selanjutnya

Sanity Testing

• Pemeriksaan terhadap fungsionalitas terhadap perubahan yang sudah diterapkan
• Memastikan tidak ada error/bug setelah code change pada fungsionalitas yang diubah

Regression Testing

• Regression (software engineering): fitur yang sebelumnya bekerja dengan benar menjadi rusak setelah terjadi perubahan pada software
• Regression testing: pengujian untuk memastikan perubahan baru tidak membuat functionality yang sebelumnya benar menjadi rusak
• Perbedaan dengan sanity: sanity memeriksa fitur yang memang diubah/mengalami code change, regression memeriksa sistem secara keseluruhan/fitur lain yang tidak kena langsung code change

API Testing

• Pemeriksaan API

Interface Testing

• Pemeriksaan terhadap interaksi terhadap sistem/fitur/interface lain
• Memastikan data exchange berjalan dengan baik antar-interface

Non-Functional Testing

Performance Testing

• Memeriksa performa, kecepatan, responsiveness dan stabiliitas sistem di bawah workload/beban yang berbeda-beda

Usability Testing

• Memastikan seberapa mudah dan intuitif aplikasi
• Digunakan untuk memeriksa user experience dan expectation

Security Testing

• Pemeriksaan keamanan, vulnerability dan weakness of the system

Reliability Testing

• Pemeriksaan apakah software/system berjalan konsisten tanpa failures dalam jangka waktu tertentu

Compatibility Testing

• Memastikan sistem berjalan di berbagai lingkungan penggunaan seperti browser, perangkat, OS berbeda

Performance Testing

Load Testing

• Memeriksa sistem ketika bekerja di bawah tekanan/beban normal
• Memeriksa apakah ada bottleneck atau penurunan performance sebelum masuk ke testing yang lebih berat

Stress Test

• Memeriksa sistem ketika bekerja di bawah tekanan/beban berat (bahkan sampai limit) untuk memeriksa batas/breaking points

Spike Test

• Pemeriksaan sistem/software ketika terjadi peningkatan/penurunan user load secara tiba-tiba

Endurance (Soak) Test

• Memeriksa apakah sistem dapat bekerja di bawah suatu load untuk waktu yang lama

Volume Testing

• Memeriksa apakah sistem bisa menangani volume data yang besar yang masuk ke dalam sistem

Deployment/Rollout Testing

• Testing yang dilakukan terhadap release software secara aman, yaitu dengan melakukan release bertahap terhadap sebagian users terlebih dahulu, instead of release software ke semua orang secara sekaigus, supaya jika terjadi error/unwanted accident di versi yang baru, tidak semua orang akan terkena masalah ini sekaligus

Blue-Green Strategy

• Kita mempersiapkan dua buah environment, yaitu environment blue dan environment green. Keduanya berjalan bersamaan dan selalu aktif. Misalkan env blue adalah env versi terbaru, maka ketika saat ini sistem masih berjalan di env green, env blue akan mulai dijalankan dan di-testing untuk memastikan seluruh env berjalan baik dan tanpa masalah
• Kemudian sistem dapat secara langsung mengganti environment live mereka ke env blue sekaligus, sementara env green yang merupakan env lama tetap idle supaya jika terjadi masalah di env blue, akan langsung di-switch ke env lama di env green
• Strategi ini disebut sebagai zero downtime strategy, karena kita ingin update env secara sekaligus tanpa downtime, tapi jika terjadi masalah langsung bisa switch/balik lagi ke env lama
• Bagus digunakan jika kita ingin downtime rendah, tapi masalahnya biaya resource sangat tinggi karena harus maintain 2 live env

Canary Testing

• Sama seperti canary application, akan ada grup khusus bagi sejumlah user dalam ukuran kecil yang terdaftar sebagai user canary. User ini akan mendapatkan fitur terbaru dan dites di mereka sebelum akhirnya dites ke jumlah user yang lebih besar.
• Jika ada masalah di user canary, maka user yang terdampak hanya sedikit dan bisa diatasi di tingkat canary tersebut (tidak banyak user jadi korban)
• Tujuannya adalah menghindari problem terhadap jumlah user yang besar, sehingga masalah dapat dideteksi lebih awal terhadap sekelompok kecil user

A/B Testing

• Seperti blue-green strategy, dua buah env: env A dan env B (bisa lebih) akan dijalankan secara bersamaan tapi untuk kelompok user yang berbeda. User A mendapatkan env A, dan user B akan mendapatkan env B. Kemudian developer akan membandingkan performa dan juga keberjalanan env A terhadap user A dan env B terhadap user B
• Metode ini digunakan untuk membandingkan/mendapatkan metrik mengenai bagaimana env A dan env B (atau fitur A dan fitur B) terhadap live user, bukan untuk memeriksa apakah sistem berjalan aman tanpa error

Testing Principles

FIRST

Gunakan metode FIRST:

1. Fast. Setiap test harus berjalan dengan cepat dan tidak boleh
2. Isolated/Independent. Sebuah test tidak boleh mempengaruhi test lainnya, jangan ada shared state/cascading effect
3. Repeatable. Hasil ketika diulang konsisten dan dapat diulang. Jangan sampai ketika test dilakukan sekali, kita ingin test lagi menggunakan test yang sama malah tidak bisa/hasilnya tidak sama
4. Self-validating. Test harus langsung menunjukkan hasil, pass atau fail. Jangan harus membuat kita infer hasilnya apa dengan membaca dulu
5. Thorough. Harus meng-cover seluruh “happy path”, artinya bahkan kemungkinan alur data/proses yang tidak akan error pun/diekspektasikan berhasil, harus dicek juga

3A

• Bagaimana cara kita menyusun tests yang fokus dan bisa dikomunikasikan/distrukturkan dengan baik?
• Gunakan 3A: Arrange, Act, Assert

1. Arrange: setup object/bagian yang akan di-test.
2. Act: lakukan sesuatu terhadap object tersebut, yaitu uji object tersebut
3. Assert: buat klaim atau hasil pemeriksaan terhadap object tersebut