Peran Software Tester dalam Agile SDLC

Tester di tim harus berpartisipasi dan berkontribusi pada semua aktivitas proyek dan pada saat bersamaan harus memanfaatkan keahlian dalam pengujian.

Berikut beberapa skill seorang software tester yang dibutuhkan dalam Agile SDLC:

• Memiliki kemampuan interpersonal yang baik.
• Mampu bertindak positif dan berorientasi pada solusi dengan team meber dan stakeholders
• Kemampuan untuk menampilkan kritis, berorientasi pada kualitas, berpikir skeptis tentang produk.
• Aptitude menjadi proaktif untuk secara aktif memperoleh informasi dari para stakeholder
• Keterampilan untuk bekerja secara efektif dengan pelanggan dan pemangku kepentingan dalam menentukan user stories dan user acceptance test
• Bakat menjadi anggota tim yang baik bekerja dengan pengembang dalam menghasilkan kode yang ber kualitas.
• emampuan untuk memiliki kasus uji yang tepat pada waktu yang tepat dan pada tingkat yang tepat dan melaksanakannya dengan baik selama durasi sprint.
• Kemampuan untuk mengevaluasi dan melaporkan hasil tes, uji kemajuan dan kualitas produk.
• Keterbukaan untuk merespon perubahan dengan cepat, termasuk mengubah, menambah atau memperbaiki test case
• Potensi untuk mengatur diri sendiri bekerja.
• Antusiasme terhadap pertumbuhan keterampilan yang berkesinambungan.

Baca Juga: Tutorial Menjadi Software Tester

Peran Software Tester dalam agile Tim

• Tester di Tim Agile berpartisipasi dalam semua kegiatan proyek dan pengembangan untuk memberikan kontribusi keahlian testing terbaik.
• Peran Agile tester antara lain:
• Memastikan penggunaan tools yang tepat.
• Mengkonfigurasi, menggunakan dan mengelola lingkungan uji dan data uji.
• Mentoring anggota tim lainnya dalam aspek pengujian yang relevan.
• Memastikan bahwa tugas pengujian yang tepat dijadwalkan selama pelepasan dan perencanaan sprint.
• Memahami, menerapkan dan memperbarui test strategy
• Berkolaborasi dengan developer, costumer dan stakeholder untuk mengkalrifikasi requirement dalam hal kemampuan testability, konsistensi dan kelengkapan.
• Melakukan tes yang tepat pada waktu yang tepat dan pada tingkat tes yang tepat.
• Pelaporan bug dan bekerja sama dengan tim dalam menyelesaikannya.
• Berpartisipasi dalam sprint retrospective, secara proaktif menyarankan dan menerapkan perbaikan.

Pengertian Agile Testing

Agile adalah salah satu iterative model SDLC  dimana aktivitas development dan testing dilakukan secara bersamaan tidak dalam fase yang terpisah. Coding dan testing dilakukan secara interaktif dan bertahap, menghasilkan produk akhir yang berkualitas, yang memenuhi persyaratan dari client / customer. Pada saat menemukan bug maka tester akan melaporkan kedapa developer lalu developer melakukan bug fixing langsung, dengan begitu dapat menghemat waktu, biaya dan tenaga.

Apa itu Agile Testing?

Agile Testing  adalah praktik pengujian perangkat lunak yang mengikuti prinsip agile software development.

Agile Testing melibatkan semua anggota tim proyek, dengan keahlian khusus yang bekerjasama dengan tester. Testing bukan fase terpisah dengan development bekerja sama dalam semua tahap pengembangan seperti requirements, design, coding dan membuat test case. Pengujian dilakukan secara bersamaan melalui Development Life Cycle.

Selanjutnya, dengan tester berpartisipasi dalam keseluruhan Development Lifecycle dengan anggota tim. kontribusi tester terhadap pengembangan perangkat lunak sesuai kebutuhan customer, dengan desain dan kode yang lebih baik akan menjadi produk yang berkualitas.

Agile Testing mencakup semua tingkat pengujian dan semua jenis pengujian.

Agile Testing Vs Waterfall Testing

Dalam metodologi Waterfall Development, development dan testing dilakukan secara bertahap yang berurutan. Dalam Waterfall, testing adalah fase terpisah dan dimulai setelah development sudah selesai.

