ALAT PENGUJIAN

MANUAL
Pengujian:
 Proses mengidentifikasi bug dalam perangkat lunak (proyek/produk) dikenal sebagai
"Pengujian".
 Insinyur Penguji harus memeriksa silang (memvalidasi) apakah perangkat lunak yang
dikembangkan sesuai dengan kebutuhan klien atau tidak. Dia bertanggung jawab untuk
memberikan perangkat lunak berkualitas kepada klien.

**Catatan: Tanggung jawab utama dari test engineer adalah, ia harus memeriksa
(memvalidasi) apakah aplikasi (perangkat lunak) yang dikembangkan bermanfaat bagi
pengguna akhir atau tidak.

Bug: Penyimpangan dari persyaratan dikenal sebagai bug atau cacat.

Kualitas: Pembenaran semua persyaratan klien dengan keramahan dan keamanan pengguna
dikenal sebagai kualitas .
 Mari kita ambil contoh : Disampaikan/Dirilis

Analis Bisnis Dokumen yang Dibutuhkan Pengembang Perusahaan Proyek/produk

Aku Arsitek Rencana Pembangu Pembangun Rumah
n
Klien

Rencana
Pengawas

Insinyur Uji

Proyek:
Ini akan dikembangkan berdasarkan kebutuhan klien; setelah dikembangkan, itu akan
dikirimkan ke klien. Berdasarkan kebutuhan klien, anggota tim (Pengguna akhir) akan
menggunakannya.
Mis: Spicejet.com, selenium4testing.com, Membangun rumah sendiri dengan
persyaratan kami.
Produk:
Ini akan dikembangkan berdasarkan kebutuhan perusahaan. Setelah dikembangkan, akan
dirilis di pasar berdasarkan kebutuhan pelanggan yang akan mereka pilih produknya.
Mis: Aplikasi Seluler, Kalkulator, Facebook, yahoo, MS Office, sistem operasi Mac, sistem
operasi windows, Gmail dll…
Jenis pengujian:

Alat Pengujian

Pengujian Fungsional Pengujian Non Fungsional

Pengujian Beban

Pengujian Manual Pengujian Otomasi Pengujian kinerja

Selenium, menangkan Pelari Stress Testing

Pengujian QTP, RFT, silktest, Water, Watin Soak

Aplikasi berbasis internet:

Aplikasi ini dapat diakses di seluruh dunia dengan jumlah pengguna yang tidak terbatas.

Contoh: Gmail, Facebook, selenium 4testing

Aplikasi Berbasis Intranet:

Aplikasi ini juga dapat diakses di seluruh dunia, namun dengan jumlah pengguna yang terbatas.

Mis: Aplikasi yang terbatas pada organisasi tertentu.

Penawaran proyek:
Peran Terlibat:
1. Analis Bisnis Pemasaran (BA)
2. Manajer Keterlibatan (EM)

 Analis Bisnis Pemasaran (BA):

Marketing BA akan menemui klien dan meyakinkan klien dengan proposal tersebut. Setelah
klien puas dengan proposal maka klien dan perusahaan akan menandatangani proyek.

Keluar :
 Kesepakatan resmi antara klien dan perusahaan tentang pengiriman proyek dikenal
sebagai ' sign off' .

Pertemuan Awal:

Setelah proyek ditandatangani, perusahaan akan melakukan pertemuan ' permulaan' .

Ini adalah pertemuan singkat di mana semua manajemen tingkat tinggi akan
berpartisipasi dan mereka akan mengumumkan proyek, klien, dan mereka akan memilih
manajer proyek untuk proyek tersebut. Manajer proyek bertanggung jawab atas SDLC.

 Manajer Keterlibatan (EM):

Engagement Manager bertanggung jawab untuk menjaga hubungan antara klien dan
perusahaan. Dia bertindak sebagai jembatan antara Klien dan Perusahaan.

Penawaran proyek
1 Kr
Klien
Tentang 1 tahun
perusahaan

Sejarah
Usul Keluar
Estimasi

Waktu & Biaya

Memulai Rapat
C1 C2 C3

2cr 1,5 cr 1 cr Manajer Proyek

2 tahun 1,5 tahun 1 tahun

Hirarki proyek atau hirarki Penunjukan atau hirarki Peran

LLM: Manajemen tingkat rendah

MLM: Manajemen tingkat menengah

HLM: Manajemen Tingkat Tinggi

SIKLUS HIDUP
PENGEMBANGAN PERANGKAT LUNAK (SDLC):
Ini terdiri dari fase-fase di bawah ini,

1. Fase Kebutuhan
2. Tahap Analisis
3. Fase desain
4. Fase Pengkodean
5. Fase pengujian
6. Fase pengiriman dan pemeliharaan.

PIN : Catatan inisiasi/inisiasi proyek:

Ini adalah email, akan disiapkan oleh manajer proyek yang berisi tanggal mulai dan tanggal
akhir proyek. Surat akan dikirim ke klien dan manajemen tingkat tinggi.
PIN menunjukkan dimulainya proyek.

1) Fase kebutuhan:
Peran : Analis Bisnis
Manajer Keterlibatan
Manajer proyek

 BA bertanggung jawab untuk mengumpulkan semua persyaratan dalam dokumen

template Persyaratan (RTD).
 Setelah semua persyaratan dikumpulkan dalam template persyaratan maka mereka
akan menandatangani persyaratan,
 Dokumen yang ditandatangani dikenal sebagai SRS (Spesifikasi kebutuhan perangkat
lunak/sistem) atau BRS (Spesifikasi kebutuhan bisnis) atau FRS (Spesifikasi kebutuhan
fungsional) atau BDD (Dokumen desain bisnis) atau BD (Dokumen bisnis).
 Setelah dokumen SRS di-baseline, BA bertanggung jawab atas POC (Proof of concept).
 Selama POC, BA bertanggung jawab untuk mengembangkan prototipe dan akan
dipresentasikan kepada klien.

Prototipe: Aplikasi sampel yang kasar dan berkembang pesat; itu tidak mengandung
fungsi yang sebenarnya. Ini hanya menjelaskan bagaimana proyek akan menjadi dan
bagaimana hal itu akan ditampilkan. Tujuan utama dari prototype adalah untuk
mengumpulkan semua persyaratan dengan baik dan memahami semua persyaratan
dengan baik.

 Engagement Manager bertanggung jawab untuk menjaga Rapport atau Relation antara
klien dan perusahaan. Dia juga akan berkonsentrasi pada persyaratan tambahan, biaya
tambahan dan waktu tambahan proyek.
 Manajer Proyek bertanggung jawab untuk memantau tahapan dan dia akan membantu
BA dan EM untuk menyelesaikan aktivitas mereka dengan baik.
Catatan: Hasil tahap requirement adalah SRS dan Prototype

2) Tahap Analisis: Menganalisis persyaratan .

Peran: Manajemen tingkat tinggi
Manajemen tingkat menengah
Manajer proyek
BA
  Semua peran di atas akan berkumpul untuk rapat dan mereka akan melakukan aktivitas
di bawah ini
a. Studi kelayakan
b. Pemilihan teknologi
c. Rencana sumber daya
d. rencana H&S
a. Studi Kelayakan : Layak berarti mungkin atau tidak. Peran di atas akan
mengambil setiap persyaratan dalam dokumen SRS. Persyaratan akan dianalisis
dan mereka akan mengidentifikasi apakah mungkin untuk dikembangkan atau
tidak, jika memungkinkan untuk dikembangkan maka mereka akan
mengidentifikasi berapa banyak waktu yang dibutuhkan untuk pengembangan,
menguji dan mengirimkannya ke klien. Jika ada persyaratan yang tidak layak
untuk dikembangkan maka mereka akan menginformasikannya kepada klien.
b. Pemilihan teknologi: Daftar teknologi seperti Java, .net, MSSQL, Oracle,
selenium, dll. diperlukan untuk pengembangan proyek, pengujian, dan
pengiriman ke klien akan dijelaskan di sini. Berdasarkan teknologi, mereka akan
menyewa sumber daya.
c. Rencana Sumber Daya: Jumlah sumber daya seperti pengembang, insinyur
pengujian, insinyur basis data diperlukan untuk pengembangan dan pengujian
proyek akan dijelaskan di sini.
d. Paket perangkat keras dan perangkat lunak: Jumlah perangkat keras seperti
desktop, laptop, ponsel, printer, dll...Dengan perangkat lunak terkait yang
diperlukan untuk proyek akan dijelaskan di sini.

 Semua hal di atas akan didokumentasikan dalam dokumen yang disebut rencana
proyek. Ini akan dikirim ke klien, untuk ditinjau.

3) Fase Desain:
Peran: Arsitek/kepala arsitek
Analis Bisnis (BA)
Manajer proyek

 Arsitek akan meninjau semua persyaratan Dokumen SRS, sambil meninjau jika
diperlukan klarifikasi pada persyaratan maka BA bertanggung jawab untuk menghapus
semua persyaratan yang tidak jelas.
  Setelah Arsitek jelas tentang semua persyaratan maka dia akan membagi persyaratan
menjadi beberapa modul dan sub modul. Kelompok persyaratan terkait dikenal sebagai '
Modul '.
 Setelah semua modul terbagi maka dia akan memberikan diagram arsitektural (flow
diagram) dari keseluruhan proyek dengan bantuan UML (unified modeling language)
 Semua hal di atas akan didokumentasikan dalam dokumen yang disebut Dokumen
Desain atau SRS.

4) Fase pengkodean:
Peran : Mengembangkan tim
Tim penguji
BA
Manajer proyek

 Setelah modul dibagi oleh arsitek, mereka akan ditugaskan ke pengembang serta tim
pengujian.
 Pengembang bertanggung jawab untuk mengembangkan kode sumber untuk modul.
Setelah kode sumber stabil maka mereka akan memasukkan kode sumber ke dalam
repositori pusat .
  Pemimpin pengembangan akan memeriksa kode sumber ke sistem lokalnya, kemudian
pemimpin pengembangan akan membuat kode sumber dan versi tersebut akan dirilis ke
tim pengujian untuk pengujian.

Repositori Pusat:

Repositori berarti folder penyimpanan. Repositori Pusat berarti folder yang biasanya dapat
diakses oleh semua sumber daya dalam organisasi. Ini berisi semua file aman.
Mis : SVN- Versi Sub
VSS- Sumber visual aman
TFS- Server Yayasan Tim
CVS- Sistem Versi Bersamaan
Perforce, Github
Lapor masuk : Proses pengunggahan file dari sistem lokal ke repositori pusat dikenal sebagai
Lapor masuk atau Komit .

Check out : Proses mengunduh file dari repositori pusat ke sistem lokal dikenal sebagai Check
out .

Build : Proses mengubah kode sumber menjadi kode yang dapat dieksekusi dikenal sebagai
Build .

5) Fase Pengujian:
Peran: Insinyur Uji
tim pengembang
Analis Bisnis (BA)
 Manajer proyek

 Setelah Dokumen SRS selesai (Selesai), itu akan dikirim ke tim pengembangan serta tim
pengujian.
 Tim Pengembang bertanggung jawab untuk meninjau dokumen SRS, memahaminya,
dan mengembangkan bangunan.
 Tim penguji juga bertanggung jawab untuk meninjau Dokumen SRS. Saat meninjau, jika
ada persyaratan yang tidak jelas (Keraguan) yang teridentifikasi, hal itu akan diperbarui
ke dalam dokumen yang disebut “ Laporan Tinjauan (RR) ”.
 Laporan tinjauan akan dikirim ke pimpinan tim di mana dia akan mengkonsolidasikan
(Membuat satu dokumen) semua laporan tinjauan ke satu dokumen yang disebut "
Laporan Tinjauan Terkonsolidasi (CRR)" dan akan dikirim ke BA.
 BA bertanggung jawab untuk Meninjau semua persyaratan yang tidak jelas dan dia akan
