Software Testing Techniques for User Acceptance (UA) and Systems Integration (SI) Testing

Software testing is the process of evaluating and verifying that a software product or application does what it is supposed to do.

The benefits of testing include preventing bugs, reducing development costs and improving performance.

In general, the levels of testing have the following hierarchy:

Unit testing
Component testing
System testing
System integration testing
User acceptance testing
Production

(Adapted from: https://www.ibm.com/my-en/topics/software-testing)

PENGUJIAN PERISIAN

Pengujian perisian adalah proses menilai dan mengesahkan bahawa produk atau aplikasi perisian telah melakukan apa yang sepatutnya ia lakukan.

Pengujian perisian membantu menyahkan pepijat, mengurangkan kos pembangunan dan meningkatkan prestasi perisian.

JENIS PENGUJIAN PERISIAN
Terdapat pelbagai jenis ujian perisian, masing-masing mempunyai objektif dan strategi yang khusus:

1) Ujian penerimaan: Mengesahkan bahawa keseluruhan sistem telah berfungsi seperti yang dihasratkan.

2) Ujian integrasi: Memastikan bahawa komponen atau fungsi perisian dapat beroperasi di antara satu sama lain.

3) Ujian unit: Menyemak bahawa setiap unit perisian berfungsi seperti yang dikehendaki. Ia adalah bentuk ujian terkecil bagi sesebuah perisian.

4) Ujian fungsi: Menilai keberkesanan fungsi bagi komponen yang terdapat di dalam sesebuah perisian.

5) Ujian prestasi: Menilai keupayaan perisian untuk menanggung beban kerja yang berbeza. Ini memperlihatkan senario dunia sebenar di mana perisian itu berada.

6) Ujian regresi: Menentukan bahawa penambahan ciri baru bagi sesebuah perisian tidak menggagalkan, mengganggu atau merencatkan perjalanan perisian tersebut. Dalam keadaan ujian regresi penuh tidak dapat dijalankan, ujian kewarasan boleh digunakan untuk mengesahkan menu, fungsi atau arahan di peringkat permukaan perisian.

7) Ujian tekanan: Menguji tahap tekanan yang mampu ditanggung oleh sistem sebelum ia gagal berfungsi.

8) Ujian kebolehgunaan: Mengesahkan sejauh mana pengguna boleh menggunakan perisian bagi menyelesaikan tugas. Pengesahan kebolehgunaan adalah kritikal untuk semua perisian. Ujian penerokaan boleh dilaksanakan bagi membantu mengenalpasti senario dan situasi yang sukar diramalkan tetapi boleh mengakibatkan berlaku gangguan atau kegagalan perisian.

KEPENTINGAN MEMBERI PERHATIAN KEPADA PENGUJIAN PERISIAN

Pembangunan perisian yang tidak memberi perhatian kepada pengujian yang baik boleh membawa akibat buruk seperti (1)kecatatan atau (2)kegagalan perisian dan seterusnya (3)kelewatan penghantaran perisian. Meskipun sudah dihantar, jika perisian itu masih mengandungi masalah yang tidak disingkap oleh proses pengujian, ia boleh membawa (4)mudarat kepada pengguna. Kesemua hal ini berkait langsung dengan kos projek pembangunan.

Proses pengujian menelan kos yang besar. Walaubagaimanapun, kos ini dapat diminimakan jika peringkat awal proses pengujian dapat menyingkap masalah yang dapat dibendung dari melarat menjadi isu yang lebih besar di tahap seterusnya dalam peringkat pembangunan perisian.

Proses pengujian juga memakan masa. Ujian manual atau ujian ad-hoc mungkin memadai bagi sistem perisian yang kecil. Bagi sistem yang lebih besar, penggunaan alat bantu terutamanya yang bersifat automatik adalah sangat berguna. Ujian automatik membantu pasukan penguji melaksanakan ujian dalam pelbagai senario atau persekitaran (seperti lokal atau awan) dan mendapatkan maklum balas dengan cepat berkaitan keputusan atau hasil penemuan pengujian.