Berikut ini adalah beberapa perbedaan antara Agile Testing dan  Waterfall Testing:

Agile Testing	Waterfall Testing
Testing bukan fase terpisah, berjalan bersamaan	Testing fase terpisah, Testing dimulai setelah development selesai
Testers dan developers bekerja bersama	Testers bekerja terpisah dengan developers.
Testers terlibat dalam fase requirement, membantu dalam pemetaan persyaratan terhadap perilaku user	Testers tidak terlibat dalam fase requirement
Acceptance Testing dilakukan setelah setiap iterasi dan mendapatkan feedback dari customer	Acceptance Testing dilakuan pada saat project selesai
Setiap iterasi melengkapi pengujiannya sendiri sehingga memungkinkan pengujian regresi untuk diterapkan setiap kali fungsi atau logika baru selesai	Regrestion Testing hanya bisa dilaksanakan setelah development selesai
tidak ada waktu delay antara coding dan testing.	biasanya ada waktu delay / tunggu-tungguan antara coding dan testing.
Testing is a best practice.	Testing sering diabaikan

Prinsip Agile Testing

Berikut adah prinsip-prinsip utama dalam agile testing:
Testing membuat project menjadi maju - Testing secara terus-menerus adalah satu-satunya cara untuk memastikan kemajuan dalam project pembangunan software. Agile Testing memberikan feedback secara berkelanjutan dan produk akhir memenuhi permintaan customer.
Testing is not a phase − Agile team tests bersama tim development (programmer) memastikan bahwa fitur yang diterapkan selama iterasi tertentu benar-benar dilakukan.
Everyone tests - Dalam agile testing seluruh tim termasuk analis, developer dan tester menguji aplikasi. Setelah setiap iterasi, bahkan customer melakukan User Acceptance Testing.
Keep the Code Clean − bug finding dan bug fixing terjadi secara bersamaan. Hal ini memastikan kode bersih pada setiap level development.
“Done Done,” not just done − Dalam agile testing, sebuah fitur bisa dikatakan "done" setelah development selesai, namun dapat dikatakan "done" apabila sudah masuk kedalam tahap development dan testing

Agile Testing Activity

Berikut adalah kegiatan dalam agile testing:

1. Release Planning (Test Plan)
2. Regression Testing
3. Release Activities (Test Related)

Kegiatan agile testing pada saat iterasi:

1. Berpartisipasi dalam perencanaan iterasi
2. mengestimasikan waktu tugas dari setiap task
3. Membuat test case berdasarkan deskripsi fitur
4. Unit Testing
5. Integration Testing
6. Feature Testing
7. Bug Fixing
8. Integration Testing
9. Acceptance Testing
10. Report Progress Testing

Baca Juga: Jenis-Jenis Testing Software

Agile Manifesto

Agile Manifesto dipublikasian oleh tim software developer pada tahun 2001, menyoroti pentingnya tim pengembangan, mengakomodasi perubahan persyaratan dan keterlibatan pelanggan.

Agile Manifesto adalah
menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya. Melalui pekerjaan ini, kita harus menghargai:

• Individu dan interaksi atas proses dan alat.
• Berjalanya software melalui dokumentasi yang komprehensif
• Kerjasama customer melalui negosiasi kontrak
• Menanggapi perubahan setelah mengikuti sebuah rencana.

Artinya apabila dalam sebuah barang mempunyai nilai lebih di kananya, kenapa kita tidak memberikan nilai lebih di sebelah kirinya.

Pengertian A/B Testing

Apa itu A/B Testing? A/B Testing adalah sebuah pengujian untuk menguji perubahan conversian rate antara beberapa variasi dalam website.

Contohnya adalah kamu mencoba beberapa variasi di dalam sebuah website, seperti kamu mengubah text box menjadi radio button atau menjadi checklist box, bahkan menganti gambar dalam sebuah website atau memotong sebuah halaman menjadi setengahnya dll.

Variasi desain ini nantinya akan digunakan untuk melihat apakah setiap perubahan desain memang membawa peningkatan atau pengurangan terhadap conversion rate (seperti perubahan jumlah signup, pembelian, dll.)

