TUGAS PENGUJIAN SISTEM

Nama Kelompok :

Abu Umar (G.231.13.0147)

M.Fauzan Affandi (G.231.13.0158)

Muhammad Dicky Rahman (G.231.13.0159)

Anas Marzuki (G.231.13.0183)

7 Prinsip Fundamental Software testing

Sumber 1 : http://istqbexamcertification.com/what-are-the-principles-of-testing/

1) Testing shows presence of defects: Testing can show the defects are present, but cannot prove that

there are no defects. Even after testing the application or product thoroughly we cannot say that the product

is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the software

but even if no defects are found, it is not a proof of correctness.

Terjemahan :

Testing menunjukkan adanya masalah / error Testing dapat menunjukkan adanya masalah / error, tetapi

tidak bisa menjamin tidak adanya masalah / error. Setelah melakukan testing produk aplikasi secara

menyeluruh kita tidak bisa mengatakan bahwa produk kita 100% tidak memiliki error.Testing akan selalau

mengurangi jumlah error / masalah yang belum ditemukan di dalam software aplikasi, tetapi walaupun

tidak ada error yang ditemukan tetap tidak bisa dibuktikan bahwa software ini bebas error.

2) Exhaustive testing is impossible: Testing everything including all combinations of inputs and

preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and priorities to

focus testing efforts.

Terjemahan :

Testing secara lengkap / menyeluruh itu tidak mungkin : Menguji segala sesuatu termasuk semua

kombinasi dari input dan kondisi sebelumnya adalah tidak mungkin. Jadi, sebagai ganti melakukan

pengujian secara menyeluruh kita bisa mengambil resiko dan prioritas untuk fokus pada upaya pengujian.

3)Early testing: In the software development life cycle testing activities should start as early as possible

and should be focused on defined objectives.

Terjemahan :

Dalam pengembangan software life cycle, aktifitas pengujian harus dilakukan sesegera mungkin dan harus

fokus pada tujuan yang sudah ditetapkan.

4)Defect clustering: A small number of modules contains most of the defects discovered during

pre-release testing or shows the most operational failures.

Terjemahan :

Sejumlah kecil modul berisi banyak masalah atau error yang ditemukan selama pengujian pra-rilis atau

menunjukkan kegagalan yang paling operasional.

5)Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the same set of

test cases will no longer be able to find any new bugs. To overcome this Pesticide Paradox, it is really

very important to review the test cases regularly and new and different tests need to be written to exercise

different parts of the software or system to potentially find more defects.

Terjemahan :

Jika jenis pengujian yang sama terus diulang lagi dan lagi, maka pengujian yang sama ini tidak akan

menemukan bug / masalah baru. Untuk mengatasi ini Pesticide Paradox menjadi benar benar sangat

penting untuk meninjau pengujian secara teratur dan baru, dan pengujian yang berbeda diperlukan untuk

ditulis untuk di lakukan pada bagian dari software atau sistem yang lain untuk menemukan masalah lain.

6)Testing is context depending: Testing is basically context dependent. Different kinds of sites are tested

differently. For example, safety critical software is tested differently from an e-commerce site.

Terjemahan :

Pengujian pada dasarnya bergantung pada konteks. Berbagai jenis situs yang berbeda telah diuji secara

berbeda beda. Contohnya, keamanan-software berbahaya telah di uji secara berbeda beda dari situs

e-comerce.

7)Absence of errors fallacy: If the system built is unusable and does not fulfil the users needs and

expectations then finding and fixing defects does not help.

Terjemahan :

Tidak adanya kesalahan / Kekeliruan : Jika sistem yang dibuat tidak dapat digunakan dan tidak memenuhi

kebutuah dan harapan pengguna, kemudian dicari dan diperbaiki masalahnya, itu tidak akan membantu.

Sumber 2 : http://www.testingexcellence.com/seven-principles-of-software-testing/

Software testing is an extremely creative and intellectually challenging task. When testing follows the

principles given below, the creative element of test design and execution rivals any of the preceding

software development steps.

1. Testing shows the presence of bugs

Testing an application can only reveal that one or more defects exist in the application, however, testing

alone cannot prove that the application is error free. Therefore, it is important to design test cases which

find as many defects as possible.

2. Exhaustive testing in impossible

Unless the application under test (UAT) has a very simple logical structure and limited input, it is not

possible to test all possible combinations of data and scenarios. For this reason, risk and priorities are

used to concentrate on the most important aspects to test.

3. Early testing

