Software Test Design

Software Test Plan: Dokumen Testing Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIF Doc. Ref. No. 01., Version: 01

SOFTWARE TEST PLAN: Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIFApprovals:

Approved By: Signature Date

Document Control

Name Dokumen Testing Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIF

Doc. Ref. No. 01Document Status For ApprovalDate of Issue 16 Apr. 12

Change History

Doc. Version Author Date Description / Change01 Rizqi Prifsanti 16 Apr. 12 Change in chapter1, 3, 4, 5, 6, 1102 Irine Dwi K. 16 Apr. 12 Change in chapter2, 7, 8, 9, 10

© Company Name, Year Date-Time Stamp: 05/12/2008 09:10:00 of 18


1 Introduction

Dokumen test plan ini dibuat untuk melakukan perencanaan terhadap testing dari Dokumen Testing Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIF. Sedangkan tujuan umum dari uji coba yang dilakukan pada system aplikasi ini antara lain:

1. Mengetahui apakah semua fungsi yang terdapat dalam dokumentasi user needs telah terpenuhi. Tolok ukur yang digunakan yaitu apabila fungsi-fungsi yang tercantum dalam dokumentasi user needs telah dipenuhi oleh perangkat lunak ini. Dan terdapat bukti dari user pengguna berupa dokumen kesesuaian.

2. Mengetahui apakah semua fungsi yang ada telah berjalan dengan benar. Tolok ukur kebenaran yang digunakan adalah apabila fungsi- fungsi tersebut telah berjalan sesuai dengan alur pada use case dalam dokumen perancangan desain yang ada di lampiran ReadySET

3. Mengetahui apakah semua fungsi yang ada didalam aplikasi sudah termasuk aplikasi yang user friendly. Tolok ukur yang digunakan yaitu apabila tidak adanya keluhan dari pengguna mengenai aplikasi yang dibuat.

2 Literature

Untuk melakukan testing ini, kami menentukan salah satu dari dua macam testing yang ada, dua macam testing yang sering kita dengar adalah White box dan Black box.White Box Testing ialah cara pengujian dengan melihat kedalam modul untuk meneliti kode-kode dari program yang ada, serta melakukan analisa apakah terdapat kesalahan atau tidak dari program tersebut. jika terdapat kesalahan dari modul yang ada, yakni modultersebut menghasilkan output yang tidak sesuai dengan proses bisnis yang dilakukan, maka baris-baris program, variabel, dan parameter yang terlibat pada unit tersebut akan dicek satu-persatu dan kemudian dilakukan perbaikan, selanjutnya di-compile ulang.Black Box Testing adalah metode pengujian perangkat lunak yang melakukan tes fungsionalitas dari aplikasi yang bertentangan dengan struktur internal. Sehingga pada pengujian dengan testing seperti ini tidak diperlukan pengetahuan khusus mengenai kode aplikasi / struktur internal dan pengetahuan pemrograman yang terlalu mendalam.Dalam rekayasa perangkat lunak pengertian dari Functional Requirement adalah suatu fungsi dari suatu sistem perangkat lunak atau komponennya. Sebuah fungsi digambarkan sebagai serangkaian input, perilaku/ kebiasaan, dan output (perangkat lunak). Persyaratan fungsional mungkin merupakan perhitungan, rincian teknis, manipulasi data dan pengolahan dan fungsi spesifik lainnya yang mendefinisikan sistem apa yang harus kita capai.



Sedangkan pengertian dari System Requirement adalah Untuk dapat digunakan secara efisien, semua perangkat lunak komputer membutuhkan komponen hardware tertentu atau sumber daya perangkat lunak lain untuk hadir pada komputer. Prasyarat ini dikenal sebagai (komputer) persyaratan sistem dan sering digunakan sebagai panduan yang bertentangan dengan aturan mutlak. Kebanyakan perangkat lunak mendefinisikan dua set persyaratan sistem: minimum dan yang direkomendasikan. Dengan meningkatnya permintaan untuk kekuatan pemrosesan yang lebih tinggi dan sumber daya dalam versi terbaru dari perangkat lunak, persyaratan sistem cenderung meningkat dari waktu ke waktu. Industri analis menunjukkan bahwa tren ini memainkan peran lebih besar dalam mendorong upgrade ke sistem komputer yang ada daripada kemajuan teknologi.