Baca Juga: Jenis-Jenis Testing Selengkapnya

Apabila kamu menjalankan A/B testing dengan baik dan benar, upaya ini akan secara signifikan meningkatkan conversion rate pada website kamu secara otomatis. Ini adalah cara termudah dan termurah untuk meningkatkan standar dari website yang kamu miliki.

Cara Kerja A/B Testing

Secara umum, berikut ini adalah siklus dari A/B testing:

• Memutuskan apa yang ingin kamu ubah
• Menggunakan tool A/B testing otomatis untuk melakukan implementasi perubahan secara visual.
• Menggunakan perubahan tersebut selama rentang waktu tertentu agar kita mendapatkan sejumlah angka pengunjung sebagai sampel.
• Tool A/B testing akan menyajikan dua variasi halaman web kepada pengunjung yang berkunjung pada rentang waktu yang sama (tool ini tidak menguji variasi secara bergantian.)
• Ketika data yang dikumpulkan telah dirasa cukup, tool A/B testing akan melaporkan apakah terdapat perubahan yang signifikan dari conversion rate di tiap halaman web. Apabila terdapat perubahan, giliranmu memutuskan untuk mengubah kode atau desain original dari sebuah halaman web menjadi yang kode dan desain yang telah melalui A/B testing atau tidak.
• Ulangi seluruh langkah di atas hingga kamu atau perusahaanmu bangkrut — atau diakuisisi.

Terdapat tiga tool A/B testing yang umum digunakan: Optimizely, VWO, dan Google Optimize. Tool yang terakhir ini gratis, memiliki fitur penuh, dan terintegrasi dengan Google Analytics. Saya merekomendasikan tool ini.

Contoh A/B Testing pada landing Page

Apa saja yang akan diujikan pada landing page? Untuk landing page atau halaman manapun, kamu akan menjalankan pengujian variasi mikro dan variasi makro. Variasi mikro adalah penyesuaian terhadap copy, elemen kreatif, dan struktur halaman. Variasi makro adalah restrukturisasi besar atau bahkan membuat ulang halaman yang telah kamu buat sebelumnya.

Variasi mikro

Berikut ini adalah beberapa ide untuk melakukan variasi mikro sebagai acuanmu untuk memulai:

• Copy: Teks pada header, subheader, feature header, paragraf feature, dst.
• Gambar: Gambar header, gambar pada konten, gambar latar, dst.
• Call to Action: Desain tombol CTA, penempatan, copy untuk CTA, dst.
• Social proof: Mencoba logo perusahaan yang berbeda, mencoba fitur yang berbeda, dst.
• Form: Jumlah kotak isian, layout dari kotak isian, dan copy untuk kotak isian.
• Urutan: Urutan dari bagian-bagian yang ada dalam sebuah halaman.
• Desain: Spasi, warna, dan gaya font yang digunakan.
• Diskon: Memanfaatkan berbagai diskon yang berbatas waktu.
• Variasi mikro terkadang menghasilkan angka konversi yang cukup besar. Tetapi seringkali tidak. Mengubah warna dari sebuah tombol atau mengubah ukurannya menjadi lebih besar biasanya tidak akan membawa dampak yang signifikan dari segi konversi. Walau begitu, ada pengecualian ketika variasi mikro membawa dampak yang besar.

Sebagai contoh: Ketika kamu menulis ulang copy untuk header atau subheader. Teks yang ada pada bagian header biasanya akan menjadi pesan utamamu untuk menarik perhatian pengguna. Apabila kamu selama ini belum berhasil menarik perhatian mereka lewat copy pada bagian header, mungkin kamu perlu mencoba untuk mengubahnya dan melihat hasilnya.

Variasi makro

Variasi makro, sebaliknya, memiliki dampak konversi yang lebih terlihat. Walau begitu, upaya ini membutuhkan lebih banyak pikiran dan tenaga. Kamu mungkin akan dipaksa untuk kembali ke meja gambar untuk membuat kembali sebuah halaman web yang baru — dengan desain baru, elemen-elemen baru, serta teks baru.

Akan sangat sulit untuk mengumpulkan fokus dan kolaborasi tim yang dibutuhkan untuk melakukan upaya ini. Inilah mengapa variasi makro jarang dilakukan.