The sooner we start the testing activities the better we can utilize the available time. As soon as the

initial products, such the requirement or design documents are available, we can start testing. It is

common for the testing phase to get squeezed at the end of the development lifecycle, i.e. when

development has finished, so by starting testing early, we can prepare testing for each level of the

development lifecycle.

Another important point about early testing is that when defects are found earlier in the lifecycle, they

are much easier and cheaper to fix. It is much cheaper to change an incorrect requirement than having to

change a functionality in a large system that is not working as requested or as designed!

4. Defect clustering

During testing, it can be observed that most of the reported defects are related to small number of

modules within a system. i.e. small number of modules contain most of the defects in the system. This is

the application of the Pareto Principle to software testing: approximately 80% of the problems are found

in 20% of the modules.

5. The pesticide paradox

If you keep running the same set of tests over and over again, chances are no more new defects will be

discovered by those test cases. Because as the system evolves, many of the previously reported defects

will have been fixed and the old test cases do not apply anymore. Anytime a fault is fixed or a new

functionality added, we need to do regression testing to make sure the new changed software has not

broken any other part of the software. However, those regression test cases also need to change to reflect

the changes made in the software to be applicable and hopefully fine new defects.

6. Testing is context dependent

Different methodologies, techniques and types of testing is related to the type and nature of the

application. For example, a software application in a medical device needs more testing than a games

software. More importantly a medical device software requires risk based testing, be compliant with

medical industry regulators and possibly specific test design techniques. By the same token, a very

popular website, needs to go through rigorous performance testing as well as functionality testing to

make sure the performance is not affected by the load on the servers.

7. Absence of errors fallacy

Just because testing didnt find any defects in the software, it doesnt mean that the software is ready to be shipped. Were the executed tests really designed to catch the most defects? or where they designed to

see if the software matched the users requirements? There are many other factors to be considered before making a decision to ship the software.

Other principles to note are:

Testing must be done by an independent party.

Testing should not be performed by the person or team that developed the software since they tend to

defend the correctness of the program.

Assign best personnel to the task.

Because testing requires high creativity and responsibility only the best personnel must be assigned to

design, implement, and analyze test cases, test data and test results.

Test for invalid and unexpected input conditions as well as valid conditions.

The program should generate correct messages when an invalid test is encountered and should generate

correct results when the test is valid.

Keep software static during test.

The program must not be modified during the implementation of the set of designed test cases.

Provide expected test results if possible.

A necessary part of test documentation is the specification of expected results, even if providing such

results is impractical.

KESIMPULAN DARI KELOMPOK KAMI UNTUK SOAL PERTAMA

Testing menunjukkan masalah / error

Testing adalah suatu cara untuk menemukan suatu masalah / error dalam suatu software, tetapi

walaupun suatu software telah ditest tetap saja tidak bisa software itu dikatakan bebas error.

Testing Secara Menyeluruh / lengkap itu tidak mungkin.

Maksudnya melakukan testing pada semua bagian dari software aplikasi itu tidak mungkin karena

memerlukan jumlah kombinasi test case sangat besar, dan setiap ditemukan bug dan diperbaiki akan

dilakukan test ulang, jika dilakukan secara menyeluruh tentunya akan memakan waktu yang sangat

lama.

Melakukan Testing Sesegera Mungkin

Lakukanlah testing sesegera mungkin, karena semakin cepat ditemukan suatu bug / error dalam suatu

program akan semakin cepat pula penanganannya.

Pengelompokan Kesalahan / Error

Kita perlu melakukan pengelompokan error / masalah yang ditemukan, untuk mempermudah dalam

melakukan perbaikan dan sebagai catatan juga dalam melakukan perbaikan software lain yang

mempunyai kesalahan yang sama.

Pesticide Paradox

Pesticide paradox sangat sangat diperlukan, dalam melakukan pengujian sistem jika kita terus

melakukan pengujian yang sama pada masalah yang sama maka tidak akan ditemukan solusinya, oleh

karena itu diperlukan pesticide paradox yaitu suatu bentuk pengujian yang berbeda.

Testing Butuh Independensi

Testing yang paling efektif adalah yang dilakukan oleh pihak ke 3.

Tidak adanya kesalahan atau errro

Jika sistem yang dibuat tidak sesuai dengan kebutuhan yang di perlukan konsumen maka sekalipun

dilakukan pengujian sistem, dicari kesalahannya dan diperbaiki, maka tidak akan berpengaruh, yang