3 Scope

Spesifikasi komputer yang digunakan untuk menguji Sistem Informasi Pengelolaan Surat Keputusan ini antara lain:

a. Spesifikasi komputer aplikasi server dan database server Processor Intel Pentium 4 Memory 1 GB Kapasitas harddisk free sebesar 40 GB Lan Card Sistem operasi yang digunakan adalah Windows XP Server database yang digunakan adalah MySQL 5.0

b. Spesifikasi komputer client Processor AMD Turion 64X2 Memory 512 MB Kapasitas harddisk free sebesar 10 GB Lan Card Sistem operasi yang digunakan adalah Windows XP

Skenario uji coba ini disusun berdasarkan beberapa use case yang telah dibuat pada tahap desain. Skenario terdiri dari 2 bagian, yaitu overview dan langkah-langkah untuk menjalankan usecase yang akan diuji. Langkah-langkah tersebut akan dilaksanakan dan hasilnya akan digambarkan. Setelah itu akan dilakukan evaluasi dari hasil pelaksanaan skenario tersebut.

4 References

Dokumen yang terkait dengan test plan ini adalah: System Requirements

- Use Cases - Feature specs



- Kebutuhan Non-Fungsional dan Kebutuhan Lingkungan (Non-functional Requirements & Enviromental Requirements)

Require Tracebility Matrix

Document Reference & Version Document Title / DescriptionVersion 1 Lampiran ReadysetVersion 1 Requirement Tracebility Matrix

5 Test Items

Test Item Name Test Item Version No.Use Case Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIF

Use Case version 1

5.1 Features to be Tested

Feature Use Case OverviewF-01 Textfield UC-00.00.01 UC-00.01.02 UC-00.01.03

UC-00.01.05 UC-00.01.06 UC-00.02.02 UC-00.02.03 UC-00.02.04 UC-00.02.06 UC-00.02.07 UC-00.02.09 UC-00.02.10 UC-00.02.12 UC-00.02.13 UC-00.03.05 UC-00.03.06 UC-00.03.07 UC-00.03.08 UC-00.03.09 UC-00.03.10 UC-00.03.11 UC-00.03.12 UC-00.03.13 UC-00.03.14 UC-00.03.15 UC-00.03.16 UC-00.03.18 UC-00.03.19 UC-00.03.20 UC-00.03.21 UC-00.03.22 UC-00.03.23 UC-00.03.24 UC-00.03.25 UC-00.03.31 UC-00.03.32 UC-00.03.33 UC-00.03.34 UC-00.03.35 UC-00.03.36 UC-00.04.02 UC-00.04.04 UC-00.04.05

Dengan adanya fitur ini, di harapkan actor yang melakukan entri data mempunyai tempat / field yang di gunakan untuk melakukan pengisian akan suatu hal. Seperti data pengguna, dsb.

F-02 Check Box

UC-00.03.19 UC-00.03.26 UC-00.03.27 UC-00.03.28 UC-00.03.29 UC-00.03.30 UC-00.03.31 UC-00.03.32 UC-00.03.33 UC-00.03.34 UC-00.03.35 UC-00.03.36 UC-00.04.04 UC-00.04.05

Fitur ini berfungsi bila ingin melakukan pengisian field yang berupa check apakah syarat yang ada di dalam use case tersebut telah terlaksana. Sebagai sebuah bukti.

F-03 Password Field

UC-00.00.01 UC-00.01.02 UC-00.01.03 UC-00.01.05

Fitur ini digunakan untuk mengatasi permasalahan pada login, yaitu untuk menutupi password akun pengguna agar tidak terlihat.

