Software Testing - QTP, Manual Testing Automation Testing, Load Runner

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.

The most common approach to unit testing requires drivers and stubs to be written. The driver simulates a calling unit and the stub simulates a called unit. The investment of developer time in this activity sometimes results in demoting unit testing to a lower level of priority and that is almost always a mistake. Even though the drivers and stubs cost time and money, unit testing provides some undeniable advantages. It allows for automation of the testing process, reduces difficulties of discovering errors contained in more complex pieces of the application, and test coverage is often enhanced because attention is given to each unit.

Here are a few Best Practices:
1. The print out of a unit should reside on a single sheet of paper.
2. If there are more than 4 levels of nested unit, then maybe it should be split in two.
3. Whenever the cyclomatic complexness of a unit is greater than 10 then it's getting excessively complex.
4. Whenever it is content-coupled with another unit then it Is not a good unit.

The process is:
1. Prepare a test Plan of the unit tests.
2. Design the tests, the test environment, and operator instructions.
3. Identify and get the test data.
4. Code and run the tests.
5. Analyse the results.

Related Posts:

1. Unit Testing vs System Testing

2. Test Levels

Your Name
1234 Commonwealth Ave
Boston, USA-02134
1-234-567-0171 (Home)
1-234-567-0171 (Cell)
Youremail@gmail.com

Summary:

State this clearly in Bulleted points. This will make your achievements stand out:

Example:
• Has been working in the IT industry for more than eight and a half years and out of that over four years in SQA and testing arena.
• Has the ability and experience to understand the architecture and life cycle of a project in depth and would be an ideal candidate for a process oriented black box as well as white box testing and team management.
• Have in depth knowledge of processes and procedures needed in a professional performance management environment, well versed in testing methodologies as data driven tests, regression tests, code coverage, etc. and Mercury Interactive proprietary Test Scripting Language (TSL).

Skills/Tools:
The mentioned list below is quite comprehensive skill sets. But never list anything or too many thinks, particularly if you are writing fresher software testing resume with the hope that people wont able to catch it. Once you are hired, a falsehood on your resume can be grounds for termination. If your resume is examined as part of your promotion review, you could lose your job if someone finds a lie. Or, if your employer wants an excuse to fire you, he could investigate details on your resume with the hope of finding a lie.

• Testing Tools: Win Runner 6.0/5.0, Load Runner 6.0/5.0, Silk Test 5.03, Silk Performer 3.5, Silk Test Radar 2.1, Test Track 5.0, Silk Test 5.03
• Languages: Java, C++, C and Power Builder 4.0
• Internet: ASP, Java Script, VB Script, HTML, XML and DHTML
• GUI: Visual Basic 6.0/5.0/4.0/3.0, Oracle Forms 6i/4.5, Reports 6i/2.5, Crystal Reports 8.0/6.0
• Statistical Package: SAS
• Web Servers: IIS 5.0/4.0,Vignette Story Server, Web logic Server, SQL Server 7.0/6.0
• Middleware: COM/DCOM, MTS
• Trackers: PVCS Tracker, SQA Manager and Test Director
• IDE’s: Visual Interdev, Home Site and Cold Fusion RDBMS: SQL Server 7.0/6.5, Oracle 8i/7.x/6.0, MS-Access
• Operating Systems: Macintosh, Unix, Windows XP/2000/NT/98/95

Experience:

Company Name 1 and web site: It is a good practice to put the web site address so that people can find it quickly. Give the name of the latest company first.

May 2001 – Till date

Similarly put project # 2 and so on..

You can also use this format :
Company:  Company name.
Web site: www.xyz.com
Role:  Team Leader
Duration:  January 1999 to March 2001.

Responsibilities:
• Leading teams of developers/designers/testers, system analysis, and quality assurance.
• Designing, Planning, Executing White Box and Black Box tests.
• Planning and scheduling multiple projects as well as overall administration and management.
• Development of various e-commerce web sites.
• Administration and Maintenance of Windows 2000 Advanced Server based production network and MS SQL Server based database.
• Maintenance of web sites including content management, online database administration using MS SQL Server Enterprise Manager and performance analysis.
• Remote administration of collocated web server, Windows 2000/IIS5, through PcAnywhere.
• Remote administration of LINUX/Apache server through SSH.

Education:

• Master in Computer Applications (MCA)
• PG Diploma in Computer Application (PGDCA)

