Tools Interview Questions -
- 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."
- Why does software have bugs?
- miscommunication or no communication - as
to specifics of what an application should or shouldn't do (the
- software complexity - the complexity of
current software applications can be difficult to comprehend for anyone
without experience in modern-day software development. Multi-tiered
applications, client-server and distributed applications, data
communications, enormous relational databases, and sheer size of
applications have all contributed to the exponential growth in
- programming errors - programmers, like
anyone else, can make mistakes.
- changing requirements (whether documented
or undocumented) - the end-user may not understand the effects of changes,
or may understand and request them anyway - redesign, rescheduling of
engineers, effects on other projects, work already completed that may have
to be redone or thrown out, hardware requirements that may be affected,
etc. If there are many minor changes or any major changes, known and
unknown dependencies among parts of the project are likely to interact and
cause problems, and the complexity of coordinating changes may result in
errors. Enthusiasm of engineering staff may be affected. In some
fast-changing business environments, continuously modified requirements
may be a fact of life. In this case, management must understand the
resulting risks, and QA and test engineers must adapt and plan for
continuous extensive testing to keep the inevitable bugs from running out
- time pressures - scheduling of software
projects is difficult at best, often requiring a lot of guesswork. When
deadlines loom and the crunch comes, mistakes will be made.
- egos - people prefer to say things like:
'piece of cake'
'I can whip that out in a few hours'
'it should be easy to update that old code'
'that adds a lot of complexity and we could end up
making a lot of mistakes'
'we have no idea if we can do that; we'll wing it'
'I can't estimate how long it will take, until I
take a close look at it'
'we can't figure out what that old spaghetti code
did in the first place'
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
- software development tools - visual tools,
class libraries, compilers, scripting tools, etc. often introduce their
own bugs or are poorly documented, resulting in added bugs.
How can new Software QA processes be
introduced in an existing organization?
- A lot depends on the size of the
organization and the risks involved. For large organizations with
high-risk (in terms of lives or property) projects, serious management
buy-in is required and a formalized QA process is necessary.
- Where the risk is lower, management and
organizational buy-in and QA implementation may be a slower,
step-at-a-time process. QA processes should be balanced with productivity
so as to keep bureaucracy from getting out of hand.
- For small groups or projects, a more ad-hoc
process may be appropriate, depending on the type of customers and
projects. A lot will depend on team leads or managers, feedback to
developers, and ensuring adequate communications among customers,
managers, developers, and testers.
- The most value for effort will often be in
(a) requirements management processes, with a goal of clear, complete,
testable requirement specifications embodied in requirements or design
documentation, or in 'agile'-type environments extensive continuous
coordination with end-users, (b) design inspections and code inspections,
and (c) post-mortems/retrospectives.
What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents,
plans, code, requirements, and specifications. This can be done with
checklists, issues lists, walkthroughs, and inspection meetings. Validation
typically involves actual testing and takes place after verifications are
completed. The term 'IV & V' refers to Independent Verification and
What is a 'walkthrough'?
A 'walkthrough' is an informal meeting for evaluation or informational
purposes. Little or no preparation is usually required.
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.
Search more content related to TESTING...
more resources coming soon.....keep visiting..