Jika QA baru masuk dalam kondisi di mana tidak ada tim QA atau QA sebelumnya sudah meninggalkan posisi tanpa adanya transfer knowledge atau dokumentasi yang memadai, itu bisa menjadi tantangan yang besar. Namun, ada beberapa langkah yang bisa dilakukan untuk mengatasi masalah tersebut:

1. Tentukan Proses dan Prioritas Awal

2. Bangun Proses Pengujian dari Awal

3. Tanyakan Detail tentang Infrastruktur dan Alur Kerja

4. Bangun Dokumentasi untuk Pengujian

5. Menilai dan Mengatasi Masalah Secara Bertahap

6. Membangun Rencana Pengujian Jangka Panjang

7. Membangun Tim QA (Jika Diperlukan)
Rekrutmen atau Kolaborasi dengan Tim Lain: Jika kebutuhan pengujian berkembang dan lebih banyak sumber daya diperlukan, pertimbangkan untuk merekrut anggota baru untuk membangun tim QA. Jika perusahaan tidak siap untuk tim QA besar, kamu bisa berkolaborasi dengan tim pengembang atau tim produk untuk menyelesaikan tugas-tugas pengujian secara bersama-sama.

8. Peningkatan Terus-Menerus
Iterasi dan Penyesuaian: Setelah QA baru mulai melakukan pengujian, lakukan iterasi dan penyesuaian pada proses pengujian berdasarkan feedback dan temuan yang ada. Uji efektivitas prosedur dan alat yang digunakan, dan pastikan untuk terus belajar dan berkembang dalam metodologi pengujian.

9. Berkomunikasi dengan Manajer atau Pihak Terkait
Laporan Berkala: Pastikan untuk memberikan laporan berkala kepada manajer atau pemangku kepentingan lainnya mengenai kemajuan pengujian dan masalah yang ditemukan. Ini bisa membuka peluang untuk diskusi lebih lanjut tentang bagaimana meningkatkan proses pengujian dan mendapatkan dukungan lebih banyak.

Dalam situasi seperti ini, tantangannya memang besar karena tidak ada warisan pengetahuan yang jelas, tetapi dengan pendekatan yang terstruktur dan penuh inisiatif, QA baru bisa mulai membangun sistem pengujian yang efektif untuk memastikan kualitas produk.

Jika dokumentasi belum ada atau berantakan saat seorang QA baru masuk, itu bisa menjadi tantangan besar, tetapi ada beberapa langkah yang dapat dilakukan untuk mengatasi masalah ini:

1. Tanya Tim untuk Penjelasan Langsung

2. Mendokumentasikan Proses yang Ada

3. Menggunakan Knowledge Transfer (KT) atau Sesi Q&A

4. Evaluasi dan Perbaiki Dokumentasi yang Ada

5. Bekerja dengan Scrum atau Agile Framework
Jika tim bekerja dalam framework Scrum atau Agile, QA baru bisa memanfaatkan Daily Stand-ups dan Sprint Retrospectives untuk menanyakan hal-hal yang belum jelas. Tim sering berbagi kendala dan pembaruan selama pertemuan ini, yang dapat memberikan insight yang lebih baik bagi QA baru.

6. Belajar dari Kesalahan
Trial and Error: Jika dokumentasi kurang, QA baru juga bisa belajar dengan mencoba dan melakukan pengujian langsung. Meskipun ini bisa memakan waktu, itu akan membantu dalam memahami alur kerja tim dan proses pengujian lebih baik.

7. Feedback untuk Penyempurnaan
Jika QA baru merasa bahwa kurangnya dokumentasi menghambat pekerjaan mereka, mereka bisa memberikan umpan balik kepada manajer atau lead QA mengenai perlunya peningkatan dokumentasi untuk mendukung tim di masa depan. Ini bisa menjadi peluang untuk membangun dokumentasi yang lebih baik dan lebih berguna bagi tim.

Memang, tidak adanya dokumentasi yang jelas atau berantakan bisa menambah kesulitan, tetapi dengan pendekatan yang terstruktur dan kolaboratif, QA baru tetap dapat beradaptasi dan mulai memberikan kontribusi yang signifikan.

