India all set to rule software testing market

India is all set to become a leader in the software testing market with an increasing number of software development companies outsourcing their software testing work here. Industry analyst firm Gartner has pegged the worldwide software testing market at $13 billion and the global market for outsourced testing services to be around $6.1 billion, of which India is expected to corner a 70% share.

Software testing implies checking any IT system prior to implementation for multiple aspects like functionality, reliability, usability, security, compliance and performance. Market players like Hexaware and AppLabs believe that the need for outsourcing software testing has grown due to the high level of complexity and multiple intersection points in modern software.

“The winning combination of cost, communication, exposure to various domains, testing principles and test tools gives a clear edge to India in software testing,” said Hexaware Technologies global delivery head and chief software architect Ramanan RV. While software services are growing at an average of about 10-12% globally, testing is growing at over 50% every year. The market opportunity for Indian offshore testing companies is seen at around $8 billion by year-end, from $2-3 billion a year ago.

“Indian businesses have matured in terms of making IT central to all business processes. Hence, there is a very high level of business dependence on error-free software code,” said AppLabs president and CEO Makarand Teje.

A global case in point is eBay, which experienced a 22-hour outage of its website in 1999 due to software flaws. It cost eBay $5 million in revenue and an 11% drop in share price. The outage affected 1.2 million customers who were either trying to sell or buy something on the website.


Along with the growth witnessed in off shoring of software testing to India, the average deal size of such projects is also on the rise. A few years ago, the average deal size for an outsourced testing project was about $50,000-60,000, requiring a few testers. That has now grown to about $2-4 million per project.

According to Gartner, India will require around 18,000 testing professionals every year over the next three years to fulfill the demand seen in the software testing market.

How to apply for Software Testing Certification exam?

Many readers don’t know how to apply and prepare for these Testing and QA certifications. I will briefly guide here about the certifications available and the locations where you can give the exams.

Certifications In software testing some history:

In 1980 Quality Assurance Institute (QAI) established an association to represent Quality Assurance professionals. Currently many beginners and advanced level certifications are offered by QAI. Certifications like CSQA (Certified Software Quality Analyst), CSTE (Certified Software Test Engineer), CSPM (Certified Software Project Manager) and Some Advanced level certifications like CMST (Certified Manager of Software Testing), CMSQ (Certified Manager of Software Quality).

Normally people having these certifications are recognized as proficient in Quality Assurance. (As what they believe) But there is definitely a plus when it’s comes to your promotion. Other advantage of having certification what I feel is you will brush up the testing knowledge and methodologies while preparing for exam.

There are some prerequisite you should meet before applying for these software Testing certifications. These depend on the certification you are applying for plus some common prerequisites like:

• 4 years degree from reputed college + 2 years of IT experience OR
• 3 years degree + 3 years UT experience OR
• 2 years degree + 4 years IT experience OR
• 6 years IT experience OR

AND Should be worked in IT field for the last 18 months.

To apply for the certification fill out the form available at Testing certification application form. Please check which certification you want to pursue and then fill the form accordingly.

Please note that the application fee for any fresh certification is US $350 in which you can also get the exam guide CD. You must mail or fax the above filled application form to the appropriate address provided in the application form with your fees payment.

Note that these certifications exams are conducted in the location of your choice. Your application is first reviewed by QAI board and on approval further notes are sent to the local exam centers approved by QAI. You can check the current year schedule and locations of testing certification here.

For example if you want to give software testing certification exam in India, Pune center (MIT college) you must fill the application form before 15th October 2009 and can give the exam on 15th December 2009. Total 2 retakes are allowed for any certification. If you still not cleared the exam then forget about the testing certifications and even Testing.

More guides on available certifications and filling the form can be found here

Software Testing Models

One doesn't have to spend much time in the software industry to become familiar with several software development models. Some of the most commonly known include waterfall, iterative, test-first or test-driven development (TFD or TDD), and Extreme Programming (XP). Interestingly, one needs to have a rather diverse set of software development experiences and needs to pay rather close attention to those experiences to realize that there are just as many models for testing software as there are for developing software -- and that the testing model a particular project follows need not be dictated by the software development model.

Categories of testing activities

To aid in this discussion, let's agree to think about software testing in terms of five general categories of activities:

1. Researching information to improve or enhance testing -- This information may come from specifications, use cases, technical design documentation, contracts, industry standards, competing applications, or almost anything else that is likely to improve a tester's ability to test the software deeper, faster or better.

2. Planning and/or designing tests -– This category would encompass such activities as writing test cases, developing test strategies, writing test plans, creating manual test scripts and preparing test data.

3. Scripting and/or executing tests –- Here is where tests are actually executed and/or automated. This is what most non-testers think of when they hear someone talk about software testing.

4. Analyzing test results and new information –- Not all tests produce results that clearly pass or fail. Many tests result in data that can only be understood by human judgment and analysis. Additionally, changing specifications, deadlines or project environments can make a test that had been clearly passing fail without anything changing in the software. This category is where this type of analysis occurs.

5. Reporting relevant information -- Reporting defects and preparing compliance reports are what come to mind first for most people, but a tester may need to report all kinds of additional information.

Again, these five categories are intended to be simple in order to make our discussion about testing models easier. They aren't intended to supplant your current terminology.

Testing waterfall-style

Just like developing software using the waterfall model, testing waterfall-style is a fundamentally linear process except for a minimal feedback loop created by the need to fix some of the problems in the software that are indicated by failing tests. Visually, that feedback loop is equivalent to the small eddy current at the bottom of a real waterfall.

Waterfall-style testing is rarely chosen voluntarily anymore. It is commonly a side effect of some logistical challenge that kept the testers from being able to interact with the application or the developers prior to the first -- and what they hope will be the only -- build of the software. Waterfall testing is occasionally appropriate for situations where it is reasonable to hope the software will "just work," such as applying a service release or a patch to a production application.

Testing, iterative-style

Iterative testing is similar to iterative development in that many of the test iterations happen to coincide with development releases. In that regard, it is like a bunch of waterfall testing cycles strung end to end. Testing iterations differ from development iterations in that there can be iterations prior to the first software build, and there can be multiple test iterations during a single software build. Another difference is that unlike a development iteration, a test iteration can seamlessly abort at any point during the iteration to return to a research mode. While a development iteration can also abort and restart at any time, doing so is quite likely to jeopardize the project schedule.

Iterative software testing is extremely common in the commercial market, though it has many variants. The V-Model, the spiral model, and Rational Unified Process (RUP) based testing are all derivatives of an iterative testing approach. Iterative testing generally works well on projects where software is being developed in pre-planned, predictable increments and on projects where the software is being developed and released in such rapid or unpredictable cycles that it is counter productive for testers to plan around scheduled releases.

Testing, agile-style

Agile-style testing more or less eliminates the element of pre-determined flow from the test cycle in favor of shifting among the five basic activities whenever it adds value to the project to do so. For example, while analyzing the results of a test, the tester may realize that his test was flawed and move directly back to planning and designing tests. In a waterfall or iterative flow, that test redesign would wait until after the current results were reported and preparations were being made for the next test iteration.

Agile-style testing can be implemented as an overall approach or as a complement to any other testing approach. For example, within an iterative test approach, a tester could be encouraged to enter a period of agile testing, side-by-side with a developer, while tracking down and resolving defects in a particular feature.

Agile-style testing is significantly more common than most people realize. As it turns out, this model is what is going on in the heads of many testers all the time, regardless of the external process they are following. Be that as it may, this approach isn't very popular with managers and process improvement specialists because it is misunderstood by many non-testers and few testers following this process are able to express what they are doing in a manner that gives stakeholders confidence that they are actually doing organized and thoughtful testing.

For more information Try Googling it!

IEEE 829 Compliant Test Plan Template

You have read about how to write a good test plan, now let's go through the 16 clauses of the IEEE 829 plan standard that are as follows:

1. Test plan identifier.
2. Introduction.
3. Test items.
4. Features to be tested.
5. Features not to be tested.
6. Approach.
7. Item pass/fail criteria.
8. Suspension criteria and resumption requirements.
9. Test deliverables.
10. Testing tasks.
11. Environmental needs.
12. Responsibilities.
13. Staffing and training needs.
14. Schedule.
15. Risks and contingencies.
16. Approvals.