Akan tetapi, variasi makro adalah sebuah kebutuhan untuk membuat sebuah halaman menjadi sesuai dengan yang diharapkan oleh pengguna. Untuk menginspirasimu, berikut adalah beberapa sumber ide yang dapat kamu gunakan untuk melakukan variasi makro:

• Inspirasi dari website kompetitor: Temukan kompetitor yang menurutmu terlihat berkembang dengan pesat dari sisi bisnis dan memiliki gaya penyajian konten yang terbilang baik. Tiru gaya penyajian mereka dengan nuansa yang kamu miliki. Pro tip: Jangan mencuri aset kreatif yang telah mereka buat apabila kamu memutuskan untuk meniru gaya kompetitor. Ingat, meniru bukan berarti Plagiat
• Gunakan persona yang sesuai dengan target audiens kamu: Sesuaikan seluruh elemen dan gaya penyampaian pesan dengan tipe audiens yang kamu bidik. Sebagai contoh: Jika sebagian besar pengunjung website kamu berasal dari kalangan anak muda, gunakanlah gaya penulisan selayaknya anak muda yang segar dan dinamis. Bisa saja kamu menggunakan persona yang salah ketika menghadapi audiens yang paling potensial.

Sumber: Techinasia.id

Jenis-Jenis Testing SAP

Banyak organisasi / perusahaan menggunakan SAP ERP (Enterprise Resource Planning) untuk mengelola operasi bisnis mereka dan menyesuaikannya dengan tantangan pasar baru. SAP R / 3 adalah perangkat lunak ERP terpadu yang memungkinkan organisasi mengelola bisnis mereka secara efisien. Organisasi dapat mengurangi biaya untuk menjalankan operasinya dengan menggunakan paket SAP R / 3 ERP.

SAP R / 3 juga memungkinkan pelanggan berinteraksi dengan database yang berbeda untuk menjalankan aplikasi yang berbeda dengan bantuan GUI yang user-friendly. Sistem SAP R / 3 dibagi ke dalam modul yang berbeda untuk mencakup fungsionalitas operasi bisnis yang berbeda dalam sebuah organisasi.

Baca Juga: Manfaat dari Testing SAP

Berikut adalah berbagai jenis metode pengujian yang tersedia yang bisa digunakan untuk melakukan pengujian SAP:

Unit Testing
Unit Testing digunakan untuk menguji fungsionalitas sistem SAP dan berbagai komponennya. Hal ini dilakukan oleh ahli domain dan konfigurasi yang mengetahui fungsionalitas masing-masing unit dalam suatu sistem.

Contoh
Misalkan tugasnya adalah membuat sales order dan menyimpannya. Untuk melakukan pengujian unit untuk tugas ini, penguji harus mengetahui bahwa pesanan penjualan dapat disimpan dengan menggunakan elemen organisasi SAP seperti data induk pelanggan, fungsi mitra, data master material, kode perusahaan, area kontrol kredit, organisasi penjualan, dll.
Dalam pengembangan ABAP, Unit testing dapat dilakukan untuk memeriksa apakah sebuah laporan dapat dibuat dari data yang dihasilkan oleh pengembang. Ini membutuhkan bantuan dari pakar domain.

System Testing
System Testing  melibatkan integrasi elemen sistem SAP untuk memastikan bahwa fungsionalitas SAP terkait dihubungkan bersama dalam lingkungan pengembangan.

Contoh
Jika Anda mengatakan arus kas untuk sebuah kutipan dalam sebuah organisasi akan menunjukkan bahwa kutipan dapat digunakan untuk membuat pesanan penjualan, pengiriman dapat dibuat dan diproses dari pesanan, pengiriman dapat ditagihkan, penagihan dikeluarkan ke akuntansi, dan Pembayaran pelanggan diterapkan terhadap faktur akuntansi.

Scenario-based Testing
Scenario testing, seperti namanya, dilakukan sesuai dengan kasus bisnis tertentu.

Contoh
Misalkan ada beberapa tugas yang spesifik untuk segmen pelanggan atau lini produk tertentu atau satu set layanan. Untuk target spesifik ini, Anda memiliki skenario yang berbeda yang perlu Anda uji. Pengujian ini juga dilakukan di development environment.