Knowledge transfer dan handover ke QA baru biasanya dilakukan oleh seseorang yang memiliki pengalaman yang lebih dalam, biasanya seorang senior QA, lead QA, atau QA yang sudah berpengalaman dengan sistem dan proses yang ada. Berikut adalah beberapa pihak yang berhak dan biasanya terlibat dalam knowledge transfer dan handover ke QA baru:

Tujuan dari knowledge transfer adalah memastikan bahwa QA baru dapat beradaptasi dengan cepat dan efektif dengan lingkungan kerja, serta dapat menjalankan tugas pengujian dengan baik dan sesuai standar yang ditetapkan.

Dalam tim QA (Quality Assurance), biasanya QA Manager atau QA Lead yang bertanggung jawab untuk membuat quality metrics dan KPI (Key Performance Indicators). Mereka bekerja sama dengan manajer produk, tim pengembangan, dan pihak terkait lainnya untuk menentukan metrik yang relevan dengan tujuan kualitas produk yang diinginkan.

Berikut adalah beberapa peran yang terlibat dalam pembuatan quality metrics dan KPI:

Beberapa contoh quality metrics dan KPI yang umum digunakan dalam QA adalah:

Tujuan dari metrik dan KPI ini adalah untuk mengukur kinerja tim QA, memastikan kualitas produk, serta meningkatkan proses pengujian secara berkelanjutan.

Dalam proses pengujian perangkat lunak, dashboard bug tracking di Jira sangat membantu untuk memantau dan mengelola status bug atau masalah yang ditemukan selama pengujian.

Apakah QA Perlu Membuat Dashboard Bug Tracking di Jira?

Siapa yang Membuat Dashboard di Jira?

Keuntungan Dashboard Bug Tracking di Jira:

Kapan Dashboard Biasanya Dibuat?

Apa Saja yang Bisa Ditampilkan dalam Dashboard Bug Tracking?

Kesimpulan
Secara keseluruhan, meskipun tidak selalu menjadi kewajiban utama QA untuk membuat dashboard, keterlibatan mereka dalam pengaturan dan pemantauan bug yang tercatat sangat penting. Dashboard ini bisa sangat berguna untuk memastikan alur kerja bug tracking yang transparan dan efisien.

Perbedaan antara Software QA Engineer Manual, QA Manual, QA Analyst, dan QA Tester seringkali bergantung pada terminologi yang digunakan oleh perusahaan, tetapi berikut adalah gambaran umum mengenai perbedaan tersebut:

1. Software QA Engineer Manual

2. QA Manual

3. QA Analyst

4. QA Tester

Kesimpulan

Penting untuk diingat bahwa setiap perusahaan mungkin mendefinisikan peran ini secara berbeda, jadi selalu perhatikan deskripsi pekerjaan saat melamar.

Perbedaan antara microservice dan monolith terletak pada cara mereka merancang, mengembangkan, dan mengelola aplikasi perangkat lunak.

1. Monolith Architecture
Monolith adalah pendekatan tradisional di mana seluruh aplikasi dibangun sebagai satu kesatuan besar, mencakup semua fitur dan fungsionalitas.

Karakteristik:

Kelebihan:

Kekurangan:

2. Microservice Architecture
Microservice adalah pendekatan modern di mana aplikasi dibangun sebagai kumpulan layanan kecil yang independen dan berfungsi secara terpisah.

Karakteristik:

Kelebihan:

Kekurangan:

Perbandingan Utama

Kapan Bisa di Implementasikan?

API Testing kini menjadi salah satu skill penting yang sebaiknya dimiliki oleh seorang QA. Seiring dengan semakin banyaknya aplikasi modern yang menggunakan arsitektur berbasis API (seperti microservices), pengujian API berperan penting dalam memastikan integrasi antar komponen berjalan lancar.

Mengapa API Testing Penting untuk QA?

Skill yang Dibutuhkan untuk API Testing