F-04 Text Area UC-00.02.02 UC-00.02.03 UC-00.02.04 UC-00.02.06 UC-00.02.07 UC-00.02.09 UC-00.02.10 UC-00.02.12 UC-00.02.13

Dengan adanya fitur ini, di harapkan actor yang melakukan entri data mempunyai tempat / field yang di



UC-00.03.05 UC-00.03.06 UC-00.03.07 UC-00.03.08 UC-00.03.09 UC-00.03.10 UC-00.03.11 UC-00.03.12 UC-00.03.13 UC-00.03.14 UC-00.03.15 UC-00.03.16 UC-00.03.18 UC-00.03.19 UC-00.03.31

gunakan untuk melakukan pengisian akan suatu hal dalam jumlah banyak.

F-05 Error Message

UC-00.00.01 UC-00.01.02 UC-00.01.03 UC-00.01.04 UC-00.01.05 UC-00.02.02 UC-00.02.04 UC-00.02.05 UC-00.02.06 UC-00.02.07 UC-00.02.10 UC-00.02.13 UC-00.03.05 UC-00.03.06 UC-00.03.07 UC-00.03.08 UC-00.03.13 UC-00.03.14 UC-00.03.15 UC-00.03.16 UC-00.03.19 UC-00.03.26 UC-00.03.27 UC-00.03.28 UC-00.03.29 UC-00.03.30 UC-00.03.31 UC-00.03.37 UC-00.04.03 UC-00.04.04 UC-00.04.05 UC-00.06.01 UC-00.06.02 UC-00.06.03 UC-00.06.04 UC-00.06.05 UC-00.06.06 UC-00.06.07 UC-00.06.08 UC-00.06.09 UC-00.06.10 UC-00.06.11 UC-00.06.12 UC-00.06.13 UC-00.06.14 UC-00.06.15 UC-00.06.16 UC-00.06.17

Fitur ini berfungsi bila ingin melakukan pengisian field yang tidak boleh kosong dan harus sesuai dengan ketentuan yang telah ditentukan. Jika field tersebut kosong atau tidak sesuai dengan ketentuan yang sudah ditentukan, maka akan mucul error message.

F-06 Radio Button

UC-00.02.07 UC-00.02.10 UC-00.03.05 UC-00.03.06 UC-00.03.07 UC-00.03.08 UC-00.03.13 UC-00.03.14 UC-00.03.15 UC-00.03.16

Fitur ini berfungsi untuk memilih salah satu data dari sekian banyak data yang ada.

F-07 Session Expiration

UC-00.00.02 Digunakan untuk mengotomasi log out user

F-08 Searching

UC-00.06.01 UC-00.06.02 UC-00.06.03 UC-00.06.04 UC-00.06.05 UC-00.06.06 UC-00.06.07 UC-00.06.08 UC-00.06.09 UC-00.06.10 UC-00.06.11 UC-00.06.12 UC-00.06.13 UC-00.06.14 UC-00.06.15 UC-00.06.16 UC-00.06.17

Fitur ini berfungsi untuk melakukan proses pencarian data. Seperti data pengguna, dll.

6 Testing Risk Register

Pada dokumen System Requirement dari Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIF risiko dari tiap fitur yang ada dinyatakan dalam dua kategori yaitu termasuk Aman dan termasuk Risiko. Berikut ini daftar tingkat risiko dari fitur yang ada.

Risk ID Feature Risiko KeteranganR01 F-01 Textfield Aman -R02 F-02 Check Box Aman -R03 F-03 Password Field Risiko Fitur ini digunakan untuk mengatasi

permasalahan pada login, yaitu untuk menutupi password akun pengguna agar



tidak terlihat. Fitur ini penting untuk diperhatikan karena menyangkut security dari pengguna, sehingga diharapkan risiko pencurian identitas ataupun akses pihak tidakberwenang bisa dihindari.

R04 F-04 Text Area Aman -R05 F-05 Error Message Aman -R06 F-06 Radio Button Aman -R07 F-07 Session Expiration Risiko Digunakan untuk mengotomasi log out

