Tugas Pertemuan 15

Dokumentasi Software Testing Life Cycle (STLC)

Software Testing Life Cycle (STLC) adalah tahap-tahap proses pengujian yang dilaksanakan secara sistematis dan terencana. Dalam proses STLC, berbagai kegiatan dilakukan untuk meningkatkan kualitas produk salah satunya yaitu menyiapkan dokumen-dokumen dengan tujuan untuk menunjang proses testing pada proyek yang dikerjakan. Dokumen STLC tersebut meliputi user story, test case, test reporting, dan test plan.

Dokumen STLC pertama yang akan dibahas adalah user story. User story merupakan deskripsi mengenai kebutuhan sistem dalam bentuk bahasa natural yang dapat dengan mudah dipahami oleh end user yang tidak memiliki background IT. User story merupakan kalimat yang terstruktur, karena sintaks yang harus diikuti dalam membuat user story. Berikut adalah template sederhana dalam membuat user story:

• As a, diikuti oleh role dari user yang akan menggunakan feature dari user story tersebut.
• I want, merupakan penjelasan mengenai fungsi/feature yang akan dikembangkan
• So that, merupakan hasil yang didapatkan setelah fungsi yang diminta dijalankan. Pada beberapa teori, disebutkan bahwa “so that” adalah opsional.

Berikut merupakan contoh dari user story:

Sebagai murid, saya ingin login ke website, sehingga saya bisa mengakses fitur yang ada pada website.

Dokumen kedua adalah test case. Apa itu test case? test case merupakan dokumen yang menggambarkan input, tindakan, atau peristiwa dan respon yang diharapkan, untuk menentukan apakah fitur dari aplikasi bekerja dengan benar. Biasanya isi dari dokumen test case adalah keterangan seperti hasil setelah di tes, nama tes, kondisi pengujian/setup, persyaratan input data, langkah-langkah, dan hasil yang diharapkan. Berikut merupakan contoh dari test case:

Gambar Test Case

Dokumen ketiga adalah test reporting. Apa itu test reporting? Test reporting merupakan Laporan hasil testing dalam bentuk dokumen yang akan menjadi acuan Tech Lead atau Project Manager untuk memutuskan apakah fitur akan di sudah sesuai dengan permintaan client atau tidak sesuai. Dokumen test reporting biasanya berisi tentang fitur yang terdapat bug, detail dari bug, bug priority, bug category, dan rekap persentase keseluruhan bug. Berikut merupakan contoh dokumen test reporting:

Gambar Test Reporting

Dokumen keempat adalah test plan. Apa itu test plan? Test plan merupakan sebuah dokumen yang digunakan memastikan dan memverifikasi antara rencana yang sudah dibuat dengan hasil yang dicapai. Apakah sudah sesuai dengan planning yang telah dibuat atau terdapat perubahan-perubahan dengan seiring pembuatan software. Berikut merupakan contoh dokumen test plan:

TEST PLAN DOCUMENT

1. Test Plan Identifier

Perihal	Keterangan
Nama Project	Tokopedia
Penyusun	John Doe
Tanggal Pembuatan	09/06/2022
Revisi	-

2. Overview Project

Overview Project ini berisi tentang deskripsi project yang akan dikerjakan. Contoh: Tokopedia merupakan salah satu online marketplace terkemuka di Indonesia yang menyediakan sarana jual-beli dari konsumen ke konsumen. Semua orang dapat membuka toko online di Tokopedia dan melayani pembeli dari seluruh Indonesia untuk transaksi satuan maupun banyak.

3. Reference Document

Untuk reference Document dapat diisi list dokumen yang menjadi acuan beserta link (jika memungkinkan) .

4. Test Strategy

a. Test scope

Berisi list fitur yang harus dites dan fitur yang tidak perlu dites. Contoh : Login

b. Test type

Dapat diisi list tipe test apa yang akan digunakan. Contoh: Manual Testing, Automated Testing

c. Test Method/tools

Dapat diisi list tools apa yang akan digunakan dalam proses testing dan mencakup dari test type yang sudah ditentukan. Contoh: Cypress

5. Document of Testing

a. Test Plan

b. User Story

Dapat diisi deskripsi dari user story itu apa dan dilampirkan link user story dari project yang akan dikerjakan.

c. Scenario Test

Dapat diisi deskripsi dari skenario test itu apa dan dilampirkan link skenario test dari project yang akan dikerjakan.

d. Report Testing

