A tipical Test Plan content

Summery
Objectives
Test Approach and Assumptions
Major Test Responsibilities
Features and Functionality to Test
Expected Result of Tests
Deliverables
Test Documentation
Test Data
Interactions with Other organizations
Testing Procedures and Walkthrough
Testing Setup
Testing Procedure
Testing Walkthrough
Tracking and Reporting Status
Test Resource Requirements
Environmental Needs
Staffing & Training Needs
Test Tool Requirements
Bug Reporting Tools and Methods
Bug Reporting Tool Strategy
Bug Classification Strategy
Triage Strategy
Bug Closure Ciretria
Schedule
Risks & Dependencies
Open Issues
Appendix
Appendix A - Test Case Specification Example

ISO Certification standards in Quality Assurance perspective

The ISO 9001:2000 Quality Management System certification enables you to demonstrate your commitment to quality and customer satisfaction, as well as continuously improving your quality systems and integrating the realities of a changing world

ISO 9001:2000 is based on eight quality management principles

customer focus
leadership
involvement of people
process approach
system approach
continual improvement
fact-based decision making
mutually beneficial supplier relationships

whats is testing effort estimation

Effort estimation can be done, based on different techniques available like Function Point Analysis, COCOMO, Use Case Point Analysis, Test Case Point Analysis, Metrics based.

Effort estimation is basically done any of the above techniques for different test activities like Test Case Preparation, Automation Script Creation and Test Execution.

Let me explain the metrics based and very commonly used effort estimation procedure in doing effort estimation for Yahoo Mail application.


Identify the requirements (Login Page, Inbox, Compose, Address)

Classify the requirements in different complexity (Simple, Average, High)

Based on the past experience, metrics will be collected on how much time it took to write test case for simple, average and high functionality. Similarly it is collected for other testing
activities.

Now multiply your complexity with the time factor which you derived from metrics to calculate the effort.

Don't report the total has your total effort, always use buffer time, it various based on the domain, tool and other factors. Example we use 20% on the previous total. This buffer will save you
on risk and other deadline factors

Now add you the buffer time and the effort calculated from metrics, and this is your Total effort for the activity.

Test Case Point Analysis: You can use this effort estimation technique
for Test Automation and Test Execution.

1. Identify the total number of test cases to be automated or executed.
2. Classify the steps into High, Medium and Low complexity based on the
business process it performs.
3. Based on the previous experience (metrics based) on how much time it
would take to execute High complexity steps. You can have the average
time.
4. Multiply this average time with total number of steps and get the
total
5. Add the buffer time with the total to get Final estimation time. This
buffer time will vary based on the application, domain and other
factors.

Most of these effort estimation techniques use Metrics Based, which you are going to calculate the actual time for all effort and then take the average.

Manual Testing or Automation Testing

Here are few points to share on Manual Testing or Automation Testing:

1) Any Automation testing scripts can cover only 60 to 80 % of entire product testing

2) There should be separate team other than testing team to develop and maintain automation test scripts Should never mix testing team and automation test script development team.

3) Automation is good for the products where software product is tending to stable condition and there are marginal feature changes in next coming releases. Here the manual testing team is moved to some other product testing assignment and test scripts are sufficient to check core features of the software product.

4) Automation and manual testing should be of right mix. Manual testing can not be avoided.

5) It is decision of project manager for budgeting the automation test script development.

6) Certainly, there are pros and cons for both manual and automation testing.

7) The decision based on type of the application, type of the resources available[software, hardware and human] , product deliverable time line and most important - the budget.

What is the Bug Free Zone?

The Bug Free Zone is a membership-based community of professionals sponsored by the International Institute for Software Testing providing a wealth of information for software test and QA professionals.

- Get acess to Articles - Software Testing Articles written by practitioners for practitioners

- Get access to Conference Presentations – Complete decks from past PSQT Conferences

- Get access to Test Process Templates - Downloadable templates for different tasks in the test process.

- Discussion Board - Communicate and Interact with other QA and Test Professionals.

- Download papers on different Testing and QA Topics

- Get access to the IIST Unified Testing Terminology

- Listen to Industry experts offering software quality and testing tips on a regular basis

- Post jobs or look at job postings

- Get answers to many questions you may have on different testing and QA topics

Membership is free at http://www.iist.org

Development hours Vs QA hours

Variable that change ratio of development hours to QA hours.

• Are the QA and Dev teams equivalently skilled between the 2 projects?

• Are the QA and Dev teams equivalently knowledgable between the 2 projects?
  

• In the business envrionment similar between the 2 projects?
  

• Is the Development model similar between the 2 projects?
  