user. Dalam tahap uji coba harus dipastikan setelah proses log out, jika kembali ke halaman sebelumnya maka seharusnya session time out dapat berjalan

R08 F-08 Searching Aman -

7 Test Approach (Strategy)

Sebelum melakukan perencanaan software testing ini, kami menentukkan strategi software testing terlebih dahulu. Dari beberapa strategi yang sering digunakan, disini strategi yang akan kami gunakan ialah Incremental testing top-down.Maksud dari strategi Incremental testing top-down, kami akan melakukan sebuah pengujian terhadap software secara sedikit demi sedikit dari modul yang sudah ada, kemudian menguji sekelompok modul yang saling terintegrasi dengan modul-madul baru yang telah di lakukan pengujian sebelumnya. Selanjutnya semua paket-paket modul tersebut dapat dilakukan uji sistem secara keseluruhan.Setelah itu menentukan strategi dasar tambahan yang akan digunakan untuk pengujian akan dilakukan berdasarkan strategi dasar yang ada yaitu bottom-up dan top-down dari kedua strategi pengujian tambahan ini menambahkan asumsi bahwa paket perangkat lunak akan terbuat dari sebuah hirarki pada modul perangkat lunak. Disni kami memilih dasar strategi dengan top-down dimana modul yang akan diuji pertama kali adalah modul utama yaitu modul dengan level tertinggi pada struktur perangkat lunak, dan modul terakhir yang akan dilakukan pengujian adalah modul dengan level terrendah.Setelah menentukan metode-metode yang akan digunakan, maka selanjutnya kami menentukan Testing seperti apa yang akan dijalankan. Kami akan melakukan testing meliputi:▫ Functional and System Testing

Memastikan fungsionalitas pada requirement telah berjalan semua

Menguji program baru di lingkungan yang berbeda Menguji high level design Melakukan testing dengan metode Black Box



Kami juga membuat list-list untuk pertanyaan tambahan, dimana pertanyaan ini akan digunakan untuk bertanya dalam merancang pendekatan terhadap pengujian meliputi:

• What to test:▫ Semua functional requirement dari Sistem Informasi Pengelolaan

Surat Keputusan di FTIF• Which sources to use for test case:

▫ SRS/feature specs▫ Requirement Traceability Matrix

• Who is to perform the tests:▫ Irine Dwi Kenestie▫ Rizqi Prifsanti

• Where to perform the tests:▫ In the classroom, laboratory

• When to terminate the tests:▫ On April

7.1 Test Tools Kami telah menentukan tools yang akan digunakan untuk melakukan Testing pada Rancang Bangun Sistem Informasi Pengelolaan Surat Keputusan di FTIF dengan menggunakan TCM. Test Case Manager (TCM) ini adalah sebuah tools yang dirancang untuk para engineer dalam melakukan sebuah testing terhadap software. Ktika pengujian akan dilakukan, maka penguji harus menggunakan TCM untuk melacak dan melakukan pelaporan mengenai keberhasilan atau kegagalan.Utnuk TCM ini memiliki peranyang berbeda serta tingkat akses yang berbeda pula, tergantung pada kebutuhan testing yang akan dijalankan.TCM yang digunakan untuk SOFTWARE Quality Assurance ini dapat meliputi 2 hal:

- Dapat melihat test case, melakukan update pada hasil (lulus/gagal) dari tiap testcase yang ada

Masing-masing test case dengan hasil kegagalan membutuhkan ID

8 Personnel

Name Role ResponsibilityRizqi Prifsanti Test team member UC-00.00.01 - UC-00.03.18Irine Dwi Kenestie Test team member UC-00.03.19 - UC-00.05.15



9 Management and Metrics

Who will be managing the testing? Will different people be managing different phases, for example integration test phase, component test phases? Does the Project Manager require metrics to be collected from you? If so, then list these here and state when and how you will construct the metrics and report them.

