Software Testing Notes

Software Testing Notes Discussion forum " Software Testing Notes"

27/06/2012

Elements of a Test Case
Every test case must have the following details:


Anatomy of a Test Case

Test Case ID



Requirement # / Section:



Objective: [What is to be verified? ]



Assumptions & Prerequisites



Steps to be executed:



Test data (if any): [Variables and their values ]



Expected result:



Status: [Pass or Fail with details on Defect ID and proofs [o/p files, screenshots

27/06/2012

1. On which basis we give priority and severity for a bug and give one example for high priority and low severity and high severity and low priority?
Always the priority is given by team leader or Business Analyst. Severity is given by the reporter of bug. For example, High severity: hardware bugs application crash. Low severity: User interface bugs. High priority: Error message is not coming on time, calculation bugs etc. Low priority: Wrong alignment, etc

2. What do you mean by reproducing the bug? If the bug was not reproducible, what is the next step?
If you find a defect, for example click the button and the corresponding action didn’t happen, it is a bug. If the developer is unable to find this behaviour he will ask us to reproduce the bug. In another scenario, if the client complaints a defect in the production we will have to reproduce it in test environment.

If the bug was not reproducible by developer, then bug is assigned back to reporter or goto meeting or informal meeting (like walkthrough) is arranged in order to reproduce the bug. Sometimes the bugs are inconsistent, so that that case we can mark the bugs as inconsistent and temporarily close the bug with status working fine now.

3. What is the responsibility of a tester when a bug which may arrive at the time of testing. Explain?
First check the status of the bug, then check whether the bug is valid or not then forward the same bug to the team leader and then after confirmation forward it to the concern developer.

If we cannot reproduce it, it is not reproducible in which case we will do further testing around it and if we cannot see it we will close it, and just hope it would never come back ever again.

4. How can we design the test cases from requirements? Do the requirements, represent exact functionality of AUT?
Ofcourse, requirements should represents exact functionality of AUT.
First of all you have to analyze the requirements very thoroughly in terms of functionality. Then we have to think about suitable test case design technique [Black Box design techniques like Specification based test cases, functional test cases, Equivalence Class Partitioning (ECP), Boundary Valve Analysis (BVA), Error guessing and Cause Effect Graphing] for writing the test cases.
By these concepts you should design a test case, which should have the capability of finding the absence of defects.

Read: Art of Test case writing

5. How to launch the test cases in Quality Centre (Test Director) and where it is saved?
You create the test cases in the test plan tab and link them to the requirements in the requirement tab. Once the test cases are ready we change the status to ready and go to the “Test Lab” Tab and create a test set and add the test cases to the test set and you can run from there.
For automation, in test plan, create a new automated test and launch the tool and create the script and save it and you can run from the test lab the same way as you did for the manual test cases.
The test cases are sorted in test plan tab or more precisely in the test director, lets say quality centers database. test director is now referred to as quality center.

6. How is traceability of bug follow?
The traceability of bug can be followed in so many ways.
1. Mapping the functional requirement scenarios(FS Doc) - test cases (ID) - Failed test cases(Bugs)
2. Mapping between requirements(RS Doc) - Test case (ID) - Failed test cases.
3. mapping between test plan (TP Doc) - test case (ID) - failed test cases.
4. Mapping between business requirements (BR Doc) - test cases (ID) - Failed test cases.
5. Mapping between high level design(Design Doc) - test cases (ID) - Failed test cases.
Usually the traceability matrix is mapping between the requirements, client requirements, function specification, test plan and test cases.

7. What is the difference between use case, test case, test plan?
Use Case: It is prepared by Business analyst in the Functional Requirement Specification(FRS), which are nothing but a steps which are given by the customer.
Test cases: It is prepared by test engineer based on the use cases from FRS to check the functionality of an application thoroughly
Test Plan: Team lead prepares test plan, in it he represents the scope of the test, what to test and what not to test, scheduling, what to test using automation etc.

18/06/2012

What are you going to do if there is no Functional Spec or any documents related to the system and developer who wrote the code does not work in the company anymore, but you have system and need to test?

A. A typical situation in Indian companies! Right? Due to high attrition rate
In this case fist you will need to do the exploratory testing of the product. In this testing you will come to know the system and its basic workflow. In exploratory testing you can also find some ‘blocker’ bugs that cause system to be crash.

If you are a white box tester then next step you can do is to see the different module code. By this you will know the test cases for different modules and relation of modules.

18/06/2012

1. In an application currently in production, one module of code is being modified. Is it necessary to re-test the whole application or is it enough to just test functionality associated with that module?

A. Well, the answer is both. You will have to test the functionality of that module as well as the other modules. But you can differentiate on the stress to be given on the module to be tested.

I think this scenario will explain the answer to your question well.

If Module A is modified, Module B is depending on module A, and Module C is a general module independent of module A.
So in this case you will test the module A in depth to all test cases. Then your next stress will be on module B. Wait now what about module C? You will have to test this module as well but may be with less stress because module C is not depend on module A but may be depend on module B.
Again if you are a white box tester you probably know which modules will get affected and which modules should be tested. But as a black box tester you will need to do regression testing as well.

18/06/2012

Q: What is difference between Performance Testing, Load Testing and Stress Testing?

A. 1) Performance Testing:

Performance testing is the testing, which is performed, to ascertain how the components of a system are performing, given a particular situation. Resource usage, scalability and reliability of the product are also validated under this testing. This testing is the subset of performance engineering, which is focused on addressing performance issues in the design and architecture of software product.

Performance Testing Goal:

The primary goal of performance testing includes establishing the benchmark behaviour of the system. There are a number of industry-defined benchmarks, which should be met during performance testing.

Performance testing does not aim to find defects in the application, it address a little more critical task of testing the benchmark and standard set for the application. Accuracy and close monitoring of the performance and results of the test is the primary characteristic of performance testing.

Example:

For instance, you can test the application network performance on Connection Speed vs. Latency chart. Latency is the time difference between the data to reach from source to destination. Thus, a 70kb page would take not more than 15 seconds to load for a worst connection of 28.8kbps modem (latency=1000 milliseconds), while the page of same size would appear within 5 seconds, for the average connection of 256kbps DSL (latency=100 milliseconds).1.5mbps T1 connection (latency=50 milliseconds) would have the performance benchmark set within 1 second to achieve this target.

For example, the time difference between the generation of request and acknowledgement of response should be in the range of x ms (milliseconds) and y ms, where x and y are standard digits. A successful performance testing should project most of the performance issues, which could be related to database, network, software, hardware etc…
1.5mbps T1 connection (latency=50 milliseconds) would have the performance benchmark set within 1 second to achieve this target.

For example, the time difference between the generation of request and acknowledgement of response should be in the range of x ms (milliseconds) and y ms, where x and y are standard digits. A successful performance testing should project most of the performance issues, which could be related to database, network, software, hardware etc…

2) Load Testing:

Load testing is meant to test the system by constantly and steadily increasing the load on the system till the time it reaches the threshold limit. It is the simplest form of testing which employs the use of automation tools such as LoadRunner or any other good tools, which are available. Load testing is also famous by the names like volume testing and endurance testing.

The sole purpose of load testing is to assign the system the largest job it could possible handle to test the endurance and monitoring the results. An interesting fact is that sometimes the system is fed with empty task to determine the behaviour of system in zero-load situation.

Load Testing Goal:

The goals of load testing are to expose the defects in application related to buffer overflow, memory leaks and mismanagement of memory. Another target of load testing is to determine the upper limit of all the components of application like database, hardware and network etc… so that it could manage the anticipated load in future. The issues that would eventually come out as the result of load testing may include load balancing problems, bandwidth issues, capacity of the existing system etc…

Example:

For example, to check the email functionality of an application, it could be flooded with 1000 users at a time. Now, 1000 users can fire the email transactions (read, send, delete, forward, reply) in many different ways. If we take one transaction per user per hour, then it would be 1000 transactions per hour. By simulating 10 transactions/user, we could load test the email server by occupying it with 10000 transactions/hour.


3) Stress testing

Under stress testing, various activities to overload the existing resources with excess jobs are carried out in an attempt to break the system down. Negative testing, which includes removal of the components from the system is also done as a part of stress testing. Also known as fatigue testing, this testing should capture the stability of the application by testing it beyond its bandwidth capacity.

The purpose behind stress testing is to ascertain the failure of system and to monitor how the system recovers back gracefully. The challenge here is to set up a controlled environment before launching the test so that you could precisely capture the behaviour of system repeatedly, under the most unpredictable scenarios

Stress Testing Goal:

The goal of the stress testing is to analyse post-crash reports to define the behaviour of application after failure. The biggest issue is to ensure that the system does not compromise with the security of sensitive data after the failure. In a successful stress testing, the system will come back to normality along with all its components, after even the most terrible break down.

Example:

As an example, a word processor like Writer1.1.0 by OpenOffice.org is utilized in development of letters, presentations, spread sheets etc… Purpose of our stress testing is to load it with the excess of characters.

To do this, we will repeatedly paste a line of data, till it reaches its threshold limit of handling large volume of text. As soon as the character size reaches 65,535 characters, it would simply refuse to accept more data. The result of stress testing on Writer 1.1.0 produces the result that, it does not crash under the stress and that it handle the situation gracefully, which make sure that application is working correctly even under rigorous stress conditions.

08/11/2011

Why is Software Testing Important????

1. To discover defects.

2. To prove that the software has no faults ..
3. To learn about the reliability of the software.

4. To ensure that product works as user expected.

5. To stay in business

6. To detect defects early, which helps in reducing the cost of defect fixing?

08/11/2011

What is Software Testing ??

It is the process of Creating, Implementing and Evaluating tests.

Address

Shiv Nagar
Delhi
110058

Telephone

9873829629

Website

Alerts

Be the first to know and let us send you an email when Software Testing Notes posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Share