Integration Testing
Dalam Integration Testing, data pengujian berasal dari sumber ekstraksi data nyata. Data diketahui pengguna akhir bisnis.
Integration Testing digunakan untuk menyajikan proses bisnis, seperti yang dirancang dan dikonfigurasi dalam SAP, berjalan menggunakan data real. Selain itu, pengujian menunjukkan bahwa user interface, laporan, alur kerja bekerja sesuai harapan

SAP Interface Testing
Interface testing atau Pengujian antarmuka memastikan bahwa proses bisnis pada sistem SAP berjalan secara otomatis, Pengujian Interface melibatkan eksekusi pada sistem pengirim yang diikuti oleh keluaran output Interface. dan kemudian sistem penerima mengkonsumsi file tersebut dan membuktikan bahwa proses bisnis berlanjut di receiver.

Idealnya, pengujian antarmuka melibatkan aktivitas pengujian yang lebih besar saat sebuah proyek berjalan. Pengujian antar muka menunjukkan bahwa pemicu kerja, pemilihan data yang akurat dan lengkap, transfer data berhasil, dan receiver mampu mengkonsumsi data yang dikirim.

SAP User Acceptance Testing (UAT)
SAP UAT digunakan untuk memastikan bahwa pengguna akhir dapat melakukan fungsi pekerjaan yang ditugaskan dengan sistem yang baru. Aspek penting dari pengujian ini adalah memahami kebutuhan bisnis dan untuk memastikan bahwa fitur, fungsi dan kemampuan yang diharapkan tersedia.

SAP System Performance Testing
Performance Testing memeriksa aspek-aspek seperti:
Apakah waktu respon sistem dapat diterima sesuai kebutuhan bisnis
Apakah proses periodik berjalan dalam waktu yang diperbolehkan,
Apakah beban pengguna konkuren yang diharapkan dapat didukung
Performance Testing mengidentifikasi kemacetan dan pengkodean inefisiensi dalam sistem SAP. Hal ini tidak mungkin bahwa tuning kinerja sistem diatur dengan sempurna dan program berjalan dengan kode yang optimal.

SAP Load Testing
dalam SAP Load Testing, tester menerapkan beban maksimum pada sistem, baik pengguna online atau pemrosesan batch berkala, dan mengidentifikasi apakah sistem cukup mampu untuk menangani beban. Jika tidak, ia mengetahui langkah-langkah yang diperlukan untuk meningkatkan kinerja.

SAP Security Dan Authorizations Testing
Security dan Authorizations Testing digunakan untuk memastikan pengguna hanya dapat melakukan transaksi dan mengakses data yang sesuai yang relevan dengan proyek mereka.

Seperti penerapan standar Keamanan, ini sangat penting untuk menguji apakah keamanan dan otorisasi ditempatkan dalam sistem. Pengujian ini dibuat dan digunakan untuk mengkonfirmasi apa yang pengguna dapat lakukan dan apa yang pengguna tidak dapat lakukan.

SAP Cutover Testing
Cutover testing biasanya dilakukan satu kali dalam siklus hidup proyek. Di sini eksekusi skala penuh dilakukan terhadap semua tugas yang terlibat untuk mengekstrak data dari sistem sebelumnya.

SAP Regression Testing
Regression testing digunakan untuk menemukan fungsionalitas baru dan untuk menguji fungsi sebelumnya dalam sistem saat diupgrade atau sistem baru disiapkan. Peran kunci dari pengujian regresi adalah menguji fungsi yang ada dan konfigurasi dan basis kode yang baru diperbarui.

Saat Anda meng-upgrade sistem SAP , seharusnya tidak mempengaruhi fungsi yang diharapkan dilakukan oleh pengguna. Selain itu, seharusnya tidak mempengaruhi fitur baru yang seharusnya diperkenalkan dalam rilis baru.

Manfaat Pengujian dalam SAP

Pengujian SAP adalah tentang menguji fungsionalitas modul-modul yang ada untuk untuk memastikan fungsi dari modul tersebut berjalan sesuai dengan konfigurasi nya.