(Disesuaikan dari: https://www.ibm.com/my-en/topics/software-testing)

.
Article:

RALAT TITIK TERAPUNG (FLOATING POINT ERROR) YANG MENYEBABKAN KEROSAKAN BERNILAI SETENGAH BILION

Pepijat Perisian Dalam Komputer

Jika anda pernah melakukan pengaturcaraan, anda tentunya tahu tentang istilah ralat titik terapung. Ia adalah ralat yang paling diabaikan tetapi sangat bahaya.

Sejauhmanakah bahayanya ralat titik terapung? Tanyalah hal ini kepada Agensi Angkasa Eropah yang kehilangan (1) usaha selama lebih sedekad dan (2) USD500 juta.

Kisah Ariane 5

Pada 4 Jun 1996, penerbangan sulung pelancar Ariane 5 berakhir dengan kegagalan. Hanya kira-kira 40 saat selepas memulakan penerbangan, pada ketinggian kira-kira 3700 m, pelancar itu melencong dari laluan penerbangannya, pecah dan meletup.

Kegagalan Ariane 501 disebabkan oleh kehilangan panduan dan maklumat ketinggian ketika 37 saat selepas dilancarkan. Kehilangan maklumat ini berpunca dari kegagalan perisian sistem rujukan inersia.

Kegagalan diakibatkan oleh kesilapan perisian ketika menukar titik terapung 64-bit kepada nilai integer bertanda 16-bit (Nombor titik terapung itu adalah berkaitan dengan halaju roket berkenaan dari pelantar pelancarnya). Nombor titik terapung yang ditukar mempunyai nilai yang lebih besar daripada yang boleh diwakili oleh integer bertanda 16-bit (maksudnya nombor itu lebih besar daripada 32,767 iaitu integer terbesar yang boleh disimpan dalam integer bertanda 16 bit). Oleh itu penukaran gagal.

Sebagai tindakbalas, sistem roket menukar kawalan kepada komputer sandaran yang malangnya mempunyai data yang sama. Bencana pun berlaku.

Pengekodan telah dilakukan melalui bahasa ADA. Baris terakhir yang menyebabkan tragedi adalah seperti berikut:

(Disesuaikan dari: https://itsfoss.com/a-floating-point-error-that-caused-a-damage-worth-half-a-billion/)

Workbook:
B) Getting Started

1.1. Rationale of Acceptance Testing
1.2. User Acceptance Testing Scenario
1.3. Steps to Perform Acceptance Testing
1.4. Requirement Analysis
1.5. Test Plan Creation
1.6. Test Case Designing
1.7. Test Case Execution
1.8. Confirmation of objectives
1.9. Tools used in Acceptance Testing

Article:

1.1. Rationale of Acceptance Testing

The main purpose of this test is to evaluate the system's compliance with the business requirements and verify if it is has met the required criteria for delivery to end users.

Tujuan utama ujian ini adalah untuk menilai pematuhan sistem dengan keperluan perniagaan dan mengesahkan sama ada ia telah memenuhi kriteria yang diperlukan untuk penghantaran kepada pengguna akhir.

https://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm#:~:text=Acceptance%20testing%2C%20a%20testing%20technique,for%20delivery%20to%20end%20users.

1.2. User Acceptance Testing Scenario

UAT scenarios template is a data and information collection tool that allows testers to accumulate feedback so they can improve their end product.

Templat senario UAT ialah alat pengumpulan data dan maklumat yang membolehkan penguji mengumpul maklum balas supaya mereka boleh menambah baik produk akhir mereka.

https://usersnap.com/blog/user-acceptance-testing-example/#:~:text=UAT%20Scenarios%20%E2%80%93%20User%20Acceptance%20Testing%20Example&text=UAT%20scenarios%20template%20is%20a,can%20improve%20their%20end%20product.

1.3. Steps to Perform Acceptance Testing

Analyze product requirements and define key deliverables. ...
Choose the time and form of end-user testing. ...
Recruit users and form UAT team. ...
Implement end-user testing tools and onboard testers. ...
Create user acceptance environment and run training. ...
Run the tests. ...
Collect output information and analyze it.

Analisis keperluan produk dan menentukan penghantaran utama. ...
Pilih masa dan bentuk ujian pengguna akhir. ...
Rekrut pengguna dan bentuk pasukan UAT. ...
Laksana alat ujian pengguna akhir dan penguji onboard. ...
Cipta persekitaran penerimaan pengguna dan jalankan latihan. ...
Jalankan ujian. ...
Kumpul maklumat output dan menganalisisnya.

https://www.altexsoft.com/blog/engineering/user-acceptance-testing/

1.4. Requirement Analysis

Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications.

Analisis keperluan, juga dipanggil kejuruteraan keperluan, ialah proses menentukan jangkaan pengguna untuk produk baharu atau diubah suai. Ciri-ciri ini, yang dipanggil keperluan, mestilah boleh diukur, relevan dan terperinci. Dalam kejuruteraan perisian, keperluan sedemikian sering dipanggil spesifikasi fungsi.

https://www.techtarget.com/searchsoftwarequality/definition/requirements-analysis#:~:text=Requirements%20analysis%2C%20also%20called%20requirements,often%20called%20functional%20specifications.

1.5. Test Plan Creation

How to write a test plan:
1) Learn about the software. Before testing starts, it's important to learn everything you can about the software. ...
2) Define the scope of testing. ...
3) Create test cases. ...
4) Develop a test strategy. ...
5) Define the test objective. ...
6) Choose testing tools. ...
7) Find bugs early. ...
8) Define your test criteria.