Apakah Harus Wajib?
Tidak semua QA diwajibkan memiliki kemampuan ini tergantung pada peran dan kebutuhan perusahaan. Namun, memiliki skill API Testing akan memberikan nilai tambah signifikan, terutama di perusahaan yang menerapkan DevOps, CI/CD, atau mengembangkan aplikasi berbasis microservices.

Kemampuan untuk melakukan query SQL dan MongoDB bisa jadi wajib atau opsional tergantung pada jenis proyek, organisasi, dan tanggung jawab spesifik dari peran QA. Berikut adalah situasi di mana kedua kemampuan ini relevan:

1. Wajib

2. Opsional

Nilai Tambah Jika Dikuasai
Memiliki kemampuan query SQL dan MongoDB adalah nilai tambah besar untuk QA karena:

Rekomendasi
Jika saat ini kemampuan tersebut belum kamu kuasai, mulailah belajar dasar-dasarnya. Anda bisa fokus pada:

Sebagai QA, kemampuan untuk melakukan debug pada browser tidak selalu wajib, tetapi sangat berguna. Tingkat kebutuhan tergantung pada jenis pengujian yang dilakukan, lingkungan kerja, dan kompleksitas aplikasi yang diuji.

Mengapa Kemampuan Debug Browser Penting?

Situasi Ketika Tidak Wajib

Dasar Debugging yang Berguna untuk QA
Jika ingin belajar debugging browser, berikut adalah fitur DevTools yang sebaiknya Anda pahami:

Kemampuan ini membuatmu lebih mandiri dalam pengujian, meningkatkan kolaborasi dengan developer, dan menunjukkan keahlian teknis yang bernilai tinggi.

Kepribadian introvert dapat sangat cocok untuk peran sebagai Quality Assurance (QA). Beberapa alasan mengapa introvert sering berhasil dalam bidang ini adalah:

Namun, ada beberapa tantangan yang mungkin dihadapi introvert, seperti kebutuhan untuk berkolaborasi dengan tim atau memberikan presentasi. Tetapi dengan latihan dan kepercayaan diri, aspek ini dapat ditingkatkan.

Memilih antara logging dan monitoring, unit testing, atau automation testing tergantung pada beberapa faktor seperti tahap pengembangan, kebutuhan aplikasi, prioritas bisnis, dan sumber daya yang tersedia. Namun, dalam praktik terbaik, ketiganya diperlukan dan saling melengkapi. Untuk membantu memprioritaskan, berikut adalah panduannya:

1. Jika Proyek Masih Dalam Tahap Pengembangan Awal

2. Jika Proyek Sedang Dalam Tahap Pengujian atau Pra-Perilisan

3. Jika Aplikasi Sudah Berjalan di Produksi

Sebagai seorang QA, kemampuan membaca logging dan monitoring menjadi semakin penting, terutama dalam lingkungan teknologi yang kompleks. Berikut adalah penjelasan terkait tuntutan dan alat yang digunakan untuk logging dan monitoring:

Apakah QA Dituntut Bisa Membaca Logging dan Monitoring?
Iya, tetapi tergantung kebutuhan perusahaan dan proyeknya.

2. Cara Membaca Logging dan Tools yang Digunakan

3. Cara Melakukan Monitoring dan Tools yang Digunakan

Tips untuk QA

Kemampuan ini akan meningkatkan efisiensi dan kredibilitas sebagai QA, terutama di lingkungan yang menerapkan prinsip DevOps atau CI/CD.

Implementasi flagging di environment produksi (production) adalah praktik umum dalam pengembangan perangkat lunak, terutama untuk fitur baru atau perubahan yang memerlukan peluncuran bertahap. Namun, ada beberapa pertimbangan penting terkait keamanan dan risiko, terutama jika environment production penuh dengan data sensitif seperti credential.

Apakah boleh meminta implementasi flagging di production?
Ya, boleh, dan ini adalah praktik yang sering digunakan untuk:

Namun, penerapan ini harus dilakukan dengan pengelolaan yang tepat.