Sistem SAP mengalami berbagai perubahan seperti patch untuk perbaikan dan manajemen, implementasi modul baru, dan berbagai perubahan konfigurasi lainnya. Semua modifikasi ini meningkatkan kebutuhan akan pengujian secara berulang-ulang yang akan dilakukan tester. Tools automatic testing SAP seperti  SAP Test Acceleration dan Optimasi SAP dapat digunakan untuk pengujian SAP ini.

Tujuan Pengujian SAP

Berikut adalah daftar alasan utama mengapa pengujian SAP dilakukan dan mengapa ini merupakan fungsi penting dalam pertumbuhan sebuah organisasi:

• Validasi Sistem - Pengujian SAP melibatkan pengujian menyeluruh  dan validasi semua modul SAP di lingkungan SAP ERP.
• Quality dan Revenue - Pengujian SAP adalah pengujian berbasis output dan tidak seperti metode pengujian konvensional yang berbasis input. memastikan kualitas sistem SAP dan juga berfokus pada pendapatan dan biaya organisasi.
• Biaya dan Prediktabilitas - Pengujian SAP melibatkan pengurangan biaya pengembangan SAP dan meningkatkan prediktabilitas.
• Compliance Requirement − Pengujian SAP memastikan bahwa implementasi SAP memenuhi persyaratan kepatuhan baru dalam organisasi tertentu dan semua modul bekerja sesuai konfigurasi yang diharapkan.
• Implementasi Baru dan Perubahan Konfigurasi - Ada berbagai jenis perubahan yang diterapkan dalam sistem SAP, seperti tambalan dan perbaikan, implementasi baru, perubahan konfigurasi. Oleh karena itu, pengujian SAP memastikan bahwa semua modul berkinerja sesuai kebutuhan di lingkungan sistem dinamis ini.
• Integrasi - Pengujian SAP dilakukan untuk menguji berbagai laporan, arus data dan arus kerja, bentuk GUI, dll. Ini digunakan untuk memeriksa integrasi sistem antara modul yang berbeda. Misalnya, jika sebuah order postingan dilakukan yang memerlukan tindakan Sales and Distribution, MM dan FICO, maka pengujian SAP memeriksa integrasi antar sistem ini.
• Kinerja - Ini juga digunakan untuk memastikan apakah sistem akan dapat memenuhi perjanjian Tingkat Layanan, waktu yang dibutuhkan oleh sistem untuk melakukan tindakan tertentu, kinerja sistem, dll.

Manual Testing

Manual Testing berarti Anda menguji software SAP secara manual tanpa menggunakan alat otomatis atau script apapun. Dalam jenis pengujian ini, penguji mengambil alih peran pengguna akhir dan menguji perangkat lunak untuk mengidentifikasi bug

Ada berbagai tahap pengujian manual. antara lain: unit testing, integration testing, system testing, dan user acceptance testing.

Baca Juga: Jenis jenis testing Software

Berbagai  test plans, test cases, atau test scenarios digunakan oleh penguji untuk memastikan kelengkapan pengujian. Pengujian manual juga bisa disebut pengujian eksplorasi karena penguji mengeksplorasi perangkat lunak untuk mengidentifikasi kesalahan di dalamnya secara manual.

Automation Testing.

Dalam Automation Testing, penguji menulis skrip dan menggunakan tools software untuk melakukan pengujian.  Proses ini melibatkan otomatisasi proses manual. Automation Testing meliputi pengujian ulang beberapa kasus uji coba yang dilakukan secara manual.

Automation Testing juga digunakan untuk menguji aplikasi dari load, performance, dan stress test. Hal ini digunakan untuk meningkatkan cakupan tes. Automation Testing  meningkatkan akurasi dan menghemat waktu dan uang dibandingkan dengan pengujian manual.

Software Testing Tools

• Tools berikut ini dapat digunakan untuk Automation testing:
• HP Quick Test Professional (QTP)
• Selenium
• SAP TAO
• ECATT
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Testing Anywhere
• WinRunner
• LaodRunner
• Visual Studio Test Professional
• WATIR

Untuk pengunaan tools nya bisa dicari di google ya!

Dokumentasi dalam Software Testing

