Manual Testing Interview Questions
Manual Testing Interview Questions
with developers, and an ability to communicate with both technical (developers) and
non-technical (customers, management) people is useful. Previous software
development experience can be helpful as it provides a deeper understanding of the
software development process, gives the tester an appreciation for the developers' point
of view, and reduce the learning curve in automated test tool programming. Judgement
skills are needed to assess high-risk areas of an application on which to focus testing
efforts when time is limited.
1.What are some recent major computer system failures caused by software
bugs?
• A major U.S. retailer was reportedly hit with a large government fine in October of
2003 due to web site errors that enabled customers to view one anothers' online orders.
• News stories in the fall of 2003 stated that a manufacturing company recalled all their
transportation products in order to fix a software problem causing instability in certain
circumstances. The company found and reported the bug itself and initiated the recall
procedure in which a software upgrade fixed the problems.
• In August of 2003 a U.S. court ruled that a lawsuit against a large online brokerage
company could proceed; the lawsuit reportedly involved claims that the company was
not fixing system problems that sometimes resulted in failed stock trades, based on the
experiences of 4 plaintiffs during an 8-month period. A previous lower court's ruling that
"...six miscues out of more than 400 trades does not indicate negligence." was
invalidated.
• In April of 2003 it was announced that the largest student loan company in the U.S.
made a software error in calculating the monthly payments on 800,000 loans. Although
borrowers were to be notified of an increase in their required payments, the company
will still reportedly lose $8 million in interest. The error was uncovered when borrowers
began reporting inconsistencies in their bills.
• News reports in February of 2003 revealed that the U.S. Treasury Department mailed
50,000 Social Security checks without any beneficiary names. A spokesperson indicated
that the missing names were due to an error in a software change. Replacement checks
were subsequently mailed out with the problem corrected, and recipients were then able
to cash their Social Security checks.
• In March of 2002 it was reported that software bugs in Britain's national tax system
resulted in more than 100,000 erroneous tax overcharges. The problem was partly
attibuted to the difficulty of testing the integration of multiple systems.
• A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-
shelf software that had long been used in systems for tracking certain U.S. nuclear
materials. The same software had been recently donated to another country to be used
in tracking their own nuclear materials, and it was not until scientists in that country
discovered the problem, and shared the information, that U.S. officials became aware of
the problems.
• According to newspaper stories in mid-2001, a major systems development contractor
was fired and sued over problems with a large retirement plan management system.
According to the reports, the client claimed that system deliveries were late, the
software had excessive defects, and it caused other systems to crash.
• In January of 2001 newspapers reported that a major European railroad was hit by the
aftereffects of the Y2K bug. The company found that many of their newer trains would
not run due to their inability to recognize the date '31/12/2000'; the trains were started
by altering the control system's date settings.
• News reports in September of 2000 told of a software vendor settling a lawsuit with a
large mortgage lender; the vendor had reportedly delivered an online mortgage
processing system that did not meet specifications, was delivered late, and didn't work.
• In early 2000, major problems were reported with a new computer system in a large
suburban U.S. public school district with 100,000+ students; problems included 10,000
erroneous report cards and students left stranded by failed class registration systems;
the district's CIO was fired. The school district decided to reinstate it's original 25-year
old system for at least a year until the bugs were worked out of the new system by the
software vendors.
• In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was
believed to be lost in space due to a simple data conversion error. It was determined
that spacecraft software used certain data in English units that should have been in
metric units. Among other tasks, the orbiter was to serve as a communications relay for
the Mars Polar Lander mission, which failed for unknown reasons in December 1999.
Several investigating panels were convened to determine the process failures that
allowed the error to go undetected.
• Bugs in software supporting a large commercial high-speed data network affected
70,000 business customers over a period of 8 days in August of 1999. Among those
affected was the electronic trading system of the largest U.S. futures exchange, which
was shut down for most of a week as a result of the outages.
• In April of 1999 a software bug caused the failure of a $1.2 billion U.S. military satellite
launch, the costliest unmanned accident in the history of Cape Canaveral launches. The
failure was the latest in a string of launch failures, triggering a complete military and
industry review of U.S. space launch programs, including software integration and
testing processes. Congressional oversight hearings were requested.
• A small town in Illinois in the U.S. received an unusually large monthly electric bill of
$7 million in March of 1999. This was about 700 times larger than its normal bill. It
turned out to be due to bugs in new software that had been purchased by the local
power company to deal with Y2K software issues.
• In early 1999 a major computer game company recalled all copies of a popular new
product due to software problems. The company made a public apology for releasing a
product before it was ready.
2.Why is it often hard for management to get serious about quality assurance?
Solving problems is a high-visibility process; preventing problems is low-visibility. This is
illustrated by an old parable:
In ancient China there was a family of healers, one of whom was known throughout the
land and employed as a physician to a great lord. The physician was asked which of his
family was the most skillful healer. He replied,
"I tend to the sick and dying with drastic and dramatic treatments, and on occasion
someone is cured and my name gets out among the lords."
"My elder brother cures sickness when it just begins to take root, and his skills are
known among the local peasants and neighbors."
"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes
form. His name is unknown outside our home."
If there are too many unrealistic 'no problem's', the result is bugs.
• poorly documented code - it's tough to maintain and modify code that is badly written
or poorly documented; the result is bugs. In many organizations management provides
no incentive for programmers to document their code or write clear, understandable,
maintainable code. In fact, it's usually the opposite: they get points mostly for quickly
turning out code, and there's job security if nobody else can understand it ('if it was hard
to write, it should be hard to read').
• software development tools - visual tools, class libraries, compilers, scripting tools, etc.
often introduce their own bugs or are poorly documented, resulting in added bugs.
6.What is a 'walkthrough'?
A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or
no preparation is usually required.
7.What's an 'inspection'?
An inspection is more formalized than a 'walkthrough', typically with 3-8 people including
a moderator, reader, and a recorder to take notes. The subject of the inspection is
typically a document such as a requirements spec or a test plan, and the purpose is to
find problems and see what's missing, not to fix anything. Attendees should prepare for
this type of meeting by reading thru the document; most problems will be found during
this preparation. The result of the inspection meeting should be a written report.
Thorough preparation for inspections is difficult, painstaking work, but is one of the most
cost effective methods of ensuring quality. Employees who are most skilled at
inspections are like the 'eldest brother' in the parable in 'Why is it often hard for
management to get serious about quality assurance?'. Their skill may have low visibility
but they are extremely valuable to any software development organization, since bug
prevention is far more cost-effective than bug detection.
Manual Testing Interview Questions - 4 1.What are 5 common problems in the software
development process?
• poor requirements - if requirements are unclear, incomplete, too general, or not
testable, there will be problems.
• unrealistic schedule - if too much work is crammed in too little time, problems are
inevitable.
• inadequate testing - no one will know whether or not the program is any good until the
customer complains or systems crash.
• featuritis - requests to pile on new features after development is underway; extremely
common.
• miscommunication - if developers don't know what's needed or customer's have
erroneous expectations, problems are guaranteed.
2.What are 5 common solutions to software development problems?
• solid requirements - clear, complete, detailed, cohesive, attainable, testable
requirements that are agreed to by all players. Use prototypes to help nail down
requirements.
• realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-
testing, changes, and documentation; personnel should be able to complete the project
without burning out.
• adequate testing - start testing early on, re-test after fixes or changes, plan for
adequate time for testing and bug-fixing.
• stick to initial requirements as much as possible - be prepared to defend against
changes and additions once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be adequately reflected in related
schedule changes. If possible, use rapid prototyping during the design phase so that
customers can see what to expect. This will provide them a higher comfort level with
their requirements decisions and minimize changes later on.
• communication - require walkthroughs and inspections when appropriate; make
extensive use of group communication tools - e-mail, groupware, networked bug-
tracking tools and change management tools, intranet capabilities, etc.; insure that
documentation is available and up-to-date - preferably electronic, not paper; promote
teamwork and cooperation; use protoypes early on so that customers' expectations are
clarified.
For C and C++ coding, here are some typical ideas to consider in setting
rules/standards; these may or may not apply to a particular situation:
• minimize or eliminate use of global variables.
• use descriptive function and method names - use both upper and lower case, avoid
abbreviations, use as many characters as necessary to be adequately descriptive (use of
more than 20 characters is not out of line); be consistent in naming conventions.
• use descriptive variable names - use both upper and lower case, avoid abbreviations,
use as many characters as necessary to be adequately descriptive (use of more than 20
characters is not out of line); be consistent in naming conventions.
• function and method sizes should be minimized; less than 100 lines of code is good,
less than 50 lines is preferable.
• function descriptions should be clearly spelled out in comments preceding a function's
code.
• organize code for readability.
• use whitespace generously - vertically and horizontally
• each line of code should contain 70 characters max.
• one code statement per line.
• coding style should be consistent throught a program (eg, use of brackets,
indentations, naming conventions, etc.)
• in adding comments, err on the side of too many rather than too few comments; a
common rule of thumb is that there should be at least as many lines of comments
(including header blocks) as lines of code.
• no matter how small, an application should include documentaion of the overall
program function and flow (even a few paragraphs is better than nothing); or if possible
a separate flow chart and detailed program documentation.
• make extensive use of error handling procedures and status and error logging.
• for C++, to minimize complexity and increase maintainability, avoid too many levels of
inheritance in class heirarchies (relative to the size and complexity of the application).
Minimize use of multiple inheritance, and minimize use of operator overloading (note
that the Java programming language eliminates multiple inheritance and operator
overloading.)
• for C++, keep class methods small, less than 50 lines of code per method is
preferable.
• for C++, make liberal use of exception handlers
Level 4 - metrics are used to track productivity, processes, and products. Project
performance is predictable, and quality is consistently high.
Level 5 - the focus is on continouous process improvement. The impact of new processes
and technologies can be predicted and effectively implemented when required.
• IEEE = 'Institute of Electrical and Electronics Engineers' - among other things, creates
standards such as 'IEEE Standard for Software Test Documentation' (IEEE/ANSI
Standard 829), 'IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008),
'IEEE Standard for Software Quality Assurance Plans' (IEEE/ANSI Standard 730), and
others.
• ANSI = 'American National Standards Institute', the primary industrial standards body
in the U.S.; publishes some software-related standards in conjunction with the IEEE and
ASQ (American Society for Quality).
• Other software development process assessment methods besides CMM and ISO 9000
include SPICE, Trillium, TickIT. and Bootstrap.
The life cycle begins when an application is first conceived and ends when it is no longer
in use. It includes aspects such as initial concept, requirements analysis, functional
design, internal design, documentation planning, test planning, coding, document
preparation, integration, testing, maintenance, updates, retesting, phase-out, and other
aspects.