memberikan klarifikasi, kemudian “ Laporan Tinjauan yang Diperbarui (URR)” akan
dikirim ke tim pengujian
 Tim penguji akan kembali meninjau dokumen SRS dengan klarifikasi.
 Setelah tim pengujian sangat jelas tentang semua persyaratan, maka mereka akan
mengambil template kasus pengujian dan menulis kasus pengujian untuk semua
persyaratan.
 Dokumen test case akan dikirim ke BA. Dimana dia akan meninjaunya dan dia akan
memberikan komentar apakah ada test case baru yang perlu ditambahkan.
 Berdasarkan komentar BA, tim penguji akan memperbarui kasus uji.
 Setelah kasus uji selesai (diselesaikan), itu akan dikirim ke klien untuk tinjauan akhir.
 Setelah build dirilis ke tim pengujian, mereka akan mengeksekusi semua test case di
Build.
 Saat menguji build, jika ada Bug yang teridentifikasi akan dilaporkan (dikirim) ke tim
pengembangan. Pengembang akan memperbaikinya dan mengirimkannya kembali ke
tim pengujian untuk pengujian.
 Test Engineer akan menguji apakah bug tersebut benar-benar diperbaiki atau tidak dan
pada saat yang sama ia akan memeriksa bug lainnya.
 Jika teridentifikasi akan dilaporkan ke pengembang.
 Proses yang sama akan dilanjutkan sampai build stabil (Bug free atau No Bugs).
 Build stabil akan dikirimkan ke klien.
 6) Pengiriman dan Pemeliharaan :
Peran: Insinyur Uji
tim pengembang
Analis Bisnis (BA)
Manajer proyek
Klien

Pengiriman: Setelah build stabil di lingkungan pengujian, tim pengujian (TL) akan mengirim
email ke manajer proyek yang mengatakan bahwa build tersebut stabil, maka manajer proyek
akan mengirimkan build tersebut ke klien.

 Klien akan menerapkan lingkungan build in stage dan melakukan pengujian.

 Lingkungan panggung adalah lingkungan umum di mana tim pengujian dan tim klien
akan menguji aplikasi sebelum ditayangkan. Ini juga dikenal sebagai lingkungan pra-
produksi.
 Setelah Build stabil di lingkungan tahap, klien akan menerapkan build di lingkungan
langsung atau produksi.
 Setelah build berhasil diterapkan di lingkungan produksi/live, maka kami dapat
menyimpulkan bahwa proyek berhasil dikirimkan ke klien.
Pemeliharaan:
'Live' berarti di mana klien atau pengguna akhir menggunakan aplikasi. Pemeliharaan akan
dilanjutkan selama aplikasi hidup.

Fase Pemeliharaan TAT

Memperbaiki Bug,
Klien penyelesaian
Waktu CR
BA/PM/TL
3 Bug
(Peningkatan)
3 CR Perusahaan

12/24 Jam 3 Bug – 3 hari

3 RS – 4 hari

7 hari

 Setelah proyek berhasil dikirim ke klien dan berhasil diterapkan di lingkungan

live/produksi, maka pemeliharaan proyek akan dimulai.
 Selama pemeliharaan, perusahaan bertanggung jawab atas dua kegiatan.
a) Memperbaiki Bug.
b) Memperbarui peningkatan/Permintaan perubahan CR.
 Selama proyek hidup, pemeliharaan proyek akan dilanjutkan.
 Sesuai signoff (Perjanjian) awalnya perusahaan akan memberikan perawatan gratis
hingga 3 sampai 5 tahun (tergantung pada signoff proyek).
 Setelah periode pemeliharaan gratis selesai, klien akan memperbarui perjanjian
pemeliharaan.
  Setiap kali klien mengirim bug dan CRS apa pun, maka dari perusahaan seseorang
(Pengembang, BA, Penguji) harus mengirim email pemberitahuan kepada klien dalam
waktu TAT (Waktu penyelesaian) yang disepakati sesuai perjanjian, bisa jadi 12/24 jam.
 Surat berisi jumlah jam yang akan kami ambil untuk memperbaiki dan mengirimkan
bangunan baru ke klien.
 Selama proyek masih hidup, pemeliharaan proyek akan dilanjutkan

T. Jenis aplikasi apa yang telah Anda uji?

JENIS APLIKASI:

Ada tiga jenis aplikasi yang bisa diuji;

1) Aplikasi Web
2) Aplikasi Desktop
3) Aplikasi Seluler

1) APLIKASI WEB :

Aplikasi ini diakses dengan bantuan beberapa browser.

Ini terdiri dari dua jenis
a) Aplikasi arsitektur 3-Tier.
b) Aplikasi arsitektur N-Tier.

Lingkungan/Sistem :

Semua aplikasi adalah kombinasi dari lingkungan.

Lingkungan berisi:
1. Lapisan presentasi.
2. Lapisan bisnis.
3. Lapisan basis data.
LINGKUNGAN

APLIKASI
LAPISAN PRESENTASI/KLIEN

Respon permintaan
SERVER
LAPISAN BISNIS

Respon permintaan
BASIS DATA
LAPISAN DATABASE

1 . Lapisan presentasi:

Ujung depan yang akan diakses pengguna akhir dikenal sebagai lapisan
presentasi/klien.

2. Lapisan bisnis:

Ini adalah server yang bertanggung jawab untuk melayani permintaan tersebut.
Artinya akan mengambil permintaan dari aplikasi, mengirimkannya ke database,
mengambil respon dari database dan mengirimkannya kembali ke aplikasi.
Seluruh proses dikenal sebagai melayani permintaan.

Contoh: Tomacat, JBoss, Weblogic, WebSphere, IIS

3. Lapisan basis data:

Lapisan database bertanggung jawab untuk menyimpan data dalam bentuk

tabel.
Contoh : MS SQL, My SQL, ORACLE

a) Aplikasi arsitektur 3-Tier :

Dalam aplikasi arsitektur 3-tier, 3 Layer di atas tersedia dalam tiga mesin (Layer) yang
berbeda yang akan kita sebut sebagai tier. Oleh karena itu mereka disebut sebagai aplikasi
arsitektur 3 Tier.

Contoh: PL - Browser
Server - Tomacat
Basis Data - Oracle
b) N - Aplikasi arsitektur tingkat:

Sama seperti aplikasi arsitektur 3-tier berdasarkan jumlah pengguna (load), kita akan
memiliki lebih banyak server dan database.

Berdasarkan permintaan beban, logika bisnis akan didistribusikan di antara server dan DB.
Karenanya kami akan menyebutnya sebagai aplikasi lingkungan terdistribusi.

PL PL PL

Server Server Server

BL

DB DB DB

DBL

2) APLIKASI DESKTOP :

Aplikasi ini dapat diakses tanpa browser apapun.

Contoh: Skype, kalkulator, MS Office, pemutar vlc, dll.
Ini terdiri dari dua jenis:
 1 Tingkat
 2 Tingkat

 1 Tingkat :

Aplikasi ini terbatas pada sistem tertentu (PC). Semua 3 lapis PL, BL, dan DBL hanya akan
tersedia di sistem khusus tersebut.
Contoh: Pemutar VLC , Calc

 2 Tingkat :
 Lapisan presentasi akan tersedia di satu sistem, lapisan bisnis dan lapisan basis data akan
tersedia di sistem lain, dengan bantuan LAN/WAN kami dapat mengakses aplikasi ini dari
banyak sistem. Oleh karena itu kami akan menyebutnya sebagai aplikasi 2-Tier juga dikenal
sebagai aplikasi arsitektur client-server.
Contoh: Skype

CATATAN: Untuk Aplikasi Desktop kita perlu menginstal aplikasi di sisi pengguna/klien maka
hanya kita yang dapat mengaksesnya. Untuk melakukan pengujian untuk aplikasi desktop, kami
perlu melakukannya di klien maupun server.

Untuk aplikasi Web, kita perlu mengujinya di klien saja.

(BL)

Server + DBL

Aplikasi

LAN WAN LAN

M1 M2 M3
PL

3) APLIKASI SELULER :
Aplikasi yang dapat diakses pada platform seluler dikenal sebagai Aplikasi Seluler.
Contoh : Android, IOS, Blackberry, Windows dll.

Mereka terdiri dari tiga jenis

sebuah . Aplikasi Asli
b . Aplikasi Web
c . Aplikasi Hibrid

a. Aplikasi Asli:

Aplikasi ini dapat diakses tanpa browser apapun.

Mis : Viber, fungsionalitas panggilan, pesan, jam, dll.

b. Aplikasi Web :

Aplikasi ini dapat diakses dengan bantuan browser di ponsel.

Contoh : selenium4testing.com

c. Aplikasi Hibrida :

Aplikasi ini dapat diakses baik tanpa browser maupun dengan browser .
Mis: aplikasi Gmail/Gmail, aplikasi Facebook/Facebook, Situs Web/Aplikasi Perbankan, dll.

CATATAN: Aplikasi ForWeb tidak perlu menginstal aplikasi di sisi pengguna/klien karena kami
dapat mengakses dengan bantuan browser. Untuk melakukan pengujian aplikasi web, kami
hanya perlu melakukannya di klien.

METODOLOGI PENGUJIAN:

T: Siapa yang bertanggung jawab untuk pengujian. Pada level apa Test Engg.. akan terlibat
dalam pengujian

Mereka terdiri dari tiga jenis

A. Pengujian kotak hitam

B. Pengujian kotak putih
C. Pengujian kotak abu-abu

a. Pengujian kotak hitam :

Jika resource sedang melakukan pengujian pada bagian fungsional aplikasi maka dia
akan diperlakukan sebagai “ Black box tester ”.
Bagian fungsional berarti apakah aplikasi yang dikembangkan sesuai dengan kebutuhan klien
atau tidak. Penguji akan melakukan pengujian kotak hitam di lingkungan pengujian dan tahap
env (Pre production env)

B. Pengujian kotak putih:

Jika sumber daya menguji bagian struktural (pemrograman) aplikasi, maka dia akan
diperlakukan sebagai "penguji kotak putih ". Pengembang bertanggung jawab atas pengujian
kotak putih di lingkungan pengembangan.

C. Pengujian kotak abu-abu :

Jika sumber daya memiliki pengalaman di kedua pengujian (pengujian kotak putih dan
pengujian kotak hitam). Kemudian dia akan diperlakukan sebagai “ Penguji kotak abu-abu ”.

TINGKAT PENGUJIAN:
Jika satu proyek harus beralih dari tahap signoff ke live (produksi), itu harus menjalani tingkat
pengujian di bawah ini.

1) Pengujian tingkat unit

2) Pengujian tingkat modul
3) Tingkat integrasi pengujian
4) UAT (Pengujian penerimaan pengguna)
5) Pengujian sistem

1) Tingkat unit pengujian : Unit berarti aliran atau skenario terkecil dalam aplikasi.
 Pengembang bertanggung jawab atas pengujian tingkat Unit.
 Dia akan membagi modul yang ditugaskan ke beberapa unit dan
mengembangkan kode untuk semua unit.
 Dia bertanggung jawab untuk memeriksa apakah setiap unit bekerja seperti yang
diharapkan atau tidak.

2) Pengujian tingkat modul:

 Dari pengujian tingkat Modul, tim pengujian dan tim pengembangan
bertanggung jawab.
 Pengembang akan menggabungkan semua unit terkait untuk membentuk
modul.
  Setelah modul dikembangkan, pengembang bertanggung jawab atas pengujian
kotak putih di lingkungan pengembangan.
 Setelah modul dirilis ke tim pengujian, mereka bertanggung jawab atas
pengujian Black box di lingkungan pengujian.