Bagaimana menulis rancangan ujian:

1) Ketahui tentang perisian. Sebelum ujian bermula, adalah penting untuk mempelajari semua yang anda boleh tentang perisian. ...

2) Tentukan skop ujian. ...

3) Buat kes ujian. ...

4) Membangunkan strategi ujian. ...

5) Tentukan objektif ujian. ...

6) Pilih alat ujian. ...

7) Cari pepijat awal. ...

8) Tentukan kriteria ujian anda.

https://www.wearedevelopers.com/magazine/how-to-create-a-test-plan-for-software-testing

1.6. Test Case Designing

Test case design refers to how you set-up your test cases. It is important that your tests are designed well, or you could fail to identify bugs and defects in your software during testing. There are many different test case design techniques used to test the functionality and various features of your software.

Reka bentuk kes ujian merujuk kepada cara anda menyediakan kes ujian anda. Adalah penting bahawa ujian anda direka bentuk dengan baik, atau anda mungkin gagal mengenal pasti pepijat dan kecacatan dalam perisian anda semasa ujian. Terdapat banyak teknik reka bentuk kes ujian yang berbeza digunakan untuk menguji fungsi dan pelbagai ciri perisian anda.

https://reqtest.com/testing-blog/test-case-design-techniques/#:~:text=Test%20case%20design%20refers%20to,various%20features%20of%20your%20software.

1.7. Test Case Execution

Test execution is the process of executing the code and comparing the expected and actual results. Following factors are to be considered for a test execution process: Based on a risk, select a subset of test suite to be executed for this cycle. Assign the test cases in each test suite to testers for execution.

Pelaksanaan ujian ialah proses melaksanakan kod dan membandingkan hasil yang diharapkan dan sebenar. Faktor berikut perlu dipertimbangkan untuk proses pelaksanaan ujian: Berdasarkan risiko, pilih subset suite ujian untuk dilaksanakan bagi kitaran ini. Tetapkan kes ujian dalam setiap suite ujian kepada penguji untuk dilaksanakan.

https://www.tutorialspoint.com/software_testing_dictionary/test_execution.htm#:~:text=Test%20execution%20is%20the%20process,suite%20to%20testers%20for%20execution.

1.8. Confirmation of objectives

The main motto of testing is to find maximum defects in a software product while validating whether the program is working as per the user requirements or not. Defects should be identified as early in the test cycle as possible.

Moto utama ujian adalah untuk mencari kecacatan maksimum dalam produk perisian sambil mengesahkan sama ada program itu berfungsi mengikut keperluan pengguna atau tidak. Kecacatan harus dikenal pasti seawal mungkin dalam kitaran pengujian.

https://www.toolsqa.com/software-testing/istqb/software-testing-objectives/

1.9. Tools used in Acceptance Testing

1. Create – Create tests, add descriptions, input expected results, and add images in a simple, easy-to-use format.

2. Test – Group tests based on your unique use cases. Assign tests to users and track their progress in real-time.

3. Approve – Verify that requirements are met by approving tests and projects.

1. Cipta ujian – Buat ujian, tambah penerangan, masukkan hasil yang dijangkakan dan tambahkan imej dalam format yang ringkas dan mudah digunakan.

2. Laksana ujian – Ujian kumpulan berdasarkan kes penggunaan unik anda. Berikan ujian kepada pengguna dan jejak kemajuan mereka dalam masa nyata.

3. Sahkan ujian – Sahkan bahawa keperluan telah dipenuhi dengan meluluskan ujian dan projek.

https://thewfcgroup.com/hcm-systems-software-services/engageuat/2014-04-28-simple-tool-user-acceptance-testing/

Workbook:
Activity1

2.1. Rationale of Integration Testing
2.2. Integration Testing Scenarios
2.3. Integration Testing Techniques
2.4. Black Box Testing
2.5. White Box Testing
2.6. Types of Integration Testing
2.7. Incremental integration testing
2.8. Non-incremental integration testing
2.9. Guidelines for Integration Testing
2.10. Tools used in Integration Testing

Article:

2.1. Rationale of Integration Testing

Integration testing -- also known as integration and testing (I&T) -- is a type of software testing in which the different units, modules or components of a software application are tested as a combined entity.

Ujian integrasi -- juga dikenali sebagai integrasi dan ujian (I&T) -- ialah sejenis ujian perisian di mana unit, modul atau komponen yang berbeza bagi aplikasi perisian diuji sebagai entiti gabungan.