Personal Information:
Age and Date of Birth: 
Sex: 
Marital status: 
Nationality: 
Place of Birth: 
Religion: 
Permanent Address:.

Passport Details:
Passport Number: 
Date of Issue: 
Date of Expiration: 
Place of Issue:

Conclusion: Do not make your resume too long. On average try to keep it between 3 pages. Also if it is a Fresher Software Testing Resume then keep it in 1-2 pages only. If it is little more than one page then just try fit it into one page by doing little editing.

Happy Testing ツ

Whenever a piece of software is written, defects are inserted during development. The more effective the testing is in finding those defects, the fewer will escape into operation. For example, if 100 defects have been built into the software, and our testing only finds 50, then its DDP is 50%. If we had found 80 defects, we would have a DDP of 80%; if we had found only 35, our DDP would only have been 35%. Thus it is the escapes, those defects that escaped detection, which determine the quality of the detection process. Although we may never know the complete total of defects inserted, this measure is a very useful one, both for monitoring the testing process and for predicting future effort.

The basic definition of the Defect Detection Percentage is the number of defects found by testing, divided by the total known defects. Note that the total known defects consists of the number of defects found by (this) testing plus the total number of defects found afterwards. The scope of the testing represented in this definition may be a test phase such as system testing or beta testing, testing for a specific functional area, testing of a given project, or any other testing aspect which it is useful to monitor.

The total known defects found so far is a number that can only increase as time goes on, so the DDP computed will always go down over time.

DDP at different test stages or application areas DDP can be measured at different stages of software development and for different types of testing.
• Unit testing. Because testing at this stage is usually fairly informal, the best option is for each individual developer to track his or her own DDP, as a way to improve personal professionalism, as recommended
by Humphreys (1997).
• Link, integration, or system testing. The point at which software is turned over to a more formal process is normally the earliest practical point to measure DDP.
• Different application areas, such as functional areas, major subsystems, or commercial products. The DDP would not be the same over all groups, as they may have different test objectives, but over time this can help the test manager to plan the best value testing within limited constraints.

• DDP of early defect detection activities such as early test design and reviews or inspections. Early test design (the V-model) can find defects when they are much cheaper to fix, as can reviews and inspections. Knowing the DDP of these early activities as well as the test execution DDP can help the test manager to find the most cost effective mix of defect detection activities.

Traditional Practices

1.    Current Test Planning Methods include
a.    Using Percentage of Development Effort
i.    Depends on the accuracy of the Development Effort
ii.    Does not account revisit of Development Effort
b.    Using Tester Developer Ratio
i.    May not be same for all types of Projects
ii.    Does not consider the size of the Project
c.    Using KLOC
i.    Does not consider Complexity, Criticality & Priority of the Project.

What’s the Best Approach to Test Estimation?

There is no simple answer for this. The 'best approach' is highly dependent on the particular organization and project and the experience of the personnel involved.

For example, given two software projects of similar complexity and size, the appropriate test effort for one project might be very large if it was for life-critical medical equipment software, but might be much smaller for the other project if it was for a low-cost computer game. A test estimation approach that only considered size and complexity might be appropriate for one project but not for the other.

Approaches to Test Estimation

1. Implicit Risk Context Approach:

2. Metrics-Based Approach:

3. Test Work Breakdown Approach:

4. Iterative Approach:

5. Percentage-of-Development Approach:

   Test Estimation Process – A Practical Approach

1.    Combination of all the Approaches
2.    Considers Risk & Complexity Factors
3.    Based on Previous History i.e. Organization or Project Metrics
4.    Based on Work Breakdown Structure
5.    Based on Iterative Model

Elements of Test Estimation Process 

1.    Break sizing into smaller, easier to estimate tasks
a.    Decompose the test project into phases:

i.    System Test

ii.    Unit Test

b.    Decompose each phase into constituent activities:

i.    System Test Planning

ii.    Test Execution


c.    Decompose each activity into tasks and subtasks until each task or subtask at the lowest level of composition:


i.    Executing a test scenario
ii.    Writing a defect