Who will be managing the different versions of software released into the testing phase(s)? Will this be the responsibility of the test team or development? Are there other test teams you need to work with? Will a dedicated configuration management team manage this? Cover such aspects here.

Will you set up regular meetings to review test progress? A 15-minute daily meeting of the test team is very useful, although a weekly meeting between the test manager and senior management may be more appropriate for this level. Document your meeting schedules and reporting lines here.

9.1 Test Estimation and Schedule

9.2 Test Phase Entry and Exit Criteria

9.2.1 Integration Test Phase Entry Criteria Integration test documentation/scripts have been peer-reviewed Software to be integration tested has been checked into configuration

management system Test data completed Test environment completed Planned number of issues expected to be found in integration test has been

agreed etc

9.2.2 Integration Test Phase Exit Criteria 100% of integration tests are executed n% of integration tests pass Integration Test Report has been approved Integration tested software has been checked into configuration

management system Integration tested software is available for next test phase Less than n outstanding low severity issues Less than n outstanding medium severity issues Less than n outstanding high severity issues Number of issues found did not exceed planned number by more than 25% etc



9.2.3 Acceptance Test Phase Entry Criteria Acceptance test documentation/scripts have been peer-reviewed Acceptance Testers have been trained (if doing true UAT) Software to be acceptance tested has been checked into configuration

management system (this could include documentation and user manuals, etc.)

Test data completed Test environment completed Planned number of issues expected to be found in component test has been

agreed etc

9.2.4 Acceptance Test Phase Exit Criteria 100% of acceptance tests are executed 100% of acceptance tests pass User needs 100% validated Acceptance Test Report has been approved Acceptance tested software has been checked into configuration

management system Customer has formally approved acceptance of the software into the live

environment Less than n outstanding low severity issues Less than n outstanding medium severity issues Less than n outstanding high severity issues Number of issues found did not exceed planned number by more than 25% etc

9.3 Suspension and Resumption Criteria

10 Test Deliverables

Untuk melakukan Test deliverables, yang kami lakukan antara lain:1. Updated RTM2. TCM

TC#Test Execution

StepsExpected

ResultTest

ResultDate

Tested TesterTC

Time

Comment /(or

Requirement xref)

1 P 15 m 2 Testcase done F 50 m 3 S 1 m 4 B 25 m 5 U

3. Daftar log dari error yang terjadi



11 Communication Plan

Name Role Contact DetailsIrine Dwi Kenestie

Test Team Member Email: [email protected]: 085649421991

Rizqi Prifsanti Test Team Member Email: [email protected]: 085236951427

Communication Aspect PurposeTest Team Meeting Mereview issue yang ditemukan dan

merencanakan tugas untuk hari selanjutnya



12 Software test descriptions (STD) – template1. Scope of the tests1.1 The software package to be tested (name, version and revision)1.2 The documents providing the basis for the designed tests (name and version for each document)

2. Test environment (for each test)2.1 Test identification (the test details are documented in the STP)2.2 Detailed description of the operating system and hardware configuration and the required switch settings for the tests2.3 Instructions for software loading

3 Testing process3.1 Instructions for input, detailing every step of the input process3.2 Data to be recorded during the tests

4 Test cases (for each case)

4.1 Test case identification details

Test ID Description Expected Result

Actual Result Keterangan

TC-00.00.01 Pre kondisi: Aktor telah masuk halaman masuk akun.

Skenario utama1. Aktor memasukkan

nama pengguna dan kata sandi pada form akun

2. Aktor menekan tombol ’Masuk’ untuk masuk ke dalam aplikasi dan menekan tombol ’Batal’ jika ingin mengosongkan form akun

3. Sistem akan memeriksa apakah form telah terisi, jika kosong jalankan skenario alternatif 1

Sistem akan menampilkan halaman utama



4. Sistem akan memeriksa apakah nama akun dan kata sandi sesuai dengan database pada tabel akun dan hak akses, jika tidak sesuai maka jalankan skenario alternatif 2

Skenario Alternatif1. Jika aktor tidak