3) Pengujian tingkat integrasi :

 Proses menggabungkan semua modul yang dikembangkan dikenal sebagai
integrasi .
 Periksa apakah aliran data bernavigasi dari satu modul ke modul lainnya dikenal
sebagai pengujian tingkat integrasi .
 Tim pengembangan dan tim pengujian bertanggung jawab atas pengujian
tingkat integrasi.
Mis : Buat satu akun di Gmail, periksa apakah Anda dapat masuk ke aplikasi
dengan akun yang dibuat. Kemudian tulis surat dan kirimkan, periksa apakah
sudah terkirim dengan benar atau tidak.
 Sedangkan integrasi jika ada modul wajib yang hilang maka Pimpinan
pengembangan akan mengganti modul wajib dengan beberapa kode dummy
yang dikenal sebagai rintisan atau driver.

D1 D2 D3 D4 D5
+ + + + +
Login Kredensial Menyusun Mengirim Keluar

Stub/Driver: Keduanya tidak lain adalah kode dummy, tidak mengandung fungsi
apa pun.

 Jika pemimpin pengembangan menggunakan pendekatan top down untuk

mengintegrasikan modul, sedangkan integrasi jika ada modul wajib yang hilang
maka akan diganti dengan Stub .
  Jika pemimpin pengembangan menggunakan pendekatan bottom up untuk
mengintegrasikan modul, sedangkan integrasi jika ada modul wajib yang hilang
maka dia akan menggantinya dengan Driver.

4) Pengujian Penerimaan Pengguna :

 Ini dikenal sebagai pengujian penerimaan pengguna/klien . Setelah build stabil di
lingkungan pengujian, kami akan mengirimkan build ke klien. Sebelum
mengirimkan build ke klien, klien akan mengirimkan kasus pengujian penerimaan
Pengguna ke tim pengujian untuk dieksekusi.
 Tim pengujian akan menjalankan semua kasus pengujian UA di lingkungan
pengujian; jika semua lulus maka manajer proyek akan mengirimkan build ke
klien.
 Klien kembali akan mengeksekusi semua kasus uji UA di lingkungan klien
(lingkungan panggung). Jika semua lulus maka klien akan menerapkan build di
lingkungan Live atau Production.
 UAT terdiri dari dua jenis:

A. Pengujian Alfa
B. Pengujian Beta UAT

Pengujian alfa Pengujian beta (UATCS)

(UATCs) Lingkungan pengujianStage Environment

 A. Pengujian Alfa: Menjalankan semua kasus pengujian UA di lingkungan pengujian oleh
tim pengujian dikenal sebagai ' pengujian Alfa' .

B. Pengujian Beta: Menjalankan semua kasus uji UA di lingkungan Tahap klien oleh tim
klien atau tim pengujian dikenal sebagai ' Pengujian Beta' .

Setelah pengujian Beta berlalu maka klien akan pergi ke lingkungan hidup.

Lingkungan Uji Klien

Build (UATCS) lulus

Membangun Tim Awal
Pengujian Mengantarkan

UATCS

5) Pengujian Sistem :
 Ini juga dikenal sebagai pengujian non-fungsional . Setelah aplikasi stabil, maka
kita dapat melakukan pengujian non-fungsional.
 Dalam pengujian non-fungsional, kinerja (waktu respons) aplikasi akan
diidentifikasi.
 Waktu yang diperlukan antara permintaan dan respons dikenal sebagai waktu
respons . Ini akan diidentifikasi dengan bantuan beberapa jenis pengujian non-
fungsional seperti pengujian beban, pengujian kinerja, pengujian stres, pengujian
titik putus.
MODEL PENGEMBANGAN PERANGKAT LUNAK:
T. Proses apa yang telah Anda gunakan untuk mengembangkan proyek Anda

Modelnya adalah sebagai berikut.

1) Model air terjun

2) Model spiral
3) Model-V
4) Model Ikan
5) Proses gesit

1) Model Air Terjun:

Itu adalah proses atau model awal yang diperkenalkan untuk pengembangan perangkat
lunak (proses lama). Eksekusi berurutan dari semua fase dalam SDLC dikenal sebagai
model air terjun. Setelah fase selesai, manajemen tingkat tinggi akan menganalisis fase
itu.

CATATAN: Bagaimana air terjun dari satu level ke level lainnya, dengan cara yang
sama fase SDLC akan diimplementasikan.

Keuntungan:

 Sangat mudah untuk mengimplementasikan proyek karena ini adalah Eksekusi

Berurutan.
 Kekurangan:

 Risiko tidak dapat diidentifikasi pada tahap awal siklus hidup sehingga tidak
dapat dicegah.
 Ini adalah proses yang memakan waktu serta proses yang mahal.
 Kami tidak dapat menerima perubahan persyaratan di tengah proyek. Jika masih
perlu diterima maka kami akan menerima perubahan persyaratan berupa
permintaan perubahan CR. Permintaan perubahan dilakukan pada akhir proyek
dan CR dibebankan oleh perusahaan.

bulan

2) Model Spiral:
  Model spiral merupakan gabungan antara model waterfall dan prototipe.

 Alih-alih mengumpulkan semua persyaratan sekaligus, BA mengumpulkan beberapa

persyaratan; itu akan dianalisis dan dirancang dengan bantuan prototipe. Kemudian
akan diberikan untuk pembangunan.
 Setelah pengembang mengembangkan build, build tersebut akan dirilis ke tim
pengujian. Proses yang sama akan dilanjutkan untuk semua persyaratan.
 Setelah semua persyaratan selesai dan build stabil, maka build akan dikirim ke klien.

Keuntungan:

 Kami dapat menghemat waktu dan biaya, karena kami menjalankan semua fase
secara paralel.
 Risiko dapat diidentifikasi pada tahap awal SDLC dan dapat dicegah pada tahap awal
siklus hidup.
 Perubahan persyaratan dapat diterima di tengah proses.

Kekurangan:

 Itu memiliki risiko pengiriman yang sangat besar, karena garis waktu yang agresif
(lebih sedikit waktu).
 Tidak dapat menerima perubahan persyaratan pada tahap akhir proyek untuk
menghindari risiko pengiriman.
 3) V-Model (model Verifikasi dan Validasi):
Validasi :

Ini juga dikenal sebagai " QC" (Kontrol kualitas ). Tim penguji bertanggung jawab untuk
validasi. Tim pengujian akan memeriksa apakah perangkat lunak yang dikembangkan
sesuai dengan kebutuhan klien atau tidak.

Insinyur penguji adalah validator.

Verifikasi :

Def1: Periksa apakah setiap dokumen hasil fase sesuai dengan pedoman perusahaan
dan klien atau tidak.

Def2 : Periksa apakah setiap peran dalam organisasi berfungsi sesuai

Garis panduan perusahaan dan klien atau tidak. Verifikasi juga dikenal sebagai QA
(Jaminan kualitas).

Grup manajemen proyek/Proses (PMG) atau grup audit bertanggung jawab untuk verifikasi.

 Mulai dari V-model dan seterusnya, bahkan tim penguji akan berpartisipasi dalam
mengumpulkan persyaratan.
 BA bertanggung jawab untuk mengumpulkan persyaratan, secara paralel tim
pengujian akan menganalisis semua persyaratan untuk memeriksa apakah mungkin
untuk menguji atau tidak.
 Setelah SRS ditetapkan, tim validasi bertanggung jawab atas rencana pengujian
 Berdasarkan tahap analisis dan desain, tim validasi menyusun rencana pengujian
sistem dan rencana desain.
 Setelah kode dikembangkan, mereka akan merilis build ke tim pengujian tempat
mereka akan melakukan semua level pengujian. Setelah build stabil, itu akan
dikirimkan ke klien.

Keuntungan:
  Kegiatan pengujian dimulai dari tahap persyaratan dan seterusnya sehingga kami
dapat memastikan kualitasnya.
 Untuk setiap tahapan tim verifikasi dan tim validasi akan melakukan pengecekan
tahapan agar kami dapat memastikan kualitasnya.
 Risikonya bisa teridentifikasi sejak dini karena kami memiliki aktivitas pengujian
paralel, sehingga bisa dicegah.
 Kami dapat menerima perubahan persyaratan di tengah fase.

Kekurangan:

 Ini adalah proses yang memakan waktu dan mahal, tetapi kami dapat memastikan
kualitasnya.

4) Model ikan:

 Ini sama seperti v-model.

 Dalam model ikan kami akan memiliki beberapa tim Verifikasi dari klien dan
perusahaan untuk memeriksa proses dan untuk memberikan kualitas dan keamanan
yang lebih baik.
 Itu lebih mahal daripada v-model.
 Ini memberikan keamanan lebih dan diterapkan dalam proyek keamanan tingkat
tinggi seperti NASA, Angkatan Udara, Angkatan Laut, Angkatan Darat dll.
 Catatan: Tim validasi akan meninjau hasil kasus pengujian unit saat build sedang
dalam pengembangan

5) Proses tangkas:

 Itu memiliki beberapa sub model seperti adaptif, Scrum, model iteratif dll… Model
yang akan kita gunakan adalah model scrum.
 Ini adalah model iteratif dan inkremental. Model scrum memiliki aktivitas di bawah
ini.
a. Ahli scrum
b. Cerita pengguna
c. Rapat scrum/panggilan scrum/DSM
d. Rencana sprint
e. Pertemuan lari cepat
f. Backlog

a. Ketua scrum:

Master scrum adalah, siapa yang akan memimpin proyek. Manajer proyek atau klien
akan bertindak sebagai master scrum. Scrum master bertanggung jawab atas rapat
scrum dan rapat sprint.
b. Cerita pengguna:

Persyaratan akan ditangkap dalam bentuk aliran yang digunakan pengguna akhir (end
user usedways). Karenanya kami akan menyebutnya sebagai cerita Pengguna . BA
bertanggung jawab untuk mengumpulkan

c. Rapat scrum:

 Setiap hari semua anggota tim akan berpartisipasi dalam pertemuan cepat di
mana mereka akan menjelaskan kegiatan apa yang dilakukan kemarin dan tugas
apa yang direncanakan untuk dilakukan hari ini dan apakah ada tantangan.
 Semua anggota tim termasuk master scrum dan klien harus menjelaskan.
 Tujuan utama dari pertemuan scrum adalah untuk melacak sumber daya dan
juga untuk menjaga transparansi.

d. Rencana sprint:

 Sprint adalah periode waktu tetap bisa satu minggu / dua minggu / tiga minggu
dll. Ini akan diputuskan oleh master scrum.
 Rencana sprint adalah, untuk mengumpulkan cerita pengguna, menganalisis,
mengembangkan, menguji, dan mengirimkannya ke klien.
 Selama sprint jika kami tidak dapat menyelesaikan persyaratan apa pun, sprint
tidak akan diperpanjang. Dan persyaratan yang tertunda harus dibawa ke sprint
berikutnya. Sprint adalah periode waktu yang tetap

e. Pertemuan sprint:

Setelah sprint selesai, rencana sprint berikutnya akan diputuskan di bawah rapat sprint.
Mereka akan berdiskusi, apakah sprint kali ini berhasil atau tidak, apakah ada tantangan
yang dihadapi.

f. Backlog:

Selama rencana sprint, jika ada cerita pengguna yang tidak dapat diselesaikan, itu akan
dianggap sebagai Backlog. Backlog ini harus diselesaikan pada sprint berikutnya.

Ini terdiri dari dua jenis,

(i) Jaminan Produk

(ii) Sprint backlog
 Product Backlog: Persyaratan (cerita pengguna) yang akan kami kumpulkan,
kembangkan, uji, dan kirimkan ke klien sebagai bagian dari rencana sprint
dikenal sebagai backlog produk.
Sprint Backlog : Persyaratan yang tidak diselesaikan sebagai bagian dari rencana
sprint akan diperlakukan sebagai sprint backlog.