Dokumentasi software testing melibatkan dokumen artefak yang harus dikembangkan sebelum dan sesudah testing software.

Dokumentasi pada software testing membantu dalam memperkirakan upaya pengujian yang diperlukan, cakupan uji, tracking, dan lain-lain. Berikut adalah jenis dokumentasi yang umum digunakan terkait dengan pengujian software seperti:

1. Test Plan
2. Test Scenario
3. Test Case
4. Traceability Matrix

Test Plan

Test Plan merupakan dokumen yang digunakan untuk  menguraikan strategi yang akan digunakan untuk menguji aplikasi, sumber daya yang akan digunakan, lingkungan pengujian dimana pengujian akan dilakukan, dan keterbatasan pengujian dan jadwal kegiatan pengujian. Biasanya leader Software QA akan bertanggung jawab untuk menulis Test Plan.

Berikut adalah poin-poin yang harus ada di dalam test plan:

• Pengantar dokumen test plan
• Asumsi saat menguji aplikasi (waktu pengujian, jumlah tester, device yang dibutuhkan, dll)
• Daftar test case yang akan digunakan
• Daftar fitur-fitur yang akan di test
• Jenis-Jenis testing yang digunakan saat testing software 
• Sumber daya yang akan digunakan
• Resiko-resiko yang mungkin akan muncul pada saat pengetesan
• Jadwal dan tugas tiap-tiap tester yang ada dalam tim

Test Scenario

Test Scenario / Scenario test adalah pernyataan satu baris yang memberitahukan bidang mana dalam aplikasi yang akan diuji. Test Scenario  digunakan untuk memastikan bahwa semua aliran proses diuji dari ujung ke ujung (contoh: dari register, login, sampai logout). Area aplikasi tertentu hanya memiliki satu Test Scenario (contoh: website a mempunyai 1 scenario test, dimana terdapat puluhan scenario seperti login, register, logout, upload dll)

Test Case

Test Case meliputi step-step, kondisi dan inputan yang bisa digunakan selama pengujian. Tujuan utama dari kegiatan ini adalah untuk memastikan apakah sebuah software  lolos atau gagal dalam hal fungsionalitas dan aspek lainnya. Ada banyak jenis test case, seperti functional test, positive test, negative test, error test, logical test, UI test dll

Selanjutnya test case ditulis untuk tracking jangkauan testing software. Umumnya, tidak ada template formal yang bisa digunakan saat test case. Namun, ada poin-poin utama yang harus tersedia di dalam setiap test case, contohnya:

• Test case id:
• Unit to test: Apa yang harus di verifikasi?
• Assumptions:
• Test data: Variables dan values
• Steps to be executed:
• Expected result:
• Actual result:
• Pass/Fail:
• Comments:

Baca Juga: Tips Membuat Test Case / Scenario Test

Istilah Test Scenario dan Test Case digunakan secara bergantian, dimana test scenario biasanya lebih banyak step nya dibanding dengan test case, dimana test case hanya memiliki single step. Dilihat dari perspective nya test scenario sama dengan test case.

Traceability Matrix

Traceability Matrix (juga dikenal sebagai Requirement Traceability Matrix - RTM) adalah tabel yang digunakan untuk melacak persyaratan selama Software Development Life Cycle. dapat digunakan untuk pelacakan ke depan (yaitu dari Persyaratan untuk Desain atau Pengkodean) atau mundur (yaitu dari Coding to Requirements). Ada banyak template yang ditentukan pengguna untuk RTM.

Setiap persyaratan dalam dokumen RTM dihubungkan dengan test case terkait sehingga pengujian dapat dilakukan sesuai persyaratan yang disebutkan. Selanjutnya, Bug ID juga disertakan dan dihubungkan dengan persyaratan dan uji yang terkait.

Tujuan utama untuk matriks ini adalah:

• Pastikan perangkat lunak dikembangkan sesuai persyaratan yang disebutkan.
• Membantu menemukan akar penyebab bug.
• Membantu menelusuri dokumen yang dikembangkan selama fase SDLC yang berbeda.

Standar ISO dalam Software Testing