Dapat diisi deskripsi dari report test itu apa dan dilampirkan link dari report test dari project yang akan dikerjakan.

6. Test Environment

Untuk test environment dapat diisi detail dari spec device yang digunakan testing (hardware), diisi spec dari software yang digunakan testing (google version misalnya), dan juga hasil persetujuan tim di environment manakah Quality Assurance akan melakukan testing (dev, staging, atau production).

7. Team

Nama	Role
John Doe	Project Manager
John Doe	Front End
John Doe	Back End
John Doe	Quality Assurance

Sekian dan terima kasih, semoga bermanfaat.

Tugas Pertemuan 9

Strategi Pengujian Perangkat Lunak

Definisi

Suatu langkah yang perlu dilakukan untuk memastikan kualitas produk akhir setinggi mungkin. Jika kamu memilih strategi dimana proyek tidak perlu sempurna, maka kamu hanya membuang waktu dan sumber daya.

Tujuan

Tujuan utama dari pengujian perangkat lunak adalah untuk merancang tes sedemikian rupa sehingga secara sistematis menemukan berbagai jenis kesalahan tanpa memakan banyak waktu dan usaha sehingga lebih sedikit waktu yang dibutuhkan untuk pengembangan perangkat lunak. Itulah sebabnya kita harus memilih strategi pengujian yang terbaik!

Karakteristik Pengujian

Sejumlah strategi pengujian perangkat lunak perlu diimplementasikan untuk memberikan kerangka pengujian untuk pengembangan perangkat lunak, yaitu sebagai berikut:

• Pengujian dimulai dari level komponen terkecil hingga integrasi antar komponen di seluruh sistem komputer tercapai.
• Teknik pengujian bervariasi sesuai dengan waktu penggunaan.
• Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek besar) oleh kelompok tes mandiri.
• Pengujian dan debugging adalah aktivitas yang terpisah, tetapi debugging harus diakomodasi dalam strategi pengujian apa pun

Strategi Pengujian

• Pengujian unit dimulai pada pusaran spiral dan berkonsentrasi pada setiap unit (misalnya, komponen, kelas, atau objek konten WebApp) dari perangkat lunak seperti yang diimplementasikan dalam kode sumber.
• Bergerak keluar sepanjang spiral ke pengujian integrasi, di mana fokusnya adalah pada desain dan konstruksi arsitektur perangkat lunak.
• Menghadapi pengujian validasi, di mana persyaratan ditetapkan sebagai bagian dari pemodelan persyaratan divalidasi terhadap perangkat lunak yang telah dibangun.
• Terakhir, pengujian sistem, di mana perangkat lunak dan sistem elemen lainnya diuji secara keseluruhan.

Langkah - Langkah Pengujian

1. Pengujian Unit : Tes fokus pada setiap komponen secara individual, memastikan bahwa itu berfungsi dengan baik sebagai satu kesatuan. Pengujian unit banyak menggunakan teknik pengujian yang menjalankan jalur tertentu dalam komponen struktur kontrol untuk memastikan cakupan lengkap dan deteksi kesalahan maksimum.
2. Pengujian Integrasi : Komponen harus dirakit atau diintegrasikan membentuk paket perangkat lunak yang lengkap. Pengujian integrasi mengatasi masalah terkait dengan masalah ganda verifikasi dan konstruksi program. Teknik desain kasus uji yang berfokus pada input dan output lebih umum selama integrasi, meskipun teknik yang melatih program tertentu jalur dapat digunakan untuk memastikan cakupan utama jalur kontrol.
3. Pengujian Validasi :Setelah perangkat lunak terintegrasi (dibangun), satu set tes tingkat tinggi diadakan. Kriteria validasi (ditetapkan selama analisis kebutuhan) harus dievaluasi. Pengujian validasi memberikan jaminan akhir bahwa perangkat lunak memenuhi semua fungsi, perilaku, dan persyaratan kinerja.
4. Pengujian Sistem : Langkah pengujian tingkat tinggi terakhir berada di luar batas rekayasa perangkat lunak dan ke dalam konteks yang lebih luas dari rekayasa sistem komputer. Perangkat lunak, setelah divalidasi, harus digabungkan dengan elemen sistem lainnya (misalnya, perangkat keras, orang, database). Pengujian sistem memverifikasi bahwa semua elemen menyatu dengan benar dan bahwa sistem secara keseluruhan berfungsi dan kinerja tercapai.

Tugas Pertemuan 4

Definisi

