This document contains information about an individual named Selvy Ariska who is studying Systems Information at the Sultan Syarif Kasim Riau Islamic State University. It discusses software testing as a process that occurs throughout the software development lifecycle to find and fix defects early. Both static testing, such as document review, and dynamic testing, such as code execution, are important. Testing activities include planning, control, reporting, and closing out phases. Tests are designed to evaluate requirements, design, code, documents and whether the software is fit for its intended purpose. Finding and fixing defects improves quality and helps improve future development processes.

2.  Nama : SELVY ARISKA
 NIM : 11453201795
 JURUSAN : SISTEM INFORMASI
FAKULTAS SAINS DAN TEKONOLOGI
UNIVERSITAS ISLAM NEGERI
SULTAN SYARIF KASIM RIAU

4.  Testing is a process rather than a single
activity– there are a seriesof activities
involved.

5.  looks at testing as a process that takesplace
throughout the software development life
cycle. We saw earlierthat the later in the life
cycle we find bugs, the more expensive they
areto fix. If we can find and fix requirements
defects at the requirementsstage, that must
make commercial sense. We'll build the right
software,correctly and at a lower cost
overall.

6.  that as well as tests wherethe software code
is executed to demonstrate the results of
running tests(often called dynamic testing)
we can also test and find defects without
executing code. This is called static testing.
This testing includes reviewing ofdocuments
(including source code) and static analysis.
This is a useful andcost effective way of
testing

7.  Activities take place before and after test
execution. We need tomanage the testing;
for example, we plan what we want to do;
we control thetest activities; we report on
testing progress and the status of the
softwareunder test; and we finalize or close
testing when a phase completes. Chapter5
covers these test management activities

8.  We need to choose what testing we'll do, by
selecting test conditions and designing test
cases. Chapter 4 covers the test design
activities

9.  As well as executing the tests, we must
check the results andevaluate the software
under test and the completion criteria,
which help usdecide whether we have
finished testing and whether the software
producthas passed the tests.

10.  We don't just test code. We testthe
requirements and design specifications, and
we test related documentssuch as operation,
user and training material. Static and
dynamic testing areboth needed to cover the
range of products we need to test.

12.  Determine that (software products) satisfy
specified requirements– Some ofthe testing
we do is focused on checking products
against the specificationfor the product; for
example we review the design to see if it
meets requirements, and then we might
execute the code to check that it meets the
design.If the product meets its specification,
we can provide that information tohelp
stakeholders judge the quality of the product
and decide whether it isready for use.

13.  This is slightlydifferent to the point above; after
all the specified requirements might bewrong or
incomplete. 'Fit for purpose' looks at whether
the software doesenough to help the users to
carry out their tasks; we look at whether the
software does what the user might reasonably
expect. For example, we mightlook at who might
purchase or use the software, and check that it
does dowhat they expect; this might lead us to
add a review of the marketing material to our
static tests, to check that expectations of the
software are properlyset. One way of judging the
quality of a product is by how fit it is for
itspurpose.

14.  We most often think of software testing as a
means ofdetecting faults or defects that in
operational use will cause failures.
Findingthe defects helps us understand the
risks associated with putting the softwareinto
operational use, and fixing the defects
improves the quality of the products.
However, identifying defects has another
benefit. With root causeanalysis, they also
help us improve the development processes
and makefewer mistakes in future work.

15.  Referensi : Graham et.al (2011)