Banyak perusahaan di seluruh dunia mengembangkan dan menerapkan standar yang berbeda untuk meningkatkan kualitas kebutuhan software mereka berdasarkan standar ISO yang sudah ada. Kali ini kita secara singkat menjelaskan beberapa standar yang banyak digunakan terkait dengan Software Quality Assurance and Software Testing.

ISO/IEC 9126

Standar ini berkaitan dengan aspek untuk mengetahui kualitas aplikasi perangkat lunak, antara lain:

1. Kualitas model
2. Metrik eksternal
3. Metrik internal
4. Kualitas dalam menggunakan metrik

Standar ini menyajikan beberapa atribut kualitas untuk perangkat lunak apapun seperti:

1. Fungsionalitas
2. Keandalan/Realibility
3. Kegunaan
4. Efisiensi
5. Maintainability
6. Portabilitas

Atribut kualitas yang disebutkan di atas dibagi lagi menjadi sub-faktor, yang dapat Anda pelajari saat mempelajari standar ISO secara rinci.

ISO / IEC 9241-11

Bagian 11 dari standar ini berkaitan dengan sejauh mana suatu produk dapat digunakan oleh pengguna tertentu untuk mencapai tujuan yang ditentukan dengan Efektivitas, Efisiensi dan Kepuasan dalam konteks penggunaan tertentu.

Standar ini mengusulkan kerangka kerja yang menggambarkan komponen kegunaan dan hubungan di antara keduanya. Dalam standar ini, kegunaan dipertimbangkan dalam hal kinerja dan kepuasan pengguna. Menurut ISO 9241-11, kegunaan tergantung pada konteks penggunaan dan tingkat kegunaan akan berubah saat konteks berubah.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 umumnya dikenal sebagai standar yang memberikan panduan untuk Persyaratan dan Evaluasi Mutu Perangkat Lunak (SQuaRE). Standar ini membantu dalam mengatur dan meningkatkan proses yang terkait dengan persyaratan kualitas perangkat lunak dan evaluasinya. Pada kenyataannya, ISO-25000 menggantikan dua standar ISO lama, yaitu ISO-9126 dan ISO-14598.

SQuaRE itu sendiri dibagi ke dalam beberapa part, yaitu:

1. ISO 2500n - Quality Management Division
2. ISO 2501n - Quality Model Division
3. ISO 2502n - Quality Measurement Division
4. ISO 2503n - Quality Requirements Division
5. ISO 2504n - Quality Evaluation Division

Isi utama SQuaRE adalah:

1. Istilah dan definisi
2. Model Referensi
3. Panduan umum
4. Panduan divisi individu
5. Standar yang terkait dengan Persyaratan Teknik (yaitu spesifikasi, perencanaan, pengukuran dan proses evaluasi)

ISO / IEC 12119

Standar ini berkaitan dengan paket perangkat lunak yang dikirimkan ke klien. Ini tidak fokus atau berurusan dengan proses produksi klien. Isi utama berhubungan dengan item berikut:

Tetapkan persyaratan untuk paket perangkat lunak.
Petunjuk untuk menguji paket perangkat lunak yang dikirimkan sesuai persyaratan yang ditentukan.

Beberapa standar lain yang terkait dengan proses QA dan Testing disebutkan di bawah ini:

Standard	Deskripsi
IEEE 829	Sebuah standar untuk format dokumen yang digunakan dalam berbagai tahap software testing.
IEEE 1061	Metodologi untuk menetapkan persyaratan kualitas, mengidentifikasi, menerapkan, menganalisis, dan memvalidasi proses, dan produk metrik kualitas software.
IEEE 1059	Panduan untuk Verifikasi dan Validasi software.
IEEE 1008	Sebuah standar untuk unit testing.
IEEE 1012	Sebuah standar untuk verifikasi dan validasi.
IEEE 1028	Sebuah standar untuk software inspeksi.
IEEE 1044-1	Panduan untuk klasifikasi anomali perangkat lunak.
IEEE 830	Panduan untuk mengembangkan spesifikasi persyaratan sistem.
IEEE 730	Standar untuk rencana penjaminan mutu perangkat lunak
IEEE 12207	Standar untuk proses system development lifecycle suatu software
BS 7925-1	Kosa kata istilah yang digunakan dalam software testing.
BS 7925-2	Standar pengujian komponen software testing