Keuntungan :

 Setiap sprint akan diuji berkali-kali oleh tim pengujian dan klien, sehingga kami dapat
memastikan kualitasnya.
 Semua tahapan dalam SDLC dilakukan secara paralel sehingga dapat menghemat waktu
dan biaya.
 Perubahan persyaratan dapat diterima pada setiap tahap proyek (bahkan setelah
pengiriman sprint).
 Risiko dapat diidentifikasi sejak dini dan dapat dicegah
 Kami dapat menjaga transparansi proyek.
 Klien juga akan berpartisipasi dalam rapat scrum, sehingga kami dapat memperoleh
informasi dengan sangat cepat.
 Setiap sprint dikirimkan ke klien sehingga kami tidak memiliki risiko pengiriman.
 Kami dapat memperoleh kepuasan pelanggan dengan mengirimkan semua sprint ke
klien.
 Sprint juga dikenal sebagai iteratif. Modelnya dan iteratif dan inkremental
Kekurangan:

Mempertahankan semua informasi terkait sprint adalah tugas yang sangat menantang, tetapi
kita dapat mengatasinya dengan bantuan alat manajemen pengujian seperti Scrumwise, Quality
center, JIRA dan test link dll.

Jenis pengujian fungsional (atau) Jenis pengujian kotak hitam :

1) Pengujian asap :

 Setelah build dikembangkan dan diterapkan di lingkungan mana pun, pengujian awal
akan dilakukan, yang dikenal sebagai pengujian asap. Awalnya, tim pengembangan akan
menggunakan lingkungan pengembangan yang dibangun, dan melakukan uji asap.
Mereka akan memeriksa setiap bidang terkait modul apakah menavigasi halaman
mereka dengan benar atau tidak dan memeriksa fungsionalitas utama aplikasi. Tujuan
dari uji asap adalah untuk memeriksa apakah bangunan siap untuk pengujian lebih
lanjut atau tidak. Pengembang akan berkonsentrasi pada pengujian kotak putih
 Jika semua kolom ini dinavigasi dengan benar ke halaman terkait, maka mereka akan
menyimpulkan bahwa uji asap telah lulus.

2) Tes kewarasan:
 Setelah build diterapkan di lingkungan pengujian, tim pengujian akan melakukan
pengujian asap di lingkungan pengujian. Ini dikenal sebagai tes kewarasan.
 Dalam uji kewarasan, tim penguji akan melakukan setidaknya satu putaran fungsi aliran
utama dan memeriksa apakah berfungsi dengan baik atau tidak.
 Jika uji kewarasan lulus maka tim pengujian akan mengeksekusi semua kasus uji jika
gagal mereka akan menolak build ke tim pengembangan.

Contoh untuk aliran Utama: Buat akun di Gmail dan masuk ke akun itu dan tulis email
dan kirimkan ke satu email yang valid dan periksa apakah sudah terkirim dengan benar
atau tidak.

Catatan: Setelah uji kewarasan dilakukan, tim penguji (pemimpin uji) harus mengirim email
dengan hasil uji kewarasan ke tim pengembangan.

3) Pra pengujian SRN : SRN - Catatan Rilis Perangkat Lunak

  Ini berisi status build seperti, jumlah modul yang tersedia dalam build untuk pengujian.
 Jumlah modul yang sedang dikembangkan.
 Jumlah stub dan driver tersedia di build.
 Jumlah bug yang diperbaiki dan tersedia di build.
 Jumlah bug yang sedang dikembangkan
 Pedoman penyebaran dll.

 Sebelum merilis dokumen SRN beserta buildnya kepada tim pengujian, tim
pengujian akan melakukan uji asap di lingkungan pengembangan, yang dikenal
dengan Pre-SRN Testing
 Ini juga dikenal sebagai pengujian penerimaan Build (BAT) atau pengujian verifikasi
Build (BVT).

Catatan: Setelah build dirilis ke tim pengujian, test engg's akan meninjau dokumen SRN untuk
mengetahui status build (isi build apa). Kemudian pengujian akan melakukan uji kewarasan.

2. Urutan awalnya tim Dev akan melakukan pengujian Smoke, kemudian tim pengujian akan
melakukan pengujian Pre-SRN di Dev Env. Jika keduanya lolos maka tim Dev akan merilis build
tersebut ke tim testing kemudian pihak testing akan melakukan sanity testing

4) Pengujian GUI/UI :
Antarmuka pengguna grafis/pengujian antarmuka pengguna. Lima aktivitas di bawah ini akan
diuji dalam GUI.
  Periksa ejaan semua bidang.
 Periksa font semua bidang di mana harus menjaga konsistensi.
 Periksa warna dan keberpihakan semua bidang yang harus dijaga konsistensinya.
 Periksa keseluruhan tampilan dan nuansa halaman

5) Pengujian regresi :

Melakukan pengujian pada fungsionalitas yang sudah diuji pada build iteratif dan inkremental
dikenal sebagai ' Pengujian Regresi' .

Ini akan dilakukan dengan dua cara:

 Setiap kali ada bug yang teridentifikasi, itu akan dilaporkan ke pengembang, pengembang
akan memperbaikinya kemudian dia akan merilis bug yang diperbaiki dalam bentuk build
baru (Build2) ke tim pengujian. Insinyur penguji akan menguji lagi, untuk memeriksa apakah
bug benar-benar diperbaiki atau tidak.
 Test case yang diteruskan pada build lama akan dieksekusi lagi pada build baru dan
memeriksa apakah ini berfungsi sama seperti sebelumnya atau tidak.

Pengujian fungsionalitas yang sudah diuji adalah pengujian regresi. Menguji fungsionalitas
baru bukanlah pengujian regresi. Itu datang di bawah eksekusi kasus uji.

Catatan: Jika ada pembaruan kode, maka kode baru itu dapat memengaruhi kode yang
ada, jadi kami melakukan pengujian regresi.
 6) Pengujian ulang:

 Melakukan pengujian pada fungsionalitas yang sama berulang kali dengan beberapa
kumpulan data pengujian yang berbeda pada build yang sama dikenal sebagai '
Pengujian Ulang '.
 Mengeksekusi kasus pengujian yang gagal pada build iteratif dan inkremental juga
dikenal sebagai "Pengujian ulang".

Data uji: Data yang digunakan tim penguji untuk pengujian dikenal sebagai “ Data uji ”.

Mantan: 1. Uji fungsionalitas login Gmail dengan beberapa set yang berbeda
kredensial.

2. Uji pencarian satu arah spicejet dengan beberapa set asal yang berbeda dan
penumpang yang berbeda.

T: Apa perbedaan antara Pengujian Regresi dan Pengujian Ulang

T: Apa perbedaan antara Pengujian Regresi dan Pengujian Tingkat Integrasi

7) Pengujian Ujung ke Ujung:

Insinyur penguji harus mengidentifikasi semua skenario aplikasi yang digunakan pengguna
akhir, dan memeriksa apakah Skenario Ujung ke Ujung berfungsi dengan benar atau tidak

Dengan melakukan pengujian End To End kita dapat mencapai pengujian tingkat Integrasi

Mis : Skenario ujung ke ujung untuk Gmail.

 8) Pengujian Kompatibilitas :

 Menguji apakah aplikasi berfungsi sama seperti yang diharapkan di semua lingkungan
yang ditargetkan atau tidak dikenal sebagai ' pengujian kompatibilitas '. Lingkungan
adalah kombinasi dari OS, Browser, Server, DB dll.
 Pengujian kompatibilitas adalah dua jenis ' pengujian lintas browser' dan ' pengujian
lintas platform' .
 Menguji apakah aplikasi web berfungsi seperti yang diharapkan di semua browser yang
ditargetkan seperti firefox,safari,google chrome,IE dll. Dikenal sebagai ' pengujian lintas
browser'.
 Menguji apakah aplikasi desktop berfungsi seperti yang diharapkan di berbagai platform
atau sistem operasi seperti windows,LINUX,MAC,Solaris, dll. Dikenal sebagai ' pengujian
lintas platform'.

Contoh untuk pengujian lintas browser: Uji apakah spicejet berfungsi di lingkungan di bawah ini
atau tidak.

Windows – Penjelajah internet, Firefox, Google chrome, Safari, Opera

Linux - Penjelajah internet, Firefox, Google chrome, Safari, Opera

MAC - Firefox, Google chrome, Safari, Opera

Contoh untuk pengujian lintas platform: Uji apakah skype berfungsi di platform atau lingkungan
di bawah ini
 Windows
Linux
MAC dan Seluler

Catatan: Setiap kali kami melakukan pengujian kompatibilitas, kami perlu lebih
berkonsentrasi pada GUI aplikasi

9) Pengujian kegunaan:

 Kegunaan berarti keramahan pengguna. Insinyur penguji harus memberikan kegunaan

pada aplikasi untuk kepuasan pengguna akhir.
 Tergantung pada aplikasi kita harus menyediakan kegunaan.

Mis: Untuk aplikasi Perbankan (aman) kami harus memberikan keamanan lebih sedangkan
untuk situs sosial (Facebook, twitter) , kami perlu memberikan lebih banyak keramahan
pengguna.

10) Pengujian Adhoc :

 Adhoc berarti dengan cara kita sendiri.

 Pengujian adhoc berarti menguji aplikasi dengan cara Anda sendiri, Setelah memahami
semua persyaratan dan setidaknya satu putaran pengujian manual selesai pada aplikasi
 Tujuan utama pengujian adhoc adalah untuk memberikan kegunaan pada aplikasi.
11) Pengujian Eksplorasi:

 Eksplorasi berarti mengidentifikasi kebutuhan baru / Fitur baru. Setelah build stabil,
pakar domain akan menguji aplikasi sesuai pengetahuan domain mereka, sambil
menguji mereka akan mengeksplorasi apakah persyaratan yang ada sudah mencukupi,
jika tidak, mereka akan memberikan persyaratan baru.
 Tujuan utama pengujian eksplorasi adalah untuk memberikan kegunaan dan keamanan
pada aplikasi.

12) Pengujian monyet/pengujian gorila :

 Setelah aplikasi stabil maka kita dapat melakukan pengujian monyet.

 Melakukan pengujian pada aplikasi dengan melakukan beberapa tindakan abnormal
yang dikenal dengan pengujian Monkey/Gorilla .
 Tindakan abnormal berarti terus mengklik beberapa bidang untuk jangka waktu yang
lama dan memeriksa apakah aplikasi mogok atau tidak.
 Uji aplikasi dengan data yang tidak valid seperti tag HTML (<html>) dan periksa apakah
aplikasi mogok atau tidak.
Catatan : Tujuan dari pengujian monyet adalah untuk memeriksa apakah aplikasi mogok
atau tidak (Berarti akan mendapatkan pengecualian server tidak ditemukan)

13) Pengujian statis:

 Menguji aplikasi tanpa melakukan tindakan apapun dikenal sebagai pengujian

statis .

Contoh: 1. pengujian GUI

2. Validasi: - memeriksa ketersediaan bidang di halaman dilakukan pengujian
statis.

14) Pengujian Dinamis :

 Menguji aplikasi dengan melakukan beberapa tindakan dikenal sebagai pengujian

dinamis .
Contoh: Pengujian regresi, Pengujian ulang, pengujian Adhoc, dll…

15) Pengujian autentikasi:

 Otentikasi berarti memeriksa apakah kredensial/data yang diamankan tersedia di

database atau tidak.
 Pengujian otentikasi berarti menguji aplikasi dengan beberapa set data yang valid
dan tidak valid, untuk data yang valid itu harus menampilkan beranda, sedangkan
untuk data yang tidak valid, itu harus menampilkan pesan otentikasi yang tepat
(pesan kesalahan).

