Interview Questions for QA Tester

Software Quality Assurance Interview Questions and Answers

Q. 41: What are the common problems coming across Software Development
Process?

Common problems in software development process are:

1) Poor Projection of Requirements – Generally the users are not very clear in regards to
their exact needs. Most of the specifications given to Software Development Outsourcing
vendors are rough and very sketchy. Problems arise if the requirements are unclear,
incomplete, too general, and not testable etc.

2) Miscommunication – Becomes the main cause of problem when the developers remain
ignorant of the exact needs or expectations of the customer.

3) Unrealistic Schedules – Cause problems if too much work is crammed in too little time.

4) Inadequate Testing – Problems arise when the application has not been adequately tested
before giving it to the customer & the customer complains after using it or when there is a
systems crash.

<<<<<< =================== >>>>>>

Q. 42: What is the role of documentation in QA?

Documentation plays a critical role in QA. QA practices should be documented, so that they
are repeatable. Specifications, designs, business rules, inspection reports, configurations,
code changes, test plans, test cases, bug reports, user manuals should all be documented.
Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information.

<<<<<< =================== >>>>>>

Q. 43: What is Phase Containment and Defect Prevention?

Phase Containment is incorporating QA into all the phases of SDLC. It results in Defect
Prevention. If QA team performs Requirements Review, Design Review and Code Review,
defects would be few when actual application is tested. That means we have prevented
many defects by performing reviews at each stage of SDLC.

<<<<<< =================== >>>>>>

Q. 44: Why a Developer should not Test?

Of course, a developer can test, but he can’t be a good tester. If developers do the testing
of their own work or of the work of their peers, then the following problems crop up

1) Misunderstandings of the requirements or specifications may go unnoticed.

2) Under a given time frame, usual tendency of developers is to allocate more time in
improving the code or documentation rather than doing the testing of the code.

3) Developers have a tendency of being optimistic of producing a defect free code hence
‘under’ test the product.

4) Testing needs great skill, while an occasional tester with no prior training in testing
techniques is no match to a trained bug hunter whose sole activity is testing.

5) To uncover large number of bugs, tester needs to be aggressive. Whereas developer will
not be aggressive, if he is testing his own product.

Testers are rewarded if they hunt lots of bugs, developers are rewarded if the product they
developed has less number of bugs and this balance can only be maintained if the separate
teams exist for testing and development.

<<<<<< =================== >>>>>>

Q. 45: Out of Tester & Developer, who is most appropriate to do Unit Testing &
Integration Testing?

Of course Developers.

It is quite difficult for a tester to do unit testing and integration testing since it involves in-
depth understanding of the code. Hence developers should do the unit testing and
integration testing. While doing unit testing & integration testing, a few misinterpretation of
requirements might escape from the notice of the developer, but its better to test with
these issues rather than not testing at all.

For a better success, code developed by one developer, then his peer should do the unit
test.

<<<<<< =================== >>>>>>

Q. 46: What are the important Check Points for Installation Testing?

Installation testing of a new software application should be able to check points like

1) To check previously installed versions of the software or its dependent software or
patches like previously installed Service Packs. This is to ensure that older version of the
software should not get installed over the newer version.

2) Installer should be able to define Default Installation Path like “C:\Program Files\.”

3) Installer should be able to allow the user to install the new software at a location
different from the Default Installation Path.

4) To check if the product can be installed “Over the Network”

5) Installation should start automatically when the CD is inserted in the CD drive.

6) Software Remove / Repair options should be available to the user while using the
Installer.

7) While uninstalling the software, check that all the registry keys, files, Dll, shortcuts,
active X components are removed from the system.

8) To check if the product can be installed without Administrative Privileges (login as guest).

9) To check if the product can be installed on different operating systems.

10) To check if the product can be installed on a system having non-compliant configuration
like with less Memory / RAM / Hard Disc Capacity.

<<<<<< =================== >>>>>>

Q. 47: What is Installation Testing?

“Installation Testing” is performed to ensure that all the Installed features and options of
the software are functioning properly. Its main objective is to verify that all necessary
components of the application are actually installed or not without missing out any
component.

<<<<<< =================== >>>>>>

Q. 48: Do automated testing tools make testing easier?

For larger projects, or ongoing long-term projects, they can be valuable. But for small
projects, the time needed to learn and implement them is usually not worthwhile. A
common type of automated tool is the record/playback type. For example, a test engineer
clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI
and has an automated testing tool record and log the results. The recording is typically in
the form of text, based on a scripting language that the testing tool can interpret. If a
change is made (e.g. new buttons are added, or some underlying code in the application is
changed), the application is then retested by just playing back the recorded actions and
compared to the logged results in order to check effects of the change.

<<<<<< =================== >>>>>>

Q. 49: What should be done after a bug is found?

When a bug is found, it needs to be communicated and assigned to developers that can fix
it.

After the problem is resolved, fixes should be re-tested. Additionally, determinations should
be made regarding requirements, software, hardware, safety impact, etc., for regression
testing to check the fixes didn’t create other problems elsewhere.

If a problem-tracking system is in place, it should encapsulate these determinations. A
variety of commercial, problem-tracking/management software tools are available. These
tools, with the detailed input of software test engineers, will give the team complete
information so developers can understand the bug, get an idea

of its severity, reproduce it and fix it.

<<<<<< =================== >>>>>>

Q. 50: What to do when software is full of bugs & it can’t be tested at all?

In this situation the best solution is to have test engineers go through the process of
reporting whatever bugs or problems initially show up, with the focus being on critical bugs.

Since this type of problem can severely affect schedules and indicates deeper problems in
the software development process, such as insufficient unit testing, Insufficient integration
testing, poor design, improper build or release procedures, managers should be notified and
provided with some documentation as evidence of the problem.

Request for Free Demo @ QA Online Training.

Speak Your Mind

*