Perencanaan pengujian adalah dokumen yang berisi definisi tujuan dan sasaran pengujian dalam lingkup iterasi (atau proyek), item-item yang menjadi target pengujian, pendekatan yang akan diambil, sumber daya yang dibutuhkan dan point untuk diproduksi. Dengan kata lain perencanaan pengujian dapat disebut sebagai perencanaan atau skenario untuk melakukan testing yang akan dilakukan baik oleh expert atau user umum.

Tujuan 

Tujuan membuat perencanaan pengujian secara umum adalah untuk memudahkan developer untuk melakukan testing agar testing yang dilakukan menjadi jelas sehingga hasilnya lebih berguna dan efisien.

Langkah-langkah 

1. Test Plan Identifier

Test Plan Identifier adalah bagian untuk menjelaskan secara singkat mengenai objek yang akan di test. Bisa berupa penjelasan narasi atau berbentuk tabel dengan kategori kategori tertentu. Informasi yang dijelaskan dapat berupa sekilas mengenai subjek testing, nama orang yang bertanggung jawab terhadap testing, penyusun test plan , tanggal dibuat test plan dan tanggal revisi,dll.

2. Introduction

Pada bagian introduction dibuat untuk menjelaskan secara narasi, mengenai testing yang akan dilakukan terhadap suatu objek testing. Bagian Introduction dapat dibuat lebih rinci dengan menambahkan sub bab apabila perlu untuk dibuat. 

3. Test Items

Bagian test item menjelaskan mengenai daftar komponen komponen dalam objek testing yang akan di test satu per satu.Contohnya :

Kemudian

4. Features to be tested

Penjelasan dan daftar daftar fitur yang akan ditest di pada saat pelaksanaan testing dimulai.Dapat berupa Tabel Contohnya adalah :

5. Features Not to be Tested

Menjelaskan mengenai fitur fitur apa saja yang ada di dalam objek testing namun, fitur tersebut tidak akan di test pada saat pelaksanaan testing dan disertakan penjelasan singkat mengapa fitur tersebut tidak di test pada saat testing.

Contoh :

6. Approach / Test Strategy
   Bagian Approach adalah bagian yang digunakan untuk memberi deskirpsi mengenai Cara/approach yang dilakukan untuk melaksanakan testing dan disertakan dengan penjelasan mengenai approach yang digunakan.
   Contohnya : Unit Testing menggunakan Black Box Testing dan atau White box testing beserta dengan penjelasan mengenai approach/ pendekatan yang dipakai.

7. Item Pass / Fail Criteria

Berisi tentang Kriteria- kriteria yang harus dipenuhi sebelum berlanjut ke fase berikutnya. Dan Kriteria Testing disebut gagal/fail.
Contoh :
1. Jika suatu item di test sebanyak 10 kali dan 9 kali diantaranya berhasil namun ada 1 dimana benar benar gagal maka item tersebut dinyatakan sebagai gagal/ fail.
2. Jika hasil dari suatu item sama dengan hasil yang diharapkan maka item tersebut dinyatakan berhasil/pass.
3. System Crash akan dinyatakan sebagai fail,dsb.

8. Suspension Criteria

Berisi tentang Spesifikasi Kriteria- kriteria yang dapat digunakan untuk menghentikan sementara kegiatan testing dan testing tersebut dapat dilanjutkan di waktu lain.

Contoh:
Beberapa individual test cases dapat di suspend, di skip atau dikurangi jika test yang diperlukan(prerequisite test)  untuk individual test cases tersebut fail dan memerlukan perbaikan, apabila test cases individual tetap dilakukan meskipun prerequisite test yang diperlukan fail maka hanya akan membuang sumber daya /resources saja.

9. Test Deliverables
   Adalah List dokumen- dokumen apa saja yang akan dihasilkan setelah testing selesai dilakukan.
   Contohnya:
10. Testing Task

    Menjelaskan Kegiatan testing beserta dengan pihak yang akan melaksanakan kegiatan/task tersebut.
    Contoh:
    

11. Enviromental Needs

    Spesifikasi dan Perincian segala sesuatu yang dibutuhkan dan digunakan selama proses testing berjalan, bisa berupa hardware yaitu spesifikasi komputer atau hal lain selain hardware, misalnya izin akses seperti :
    -> Membutuhkan akses ke dalam database untuk melaksanakan testing.
    -> Membutuhkan akses ke dalam official website.
    

12. Responsibilities
    Rincian Pihak pihak yang akan bertanggung jawab terhadap suatu kegiatan task di dalam serangkaian kegiatan testing yang akan dilaksanakan.
    
    
