Software Testing-Question Bank: Q. 41 to 50
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.
Continue to Next Part : Q 51 to 60
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.