Apakah riskan jika environment penuh dengan data credential?
Pasti ada risiko jika tidak ada pengelolaan dan keamanan yang memadai, terutama terkait data sensitif. Berikut adalah risiko dan mitigasinya:

Rekomendasi untuk QA

Dengan pengelolaan yang hati-hati, implementasi feature flag di production dapat menjadi alat yang sangat berguna tanpa menimbulkan risiko besar terhadap data sensitif.

Regression testing API membutuhkan satu API untuk cleansing data testing karena beberapa alasan penting berikut:

Contoh Kasus
Misalnya, kamu memiliki pengujian API untuk sistem pemesanan. Jika data pesanan sebelumnya tidak dihapus, pengujian berikutnya dapat gagal karena:

Dengan cleansing API, kamu dapat membersihkan semua data terkait pesanan sebelum memulai pengujian baru.

Best Practices

Memiliki environment testing khusus untuk Quality Assurance (QA) sangat penting dalam siklus pengembangan perangkat lunak, karena memastikan bahwa pengujian dilakukan dalam lingkungan yang mereplikasi kondisi aktual aplikasi, tetapi dengan kendali lebih besar terhadap data dan proses. Berikut adalah alasan utama mengapa QA membutuhkan environment testing sendiri, serta implikasinya jika tidak memilikinya:

Mengapa QA Harus Punya Environment Testing?

Jika Tidak Ada Environment Testing
Jika QA tidak memiliki environment testing khusus, beberapa masalah dapat muncul:

Alternatif Jika Tidak Memiliki Environment Testing

Kesimpulan
Environment testing adalah elemen krusial bagi tim QA untuk memastikan kualitas aplikasi sebelum deployment. Jika tidak tersedia, QA harus mencari cara untuk menciptakan kondisi yang menyerupai lingkungan production, menggunakan alat bantu atau pendekatan alternatif yang minim risiko terhadap proses pengembangan dan staging.

Masing-masing versi (version) dalam proses pengembangan perangkat lunak memiliki fungsi penting untuk Quality Assurance (QA). Berikut manfaat versioning untuk QA:

1. Test Plan Version

2. Test Case Version

3. Build Version

4. API Version

5. App Version

6. Release Version

Kesimpulan
Versioning membantu QA untuk:

Versioning adalah elemen penting dalam proses pengujian, terutama di lingkungan yang menggunakan metodologi Agile atau Continuous Integration/Continuous Deployment (CI/CD).

Mengujinya aplikasi berbasis desktop memang bisa lebih sulit dibandingkan dengan aplikasi berbasis web atau mobile, karena ada beberapa faktor yang membuat pengujian aplikasi desktop lebih kompleks. Berikut alasan mengapa pengujian aplikasi desktop lebih menantang:

Kesimpulan
Pengujian aplikasi desktop lebih sulit karena kompleksitas konfigurasi perangkat keras dan perangkat lunak yang berbeda-beda, ketergantungan pada sistem operasi tertentu, proses instalasi dan pembaruan yang rumit, serta tantangan dalam pengujian kinerja dan keamanan. Meskipun aplikasi web dan mobile juga memiliki tantangan tersendiri, aplikasi desktop memerlukan pengujian yang lebih mendalam terhadap interaksi dengan sistem lokal, perangkat keras, dan kompatibilitas berbagai versi OS.

Untuk menjadi seorang QA Manual, ada beberapa syarat dan skill yang biasanya dibutuhkan agar bisa menjalankan tugas dengan efektif. Berikut adalah daftar skill dan syarat minimal yang perlu dimiliki:

Dengan memiliki skill-skill tersebut, seorang QA Manual dapat menjalankan tugas pengujian perangkat lunak dengan baik, memastikan kualitas produk yang lebih baik, dan menghindari terjadinya bug atau masalah yang tidak terdeteksi.

Sebagai QA, ketika dihadapkan dengan tugas yang multitasking, penting untuk tetap menjaga komunikasi yang jelas dan terbuka dengan Project Manager (PM) / Product Manager / Product Owner agar prioritas testing dapat dikelola dengan efektif. Berikut adalah beberapa sikap dan langkah yang bisa diambil untuk melakukan negosiasi prioritas dengan PM:

Dengan sikap yang profesional, berbasis data, dan fokus pada kualitas, kamu bisa melakukan negosiasi yang efektif dan membantu tim serta Project Manager (PM) / Product Manager / Product Owner memahami bagaimana pengujian yang lebih terorganisir dapat meningkatkan keberhasilan proyek secara keseluruhan.

Untuk mengubah kebiasaan QA agar test case lebih terstruktur dan tidak asal-asalan, berikut langkah yang bisa diterapkan:

Dengan mengikuti langkah-langkah di atas, test case dapat lebih terstruktur dan efektif dalam mengcover seluruh kebutuhan pengujian, mengurangi risiko adanya skenario yang tidak tercover.

Implementasi unit testing sebaiknya dilakukan sejak awal proses pengembangan. Namun, jika fitur atau modul sudah terlalu besar, masih memungkinkan untuk memulai, meskipun ada tantangan tambahan. Berikut adalah panduan untuk keduanya:

Kapan Unit Testing Dilakukan?

Jika Fitur/Modul Sudah Terlalu Besar
Jika modul atau fitur sudah besar dan tidak memiliki unit test, kamu tetap bisa memulai, tapi perlu pendekatan bertahap dan strategis:

Tantangan dan Cara Mengatasinya

Kesimpulan

Pendekatan ini memungkinkan unit testing tetap bisa diimplementasikan, bahkan untuk fitur yang sudah besar dan kompleks.

Menghadapi situasi ini membutuhkan pendekatan yang diplomatis, kolaboratif, dan solutif agar tidak menimbulkan konfrontasi. Berikut beberapa langkah yang dapat diambil:

Contoh Diplomasi
Saat berdiskusi dengan developer: "Saya melihat beberapa skenario ini cukup penting untuk produk kita. Bagaimana kalau kita memastikan sebagian besar dari ini sudah tercover di unit test? Kalau ada yang kurang jelas, saya siap bantu jelaskan test case-nya."

Pendekatan ini menghindari kesan menyalahkan, mendukung kerja sama, dan menjaga hubungan baik antar anggota tim.

Testing lewat database sering dianggap red flag / berbahaya karena beberapa alasan berikut:

Cara Meminimalkan Risiko

Dengan pendekatan ini, QA dapat memanfaatkan testing database tanpa mengorbankan aspek penting lain dalam pengujian perangkat lunak.

Sebagai seorang Quality Assurance (QA), memahami Entity-Relationship Diagram (ERD) memang tidak selalu wajib, tetapi memiliki pengetahuan dasar tentangnya dapat sangat bermanfaat. Berikut alasannya:

Mengapa QA Perlu Tahu ERD?

Manfaat yang Dirasakan QA

Contoh Situasi
Jika dalam sebuah sistem terdapat fitur manajemen user dan order, QA yang memahami ERD bisa:

Kesimpulan
Meskipun tidak wajib, pengetahuan tentang ERD akan sangat meningkatkan kualitas kerja QA. Jika kamu ingin meningkatkan keahlian sebagai QA, belajar dasar-dasar ERD adalah investasi yang berharga.

Sebagai QA, memahami perbedaan antara validasi syntactic dan semantic sangat penting untuk memastikan kualitas aplikasi. Berikut adalah penjelasannya:

1. Validasi Syntactic (Sintaksis)

Validasi sintaktis memastikan bahwa data atau input yang dimasukkan sesuai dengan aturan format atau struktur yang telah ditentukan. Fokusnya pada how the data is structured.

2. Validasi Semantic (Semantik)

Validasi semantik memastikan bahwa data yang dimasukkan memiliki makna atau logika yang benar sesuai dengan konteks. Fokusnya pada whether the data makes sense.

Perbandingan Utama

Konteks QA

Memahami kedua jenis validasi ini membantu QA memastikan aplikasi bekerja secara optimal dan mencegah terjadinya kesalahan dari sisi pengguna maupun sistem.

