Software Testing FAQ-3

What is test Metrics?
Test metrics contains follwoing details:
Total test
Test run
Test passed
Test failed
Tests deferred
Test passed the first time

What is the use of Metrics?
Provide the accurate measurement of test coverage.

If you have shortage of time, how would you prioritize you testing?
Use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. Considerations can include:
Which functionality is most important to the project's intended purpose?
Which functionality is most visible to the user?
Which functionality has the largest safety impact?
Which functionality has the largest financial impact on users?
Which aspects of the application are most important to the customer?
Which aspects of the application can be tested early in the development cycle?
Which parts of the code are most complex, and thus most subject to errors?
Which parts of the application were developed in rush or panic mode?
Which aspects of similar/related previous projects caused problems?
Which aspects of similar/related previous projects had large maintenance expenses?
Which parts of the requirements and design are unclear or poorly thought out?
What do the developers think are the highest-risk aspects of the application?
What kinds of problems would cause the worst publicity?
What kinds of problems would cause the most customer service complaints?
What kinds of tests could easily cover multiple functionalities?
Which tests will have the best high-risk-coverage to time-required ratio?


What is the impact of environment on the actual results of performance testing?
Environment plays an important role in the results and effectiveness of test, particularly in the area of performance testing. Some of the factors will be under our control, while others will not be. These may involve the DBMS, the operating system or the network. Some of the items that we cannot control unless you can secure a stand-alone environment (which will generally be unrealistic) are:
- Other traffic on the network
- Other process running on the server
- Other process running on the DBMS

What is stress testing, performance testing, Security testing, Recovery testing and volume testing.
Stress testing: Testing the system if it can handle peak usage period loads that result from large number of simultaneous users, transactions or devices. Monitoring should be performed for throughput and system stability.

Performance Testing: Testing the system whether the system functions are being performed in an acceptable timeframe under simultaneous user load. Timings for both read and update transactions should be gathered to determine whether. This should be done stand-alone and then in a multi-user environment to determine the transaction throughput.

Security Testing: Testing the system for its security from unauthorized use and unauthorized data access.

Recovery Testing: Testing a system to see how it responds to errors and abnormal conditions, such as system crash, loss of device, communications, or power.

Volume Testing: Testing to the system to determine if it can correctly process large volumes of data fed to the system. Systems can often respond unpredictably when large volume causes files to overflow and need extensions.

What criteria you will follow to assign severity and due date to the MR?
Defects (MR) are assigned severity as follows:
Critical: show stoppers (the system is unusable)
High: The system is very hard to use and some cases are prone to convert to critical issues if not taken care of.
Medium: The system functionality has a major bug but is not too critical but needs to be fixed in order for the AUT to go to production environment.
Low: cosmetic (GUI related)