Contoh: Menguji fungsionalitas login HMS dengan beberapa kumpulan kredensial yang valid
dan tidak valid. Itu harus mengotentikasi aplikasi dengan benar.

16) Pengujian URL langsung:

 Masuk ke halaman aman dan ambil URL halaman aman dan akses URL itu di browser
baru. Dimana seharusnya tidak dapat diakses jika dapat diakses maka aplikasi
tersebut tidak diamankan.

Mis: Masuk ke Gmail.com, salin URL beranda. Buka di browser baru dan akses URL secara
langsung, di tempat yang seharusnya tidak dapat diakses.

17) Pengujian Kebocoran Firewall :

 Masuk ke aplikasi sebagai satu tingkat pengguna dan coba akses data di luar batasan
peran Anda. Jika dapat diakses maka kami menyimpulkan bahwa aplikasi tidak
berfungsi sesuai peran (Ini mengalami kebocoran firewall).

Contoh: Login ke aplikasi HMS sebagai Jr. Dokter dan coba akses data Sr. Dokter,
di mana seharusnya tidak dapat diakses
 18) Pengujian Basis Data:

 Menguji apakah data dimasukkan dengan benar ke dalam database dari semua tabel
atau tidak dikenal sebagai pengujian database . Dengan bantuan kueri SQL, kami
dapat melakukan pengujian DB.

Mis: Setiap kali kami membuat pendaftaran permanen di HMS, semua detail pasien
akan disimpan di database HMS, sebagai teknisi penguji kami harus masuk ke
database dan memeriksa apakah data sudah dimasukkan dengan benar di semua
tabel atau tidak.

Deployment Testing/Installation Testing : Tim deployment atau Test lead

akan men-deploy build di beberapa lingkungan seperti dev, testing, stage1,stage2,
produksi dll dan memeriksa apakah sudah di-deploy dengan benar atau tidak

T: Setelah build dirilis, bagaimana Anda akan menguji build tersebut

A: Awalnya kami akan melakukan pengujian kewarasan, jika lulus maka kami akan
mengeksekusi semua kasus pengujian kemudian akan melakukan semua jenis pengujian
fungsional seperti di bawah ini. Dengan melakukan semua pengujian di bawah ini maka kami
dapat memastikan kualitas aplikasi
Jenis Pengujian Fungsional – Alur eksekusi pengujian fungsi pada Build, setelah dirilis ke tim
pengujian

Catatan: Untuk aplikasi apa pun, semua pengujian di atas akan dilakukan untuk
memastikan, apakah aplikasi tersebut memenuhi persyaratan klien, kualitas dan
bermanfaat bagi pengguna akhir atau tidak.

2. Jika ini adalah aplikasi teratas desktop, Pengujian URL Langsung dan pengujian lintas
browser tidak dapat dilakukan.

Templat Laporan Tinjauan :

Tinjau dokumen SRS jet rempah-rempah dan berikan laporan tinjauan dalam templat di bawah
ini.

Persyaratan ID Persyaratan Komentar oleh Komentar TE

Keterangan
7. Drop dewasa, anak dan bayi 1. Apa perbedaan antara

Turun harus tersedia. Anak, dewasa dan bayi

2. Apa yang menghargai bidang dewasa, anak, bayi?

19) Pengujian globalisasi:

Ini adalah dua jenis

A. Pengujian lokalisasi.

B. Pengujian internasionalisasi.

A. Pengujian lokalisasi:

 Menguji aplikasi dalam semua bahasa lokal yang selektif untuk negara
kita seperti Hindi, Bengali, Telugu, dll. Dikenal sebagai pengujian
lokalisasi .
 Ini mendukung maksimal 10 bahasa untuk integrasi tunggal. Karenanya
kami akan menyebutnya sebagai pengujian 'L10N' .

Contoh : 1. Uji Google.co.in dalam semua bahasa lokal seperti Hindi, Bengali,
Telugu dll…

2. Uji mesin ATM dalam bahasa lokal seperti Hindi, Telugu, dan Inggris.

B. Pengujian internasionalisasi:

 Menguji aplikasi dalam semua bahasa internasional seperti Jepang, Cina,

dan Spanyol, dll. Dikenal sebagai pengujian internasionalisasi . Ini
mendukung maksimal 18 bahasa untuk satu integrasi. Karenanya kami
akan menyebutnya sebagai pengujian 'I18N' .

Mis: Uji Gmail.com dalam semua bahasa internasional seperti, Jepang,

Spanyol, dan China dll…

SIKLUS HIDUP PENGUJIAN PERANGKAT LUNAK:

Ini berisi fase-fase di bawah ini:

1) Rencana pengujian perangkat lunak.

2) Desain uji perangkat lunak.
 3) Eksekusi Tes.
4) Analisis hasil.
5) Pelaporan & BLC.
6) Pengiriman dan pemeliharaan.
7) Laporan ringkasan tes/ Buat laporan postmortem.

1. Rencana pengujian perangkat lunak:

 Rencana adalah dokumen strategis yang menjelaskan bagaimana melakukan tugas
dengan cara yang efektif dan efisien.
 Rencana pengujian perangkat lunak juga merupakan dokumen strategis yang
menjelaskan cara melakukan pengujian dengan cara yang efektif dan efisien. Rencana
pengujian akan disiapkan oleh pemimpin pengujian; setelah disiapkan, itu akan dikirim
ke tim pengujian untuk ditinjau.
 Berdasarkan rencana pengujian kami bertanggung jawab untuk melakukan pengujian.
 Ini berisi kegiatan atau Indeks di bawah ini.

Indeks rencana pengujian

1. Objektif

1.1 Lingkup pengujian

2. Dokumen referensi

3. Item Uji

3.1 Fitur yang akan diuji

3.2 Fitur yang tidak diuji

4. Uji strategi

4.1 Jenis pengujian

4.1.1 Jenis pengujian fungsional

5. Uji lingkungan

6. Tes kriteria lulus/Gagal

7. Analisis dan penutupan cacat

8. Uji Kiriman

9. Pengujian otomasi

10. Risiko dan kontinjensi

11. Persyaratan perangkat keras dan perangkat lunak

12. Rencana sumber daya

13. Uji laporan ringkasan/ Buat laporan postmortem.

1. Tujuan:

Tujuan utama dari rencana pengujian akan dijelaskan di sini. Ini berisi ruang lingkup pengujian.

1.1 Lingkup pengujian:

Jenis pengujian apa yang menjadi tanggung jawab tim pengujian untuk menguji aplikasi
dikenal sebagai ruang lingkup pengujian.

Mis : Tim pengujian bertanggung jawab atas pengujian manual dan otomasi untuk
proyek.

2. Dokumen Referensi:

Daftar dokumen yang digunakan oleh test lead untuk menyiapkan rencana pengujian akan
dijelaskan di sini.

Pimpinan uji akan menggunakan dokumen SRS untuk menyiapkan rencana uji.

3. Item Tes:

3.1 Fitur yang akan diuji:

Daftar fungsionalitas atau modul yang menjadi tanggung jawab tim, akan dijelaskan di
sini dan juga daftar pengujian yang dilakukan tim pengujian pada modul akan dijelaskan
di sini.

Mis : Tim penguji bertanggung jawab untuk Memesan Penerbangan, Memesan hotel,
dan mengelola pemesanan saya.

Untuk modul di atas, mereka bertanggung jawab atas pengujian dan otomasi manual.

3.2 Fitur yang tidak diuji:

 Daftar modul dan pengujian yang bukan tanggung jawab tim pengujian akan dijelaskan
di sini.

Mis: Tim pengujian tidak bertanggung jawab atas modul pembayaran dan juga tidak
bertanggung jawab atas pengujian kinerja, pengujian beban, pengujian Stres.

4. Uji strategi:

Strategi berarti daftar langkah-langkah yang akan kita ambil untuk mencapai rencana tersebut.

 Strategi pengujian berarti daftar jenis pengujian fungsional. Yang akan diambil oleh tim
pengujian untuk melakukan pengujian dikenal sebagai strategi pengujian.
 Kami akan melakukan semua jenis pengujian fungsional seperti regresi, pengujian ulang,
dll… pada aplikasi
 Singkatnya, rencana berarti apa yang harus dilakukan. Strategi berarti bagaimana
mencapai rencana.

5. Lingkungan Uji:

Lingkungan berarti sistem yang akan kita gunakan untuk menyebarkan build dan untuk
menguji aplikasi dikenal sebagai lingkungan pengujian.

Mis: Jenis mesin: Perusahaan server Windows

OS : Windows
Prosesor : CPU Intel Xeon
Memori: 4GB/2,13 GHZ
Hardisk : 150GB
Basis data: Microsoft SQL server 2008 edisi standar
Server web: IIS 7.0
Klien : Microsoft internet explorer, Firefox, Google chrome

6. Ujian gagal/kriteria:

Jika ada test case yang menyimpang dari hasil yang diharapkan maka akan dianggap
sebagai kegagalan atau bug.

Setiap bug memiliki kriteria atau jenis bug.

Itu terdiri dari lima jenis

A. Pemblokir
B. Sangat tinggi
C. Tinggi
D. Sedang
 e. Rendah

7. Penutupan Analisis Cacat:

Pada saat pengiriman build jika ada bug/cacat yang tersedia, itu akan dianalisis oleh tim
pengujian dengan manajer proyek. Jika ada bug yang tidak perlu diperbaiki maka akan ditutup.

8. Hasil Uji:

Daftar modul yang akan kami kirimkan ke klien dikenal sebagai pengiriman s.

Semua modul akan dibagi menjadi beberapa fase dan pimpinan juga akan memberikan tenggat
waktu yang ditargetkan (tanggal pengiriman).

Garis Mati (Tanggal

Fase No Modul Pengiriman)

1. BookaFlight
2. Atur Pemesanan Saya
1 3. Status PNR 30 Juni

2 4. Jadwal Penerbangan 31 Juli

5. Manfaat Perusahaan

3 6. Bumbu sambung 30 September

9. Pengujian otomasi:

Jumlah modul yang akan diotomatisasi oleh tim pengujian akan dijelaskan di sini dan juga alat
dan strategi otomasi yang akan diikuti oleh teknisi pengujian akan dijelaskan di sini.

10. Risiko dan kontinjensi:

Daftar risiko yang akan dihadapi tim saat melaksanakan proyek dan juga dengan solusi terkait
akan dijelaskan di sini.

Risiko Kontinjensi
Pertahankan sumber daya
Kekurangan sumber daya penyangga

Perubahan Persyaratan Berkelanjutan Menganalisis persyaratan

Kurangnya peer review Pantau ulasan rekan

11. Persyaratan Perangkat Keras & Perangkat Lunak:

Jumlah mesin seperti laptop, ponsel, printer, dll… yang diperlukan untuk pengujian dengan
perangkat lunak terkait akan dijelaskan di sini.

12. Rencana Sumber Daya:

Jumlah sumber daya yang diperlukan untuk pengujian manual, pengujian otomasi, pengujian
basis data akan dijelaskan di sini.

13. Uji ringkasan laporan/Bangun laporan postmortem:

Setelah pengujian selesai, pimpinan pengujian harus menyiapkan laporan ringkasan pengujian,
yang berisi ringkasan pengujian.

2) Desain Uji Perangkat Lunak:

 Proses penulisan test case pada template test case setelah memahami semua persyaratan
dikenal dengan istilah ' software test design' .

 Setiap organisasi akan memiliki template sendiri berdasarkan template tersebut;

insinyur uji bertanggung jawab untuk menulis kasus uji.
 Kami memiliki templat di bawah ini untuk menulis kasus uji. Ini berisi CoverSheet, Test
case, Testdata, Traceability matrix dan Test Report

Memerlukan- prioritas TC Tes Pra- Tes Sebena Menghar Hasil Komentar