Peran Quality Assurance (QA) sangat penting dalam audit internal maupun eksternal, terutama di akhir tahun, karena QA berkontribusi untuk memastikan bahwa proses, produk, dan layanan perusahaan sesuai dengan standar yang telah ditetapkan. Berikut beberapa alasan QA dilibatkan dalam audit tersebut:

Contoh Situasi
Misalnya, dalam audit eksternal untuk memastikan aplikasi mematuhi standar GDPR (General Data Protection Regulation), tim QA akan diminta memberikan bukti bahwa pengujian privasi data pengguna telah dilakukan dan bahwa fitur seperti data encryption dan access control berfungsi sebagaimana mestinya.

Dengan demikian, QA tidak hanya mendukung operasional, tetapi juga berperan penting dalam memastikan perusahaan dan aplikasinya berjalan sesuai standar audit.

QA (Quality Assurance) wajib mengetahui tentang OWASP (Open Web Application Security Project) karena mereka berperan penting dalam memastikan bahwa aplikasi tidak hanya berfungsi dengan baik, tetapi juga aman dari potensi ancaman keamanan. Memahami OWASP memungkinkan QA untuk mengidentifikasi, menguji, dan mencegah kerentanannya di tahap awal pengembangan aplikasi.

Mengapa QA Harus Mengetahui OWASP:

Peran QA dalam Konteks Keamanan

Dokumen yang Dapat Dibuat QA

QA berfokus pada dokumentasi pengujian fungsionalitas yang bisa memetakan potensi risiko dari perspektif pengguna. Beberapa contoh dokumen yang relevan bagi QA:

Pengujian yang Dilakukan oleh Tim Lain

Jadi, meskipun QA berperan lebih pada pengujian fungsional dan verifikasi dari sisi pengguna, mereka tetap dapat mendokumentasikan dan menguji beberapa aspek dasar dari kerentanannya. Namun, untuk pengujian yang lebih mendalam terkait dengan keamanan dan kerentanannya yang lebih kompleks, tim lain seperti pentester atau DevOps akan mengambil peran utama.

ISO/IEC 27001 adalah standar internasional yang mengatur sistem manajemen keamanan informasi (ISMS), yang membantu organisasi untuk menjaga kerahasiaan, integritas, dan ketersediaan informasi mereka. Bagi Quality Assurance (QA), mematuhi aturan ISO/IEC 27001 sangat penting karena beberapa alasan berikut:

Dengan demikian, mematuhi ISO/IEC 27001 membantu QA untuk menjaga standar keamanan yang tinggi dalam pengujian dan pengelolaan informasi, mengurangi risiko, serta mendukung keberlanjutan dan kepatuhan organisasi terhadap regulasi yang ada.

ISO/IEC 27001 adalah standar internasional yang mengatur sistem manajemen keamanan informasi (ISMS), yang membantu organisasi untuk menjaga kerahasiaan, integritas, dan ketersediaan informasi mereka. Bagi Quality Assurance (QA), mematuhi aturan ISO/IEC 27001 sangat penting karena beberapa alasan berikut:

Dengan demikian, mematuhi ISO/IEC 27001 membantu QA untuk menjaga standar keamanan yang tinggi dalam pengujian dan pengelolaan informasi, mengurangi risiko, serta mendukung keberlanjutan dan kepatuhan organisasi terhadap regulasi yang ada.

Setiap posisi ini memegang peranan yang penting dalam memastikan kualitas produk perangkat lunak dan keberhasilan proyek pengujian.

Meskipun tren industri semakin mengarah pada otomatisasi dalam pengujian perangkat lunak, QA manual tetap sangat dibutuhkan karena beberapa alasan:

Karena itu, meskipun banyak lowongan yang memerlukan keterampilan dalam otomasi, keterampilan manual tetap sangat berharga, terutama untuk perusahaan yang sedang berkembang atau memiliki aplikasi yang sangat dinamis. Memiliki kemampuan dalam kedua bidang ini (manual dan otomasi) memberi keuntungan yang lebih besar di pasar kerja.