perlu dilakukan adalah perancangan sistem baru.

Jelaskan tentang SDLC (Software/System Development Life Cycle) !

Contohnya Waterfall cycle & Iterative cycle seperti RAID & Agile.

Sumber 1 : https://www.academia.edu/9824026/System_Development_Life_Cycle

System Development Life Cycle (SDLC) atau dalam bahasa Indonesia disebut Siklus Hidup

Pengembangan Sistem adalah istilah yang digunakan untuk menjelaskan proses dalam pengembangan

Sistem Informasi.

Secara umum SDLC terdiri atas tahapan pekerjaan yang digunakan oleh pengembang sistem untuk

merancang, mendesain, membangun, serta menguji sistem informasi. Konsep dari SDLC itu sendiri

dapat mencakup pengaturan dari hardware dan software, suatu sistem dapat,diterapkan untuk hardware

atau software saja, atau dapat merupakan kombinasi dari keduanya.

SDLC itu sendiri bertujuan untuk menciptakan sebuah sistem dengan kualitas yang tinggi. Sistem

yang dimaksud disini adalah sistem yang dapat memenuhi kebutuhan pelanggan sesuai dengan tahapan

yang jelas dalam rentang waktu dan biaya yang sesuai dengan rencana.

Tahapan Pekerjaan Dalam SDLC

SDLC Model

A. Waterfall Model

1. Pengertian/Definisi

Waterfall model merupakan SDLC model yang pertama kali diperkenalkan. Dalam waterfall model,

tahapan-tahapan dalam SDLC disusun secara berurutan. Transisi antar tahapan hanya terjadi bila tahapan

yang sebelumnya sudah sepenuhnya selesai dilaksanakan sehingga tidak ada tahapan yang berjalan secara

bersamaan.

2. Diagram

3. Karakteristik

A. Proyek dibagi menjadi tahapan-tahapan berurutan yang saling berhubungan antar tahapan

sebelum dengan sesudahnya, dan transisi ke tahapan berikutnya hanya terjadi bila tahapan

sebelumnya sudah selesai.

B. Terdapat penekanan lebih pada perencanaan dan manajemen waktu pelaksanaan.

C. Terdapat pengendalian secara ketat selama proses pengembangan sistem. Pengendalian ini bisa dari

pencatatan atau dokumentasi sistem terus menerus dan/atau dari ulasan/pertemuan dengan client.

4. Kelebihan

a. Cocok untuk tim sistem analis dan/atau tim manajemen proyek yang kurang berpengalaman atau tim

yang kinerjanya sedang tidak stabil.

b. Tahapan yang berurutan memudahkan dalam kendali proyek, kecukupan proses dokumentasi, dan

pengulasan desain. Serta, memastikan kualitas hasil sistem yang dikembangkan.

c. Proses pengembangan sistem dapat diukur.

5. Kekurangan

A. Tidak fleksibel.

B. Sukar untuk melakukan proses iterasi. Permasalahan biasanya ditemui pada tahapan setelah

analisa, tetapi karena proses yang berjalan maju, akan sukar untuk melakukan perencanaan atau

analisa ulang.

C. Sistem tidak dapat diuji hingga sistem tersebut selesai dikembangkan.

D. Dokumentasi yang berlebihan.

B. Iterative / Incremental Model

1. Pengertian/Definisi

Iterative model adalah model SDLC yang tahapannya dilakukan berulang kali dimulai dari implementasi

skala kecil yang kemudian terus berevolusi hingga menjadi suatu sistem secara utuh.

2. Diagram

3. Karakteristik

A. Persyaratan dan kebutuhan sistem sudah didefinisikan di awal.

B. Proses pengembangan sistem dibagi menjadi beberapa iterasi dengan waterfall model skala kecil.

C. Iterasi dalam pengembangan sistem dibagi menjadi beberapa tipe dengan kebutuhan dan / atau

tujuan masing-masing.

D. Setiap iterasi dapat berjalan bersamaan.

E. Teknologi baru sedang dipelajari pada saat pengembangan sistem.

4. Kelebihan

A. Beberapa fungsi dapat dikembangan lebih cepat pada awal dari pengembangan sistem.

B. Hasil didapatkan lebih awal.

C. Perkembangan sistem dapat diukur dan direncanakan.

D. Perubahan masih dapat ditoleransi.

E. Setiap iterasi dapat dianalisa, diuji, dan dikelola dengan mudah, karena skala-nya yang sudah

diperkecil.