Tes PENG skenari produksi jenis rnya apkan
Jenis ENAL o Hasil Hasil

PENGENAL

Sampul:

Nama modul :

Jumlah tidak. kasus uji:

Jumlah kasus uji P1 :

Jumlah kasus uji P2 :

Jumlah kasus uji P3 :

Jumlah kasus uji P4 :

ID Persyaratan: Nomor persyaratan untuk kasus uji yang kami tulis akan dijelaskan di sini.

Jenis uji : Jenis kasus uji dikenal sebagai jenis uji. Itu terdiri dari lima jenis.

 GUI
 Validasi
 Kasus uji positif (atau) Kasus uji positif fungsional.
 Kasus uji negatif (atau) Kasus uji negatif fungsional
 Kasus uji basis data

Kasus uji positif: Uji aplikasi dengan semua data yang valid dikenal sebagai kasus uji
positif.
 Kasus uji negatif: Menguji aplikasi dengan setidaknya satu data tidak valid dikenal
sebagai kasus uji negatif.

Prioritas: Ini menjelaskan betapa pentingnya test case. Jenisnya di bawah ini: P1, P2, P3 dan P4.

P1: Jika kasus uji menggambarkan fungsionalitas utama dari aplikasi/modul maka akan
diperlakukan sebagai P1.

Fungsi utama berarti jika test case gagal kita tidak dapat melanjutkan pengujian
lebih lanjut, sehingga prioritasnya adalah 'P1'.

P2: Jika kasus uji menggambarkan fungsionalitas tingkat lapangan maka prioritasnya
adalah 'p2'.

Kasus uji tingkat lapangan berarti, jika gagal, kami dapat melanjutkan pengujian
tetapi penting untuk ada di aplikasi sesuai kebutuhan klien.

P3: Semua kasus uji GUI berada di bawah prioritas P3.

P4: Insinyur penguji memiliki opsi untuk memberikan saran ke aplikasi. Saran tersebut
akan ditangkap dalam bentuk test case dan kemudian prioritasnya adalah 'P4'.

ID kasus uji : Nomor seri kasus uji akan dijelaskan di sini.

Skenario Uji: Skenario berarti alur atau cara yang digunakan pengguna akhir. Persyaratan akan
dibagi menjadi semua alur atau skenario yang digunakan pengguna akhir dan akan dijelaskan di
sini. Tes engg harus mengidentifikasi aliran maksimum yang mungkin (Skenario) untuk
persyaratan atau cerita pengguna

Prasyarat: Kondisi yang diperlukan untuk menguji skenario akan dijelaskan di sini.

Langkah-Langkah Pengujian: Daftar langkah-langkah yang diperlukan untuk menjalankan

skenario akan dijelaskan di sini. Berdasarkan langkah-langkah pengujian, pengujian engg akan
dijalankan pada aplikasi atau build

Hasil yang Diharapkan: Pada saat penulisan test case, kami tidak akan membawa aplikasinya.
Jadi kami akan mengharapkan hasil untuk skenario. Hasil yang diharapkan itu akan diperbarui di
kolom hasil yang diharapkan.

Hasil Aktual: Ini akan diperbarui pada saat menjalankan kasus pengujian. Insinyur pengujian
akan mengamati perilaku sebenarnya dari aplikasi untuk skenario tersebut dan akan diperbarui
di sini.
Hasil : Setelah eksekusi tes selesai, insinyur tes akan membandingkan hasil aktual dengan hasil
yang diharapkan, jika keduanya cocok maka dia akan memperbarui hasilnya sebagai lulus, jika
tidak dia akan memperbaruinya sebagai gagal.

Komentar: BA atau klien akan memberikan komentar di sini.

Rujuk Dokumen TC login Gmail

Teknik desain uji:

Untuk melakukan pengujian dengan cara yang efektif dan efisien, kita perlu mengikuti
teknik desain pengujian di bawah ini.

1. Analisis Nilai Batas (BVA)

2. Partisi kelas kesetaraan (ECP)

3. Kesalahan Menebak

1. Analisis Nilai Batas (BVA):

Setiap kali kita memiliki persyaratan untuk menguji kisaran seperti 1 hingga 100 atau 1
hingga 1000 atau 1 hingga 1 kekurangan atau 1 kekurangan hingga 2 kekurangan maka
tidak mungkin untuk melakukan pengujian lengkap (pengujian lengkap). Jadi kita perlu
menerapkan teknik BVA.

 Bagi rentang ke beberapa batas seperti min-1, min, min+1, tengah, maks-1,
maks, dan maks+1.
 Untuk melakukan pengujian positif, uji lapangan dengan min, min+1, tengah,
maks-1, dan maks. Di mana ia harus menerima. (Kasus Uji +ve-nya)
 Untuk melakukan pengujian negatif, uji lapangan dengan min-1 dan max+1.
Dimana seharusnya tidak menerima. (Ini kasus Uji -ve)
 Jika berfungsi seperti di atas maka kita dapat menyimpulkan bahwa itu hanya
menerima kisaran.
Skenario Uji +Ve: Verifikasi bidang dengan batas seperti min, min+1, tengah, maks-1, dan
maks

Skenario Tes -Ve: Verifikasi bidang dengan batas seperti min-1 dan maks+1

2. Partisi kelas kesetaraan (ECP):

Setiap kali kami memiliki persyaratan khusus seperti memeriksa apakah bidang (nama
pengguna atau kata sandi) menerima karakter seperti a hingga z, A hingga Z, 0 hingga 9
dan #%@$&*. Pada saat yang sama bidang tidak boleh menerima karakter khusus
seperti <>-+/\.

 Dalam skenario ini, tidak mungkin melakukan pengujian lengkap dengan semua
karakter. Jadi kita perlu mengikuti teknik ECP.
 Bagilah sama rata data uji menjadi dua kelas.
A. kelas data uji valid b. Kelas data uji tidak valid
 Siapkan data uji dengan semua kemungkinan cara.
 Untuk melakukan pengujian positif, uji lapangan dengan data uji yang valid.
Dimana harus menerima. (Kasus Uji +ve-nya)
 Untuk melakukan pengujian negatif, uji lapangan dengan data uji yang tidak
valid. Di mana seharusnya tidak menerima. (Kasus Uji -Ve)
 Jika berfungsi seperti yang diharapkan di atas, kita dapat menyimpulkan bahwa
itu berfungsi sesuai kebutuhan.
 3) Kesalahan menebak:

Setiap kali ada bug yang diidentifikasi oleh teknisi pengujian, bug tersebut harus dilaporkan
ke pengembang di mana dia akan memperbaikinya dan mengirimkannya kembali ke tim
pengujian. Insinyur penguji akan memeriksa apakah bug tersebut benar-benar diperbaiki atau
tidak. Pada saat yang sama dia harus menebak kesalahan atau bug pada fungsi terkait. Dia
harus melakukan pengujian dalam fungsi terkait juga. Ini dikenal sebagai 'Error guessing'.

Mis: Di halaman PR, pesan peringatan tidak ditampilkan, sudah diperbaiki oleh pengembang
dan diuji oleh penguji. Di mana pesan peringatan berfungsi dengan baik di halaman PR.
Sekarang tes engg.. harus menggunakan fungsi terkait seperti Saran penerimaan dan
penerimaan kemudian mencari (menebak) jenis bug yang serupa.

Matriks Ketertelusuran:

Ini untuk melacak kembali apakah insinyur penguji telah mencakup semua kasus uji untuk
seluruh persyaratan atau tidak.
 Berdasarkan matriks ketertelusuran, pimpinan atau klien akan melacak apakah teknisi
pengujian telah mencakup semua kasus pengujian atau tidak.

Minta Jumlah Id kasus

ID TC uji Komentar
1 1 1
2 1 2
3 1 3
4 1 4
5 1 5
6 1 6
7 1 7
8&9 5 8 sampai 12
Belum Persyaratan tidak
Diimplementa jelas. Menunggu
10 sikan komentar BA

4) Eksekusi Tes:

 Proses mengeksekusi test case pada build in test environment dikenal sebagai test
execution. Setiap kali build dirilis ke tim pengujian, teknisi pengujian harus meninjau
dokumen SRN untuk mengetahui status build.
 Berdasarkan dokumen SRN, test lead akan menyebarkan build dan tim penguji akan
melakukan uji kewarasan.
 Setelah tes kewarasan selesai, hasil tes kewarasan dikirimkan ke pengembang.
 Jika uji kewarasan lulus, tim penguji akan terus mengeksekusi kasus uji, jika uji
kewarasan gagal, tim penguji akan menolak build kembali ke tim pengembang.
 Saat menjalankan kasus pengujian, teknisi pengujian akan mengamati perilaku
sebenarnya dari aplikasi untuk skenario tersebut dan akan diperbarui di bawah bidang
hasil aktual. Hal yang sama akan dilanjutkan untuk semua kasus uji.

5) Analisis hasil:

 Saat menjalankan kasus uji, insinyur uji akan memperbarui bidang hasil aktual kemudian
dia akan membandingkan hasil aktual dengan hasil yang diharapkan, jika keduanya
cocok maka dia akan memberikan hasil lulus jika tidak dia akan memperbarui sebagai
gagal.
 Untuk pass kita beri warna hijau, sedangkan untuk fail kita beri warna merah. Eksekusi
pengujian dan analisis hasil, keduanya merupakan proses paralel.
 Catatan: Setelah eksekusi kasus pengujian selesai, kami bertanggung jawab untuk
mengeksekusi semua jenis pengujian fungsional pada aplikasi untuk mengidentifikasi bug.

* Berapa banyak test case yang bisa kita tulis dalam sehari?

Itu semua tergantung pada semua persyaratan dan test engineer tetapi rata-rata kami dapat
menulis sekitar 40-50 test case dalam sehari. Ini berarti kami mengambil sekitar 8-10 menit
untuk satu kasus uji untuk menganalisis persyaratan dan menyiapkan kasus uji pada template
kasus uji dengan data uji.

* Berapa banyak test case yang bisa kita eksekusi dalam sehari?

Itu juga tergantung pada test case dan aplikasinya tetapi rata-rata kami dapat mengeksekusi
50-60 test case dalam sehari karena untuk meninjau test case dan mengeksekusinya di aplikasi.

Kami membutuhkan waktu sekitar 5-8 menit untuk mengeksekusi rata-rata satu test case.

6) Pelaporan:

 Proses pelaporan/pengiriman bug (kasus uji gagal) ke pengembang dikenal sebagai

Pelaporan.
 Ini adalah dua jenis.

1. Melaporkan Bug dengan menggunakan file XL.

2. Melaporkan bug dengan menggunakan alat pelaporan.

1. Laporkan bug dengan menggunakan file XL:

Itu adalah proses lama yang kami gunakan untuk memiliki template di bawah ini untuk
memperbarui bug dan mengirimkannya ke pengembang.

Ser Judul bug/ Status Kerasnya Prior Deskrip Tangkap Memb Dilapo Komentar yang
ang Ringkasan itas si bug an layar angun rkan Ditugaskan
ga Versi: Oleh
PE kapan ke
NG
EN
AL
1.

ID Bug:

Nomor seri bug akan dijelaskan di sini.

Judul Bug/Ringkasan:

Hasil sebenarnya dari bug akan dijelaskan di sini.

Status:

Berdasarkan bug, teknisi pengujian serta pengembang bertanggung jawab untuk memberikan
status. Itu di bawah jenis.

 Baru:
Setiap kali teknisi penguji mengidentifikasi bug apa pun. Awalnya status bug adalah
Baru. Bug baru akan dilaporkan ke pengembang.
 Membuka:
Pengembang akan memeriksa apakah bug baru tersebut benar-benar bug atau bukan.
Jika ya maka kami akan memperbarui status dari baru menjadi terbuka.
 Diperbaiki/Diverifikasi:
Pengembang akan membutuhkan waktu untuk memperbaiki bug yang terbuka setelah
diperbaiki, dia akan memperbarui status dari terbuka menjadi diperbaiki. Bug yang
diperbaiki akan dikirim ke teknisi penguji.
 Tertutup:
Insinyur penguji akan memeriksa apakah bug yang diperbaiki benar-benar berfungsi
seperti yang diharapkan atau tidak. Jika berhasil maka kami akan memperbarui status
dari tetap menjadi tertutup. Status tertutup adalah akhir dari Bug.
 Buka kembali:
Bug yang diperbaiki akan diuji oleh teknisi penguji; jika tidak berjalan seperti yang
diharapkan maka dia akan memperbarui status dari diperbaiki menjadi dibuka kembali
dan bug buka kembali akan dikirim kembali ke pengembang.
 Pengembang akan memeriksa apakah itu benar-benar bug atau tidak, jika ya dia
membukanya, memperbaiki bug tersebut dan mengirimkannya kembali ke tim
pengujian.
 Ditolak/Bukan Bug/Tahan/Berbeda:
Ketika teknisi penguji mengidentifikasi bug apa pun, itu akan dilaporkan ke pengembang
dengan status baru. Jika pengembang tidak menerima bug maka dia akan memperbarui
status dari baru menjadi Ditolak/Bukan bug dan akan dikirim kembali ke tim pengujian.

Kerasnya:

Ini menjelaskan seberapa serius bug berdampak pada aplikasi pada pengujian. Keparahan
berarti keseriusan bug. Itu di bawah tipe.

 Pemblokir:
Jika bug memblokir seluruh pengujian modul, maka tingkat keparahan atau jenis bug
adalah Pemblokir.
 Sangat tinggi:
Jika bug memblokir sebagian pengujian modul maka tingkat keparahan bug sangat
tinggi.
 Tinggi:
Jika bug hanya memblokir skenario tertentu dari modul, maka tingkat keparahannya
tinggi.
 Sedang:
Semua tingkat keparahan bug GUI sedang.
 Rendah:
Insinyur penguji juga memiliki opsi untuk memberikan saran. Sehingga saran tersebut
akan dilaporkan dalam bentuk bug yang tingkat keparahannya rendah.

Prioritas:

Prioritas menjelaskan urutan bug yang harus diperbaiki oleh pengembang. Berdasarkan
tingkat keparahannya, teknisi pengujian akan memprioritaskan bug seperti di bawah ini

Kerasnya Prioritas
 Pemblokir/Mendesak/ P1
kritis
P2
Sangat tinggi
P3
Tinggi
P4
Sedang
P5
Rendah

Keterangan:

Langkah-langkah terperinci untuk menghasilkan/mendapatkan bug akan dijelaskan di sini.

Berdasarkan langkah-langkah tersebut, pengembang akan memeriksa apakah itu benar-benar
bug atau tidak.

Tangkapan layar:

Insinyur penguji akan menangkap tangkapan layar bug dan akan diunggah di templat bug. Ini
untuk membuktikan bug yang dilaporkan valid dan juga untuk memahami tentang bug
tersebut.

Versi build:

Nomor build tempat teknisi pengujian mengidentifikasi bug akan dijelaskan di sini.

Dilaporkan oleh:

Insinyur penguji yang mengidentifikasi bug akan menjelaskan di sini.

Tetapkan ke: Nama pengembang atau nama pemimpin pengembang, yang akan memperbaiki
bug akan dijelaskan di sini.

Komentar:

Kedua insinyur pengujian, pengembang dapat mengajukan pertanyaan dalam bentuk komentar.

Catatan: Pelaporan file XL akan memakan banyak waktu sehingga rencana kami adalah
menggunakan alat pelaporan.
Mantan:

Judul /
ID Ringkasan Kerasny Priorit
Fase BUG Bug Status a as Deskripsi Bug Tangkapan layar

Aplikasi
tidak
menampilka 1. Buka Spicejet.com
n kedua 2. Klik pada tombol radio Roundtrip
pemilih Pembloki 3. Aplikasi tidak menampilkan
SAYA 1 tanggal Baru r P1 pemilih tanggal D:\Nagesh\SPicejet_Lo

Nama
Spicejet
ditampilkan 1. Buka Spicejet.com
sebagai 2. Amati logo Spicejet
II 2 spacejet Baru Sedang P4 3. Ini ditampilkan sebagai spacejet D:\Nagesh\SPicejet_Lo

Tombol
AKU radio satu 1. Buka Spicejet.com
AKU arah tidak Sangat 2. Tombol radio satu arah tidak
AKU 3 ditampilkan Baru tinggi P2 tersedia Jalur
Kotak
centang
siswa tidak 1. Buka Spicejet.com
SAYA 4 tersedia Baru Tinggi P3 2. Kotak centang siswa tidak tersedia Jalur
Ubah warna
halaman
muka
spicejet
II 5 menjadi biru Baru Rendah P5 1. Buka Spicejet.com Jalur

Tautan klub
Spicejet
tidak 1. Buka Spicejet.com
AKU mengarah ke 2. Klik tautan Spiceje Connect
AKU halaman Pembloki 3. Tautan Spiceje Connect tidak
AKU 6 klub Spicejet Baru r P1 mengarah ke halaman MySpicetrip Jalur

1. Buka
http://selenium4testing.com/hms
Aplikasi 2. Masuk ke dalam aplikasi
tidak 3. Klik Pencarian Pendaftaran
mempertaha 4. Aplikasi tidak mempertahankan
SAYA 7 nkan GUI Baru Sedang P4 GUI Spicejet_GUI.png
 1. Buka
http://selenium4testing.com/hms
2. Masuk ke hms dengan
Daftar kerja user1/user1
penerimaan 3. Klik pada ADT
GUI tidak 4. Klik Daftar kerja penerimaan
terpelihara 5. Amati GUI, tidak terpelihara
II 8 dengan baik Baru Sedang p4 dengan baik D:\Nagesh\hms_ADW

Bidang
dewasa
AKU tidak 1. Buka http://spicejet.com
AKU ditampilkan Pembloki 2. Perhatikan semua bidang
AKU 9 di halaman Baru r P1 3. Dropdown dewasa tidak tersedia D:\Nagesh\Spicejet\Sp

Aplikasi
tidak
menampilka 1. Buka http://spicejet.com
n Hyderabad 2. Klik pada bidang LeavingFrom
dan Sangat 3. Aplikasi tidak menampilkan
SAYA 1 Bangalore Baru tinggi P2 Hyderabad dan Bangalore D:\Nagesh\Spicejet\Sp
T: apa perbedaan antara tingkat keparahan dan Prioritas

T: apa perbedaan antara Prioritas dalam kasus pengujian dan Prioritas dalam template bug

T. Jika pengembang tidak menerima bug Anda, lalu bagaimana Anda akan membuktikan
bahwa bug Anda valid?

A: Berdasarkan deskripsi bug, dokumen SRS, tangkapan layar kami akan mencoba
membuktikan bahwa bug itu valid jika tidak menerimanya maka saya akan mengambil
server log untuk membuktikan bug itu valid, jika masih tidak menerimanya maka saya akan
kirimkan ke BA, manajer proyek dan akhirnya klien.

T. Jelaskan skenario di mana bug memiliki tingkat keparahan tinggi dengan prioritas rendah
dan keamanan rendah dengan prioritas tinggi?

J: Prioritas Keparahan

Pemblokir - P1

Keamanan tinggi Sangat tinggi - P2 Prioritas utama

Tinggi - P3

Sedang - P4
 Keamanan rendah Rendah - P5 Prioritas rendah

Kami memiliki dua bug, satu Blocker, satu lagi medium. Pemblokir akan memiliki
prioritas tinggi dan media akan memiliki prioritas rendah.

Berdasarkan tingkat keparahannya, tes engg.. akan memberikan prioritas. Berdasarkan

prioritas, tim pengembang bertanggung jawab untuk memperbaikinya

Tetapi pemimpin pengembangan memiliki opsi untuk mengubah prioritas, tergantung

pada situasinya.

 Bug yang terkait dengan pengiriman fase saat ini akan diubah menjadi prioritas
tinggi terlepas dari tingkat keparahannya.
 Bug yang bukan merupakan bagian dari pengiriman saat ini akan diubah menjadi
prioritas rendah terlepas dari tingkat keparahannya.

Fase Bug Id Judul Bug/Ringkasan Status Prioritas Keparahan

I. 1. Spice jetname menampilkan Media Baru P4---P1

Sebagai jet luar angkasa

2. 2. Tautan sambungan jet bumbu bukan Pemblokir Baru P1----P4

Menavigasi halaman koneksi jet rempah-rempah

Laporan Uji/Laporan status pembuatan:

Setelah eksekusi test case selesai pada build, maka test engineer bertanggung jawab
untuk mengirimkan laporan pengujian kepada pimpinan serta klien. Ini di bawah format
Bangun laporan status/Laporan Uji

Bangun Laporan Status / Laporan Uji

Tes Engg Nama:
Membangun No 1
Kredensial Masuk
Peramban FF, yaitu GoogleChrome

Matriks Uji
 Total tidak ada testcase 200
Tidak ada kasus Uji yang
dieksekusi 150
Tidak ada Test case yang
tertunda 50
Jumlah Test case Lulus 100
Jumlah Test case Gagal 50
Tidak ada Test case Dilewati 10
Tidak Ada Bug yang Dilaporkan 3

Metrik Uji:

Metrik berarti pengukuran tugas. Metrik pengujian berarti pengukuran pengujian.

Tertunda:

Jika pengembang tidak memberikan fungsionalitas sama sekali maka test case tersebut tidak
dapat dijalankan. Itu datang di bawah pending.

Dilewati:

Pengembang telah memberikan fungsionalitasnya, tetapi kami tidak dapat menguji

fungsionalitas tersebut, karena fungsionalitas dependen gagal.

Mis: jika Login gagal, kami tidak dapat menjalankan penulisan.

Tulis kasus uji yang dilewati.

 Pelaporan akan dilanjutkan hingga build stabil, stabil berarti sebagian besar kasus
pengujian lulus dan tidak ada bug pemblokir yang tersedia di alat pelaporan.
 Build stabil akan dikirimkan ke klien.

T: Jelaskan kepada saya struktur pelaporan di organisasi Anda

Laporkan Bug Dengan Menggunakan Alat Pelaporan:

 Alat pelaporan apa pun yang memiliki dua jenis pengguna: Salah satunya adalah
pengguna admin dan yang lainnya adalah pengguna Akhir.
 Pengguna admin : Pengguna admin bertanggung jawab untuk membuat proyek,
membuat pengguna seperti insinyur pengujian, pengembang… dll. Dia akan menugaskan
pengguna ke proyek
 Pengguna akhir : Dia bertanggung jawab untuk menggunakan (melaporkan) atau
menerima bug, misalnya: teknisi pengujian, pengembang…dll.
Contoh: QC, JIRA, Bugzilla, Redmine, Test manager dll…

BugZilla:

 Akses Bugzilla dengan menggunakan selenium4testing.com

 Kemudian klik Bugzilla.
 Masuk ke Bugzilla sebagai test engineer ( jan30selenium@gmail.com & kata sandi:
selenium )
 Dengan menggunakan Bugzilla kita dapat melakukan aktivitas di bawah ini.
A. Melaporkan Bug.
B. Cari bug.
C. Kita bisa mengambil laporannya.
D. Preferensi.

Pengantar Bugzilla
Apa itu Bugzilla?
Bugzilla adalah sistem pelacakan masalah/bug sumber terbuka yang
memungkinkan pengembang secara efektif melacak masalah luar biasa dengan produk
mereka. Itu ditulis dalam Perl dan menggunakan database MYSQL.