• Is the structure of the 2 projects similar? (testing an engancement to an existing system is a vastly different animal from testing new development)
  

• Are the breakdown of responsibilities for each team the same between the 2 projects?(maybe in 1 Dev handles Configuration Management and deployment, in another QA Does for example)
  

• Do both Projects have similar data requirements? (testing a system which has a large database behind it is vastly different from tesing one with a rudimentary one)
  

• Do both Projects have similar target audiences? (Code intended for trained specialists has different requirements from code intended for the general public)
  

• Do both Projects run in the same sets of operational envrionments? (Hardware, OS, Browser, JDK, .Net Framework, etc.)
  

• Do both projects support the same number of sets of operational envrionments

And that is just off the top of my head I have come up with 10 variables that will vastly change the ratio of development time to QA time and I'm sure there are at least another 10 I've missed.

So really the discussion needs to be not on what percentage of development hours should QA take but rather how do we accurately estimate how long it will take to test a project. We also need to be vigilant and immediately challenge ANYONE who mentions a ratio between Development hours and QA hours in any context except "Well Project X is similar to Project Y and in Project X QA time was Z% of Dev time so in Project Y the Ratio should be close to Z%".

open source bug tracking systems

Only few open source bug tracking systems are known to me.

1. mantis – which is easy to use comparing to bugzilla and easy to set up.
   

2. Eventum - customizable open source bug tracking system can be used in matured QA process.
   

3. bugzilla - open source bug tracking system with web based interface and setup takes little more time comparing to mantis. Advance report generation option is great.

Define integration testing

When one piece of code, or a unit, needs to interact with another, it's an interface. When we are working on interfacing the two units, we are integrating them. Testing this integration is called an integration testing. It follows unit testing and is before system testing. Therefore it is primarily a white box technique. Please see http://en.wikipedia .org/wiki/Integration_ testing However integrating the GUI with the underlying functionality is also integration testing and is best done as a black box test

Quality Processes

In general, a quality process is one designed to manage quality by the application of quality assurance (methods, standards), quality control (measurement and correction), and quality improvement (process improvement). More specifically, a quality process is a process of conducting any of the above.

Measuring the performance of a Software Quality Assurance Engineer using Bug count

Some companies evaluate their QA resources on number of defects reported per day. I would say that this is totally irrelevant measure to judge any QA guy performance coz QA guy performance have a lot of other things beyond reported bugs. For example, effective Planning, documentation, handling issues among teams, to resolve the bugs and any kid of issues among QA department and Dev department, analytical skills etc.

Bug Severity vs Priority

Severity - refers to the effect the bug has on the functionality of the application

Priority - refers to how soon the bug has to be fixed.

If we term the priorities as P1, P2 , P3 and P4, where P1 is the High priority issue and P4 is the low priority,

we can define the Severity as follows.

P1 - Complete loss of service(of the application)-
showstopper

P2 - Severe loss of service- business logic issues

P3 - Minimal loss of service - which will not effect the core business logic but still must be resolved

P4 - Needs improvement - all the UI issues.

Most of the times, a tester assigns the severity and Leads will assign the priority

QA Engineer / Tester Vs Developer

As for the salaries. It is true that Developers make more money than an equivalently skilled an experienced Tester/QA. There are several reasons for this.

First: In Testing there are a great many tasks which can be done by someone with very little technical skills or knowledge (But I always belive every tester should be technical). Indeed in some envrionments there are manual testing tasks which can be done by those who simply lack the intelligence necessary to work as a developer. There are no equivalent development tasks.

Second: Testers do not produce revenue Developers do. Quality is an impossible concept to sell on it's own and nearly as difficult to market. Outside of QA Outsourcing firms no company has ever made money off of it's Quality department. The Developers are the ones who make the products the company sells, all the Quality department can do is act as a "Force Multiplier" we can make other departments more efficient and effective but we can not produce revenue. So when it comes to allocating money for salaries to different departments it is the departments who actually generate revenue that get the bulk of the money.

Third: Generally speaking 1 tester can test the work of more than 1 developer, there are occasional exceptions where the test team has more manpower than the development team but in the overwhelming majority of cases there are fewer testers than developers. Add to that the fact that there are more people capable of being a tester than of being a developer (it requires much less training to begin working as a tester than it does as a developer). Simple supply and demand rules will then have testers making less than developers all other things being equal.

Now the one area where testers have an advantage is that at the start of our careers it is much easier to move up in the ranks quickly, especially if you have a degree in some form of technical field and knowledge of one or more development languages which is probably why some have reported that they are "ahead" of their counterparts who started with the company at the same time but took a developmet path.