5. Kekurangan

A. Tidak dapat digunakan pada proyek skala kecil.

B. Tidak cocok bila terjadi perubahan pada persyaratan dan kebutuhan sistem awal secara berkala.

Karena biasanya tidak semua persyaratan dan/atau kebutuhan sistem dapat diidentifikasi di

awal.

C. Manajemen proyek yang lebih kompleks, serta membutuhkan perhatian yang lebih.

D. Karena banyaknya proses iterasi, titik akhir dari proyek sukar untuk diidentifikasi atau ditentukan.

Sumber 2 : www.academia.edu/7478619/System_Development_Live_Cicle

SDLC adalah langkah-langkah dalam pengembangan sistem informasi. SDLC menyediakan

framework yang lengkap untuk aktivitas rekayasa bentuk dan pembangunan sistem informasi yang formal.

SDLC diperlukan untuk memecahkan berbagai masalah berikut:

1) Bagaimana perencanaan aplikasi sistem informasi.

2) Bagaimana analisis aplikasi sistem informasi.

3) Bagaimana desain aplikasi sistem informasi.

4) Bagaimana implementasi aplikasi sistem informasi.

5) Bagaimana penggunaan aplikasi sistem informasi.

6) Bagaimana teknik-teknik pengembangan sistem informasi.

Dalam perkembangannya SDLC dilengkapi oleh berbagai teknik pengembangan

sistem, diantaranya :

1. Prototyping.

Teknik prototypingadalah proses pembuatan model sederhana untuk softwarefinal yang mengijinkan

pengguna memiliki gambaran dasar tentang program serta melakukan pengujian awal.

Jenis-jenis teknik prototyping adalah:

(a) Trowaway Prototyping.

(b) Evolutionary Prototyping.

(c) Incremental Prototyping.

Keuntungan menggunakan teknikprototyping:

(a) Mengurangi waktu dan biaya.

(b) Meningkatkan keterlibatan pengguna.

(c) Mengurangi kesalahpahaman dan kesalahan interpretasi dengan pengguna.

Kelemahan menggunakan teknikprototyping:.

(a) Analisis kurang.

(b) Biaya untuk membuat prototyping cukup tinggi.

2. Waterfall

Keuntungan menggunakan teknik waterfall:

(a) Proses menjadi teratur

(b) Estimasi proses menjadi lebih baik

(c) Jadwal menjadi lebih menentu

Kelemahan menggunakan teknikwaterfall:

(a) Sifatnya kaku, sehingga susah melakukan perubahan di tengah proses

(b) Membutuhkan daftar kebutuhan yang lengkap di awal, tapi jarang konsumen bisa memberikan

kebutuhan secara lengkap diawal

Solusi: Modified Waterfall.

Sumber 3 : http://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm

Agile SDLC model is a combination of iterative and incremental process models with focus on process

adaptability and customer satisfaction by rapid delivery of working software product.

Agile model believes that every project needs to be handled differently and the existing methods need to be

tailored to best suit the project requirements. In agile the tasks are divided to time boxes (small time frames)

to deliver specific features for a release.

Iterative approach is taken and working software build is delivered after each iteration. Each build is

incremental in terms of features; the final build holds all the features required by the customer.

Terjemahan :

Model SDLC Agile adalah kombinasi dari model iterativ dan incremental dengan fokus pada proses

adaptasi dan kepuasan pelanggan dengan penyampaian cepat pada software produk.

Agile model yakin bahwa setiap proyek harus ditangani secara berbeda dan metode yang ada harus

disesuaikan dengan persyaratan projek terbaik. Dalam Agile tugas dibagi ke kotak waktu (kerangka kecil

waktu) untuk memberikan fitur khusus untuk sebuah rilis.

Pendekatan iteratif diambil dan perancangan software kerja disampaikan setelah tiap iterasi. Setiap

membangun incremental dalam hal fitur; rancangan akhir memegang semua fitur yang diperlukan oleh

pelanggan.

http://www.slideshare.net/MarrajuBollapRagada/agile-vs-iterativevswaterfall

KESIMPULAN DARI KELOMPOK KAMI DARI SOAL KE 2

System Development Life Cycle merupakan suatu kumpulan langkah langkah dalam melakukan

pengembangan sebuah sistem informasi baik untuk merancang, mendesain, membangun serta menguji

sebuah sistem informasi.

Tahapan-Tahapan Dalam SDLC

1. Merencanakan dan menganalisa persyaratan yang dibutuhkan;