13. Staffing and Training Needs

    Secara garis besar menjelaskan bagaimana melakukan pendekatan untuk menentukan peran para staff di dalam proyek. Dan melakukan training apabila diperlukan untuk testing.
    contoh :
    Project Manager : Bertanggung jawab untuk mengatur implementasi total dari website.
    2. Test Manager : Bertanggung jawab untuk mengembangkan master test plan , review test deliverables, manage test cycle dan melaporkan status kepada test manager.
    3. Test Engineer : Bertanggung jawab untuk merancang desain dari test, membuat prosedur testing, membuat test data dan menjalankan test.

14. Schedule

    Ada beberapa tujuan dalam membuat schedule di dalam test plan, antara lain :
    Merincikan Tolak ukur waktu pengerjaan Testing.
    2. Merincikan event transmittal item.
    3. Estimasi waktu yang dibutuhkan untuk setiap task.
    4. Menjadwalkan Testing task dan Test Milestone.
    5. Merincikan periode pemakaian Testing resources.

    

15. Risk and Contingencies

Digunakan untuk memastikan agar hasil testing tetap berkualitas dengan memeriksa beberapa bagian yang tidak termasuk di dalam control pengerjaan software, namun bagian tersebut dapat berdampak langsung terhadap proses.
Contoh :
Sekuritas Layanan Ketika masuk di dalam software masih belum diperhatikan, ketika software sedang dijalankan, belum ada proteksi keamanan oleh software ini sendiri sehingga akan sangat mudah apabila diinjeksi oleh pihak yang tidak bertanggung jawab.

16. Approvals

    Lembar persetujuan sebagai tanda bahwa seluruh tim/pimpinan telah menyetujui Test Plan yang telah dibuat.
    

Tugas pertemuan 1

NPM : 19312183

Nama : Aldo Bahy Colin

Kelas : IF GAB EX 1

Link Website 

UTI : https://teknokrat.ac.id/

FTIK : https://ftik.teknokrat.ac.id/

Waterfall

Metode waterfall adalah metode kerja yang menekankan fase-fase yang berurutan dan sistematis. Disebut waterfall karena proses mengalir satu arah “ke bawah” seperti air terjun. 

Berikut adalah tahap-tahap pengembangan dalam metode waterfall.

• Requirement gathering and analysis
  Mengumpulkan kebutuhan secara lengkap untuk dianalisis dan mendefinisikan kebutuhan apa saja yang harus dicapai oleh program. Informasi dapat diperoleh melalui wawancara, diskusi, atau survey.

• Design
  Melakukan perancangan desain perangkat lunak sebagai perkiraan sebelum dibuatnya kode. Desain sistem dapat dibuat menggunakan Flowchart, Mind Map, atau Entity Relationship Diagram (ERD).

• Implementasi
  Implementasi ini adalah tahap dimana seluruh desain yang sebelumnya sudah dibuat diubah menjadi kode-kode program. Kode yang dihasilkan masih berbentuk modul-modul yang harus digabungkan di tahap selanjutnya.

• Integration & testing
  Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat sebelumnya dan melakukan pengujian untuk mengetahui apakah perangkat lunak yang dibuat telah sesuai dengan desain dan fungsinya atau tidak.

• Verification
  Di tahap ini, pengguna atau klien yang langsung melakukan pengujian pada sistem, apakah sistem telah sesuai dengan tang disetujui atau belum sesuai.

• Operation & maintenance
  Tahap ini merupakan tahap terakhir dari model waterfall. Sistem yang sudah selesai dijalankan serta dilakukan pemeliharaan. Pemeliharaan berupa memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya.

Setiap metode yang digunakan pasti memiliki kelebihan serta kekurangannya tersendiri.

Berikut adalah kelebihan dari metode waterfall:

1. Memiliki proses yang terurut, sehingga pengerjaan dapat terjadwal dengan baik dan mudah.
2. Cocok untuk sistem dengan kompleksitas rendah (predictable).
3. Setiap proses yang dilakukan tidak dapat saling tumpah tindih.

Berikut adalah kekurangan dari metode waterfall:

1. Waktu pengerjaan relatif lebih lama, karena harus menunggu tahap sebelumnya selesai.
2. Biaya yang dibutuhkan lebih mahal karena waktu pengembangan yang dibutuhkan lebih lama.
3. Model waterfall ini kurang cocok untuk pengembangan proyek yang memiliki kompleksitas tinggi.