https://www.techtarget.com/searchsoftwarequality/definition/integration-testing

2.2. Integration Testing Scenarios

Some examples of scenarios:

Data that are passed across different components/systems must remain intact, and will not produce unexpected errors (for example, due to differences in data type).
Computations and data transformation across different components/systems must work as expected.
Unexpected system errors must not appear when multiple components/systems are executed together.

Beberapa contoh senario:

Data yang dihantar merentasi komponen/sistem yang berbeza mesti kekal utuh dan tidak akan menghasilkan ralat yang tidak dijangka (contohnya, disebabkan oleh perbezaan jenis data).
Pengiraan dan transformasi data merentas komponen/sistem yang berbeza mesti berfungsi seperti yang diharapkan.
Ralat sistem yang tidak dijangka tidak boleh muncul apabila berbilang komponen/sistem dilaksanakan bersama.

https://www.quora.com/What-is-the-test-scenario-for-integration-testing#:~:text=Data%20that%20are%20passed%20across

2.3. Integration Testing Techniques

Types:

State Transition.
Decision Table.
Boundary Value Analysis.
All-pairs Testing.
Cause and Effect Graph.
Equivalence Partitioning.
Error Guessing.

Jenis:

Peralihan Keadaan.
Jadual Keputusan.
Analisis Nilai Sempadan.
Ujian semua pasangan.
Graf Sebab dan Akibat.
Pembahagian Kesetaraan.
Teka Ralat.

https://www.javatpoint.com/integration-testing#:~:text=integration%20testing%20techniques

2.4. Black Box Testing

Black box testing involves testing a system with no prior knowledge of its internal workings.

Ujian kotak hitam melibatkan ujian sistem tanpa pengetahuan awal tentang hal dalamannya.

https://www.imperva.com/learn/application-security/black-box-testing/

2.5. White Box Testing

White box testing involves looking at the structure of the code.

Ujian kotak putih melibatkan pemerhatian ke atas struktur kod.

https://www.softwaretestinghelp.com/white-box-testing-techniques-with-example/

2.6. Types of Integration Testing

Types:

1.Incremental

2.Non-Incremental (Big Bang)

Jenis:

1.Menokok

2.Bukan-Menokok (Big Bang)

https://techaffinity.com/blog/what-is-integration-testing/

2.7. Incremental integration testing

The Incremental Evaluating technique involves merging two or more modules that are logically connected to one another and then testing the application for correct functionality. The additional connected modules are then progressively integrated, and the procedure is repeated until all logically linked modules have been successfully integrated and tested.

Teknik Penilaian Menokok melibatkan penggabungan dua atau lebih modul yang disambungkan secara logik antara satu sama lain dan kemudian menguji aplikasi untuk fungsi yang betul. Modul tambahan yang disambungkan kemudian disepadukan secara progresif, dan proses diulang sehingga semua modul yang dipautkan secara logik telah berjaya disepadukan dan diuji.

1.Bottom-up Integration Testing.
2.Top-down Integration Testing.
3.Sandwich Integration Testing.

https://www.tutorialspoint.com/integration-testing-types-top-down-and-bottom-up

2.8. Non-incremental integration testing

We will go for this method, when the data flow is very complex and when it is difficult to find who is a parent and who is a child. And in such case, we will create the data in any module bang on all other existing modules and check if the data is present. Hence, it is also known as the Big bang method.

Kita akan menggunakan kaedah ini, apabila aliran data sangat kompleks dan apabila sukar untuk mencari siapa ibu bapa dan siapa anak. Dan dalam kes sedemikian, kita akan mencipta data dalam mana-mana modul dan pencarkan (bang) pada semua modul sedia ada yang lain dan semak sama ada data itu wujud. Oleh itu, ia juga dikenali sebagai kaedah Big Bang.

https://www.javatpoint.com/integration-testing#:~:text=Big%20bang%20method

2.9. Guidelines for Integration Testing

Examine the structure and architecture of the application and identify the crucial modules to test them first and also identify all possible scenarios.
Design test cases to verify each interface in detail.
Choose input data for test case execution.

Periksa struktur dan seni bina aplikasi dan kenal pasti modul penting untuk mengujinya terlebih dahulu dan juga mengenal pasti semua senario yang mungkin.
Reka bentuk kes ujian untuk mengesahkan setiap antara muka secara terperinci.
Pilih data input untuk pelaksanaan kes ujian.

https://www.javatpoint.com/integration-testing#:~:text=Guidelines%20for%20Integration%20Testing&text=Examine%20the%20structure%20and%20architecture,data%20for%20test%20case%20execution.

2.10. Tools used in Integration Testing