2.    Taking risk priority into account
3.    Set up dependencies
a.    Dependent tasks internal to the test subproject.
b.    Document dependencies, resources, and tasks external to the test subproject (i.e., those that involve collaborative processes)
• Consider type of code (complex, reused, etc.)
• Augment professional judgment and gut instinct with previous project data, industry metrics, and so forth.
• Identify and, if possible, resolve discrepancies between the test subproject schedule and the project schedule.
• Use the work-breakdown-structure and schedule to develop a budget. Extract from your work-breakdown-structure a complete list of resources. For each resource, determine the first and last day of assignment to the project.
• If you have resources shared across multiple test projects within a given time period, understand the percentage allocation of each resource’s assignment to each project during various time periods.
• Revisit the Estimation continuously in order to reflect any change in the Project Requirements or Schedule
• Be Repeatable preferably Automat able

A Sample Estimation Process 

Total work = Test case time + Defect time
Test Case Time = Test Case Development time + Test Case Execution Time
Defect Time = (Hours/Defect * # Defects)

Note:  Consider the defect severities while arriving at Hours/Defect and also that Hours/Defect should take into account the Defect creation time, Debugging time and Defect Retesting time till the closure.

Test Case Time 

Test Case Development Time = (Hours/Test case development* #Test cases)
Test Case Execution Time = (Hours/Test case Execution  * #Test Cases)

Note:  Consider the Risk, Complexity while arriving at the Hours/Test case Development and Hours/Test case Execution.

Previous Test Estimation and Planning Topics:

1. Complete Tutorial on Test Plan

2. What is Traceability Matrix from Software Testing perspective?

3. Software Testing Strategy and Methodology

4. Plan Your Software Testing Activities

· Product Data (input, output, states, etc.)

· Platforms (external hardware and software)

Ways to Analyze

· Perform product/prototype walkthrough.

· Review product and project documentation.

· Interview designers and users.

· Compare w/similar products.

Possible Work Products

· Product coverage outline

· Annotated specifications

· Product Issue list

2. Analyze product risk.

What to Analyze

· Threats

· Product vulnerabilities

· Failure modes

· Victim impact

Ways to Analyze

· Review requirements and specifications.

· Review problem occurrences.

· Interview designers and users.

· Review product against risk heuristics and

quality criteria categories.

· Identify general fault/failure patterns.

Possible Work Products

· Component risk matrices

· Failure mode outline

3. Design test strategies.

General Strategies

· Domain testing (including boundaries)

· User testing

· Stress testing

· Regression testing

· Sequence testing

· State testing

· Specification-based testing

· Structural testing (e.g. unit testing)

Ways to Plan

· Match strategies to risks and product areas.

· Visualize specific and practical strategies.

· Look for automation opportunities.

· Prototype test probes and harnesses.

· Don’t over plan. Let testers use their brains.

Possible Work Products

· Itemized statement of each test strategy chosen and how

it will be applied.

· Risk/task matrix.

· List of issues or challenges inherent in the chosen

strategies.

· Advisory of poorly covered parts of the product.

· Test cases (if required)

4. Plan logistics.

Logistical Areas

· Test effort estimation and scheduling

· Testability engineering

· Test team staffing (right skills)

· Tester training and supervision

· Tester task assignments

· Product information gathering and

management

· Project meetings, communication, and

coordination

· Relations with all other project functions,

including development

· Test platform acquisition and configuration

Possible Work Products

· Issues list

· Project risk analysis

· Responsibility matrix

· Test schedule

· Agreements and protocols

· Test tools and automation

· Stubbing and simulation needs

· Test suite management and maintenance

· Build and transmittal protocol

· Test cycle administration

· Problem reporting system and protocol

· Test status reporting protocol

· Code freeze and incremental testing

· Pressure management in end game

· Sign-off protocol

· Evaluation of test effectiveness

5. Share the plan.

Ways to Share

· Engage designers and stakeholders in the

test planning process.

· Actively solicit opinions about the test plan.

· Do everything possible to help the

developers succeed.

· Help the developers understand how what

they do impacts testing.

· Talk to technical writers and technical

support people about sharing quality

information.

· Get designers and developers to review

and approve all reference materials.

· Record and reinforce agreements.

· Get people to review the plan in pieces.

· Improve reviewability by minimizing

unnecessary text in test plan documents.

Goals

· Common understanding of the test process.

· Common commitment to the test process.

· Reasonable participation in the test process.

· Management has reasonable expectations about the test process.

Previous Test Estimation and Planning Topics:

1. Complete Tutorial on Test Plan

2. What is Traceability Matrix from Software Testing perspective?

3. Software Testing Strategy and Methodology