Entries from December 2006 ↓

I am working on Search engine project for last 6 months and now I understood most of the functionality and search engine strategies.

When you work as a Manual tester then somewhere you feel to automate your work. Sometimes doing routine manual work bores you. So here comes the need of Automation.
So Automation is very helpful for the regression type of work, to avoid repeated manual work. Now I understood the need of Automation and I want to start with it, but from where shall I start is the big question.

Before starting the Automation of your project work you need to remember following points:

1. What is the type of my project? Is it a stand-alone project or a client – server project?
2. What is the size of my project? You can find size on various metrics like kilo line of code. 3. Is there repeated work in my project?
4. Time taken for My current Manual project testing
5. Error rate by Manual testing.

In next some posts I will discuss about the Advantage – Disadvantages of Manual and Automation testing, also the step-by-step process to automate your project work.

Q Customer has reported severe defects in Daily balance report. The customer
is unhappy that the problem is not fixed even after a week. What action you
as a PM will take to restore confidence of customer and ensure that this will
not happen in suture?

Answer:
Conflict resolution – Get on your customer wavelength. Get the facts and ask
questions, get detail info and take notes listen carefully. Establish and initiate an
action program(admit error if it is there, negotiate satisfactory solution, state the
solution and get agreement, take action and follow up with customer). Finally
establish proper daily problem review process to prevent such problems in future.

Q. It’s observed that the testers in your organization are performing tests on the
deliverable even after significant defects have been found. This has resulted
in unnecessary testing of little value because re-testing needs to be done
after defects have been rectified. You are the test manager and going to
update the test plan with recommendations on when to stop testing. List the
recommendations you are going to make.

Answer:
Following steps need to be taken .
a) Acceptance criteria should tighten
b) Test cases should be re-evaluated (preferably peer review)
c) If possible more test cases should be added. With boundary value and
equivalence class partition cases.
d) More test cases with invalid condition should be added
e) Stop criteria needs to be modified

Q. You are newly appointed as a test lead in an organization which uses manual
testing. Your boss wants you to put forth three testing tools and their features
to create awareness about the testing tools in the top management. Suggest
any three testing tools for your test Environment and why do you suggest
them?

Answer:
The third question is very important one. You can write about test Director, Win
runner/Load runner, McCable or any other coverage tool. Test director is useful to
track defect. WR or LR to do functionality/Load testing, Coverage tool to check the
code coverage thereby helping in White box testing.

Q. You are working on a project, where the requirements change dynamically.
The data in the project comes from various ends (from various Platforms) and
are inter-dependent. You see this as a big risk in the project. How would you
plan accordingly?

Answer:
Give a Plan which takes care of the risk and is identified in the Risk Areas. Say that
the testing scope would concentrate more on Data driven tests etc.

Q. What is a test strategy?

Answer:
A test strategy must address the risks and present a process that can reduce those
risks.
The two components of Test strategy are:
a) Test Factor: The risk of issue that needs to be addressed as a part of the test
strategy. Factors that are to be addressed in testing a specific application
system will form the test factor.
b) Test phase: The phase of the systems development life cycle in which testing
will occur.]

Q. When to stop testing?

Answer:
a) When all the requirements are adequately executed successfully through test
cases
b) Bug reporting rate reaches a particular limit
c) The test environment no more exists for conducting testing
d) The scheduled time for testing is over
e) The budget allocation for testing is over]

Q. Your company is about to roll out an E-Commerce application. It is not
possible to test the application on all types of browsers on all platforms and
operating systems. What steps would you take in the testing environment to
reduce the business risks and commercial risks?

Answer:
Compatibility testing should be done on all browsers (IE, Netscape, Mozilla etc.)
across all the operating systems (win 98/2K/NT/XP/ME/Unix etc.)]

Q. What’s the difference between priority and severity?

Answer:
“Priority” is associated with scheduling, and “severity” is associated with standards.
“Priority” means something is afforded or deserves prior attention; a precedence
established by order of importance (or urgency). “Severity” is the state or quality of
being severe; severe implies adherence to rigorous standards or high principles and
often suggests harshness; severe is marked by or requires strict adherence to
rigorous standards or high principles, e.g. a severe code of behavior. The words
priority and severity do come up in bug tracking. A variety of commercial, problemtracking/
management software tools are available. These tools, with the detailed
input of software test engineers, give the team complete information so developers
can understand the bug, get an idea of its ‘severity’, reproduce it and fix it. The fixes
are based on project ‘priorities’ and ‘severity’ of bugs. The ‘severity’ of a problem is
defined in accordance to the customer’s risk assessment and recorded in their
selected tracking tool. A buggy software can ‘severely’ affect schedules, which, in
turn can lead to a reassessment and renegotiation of ‘priorities’.]

1. Define the following along with examples

a. Boundary Value testing
b. Equivalence testing
c. Error Guessing
d. Desk checking
e. Control Flow analysis

Answer:
1-a) Boundary value Analysis: -
A process of selecting test cases/data by
identifying the boundaries that separate valid and invalid conditions. Tests are
constructed to test the inside and outside edges of these boundaries, in addition to
the actual boundary points. or A selection technique in which test data are chosen to
lie along “boundaries” of the input domain [or output range] classes, data structures,
procedure parameters, etc. Choices often include maximum, minimum, and trivial
values or parameters.
E.g. – Input data 1 to 10 (boundary value)
Test input data 0, 1, 2 to 9, 10, 11

1-b) Equivalence testing: -
The input domain of the system is partitioned into classes
of representative values, so that the no of test cases can be limited to one-per-class,
which represents the minimum no. of test cases that must be executed.
E.g.- valid data range: 1-10
Test set:-2; 5; 14

1-c) Error guessing: -
Test data selection technique. The selection criterion is to pick
values that seem likely to cause errors Error guessing is based mostly upon
experience, with some assistance from other techniques such as boundary value
analysis. Based on experience, the test designer guesses the types of errors that
could occur in a particular type of software and designs test cases to uncover them.
E.g. – For example, if any type of resource is allocated dynamically, a good place to
look for errors is in the de-allocation of resources. Are all resources correctly deallocated,
or are some lost as the software executes?

1-d) Desk checking: -
Desk checking is conducted by the developer of the system or
program. The process involves reviewing the complete product to ensure that it is
structurally sound and that the standards and requirements have been met. This is
the most traditional means for analyzing a system or program.

1-e) Control Flow Analysis: -
It is based upon graphical representation of the
program process. In control flow analysis; the program graphs has nodes which
represent a statement or segment possibly ending in an unresolved branch. The
graph illustrates the flow of program control from one segment to another as
illustrated through branches .the objective of control flow analysis is to determine

the potential problems in logic branches that might result in a loop condition or
improper processing .