2. Memetakan persyaratan dan kebutuhan sistem;

3. Mendesain struktur dari sistem tersebut;

4. Membangun atau mengembangan sistem tersebut;

5. Menguji sistem tersebut;

6. Menerapan sistem tersebut; dan

7. Melakukan perawatan terhadap sistem tersebut secara berkala.

Waterfall Model merupakan tahapan-tahapan dalam SDLC yang disusun secara berurutan. Transisi

antar tahapan hanya terjadi bila tahapan yang sebelumnya sudah sepenuhnya selesai dilaksanakan,

sehingga tidak ada tahapan yang berjalan secara bersamaan.

Iterative model adalah model SDLC yang tahapannya dilakukan berulang kali dimulai dari implementasi skala kecil yang kemudian terus berevolusi hingga menjadi suatu sistem secara utuh.

Model SDLC Agile adalah kombinasi dari model iterativ dan incremental dengan fokus pada proses adaptasi dan kepuasan pelanggan dengan penyampaian cepat pada software produk.

Jelaskan tentang STLC (Software Test Life Cycle) !

Sumber 1 : http://www.softwaretestingmentor.com/stlc/software-test-life-cycle/

Software Testing Life Cycle

What is STLC (Software Testing LifeCycle)?

The process of testing a software in a well planned and systematic way is known as software testing

lifecycle (STLC).

Different organizations have different phases in STLC however generic Software Test Life Cycle (STLC)

for waterfall development model consists of the following phases.

1. Requirements Analysis

2. Test Planning

3. Test Analysis

4. Test Design

5. Test Construction and Verification

6. Test Execution and Bug Reporting

7. Final Testing and Implementation

8. Post Implementation

1. Requirements Analysis

In this phase testers analyze the customer requirements and work with developers during the design phase

to see which requirements are testable and how they are going to test those requirements.

It is very important to start testing activities from the requirements phase itself because the cost of fixing

defect is very less if it is found in requirements phase rather than in future phases.

2. Test Planning

In this phase all the planning about testing is done like what needs to be tested, how the testing will be

done, test strategy to be followed, what will be the test environment, what test methodologies will be

followed, hardware and software availability, resources, risks etc. A high level test plan document is

created which includes all the planning inputs mentioned above and circulated to the stakeholders.

Usually IEEE 829 test plan template is used for test planning.

3. Test Analysis

After test planning phase is over test analysis phase starts, in this phase we need to dig deeper into project

and figure out what testing needs to be carried out in each SDLC phase.

Automation activities are also decided in this phase, if automation needs to be done for software product,

how will the automation be done, how much time will it take to automate and which features need to be

automated.

Non functional testing areas(Stress and performance testing) are also analyzed and defined in this phase.

4. Test Design

In this phase various black-box and white-box test design techniques are used to design the test cases for

testing, testers start writing test cases by following those design techniques, if automation testing needs to

be done then automation scripts also needs to written in this phase.

5. Test Construction and Verification

In this phase testers prepare more test cases by keeping in mind the positive and negative scenarios, end

user scenarios etc. All the test cases and automation scripts need to be completed in this phase and got

reviewed by the stakeholders. The test plan document should also be finalized and verified by reviewers.

6. Test Execution and Bug Reporting

Once the unit testing is done by the developers and test team gets the test build, The test cases are executed

and defects are reported in bug tracking tool, after the test execution is complete and all the defects are

reported. Test execution reports are created and circulated to project stakeholders.

After developers fix the bugs raised by testers they give another build with fixes to testers, testers do

re-testing and regression testing to ensure that the defect has been fixed and not affected any other areas of

software.

Testing is an iterative process i.e. If defect is found and fixed, testing needs to be done after every defect

fix.

After tester assures that defects have been fixed and no more critical defects remain in software the build is

given for final testing.

7. Final Testing and Implementation

In this phase the final testing is done for the software, non functional testing like stress, load and

performance testing are performed in this phase. The software is also verified in the production kind of

environment. Final test execution reports and documents are prepared in this phase.

8. Post Implementation

In this phase the test environment is cleaned up and restored to default state, the process review meetings are done and lessons learnt are documented. A document is prepared to cope up similar problems in future

releases.

Sumber 2 : http://www.softwaretestinghelp.com/what-is-software-testing-life-cycle-stlc

What is Software Testing Life Cycle (STLC)

Software Testing Life Cycle refers to a testing process which has specific steps to be executed in a definite