Bugzilla adalah alat pelacak cacat, namun dapat digunakan sebagai alat
manajemen pengujian karena dapat dengan mudah dihubungkan dengan alat manajemen
kasus uji lainnya seperti Quality Center , Testlink dll.

Pelacak bug terbuka ini memungkinkan pengguna untuk tetap terhubung dengan
klien atau karyawan mereka, untuk berkomunikasi tentang masalah secara efektif di
seluruh rantai manajemen data.

Fitur utama dari Bugzilla termasuk

 Kemampuan pencarian lanjutan

 Notifikasi email
 Ubah/laporkan Bug melalui email
 Pelacakan waktu
 Keamanan yang kuat
 Kustomisasi
Bagaimana cara masuk ke Bugzilla?
Langkah 1) Untuk membuat akun di Bugzilla atau untuk masuk ke akun yang sudah
ada, buka opsi Akun Baru atau Masuk di menu utama.

Langkah 2) Sekarang, masukkan detail pribadi Anda untuk masuk ke Bugzilla

1. ID Pengguna: jan30selenium@gmail.com
2. Kata sandi: selenium
3. Dan kemudian klik "Masuk"
Langkah 3) Anda berhasil masuk ke sistem Bugzilla

Membuat laporan Bug di Bugzilla

Langkah 1) Untuk membuat bug baru di Bugzilla, kunjungi beranda Bugzilla dan klik
tab BARU dari menu utama

Klik tautan Baru kemudian aplikasi membuka jendela berikutnya seperti di bawah ini.

Langkah 2) Di jendela berikutnya

Klik pada nama proyek seperti HMS lalu aplikasi membuka jendela baru dengan opsi
berikut

1. Masukkan Produk
2. Masukkan Komponen
3. Berikan deskripsi Komponen
4. Pilih versi,
5. Pilih tingkat keparahan
6. Pilih Perangkat Keras
7. Pilih OS
8. Masukkan Ringkasan
9. Masukkan Deskripsi
10. Lampirkan Lampiran
11. Kirim

CATATAN: Kolom di atas akan bervariasi sesuai kustomisasi Bugzilla Anda

Masukkan semua bidang yang diperlukan terkait bug Anda seperti di bawah ini,
Jika Anda memiliki lampiran terkait bug pelaporan Anda, Anda dapat melampirkannya dengan mengklik
tombol "Tambahkan lampiran" dan Klik tombol Komit di akhir halaman untuk melaporkan bug Anda.

Langkah 4) Bug dibuat ID # 208 ditugaskan ke Bug kami. Anda juga dapat menambahkan informasi
tambahan ke bug yang ditugaskan seperti URL, kata kunci, papan tulis, tag, dll. Informasi tambahan ini
berguna untuk memberikan detail lebih lanjut tentang Bug yang telah Anda buat.

1. Kotak teks besar

2. URL
3. Papan tulis
4. Kata kunci
5. Tag
6. Tergantung pada
7. Blok
8. Lampiran
Langkah 5) Di jendela yang sama jika Anda menggulir ke bawah lebih jauh. Anda dapat memilih tanggal batas
waktu dan juga status bug. Deadline di Bugzilla biasanya memberikan batas waktu untuk menyelesaikan
bug dalam jangka waktu tertentu.
Membuat Laporan Grafis

Laporan grafis adalah salah satu cara untuk melihat status database bug saat ini. Anda dapat menjalankan
laporan baik melalui tabel HTML atau grafik berbasis garis/pie/bar-chart. Ide di balik laporan grafis di
Bugzilla adalah untuk menentukan sekumpulan bug menggunakan antarmuka pencarian standar dan kemudian
memilih beberapa aspek dari kumpulan tersebut untuk diplot pada sumbu horizontal dan vertikal. Anda juga
bisa mendapatkan laporan 3 dimensi dengan memilih opsi "Banyak Halaman".

Laporan sangat membantu dalam banyak hal, misalnya jika Anda ingin mengetahui komponen mana yang
memiliki jumlah bug buruk terbesar yang dilaporkan. Untuk menunjukkannya dalam grafik, Anda dapat
memilih tingkat keparahan pada sumbu X dan komponen pada sumbu Y, lalu klik hasilkan laporan. Ini akan
menghasilkan laporan dengan informasi penting.

1. Klik laporan di bagian atas jendela sebagai berikut

2. Klik pada Laporan grafis

Halaman laporan grafis akan ditampilkan seperti di bawah ini,

Pilih Sumbu Vertikal sebagai Keparahan dan Sumbu Horizontal sebagai Prioritas atau apa pun yang Anda
inginkan, Anda dapat memilihnya dan Anda akan mendapatkan laporan Grafik yang sesuai.

 Hasilkan laporan dengan fitur Lanjutan dengan memasukkan detail lebih lanjut tentang bug seperti di
bawah ini
Grafik di bawah menunjukkan representasi diagram batang untuk tingkat keparahan Bug di komponen
"Widget Gears". Pada grafik di bawah, bug atau pemblokir yang paling parah pada komponen adalah 88
sedangkan bug dengan tingkat keparahan normal berada di urutan teratas dengan angka 667.

Fungsi Telusur

Langkah 1) Untuk menemukan bug Anda, kami menggunakan fungsi jelajah, klik tombol Cari dari menu
utama.
Pelaporan akan dilanjutkan sampai build stabil. Setelah stabil, itu akan dikirimkan ke klien
kemudian Rujuk fase pengiriman dan pemeliharaan

Setelah build berhasil dikirimkan ke klien, pimpinan pengujian akan menyiapkan

laporan ringkasan pengujian dan akan diperbarui dalam rencana pengujian dan rencana
pengujian dikirim ke klien pada saat pengiriman build.

UJI RINGKASAN LAPORAN / BANGUN LAPORAN POST MARTUM

 Jumlah Bangunan yang dirilis oleh Tim Pengembang - 50

 Jumlah Bangunan yang diterima oleh tim penguji - 25
 Jumlah Bangunan yang ditolak oleh tim penguji - 25
 Jumlah kasus uji yang disiapkan oleh tim penguji - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 Tidak ada bug yang teridentifikasi - 400

o Pemblokir - 100
o Sangat Tinggi - 150
o Tinggi - 100
o Sedang - 40
o Rendah - 10
 Tidak ada bug yang diidentifikasi oleh klien - 100
 o Pemblokir - 10
o Sangat Tinggi - 50
o Tinggi - 10
o Sedang - 10
o Rendah - 20
 Cerita-cerita sukses
 Tantangan

Q : Apa kriteria masuk (mulai) pengujian dan kriteria keluar (akhir) pengujian

J: Rencana pengujian dan dokumen SRS adalah kriteria masuk pengujian.

Tidak ada akhir untuk pengujian. Ini akan dilanjutkan selama build aktif. Namun aktivitas
pengujian akan berubah setelah build dikirimkan ke klien. Selama pemeliharaan, kami tidak
akan melakukan semua jenis pengujian fungsional. Kami akan melakukan pengujian regresi.

Tinjauan Sejawat
Laporan Tinjauan Sejawat
Berjalan melalui
Berjalan melalui Laporan
Suite Tes
Tempat Tidur Tes
DSR
Terminologi
Peer berarti teman satu tim dengan sebutan yang
sama. Semua rekan akan berpartisipasi dalam
pertemuan dan mendiskusikan proyek untuk
mendapatkan kejelasan tentang semua modul.
Tujuan peer review adalah untuk mendapatkan
pengetahuan fungsional pada semua modul oleh
setiap test engine..
Sedangkan peer review senior peer akan
menyiapkan dokumen peer review yang dikenal
dengan laporan peer review
Jika tinjauan sejawat yang sama dilakukan di depan
pimpinan atau manajer proyek, maka itu disebut
Walk through. Pimpinan atau PM akan mengamati
apakah anggota tim memahami proyek dengan
benar atau tidak
Sedangkan Walk Through Lead akan menyiapkan
dokumen Walk Through yang dikenal dengan Walk
Through Report
Kombinasi beberapa test case dikenal sebagai Test
suite
Kombinasi Test suite dan lingkungan pengujian
dikenal sebagai Test Bed
Laporan status harian.
Setiap hari kita perlu mengirimkan status pekerjaan
kita ke pimpinan dalam sebuah template
 Notulen rapat.
Kapan pun kita berpartisipasi dalam rapat,
pembahasan rapat akan menjadi catatan kasar.
Nanti akan diperbarui melalui surat dan surat akan
dikirim ke semua anggota tim. Tujuan MOM adalah
untuk menjaga transparansi pertemuan di antara
MAMA anggota tim
Proses pengecekan apakah perusahaan mengikuti
pedoman atau tidak. Pemeriksaan akan dilakukan
Inspeksi tanpa pemberitahuan
Ini juga merupakan proses pengecekan apakah
perusahaan mengikuti pedoman atau tidak. Audit
akan dilakukan dengan pemberitahuan terlebih
Audit dahulu
Stabil berarti tidak diperlukan pembaruan lebih
lanjut.
Build yang stabil berarti sebagian besar kasus uji
lulus dan tidak ada bug pemblokir yang
Stabil teridentifikasi dalam build
AUT Aplikasi sedang diuji
Kapan pun build ditolak, pengembang akan
menganalisis kegagalan tersebut. Jika dia merilis
build yang sama ke tim pengujian lagi tanpa
menambahkan fungsionalitas baru, ini dikenal
sebagai PatchBuild.
Jika pengembang merilis build dengan beberapa
Pembuatan Tambalan fungsi baru, ini disebut build baru
Jadikan tersedia untuk pengguna yang ditargetkan.
Setelah dokumen Testcases atau SRS dibuat
dasar, itu akan diperiksa di Repositori pusat untuk
pengguna yang ditargetkan. Ini dikenal sebagai
Menerbitkan publikasikan
Kesalahan terkait desain dikenal sebagai cacat.
Mis: cacat GUI
Kesalahan terkait fungsional adalah bug
(Kesalahan programmer).
Mis: Semua bug fungsional
Kesalahan: Pengecualian dalam skrip dikenal
Bug/Cacat/Kesalahan sebagai kesalahan
Use case adalah daftar langkah-langkah, biasanya
mendefinisikan interaksi antara peran (dikenal
sebagai "aktor") dan sistem, untuk mencapai tujuan.
Aktor dapat menjadi Test engineer atau End user
Persyaratan akan diubah menjadi daftar langkah-
Kasus penggunaan langkah oleh BA
Laporan Ketidaksesuaian atau Permintaan
Perubahan Ketidaksesuaian. Persyaratan yang
NCR sedang dibahas
Tindakan korektif diterapkan untuk menanggapi
keluhan pelanggan
Tindakan pencegahan diimplementasikan sebagai
CAPA respons terhadap identifikasi sumber potensial
Dalam rekayasa perangkat lunak, manajemen
konfigurasi perangkat lunak (SCM atau SWCM)
SCM adalah tugas melacak dan mengendalikan
 perubahan dalam perangkat lunak. Praktek SCM
termasuk kontrol revisi dan pembentukan garis
dasar.
SDN Catatan Pengiriman Perangkat Lunak
Mereda. Menjauh dari tugas
Kelicinan Jumlah hari Anda telah tergelincir dari tugas
Produk cacat Produk dengan cacat
Usia Cacat (dalam Waktu) adalah perbedaan waktu
antara tanggal cacat dilaporkan dan tanggal saat ini
(jika cacat masih terbuka) atau tanggal cacat
Usia cacat diperbaiki (jika cacat sudah diperbaiki).
Cacat Laten Cacat Tersembunyi
Manajemen Portofolio Produk, adalah manajemen
terpusat dari proses, metode, dan teknologi yang
PPM digunakan oleh manajer proyek
PPR Laporan Tinjauan Kinerja Program
MRM Manajemen Sumber Daya Pemasaran