memasukkan nama akun dan kata sandi maka akan muncul pesan error ”Form kosong”

2. Jika nama akun dan kata sandi tidak sesuai pada database maka akan muncul pesan ”Nama Akun dan Kata Sandi belum terdaftar”

TC-00.00.02 Pre kondisi: Aktor telah masuk kedalam aplikasi

Skenario:Aktor menekan link

’Keluar’

Aktor akan disuguhkan halaman masuk akun


Skenario:1. Aktor memilih menu

Daftar akun pada pengolahan pengguna

2. Sistem akan menampilkan halaman daftar akun

Sistem akan menampilkan daftar data akun


Skenario:1. Aktor memilih menu

Daftar akun pada pengolahan pengguna


3. Sistem akan menampilkan daftar data akun



TC-00.01.02Tambah akun

Pre kondisi: Aktor telah masuk kedalam aplikasi

Skenario:1. Aktor memilih link

tambah akun2. Sistem akan

menampilkan halaman tambah akun

3. Aktor mengisi form yang telah tersedia. Form berisi field nama pengguna, kata sandi, ulangi kata sandi dan memilih daftar hak akses

4. Aktor menekan tombol ’Simpan’ untuk menyimpan data ke dalam database. Menekan tombol ’Batal’ jika ingin membatalkan dan jalankan skenario alternatif 1

5. Sistem akan memeriksa apakah terdapat field yang kosong. Jika ya, jalankan skenario alternatif 2

6. Sistem akan memeriksa apakah nama pengguna sebelumnya telah terdaftar. Jika ya, jalankan skenario alternatif 3

7. Sistem akan memeriksa apakah kata sandi dengan ulangi kata sandi telah sama. Jika tidak, maka jalankan skenario alternatif 4

8. Sistem akan menyimpan data tersebut kedalam database

Skenario Alternatif:1. Jika aktor menekan

tombol ’Batal’ maka sistem akan secara




otomatis mengosongkan form

2. Jika terdapat field yang tidak terisi maka akan muncul pesan ”Field kosong”

3. Jika nama pengguna telah terdapat pada database maka akan muncul pesan ”Nama pengguna sudah terdapat pada database”

4. Jika aktor memasukkan kata sandi dan ulang kata sandi berbeda maka akan muncul ”Kata sandi tidak sama”

TC-00.01.03 Ubah akun

Pre kondisi: Aktor telah masuk halaman pengolahan pengguna

Skenario:1. Aktor memilih data

akun yang akan diubah2. Aktor menekan tombol

’Ubah’3. Sistem akan

menampilkan halaman ubah akun

4. Aktor mengubah data pada form yang tersedia. Form tersebut terdiri atas field nama pengguna, field kata sandi baru sebanyak dua kali dan daftar hak akses.

5. Aktor menekan tombol ’Simpan’. Aktor menekan tombol ’Batal’ maka jalankan skenario alternatif 1

6. Sistem akan memeriksa apakah terdapat field yang tidak terisi. Jika ya,

8. Sistem akan menampilkan halaman Daftar Akun



maka jalankan skenario alternatif 2

7. Sistem akan memeriksa apakah kata sandi dan ulangi kata sandi telah sama. Jika tidak, maka jalankan skenario alternatif 3


tombol batal, maka sistem akan secara otomatis mengosongkan form

2. Jika terdapat field yang tidak terisi maka akan muncul pesan ”Field kosong”

3. Jika aktor memasukkan kata sandi dan ulangi kata sandi berbeda, maka akan muncul pesan ”kata sandi salah”

TC-00.01.04 Hapus akun

Pre Kondisi: Aktor telah masuk halaman Pengolahan Pengguna

Skenario Utama:1. Aktor memilih data

akun yang akan dihapus2. Aktor menekan tombol

’Hapus’3. Sistem akan

memberikan konfirmasi ’Apakah yakin ingin menghapus akun ?’.

4. Aktor menekan tombol ’OK’ jika setuju menghapus akun. Jika tidak yakin, maka menekan tombol ’Cancel’ jalankan skenario alternatif 1