These can be matched against the five characteristics of a basic plan, with a couple left over that form part of the plan document itself.

Scope

Scope clauses define what features will be tested. An aid to doing this is to prioritize them using a technique such as MoSCoW.

3. Test Items: The items of software, hardware, and combinations of these that will be tested.

4. Features to Be Tested: The parts of the software specification to be tested.

5. Features Not to Be Tested: The parts of the software specification to be excluded from testing.

Resource

Resource clauses give the overall view of the resources to deliver the tasks.

11. Environmental Needs: What is needed in the way of testing software, hardware, offices etc.

12. Responsibilities: Who has responsibility for delivering the various parts of the plan.

13. Staffing And Training Needs: The people and skills needed to deliver the plan.

Time

Time clauses specify what tasks are to be undertaken to meet the quality objectives, and when they will occur.

10. Testing Tasks: The tasks themselves, their dependencies, the elapsed time they will take, and the resource required.

14. Schedule: When the tasks will take place.

Often these two clauses refer to an appendix or another document that contains the detail.

Quality

Quality clauses define the standard required from the testing activities.

2. Introduction: A high level view of the testing standard required, including what type of testing it is.

6. Approach: The details of how the testing process will be followed.

7. Item Pass/Fail Criteria: Defines the pass and failure criteria for an item being tested.

9. Test Deliverables: Which test documents and other deliverables will be produced.

The associated article on test documentation gives details of the IEEE 829 documentation.

Risk

Risk clauses define in advance what could go wrong with a plan and the measures that will be taken to deal with these problems. An outline of risk management is in an associated article.

8. Suspension Criteria And Resumption Requirements: This is a particular risk clause to define under what circumstances testing would stop and restart.

15. Risks And Contingencies: This defines all other risk events, their likelihood, impact and counter measures to over come them.

Plan Clauses

These clauses are parts of the plan structure.

1. Test Plan Identifier: This is a unique name or code by which the plan can be identified in the project's documentation including its version.

16. Approvals: The signatures of the various stakeholders in the plan, to show they agree in advance with what it says.

For more information try Googling it!

What are IEEE 829 Test Plan Standards?

Recently I have been searching a lot on testing jargons and come across a list of IEEE 829 Test Plan Standards as it was something which is not known generally.

This could be the list of standards to make your test plan IEEE 829 compliant as per the source.

1. Test plan identifier

2. Introduction

3. Test Items

4. Features to be tested.

5. Features not to be tested.

6. Approach

7. Item pass/fail criteria.

8. Suspension criteria and resumption requirements.

9. Test deliverables.

10. Testing tasks.

11. Environmental needs.

12. Responsibilities.

13. Staffing and training needs.

14. Schedule.

15. Risks and contingencies.

16. Approvals.

For more information try Googling it!

WIPRO is the Best Software testing Company

IT major Wipro Technologies has won the best practice award for software testing, set up by the US-based International Institute for Software Testing (IIST), the company announced here Friday.

The company's testing services division was given the award for innovating a statistical tool that reduces the time taken to test a product.

'As part of our proprietary tools suite code-named StORM (statistics, operations, research, matrix), the tool helps us to reduce test case development effort by about 30 percent,' Wipro vice-president and testing services' head C.P. Gangadharaiah said in a statement.

With over 10 years of experience in independent testing services, Wipro is the largest third-party offshore testing service provider worldwide.

It has also set-up the first wireless fidelity (Wi-Fi) pre-certification and certification lab at its Bangalore campus.

The IT bellwether offers software testing services to global customers in partnership with other leading vendors such as Hewlett-Packard, IBM and Microsoft.

'The award is one of the initiatives we have taken to advance the software testing profession and encourage IT firms to adopt best practices. The award also enables firms to share their best practices with the software testing community,' IIST chairman Magdy Hanna said.

Wipro was chosen for the award out of 36 technology firms worldwide that were short-listed by the institute.

Win Runner Frequently Asked Questions Continued......

1) How does WinRunner evaluates test results?
Ans.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.

2) Have you performed debugging of the scripts?
Ans.
Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.

3) How do you run your test scripts?
Ans.
We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.

4) How do you analyze results and report the defects?
Ans.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed.

5) What is the use of Test Director software?
Ans.
TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.