1st Week Summary

Nguyen Huu Phu

06/10/2016

I.

II.

About Testing
Before I had a chance to learn about testing, my view about testing had been
something like: Tester is the one who feed the application some self-defined
data to check whether it has problems or not, then doing the oral report to
the developers to fix it. I was so wrong.
After my first week internship at KMS, I have learnt a lots about testing.
Therefore, my perspective about testing has completely changed.
o Testing includes human checking and machine checking and testing
should begin as soon as possible (Step 1 in SDLC which is Requirement
Stage) to reduce time consuming as well as cost and human resources.
o Testing cannot be done completely because you have to check every
reactions of the system to specific inputs or maybe some on-the-fly
inputs. There is a gazillion of inputs even those inputs are valid, not to
mention invalid ones and combination ones.
o Testing is like you have to check everything you can enter at the
keyboard or behavior of the mouse toward the application.
o Testers should think and act like a hacker or an end user when they
want to test a system.
o Testers should report defects and bugs in a very clear way to help the
developers fix them easily as well as reducing time consuming.
o Finding bugs in a program is a disaster to developers but it is an act to
the tester.
o Bug-free programs do not exist, there are just programs with very
small ratio of bugs.
o Developers are able to fix problems but they usually stop at
99%.Testers are the ones who finish the rest and prove that those
problems need to be fixed.
Testers should always expect a program to fail because if they do that, they
will test the program in a more outstanding way than ones who expect the
program to work smoothly.

Types of Testing
There are a lot types of testing which are used in specific situations and
environments. In addition, choosing testing types requires a lot of skills and
experiences to see which one is the most appropriate for the project. An
entire project is not only about one type but it also includes a lot of types
depending on the phases or stages.
Manual testing and automation testing do not reject each other. In the
contrary, each one is able to find bugs which could not be found by the other
one. After finishing choosing your testing type, you should choose a suitable
tool which help you minimize time consuming and cost.

Each type of testing has its own entry and exit criteria which help the tester
determine when to start and stop.
In general, testing types can be classified into 3 main types: functional, nonfunctional and maintenance.
These are types of testing that I learnt in this week.

a) Black Box Testing and White Box Testing

Black Box Testing (BBT) and White Box Testing (WBT) are two types of testing
that I have been facing a lots during my first week. Therefore, I may have
rough conclusions about these two :
o BBT is used when a tester does not know anything about the code,
code is not visible to the tester. Therefore, this kind of test basically
bases on requirements and specifications. It has 4 techniques which
are used determine the test cases, they are Equivalence Partitioning
(EP), Boundary Value Analysis (BVA), Decision Table (DT) and State
Transition (ST).
EP: dividing data into classes and if the value in one class
satisfies the conditions then that class satisfies the conditions as
well.
BVA: instead of selecting random value in each field, we select
the value in the boundary such as minimum value, below
minimum, above minimum, etc.
DT: we will use this technique to handle the combination of
inputs. The number of cases is 2^n with n is number of inputs.
ST: this is used to determine the transition of one state to
another state (each input lead the system to the corresponding
state). It will represent the next state of one state when the
corresponding event takes place. It is hard to use with
combination inputs.
o In the contrary, WBT allows testers to see through the code and testers
may write more code to perform their test. In order to do that, the
tester needs to understand clearly the source code and to understand
the source code, knowledge about the programming language which
was used must be in the testers mind. There are 3 prominent
techniques which are used to achieve as-high-as-possible code
coverage, they are Code Coverage Analysis, Statement Coverage and
Branch Coverage. Apart from these ones, there are numerous coverage
types.
BBT and WBT also do not reject each other, each one has its own merits
which help the testers in specific circumstances.

b) Unit Testing and Integration Testing

This is WBT type which uses mock objects to test section of code to make
sure that unit work properly and it is usually done by the developer.
Integration Testing is considered either WBT type or BBT type, it is used to
test modules as a group and check the interaction between them. Testers will
use stubs and drivers to simulate data communication.

c) Smoke Testing and Sanity Testing.

Smoke Testing is used to test core functionalities of the program to make sure
that these critical functionalities are working fine. If the test fails, testers will

not perform deeper testing. Smoke Testing is usually done in testers

environment.
Sanity Testing is used when developers add some new functionalities or they
had fixed some bugs, this one is performed to ascertain that there will be no
further issues in the future. Sanity is usually done in end users environment.

d) Regression Testing
Regression testing is the same as Sanity Testing but it is performed in a wider
range and it is only conducted when tester has enough time and the
manpower should be large enough. Smoke Testing and Sanity Testing are
considered to be subsets of Regression Testing.

e) Static Testing and Dynamic Testing

Static Testing is all about reviewing documents and it is done without
executing the program. It is a verification process. Static is used to find
defects.
Dynamic Testing is used to check the behavior of the system and check if it
meets business requirement. It is also used to find and fix defects. It is done
by executing the program and it is a validation process. Dynamic Testing
could be either BBT or WBT.

III.

IV.

Test case

After choosing testing type, test cases should be developed in detail and in a
standard way. Therefore, a table should be created in order to make test
cases more understandable and more comprehensive. A standard test case
table need include these columns:
o Test Case ID
o Test Scenario: A scenario that a functionality of the program can be
tested.
o Precondition: Some conditions need to be had before continuing.
o Test Steps
o Test Data
o Expected Result
o Actual Result
o Status (pass/fail)
Requirement Traceability Matrix (RTM) is a document that tracking
requirements and check current project requirements are met. The main
purpose of this matrix is to ascertain that all test cases are covered and make
sure that no functionality should miss during testing process.
In order to create RTM, you have to match the Test Case ID with Business
Requirement Number (BR#) and Technical Requirement Number
(TR#) (these merits are from Business Requirement Document and
Technical Requirement Document). This matrix will highlight any
requirements missing or document inconsistences.

Conclusion

In conclusion, testing is really important and I may have an answer for the
question Why do we have to do testing?

In my point of view, the reason why we have to test is to improve the quality
of programs. However, a tester has to have a destructive attitude toward the
developer and the more bugs are found, the better program will be.
In the bigger picture, bugs could lead to lethal problems even if the amount
of them is approximately 1 or 2. That is why we have do testing no matter
how good the program is.