Keterlibatan tim QA dalam event-event tersebut bertujuan untuk menjaga kualitas produk dan memitigasi risiko yang mungkin muncul sebelum aplikasi mencapai pengguna akhir.

Pada umumnya, dalam tim development, QA biasanya tidak terlibat langsung dalam rapat dengan klien untuk membahas requirement system. Rapat seperti itu biasanya dipimpin oleh Project Manager atau Tim Produk yang berfokus pada pemahaman kebutuhan bisnis dan spesifikasi fungsional.

Namun, QA tetap perlu mendapatkan informasi terkait requirement system dari rapat tersebut untuk memastikan bahwa pengujian dapat dilakukan dengan baik berdasarkan kebutuhan yang telah disepakati. Dalam beberapa kasus, QA dapat diminta untuk ikut berpartisipasi dalam rapat tersebut, terutama jika ada kebutuhan untuk memastikan bahwa aspek kualitas dan pengujian sudah dipertimbangkan sejak awal.

Secara ringkas:

Menurut saya, tidak ada kewajiban formal yang mengharuskan Quality Assurance (QA) untuk membuat MoM (Minutes of Meeting) dalam setiap rapat. Namun biasanya pembuatan MoM adalah bagian dari praktik terbaik dalam pengelolaan proyek. MoM berguna untuk mencatat hasil-hasil penting dari rapat, termasuk keputusan yang diambil, tindakan yang harus dilakukan, dan tanggung jawab masing-masing pihak.

Dalam konteks QA, membuat MoM saat rapat dengan tim pengembangan atau tim lainnya sangat berguna untuk beberapa alasan:

Pembuatan MoM atau tidak tergantung pada kebijakan perusahaan dan peran spesifik QA di tim. Di beberapa tim, mungkin ada orang khusus yang bertugas untuk mencatat MoM, sementara di tim lain QA mungkin terlibat langsung dalam proses ini.

Seorang QA biasanya membuat berbagai dokumen untuk memastikan proses pengujian berjalan dengan baik dan aplikasi atau sistem yang diuji memenuhi standar kualitas yang ditentukan. Berikut beberapa dokumen penting yang perlu dibuat:

Dokumen-dokumen ini membantu dalam memastikan bahwa pengujian dilakukan secara terstruktur, terorganisir, dan mencakup semua aspek yang diperlukan untuk memastikan kualitas perangkat lunak yang tinggi.

Secara keseluruhan, perbedaan antara startup dan perusahaan besar berkaitan dengan ukuran tim, tingkat formalitas, dan kebutuhan akan fleksibilitas dalam pengembangan produk.

Sebagai QA, kemampuan untuk membaca dan memahami dokumen seperti FSD (Functional Specification Document), BRD (Business Requirements Document), PRD (Product Requirements Document) atau SRS (Software Requirements Specification) adalah wajib karena dokumen-dokumen ini merupakan dasar dari proses pengujian. Berikut alasan pentingnya kemampuan ini:

Kesimpulan
QA yang tidak mampu membaca atau memahami dokumen seperti FSD, BRD, PRD, atau SRS akan sulit menjalankan tugasnya secara maksimal. Dokumen-dokumen tersebut adalah panduan utama untuk memahami apa yang diharapkan dari sistem, sehingga QA dapat memastikan bahwa hasil akhirnya sesuai dengan kebutuhan bisnis dan bebas dari cacat.

Contoh Kasus

Kesimpulan
Ilmu UI/UX memungkinkan QA untuk tidak hanya memastikan "aplikasi berjalan" tetapi juga memastikan "aplikasi berjalan dengan baik untuk pengguna." Ini menciptakan aplikasi yang lebih berkualitas dan meningkatkan kepuasan pengguna.

Kesimpulan
QA yang memahami proses bisnis yang didigitalisasi tidak hanya memastikan kualitas teknis aplikasi, tetapi juga berkontribusi langsung pada kesuksesan bisnis dengan menjamin bahwa sistem mendukung operasional secara efektif dan efisien.