continue to reading FAQs on QA Testing Part-I
What do you like
about QA?
The best thing I like about QA is, I like the job which is more process
oriented. For example, we have to work right from reading the requirement
documents, providing feedback to the Business Analysts as necessary, writing
test plans, test cases, execute the test cases, interaction with different
developers, attend walk-through meeting and so on. I am a very detailed
oriented person. When I test applications, I try to get into the depth of
functionality so that I don’t miss out anything. Finally, I love logging
defects.
What are all the
basic elements in a defect report?
The basic elements in a defect report are: Defect ID, Header,
Description, Defect Reported by, Date, Status, Version, Assigned to, Approved
by, Module where the defect was found and so on.
What is the
difference between verification and validation?
Verification: Verification is a process to ensure
that the software that is made, matches the original design. In other words, it
checks whether the software is made according to the criteria and specification
described in the requirement document. It is to check whether you built the
product right as per design. It is a low level checking. (It is done in
walk-through meetings generally). It checked whether it is made accordingly to
the design.
Validation: Validation is a process to check
whether the product design fits the client’s need. It checks whether you built
the right thing. It checks whether it is designed properly.
How do you know
it is sufficient testing?
Every company has entry and exit criteria. When we test applications, we
refer to exit criteria. When we are about to finish testing, then the QA Team
(QA Manager) refers to the exit criteria (exit criteria tells the level of
defect that you can be comfortable with before it goes to production. For
example, there should be ZERO critical defect, ZERO high level defect, ZERO
medium defect, 1 Low level defect, all the test cases must be 100% executed
etc). Once the exit criteria meet the requirements, then the software is
considered to be sufficiently tested.
Every company has entry and exit criteria. When we test applications, we
refer to exit criteria. When we are about to finish testing, then the QA Team
(QA Manager) refers to the exit criteria (exit criteria tells the level of
defect that you can be comfortable with before it goes to production. For
example, there should be ZERO critical defect, ZERO high level defect, ZERO
medium defect, 1 Low level defect, all the test cases must be 100% executed
etc). Once the exit criteria meet the requirements, then the software is
considered to be sufficiently tested.
How to derive
test scenarios and use cases? What are the contents and format?
Test scenarios are derived from
requirement documents. We follow each and every functionality (called business
rules) mentioned in the requirement document. One functionality can have
multiple business rules. For example, let us say in there is one requirement
called “Login”. This “Login” may have various scenarios. For example, one
scenario is, enter the right User ID and wrong password. The system should
display an error message. Another scenario would be to enter wrong User ID and
right Password. The system should display an error message. The third scenario
could be to enter the right User Name and right Password. The system should
allow the user to get into the system. This is how the test cases are derived
from the requirement documents or from the Use Cases.
What are the
types of test cases that you write?
We write test cases for smoke testing, integration testing, functional
testing, regression testing, load testing, stress testing, system testing and
so on.
How to write
Integration test cases?
I have never written separate Test Cases Integration Testing. Since
Integration Testing is a test to check whether the all the modules are
integrated together or not (meaning that when the developers compile all their
module and make a build, all modules should be working when they are combined
together and those modules when combined, should work as expected). If they are
not integrated (combined) in a nice way, then the application breaks.
Basically, when we do the functional testing, the integration testing is
automatically done. This is my experience.
How to write
Regression test cases? What are the criteria?
Regression test cases are also based on the requirement documents. They
are written more into detail and with every release (build), the testers need
to do regression testing. The criteria for regression testing are; there should
be no major defects while we do our smoke test and functional testing.
Is there a format
for a test case? Do you follow any methodology for numbering test cases?
Yes. It depends upon the company how the company has followed the
numbering of test cases. However, normally, it is just a simple numbering in
most of the time (see question 4 of qaquestions.com). But some companies may
also relate this numbering to the requirement number. For example, if the
requirement for Login is “REQ-LOG-001”, then we can number the test cases like
REQ-LOG-001-001 and so on.
What is Test
Harness?
(Definition from
www.wikipedia.org) “In software testing, a test harness or automated test
framework is a collection of software and test data configured to test a
program unit by running it under varying conditions and monitor its behavior
and outputs. It has two main parts: the test execution engine and the test
script repository.”
How to write User
Acceptance Test plan & test cases?
The way of writing Test Plan and Test Cases is the same in all the test
phases. However, specifically for User Acceptance Testing, the testers use data
nearly real data (meaning that the data is very much similar to the production
data or real data). For the format, please refer to question 3 and 4 in
qaquestions.com.
What are the
different matrices that you follow?
There are various reports we normally prepare in QA:
Test summary
Report – It is
a report that has list of the total test cases, list of executed test cases,
remaining test case to be executed, executed date, pass/fail
Defect Report – In this report we normally prepare
a list of defect in spreadsheet e.g. defect # CQ12345 [ if you log a defect in
the application called Rational ClearQuest]
Traceability
Matrix [also called RTM (Requirement Traceability Matrix)] Report – the document which shows the
relationship between the functionalities or the business rules and the test
cases. So, with the help of Traceability Matrix we make sure that we includes
all the functionalities in our test cases according to the requirement
document.
0 comments:
Post a Comment