sequence to ensure that the quality goals have been met. In STLC process, each activity is carried out in a

planned and systematic way. Each phase has different goals and deliverables. Different organizations have

different phases in STLC; however the basis remains the same.

Below are the phases of STLC:

Requirements phase

Planning Phase

Analysis phase

Design Phase

Implementation Phase

Execution Phase

Conclusion Phase

Closure Phase

#1. Requirement Phase:

During this phase of STLC, analyze and study the requirements. Have brain storming sessions with other

teams and try to find out whether the requirements are testable or not. This phase helps to identify the

scope of the testing. If any feature is not testable, communicate it during this phase so that the mitigation

strategy can be planned.

#2. Planning Phase:

In practical scenarios, Test planning is the first step of the testing process. In this phase we identify the

activities and resources which would help to meet the testing objectives. During planning we also try to

identify the metrics, the method of gathering and tracking those metrics.

On what basis the planning is done? Only requirements?

The answer is NO. Requirements do form one of the bases but there are 2 other very important factors

which influence test planning. These are:

Test strategy of the organization. Risk analysis / Risk Management and mitigation.

#3. Analysis Phase:

This STLC phase defines WHAT to be tested. We basically identify the test conditions through the requirements document, product risks and other test basis. The test condition should be traceable back to

the requirement. There are various factors which effect the identification of test conditions:

Levels and depth of testing Complexity of the product Product and project risks Software development life cycle involved.

Test management Skills and knowledge of the team. Availability of the stakeholders.

We should try to write down the test conditions in a detailed way. For example, for an e-commerce web

application, you can have a test condition as User should be able to make a payment. Or you can detail it out by saying User should be able to make payment through NEFT, debit card and credit card. The most important advantage of writing the detailed test condition is that it increases the test coverage, since the test

cases will be written on the basis of the test condition, these details will trigger to write more detailed test

cases which will eventually increase the coverage. Also identify the exit criteria of the testing, i.e

determine some conditions when you will stop the testing.

#4. Design Phase:

This phase defines HOW to test. This phase involves the following tasks:

Detail the test condition. Break down the test conditions into multiple sub conditions to increase coverage.

Identify and get the test data Identify and set up the test environment. Create the requirement traceability metrics Create the test coverage metrics.

#5. Implementation Phase:

The major task in this STLC phase is of creation of the detailed test cases. Prioritize the test cases also

identify which test case will become part of the regression suite. Before finalizing the test case, It is

important to carry out the review to ensure the correctness of the test cases. Also dont forget to take the sign off of the test cases before actual execution starts. If your project involves automation, identify the

candidate test cases for automation and proceed for scripting the test cases. Dont forget to review them!

#6. Execution Phase:

As the name suggests, this is the Software Testing Life Cycle phase where the actual execution takes place.

But before you start your execution, make sure that your entry criterion is met. Execute the test cases, log

defects in case of any discrepancy. Simultaneously fill your traceability metrics to track your progress.

#7. Conclusion Phase:

This STLC phase concentrates on the exit criteria and reporting. Depending on your project and

stakeholders choice, you can decide on reporting whether you want to send out a daily report of weekly

report etc. There are different types of reports ( DSR Daily status report, WSR Weekly status reports) which you can send, but the important point is, the content of the report changes and depends upon whom

you are sending your reports. If Project managers belong to testing background then they are more

interested in the technical aspect of the project, so include the technical things in your report ( number of

test cases passed, failed, defects raised, severity 1 defects etc.). But if you are reporting to upper

stakeholders, they might not be interested in the technical things so report them about the risks that have

been mitigated through the testing.

#8. Closure Phase:

Tasks for the closure activities include the following:

Check for the completion of the test. Whether all the test cases are executed or mitigated deliberately. Check there are no severity 1 defects opened.

Do lessons learnt meeting and create lessons learnt document.( Include what went well, where are the scope of improvements and what can be improved)

KESIMPULAN DARI KELOMPOK KAMI UNTUK SOAL KETIGA

Software testing life cycle merupakan proses pengujian software dengan cara terencana dan sistematis,

maksudnya dengan menggunakan langkah - langkah spesifik yang akan dieksekusi dalam urutan yang

pasti untuk memastikan bahwa tujuan dan kualitas telah terpenuhi.

Tahapan tahapan dalam STLC

Tahapan persyaratan

Tahap perencanaan

Tahap Analisis

Tahap Desain

Tahap Implementasi

Tahap Eksekusi

Tahap Kesimpulan

Tahap Penutupan