1. Sistem akan menghapus akun dari database pada tabel akun.2. Sistem akan menampilkan halaman daftar akun



tombol ’Tidak’, maka akan muncul pesan ”Data akun batal terhapus !” dan dilanjutkan aktor menekan tombol ’OK’

TC-00.01.05 Ubah Kata Sandi

Pre Kondisi: Aktor telah masuk ke dalam aplikasi

Skenario utama:1. Aktor memilih link ubah

kata sandi2. Sistem akan

menampilkan halaman ubah kata sandi

3. Aktor mengubah data pada form yang telah tersedi. Form tersebut terdiri atas field kata sandi lama, kata sandi baru dan ulangi kata sandi

4. Aktor menekan tombol ’Simpan’. Jika aktor menekan tombol ’Batal’ maka jalankan skenario alternatif 1

5. Sistem akan memeriksa apakah terdapat field yang tidak terisi. Jika ya, maka jalankan skenario alternatif 1

6. Sistem akan memeriksa apakah kata sandi lama sama dengan yang ada pada database. Jika tidak maka jalankan skenario alternatif 2

7. Sistem akan memeriksa apakah kata sandi baru dan ulangi kata sandi telah sama. Jika tidak, maka jalankan skenario laternatif 3

1. Sistem akan menyimpan perubahan pada database akun2. Sistem akan menampilkan halaman ubah kata sandi

TC-00.01.06 Pre Kondisi: Aktor telah 5. Sistem



Lihat akun masuk halama pengolahan pengguna

Skenario Utama:1. Aktor memilih data

pengguna yang akan dilihat

2. Aktor menekan tombol ’Lihat’

3. Sistem akan mengambil data pada database tabel akun dan hak akses

4. Sistem akan menampilkan halaman lihat akun

akan menampilkan data akun secara rinci

TC-00.02.01 Lihat daftar usulan SK

Pre Kondisi: Aktor telah masuk kedalam aplikasi

Skenario Utama:1. Aktor memilih link

Daftar Usulan SK2. Sistem akan mengambil

data pada database tabel usulan

Sistem akan menampilkan halaman daftar usulan sk dengan usrutan tanggal usulan yang telah masuk terlebih dahulu berada pada daftar urutan pertama

TC-00.02.02 Tambah Usulan SK

Pre Kondisi: Aktor telah masuk ke halaman Usulan SK

Skenario Utama:1. Aktor memilih link

tambah usulan sk2. Sistem akan

menampilkan halaman tambah usulan sk

3. Aktor mengisi form yang telah tersedia. Form tersebut terdiri atas field nama pengusul, pengusul, jenis sk, data usulan sk, nomor usulan, tentang, terhitung tanggal dan keterangan

1. Sistem akan menyimpan masukan data kedalam database usulan dan histori_usulan.2. Sistem akan menampilkan halaman tambah usulan SK



4. Aktor menekan tombol ’Simpan’. Jika ingin membatalkan aktor menekan tombol ’Batal’ dan jalankan skenario alternatif 1

5. Sistem akan memeriksa apakah field telah terisi semua. Jika terdapat field yang tidak terisi maka jalankan skenario alternatif 2

6. Sistem akan memeriksa apakah nomor usulan telah terdapat pada database. Jika telah terdapat pada database maka jalankan skenario alternatif 3


tombol ’Batal’, maka sistem secara otomatis mengosongkan field

2. Jika terdapat field yang tidak terisi maka akan muncul pesan ”Field Kosong !”

3. Jika nomor usulan telah terdapat pada database maka akan muncul pesan ”Nomor usulan telah terdaftar !”

4.2 Input data and system settings

4.3 Expected intermediate results (if applicable)

4.4 Expected results (numerical, message, activation of equipment, etc.)

5 Actions to be taken in case of program failure/cessation

6 Procedures to be applied according to the test results summary


Software Test Design

Documents

Transcript of Software Test Design