QA Outsourcing [Reduce Testing Cost]

There are all manner of outsourcing firms who can provide you with impressive powerpoint presentations showing how you can cut your QA costs by 30% or more by outsourcing the work. I would caution you to consider the source however.

Of course Outsourcing firms will produce evidence showing why their service is a valuable cost savings, they will even have little problem letting the managers and executives who decided to use them generate the metrics that show how much of a cost savings it was to outsource. In the case of the Outsourcing firm, it is little more than marketing speak trying to generate new business, expecting them to say any different would be like expecting a Cigarette company executive to go on Television and say "Of course Cigarettes kill people but as long as they are willing to buy them we'll be happy to take their money". As far as their Customers, well admitting that a decision to outsource was a failure would effectively end most executive's or manager's careers so they have little incentive to look too critically at the numbers.

So how much is the cost savings?

That depends on a LOT of factors. First, how much do your inhouse testers cost? Not just their salaries but their total cost.

In the US and UK the total cost of an employee is considered to be around double their salary (that varies some based on the level of benefits offered, location, and other similar factors) and QA testers earn between $45,000 and $90,000 a year depending on experience level, industry, and location. This would mean that on average a Tester in the US should have an employment cost somewhere around $60 - $75 per hour. Only you would have any clue what your costs would be, I'm just including that as a reference point.

The Bill Rates for Outsourced testers ranges from $25 - $40 per hour in places like India and China up to as much as $60 an hour for outsourced testers in industrialized countries (and it can be MUCH higher than that in some locations of if you require specialized knowledge, I've personally seen them as high as $150 per hour).

On top of that bill rate from the outsourcing firm there are additional costs that would work out to an extra $5 - $10 per hour to cover the legal expenses of negotiating the contract with them, the necessary network infrastructure work to allow the outsourcing vendor's network interface with yours securely and so on.

So, a reasonable projection is that in most cases Outsourcing IT work will cost around Half of what it cost to do the work in house on a per hour basis (at least for companies based in the US).

We're not at the end of the caluclation yet though. See that is a Per Hour cost. It assumes that the Outsourced testers are able to work exactly as efficiently as your inhouse testers and with the same skill. While the question of tester skills is highly random from company to company the question of efficiency is actually fairly static. Simply moving your testers into a different building within the same complex creates enough inefficiency to make testing projects take 25 to 50% longer than they would have if they sat next to the developers. Adding in different corporate cultures or even worse national cultures, language barriers, time zone differientals, etc. and the man hour increase is closer to an additional 100% to as much as 200%.

So a 50% reduction in cost per man hour but it takes you 2 to 3 times as many man hours says that Outsourcing is anything from a break even to a money loosing proposition until you factor in variability in skill levels between your existing test staff and the staff at whoever you outsource to. If you have very weak testers and are unable to recruit better ones the it may be that outsourcing will produce a small cost savings of maybe 10 to 20% of your testing costs.

I have yet to encounter an Outsourced testing situation where it actually saved money. Many VP's, Director's, and Manager's claimed it did on the basis of reduced per hour labor costs but never one that was a net positive to the company once all of the outsourcing costs were factored in.

Source: SoftwareQA Blogspot

Product Testing

Product would be developed as a project first and would undergo all the tests that a project normally undergoes, namely, unit, integration, and system testing. System testing is carried out more rigorously and on multiple systems. In addition, it needs some more

rigorous tests. These are:

1. Load Testing – in web applications and multi-user applications, large numbers of users are logged in and try to use the software in a random manner. The

objective is to see if the software is managing multiple requests and serving up accurate results or mixing them up. . This unearths the issues connected with the bandwidth, database, sufficiency of RAM, hard disk etc

2. Volume Testing – subject the software to a high volume of data and see the performance, whether it degrades.

3. Functional Testing – test that all functions expected of the software are functioning correctly.

4. End-to-End Testing – in this type of testing, one entity is tracked from birth to death in the application. For example, in a payroll application, an employee joins the system; then is promoted; then is demoted; salary increases are effected, salary decreases are effected; kept in abeyance; transferred, then retired, dismissed, terminated and so on to ensure that the state transitions designed in the applications happen as desired

5. Parallel Testing – a number of users using the same function and are either inputting or requesting same data. This brings out the system’s ability to handle requests at the same time and preserving the data integrity.

6. Concurrent Testing – Concurrent testing is carried out to unearth issues when two or more users use the same functionality and update or modify same data

with different values at the same time – normally using a testing tool. For example, take ticket reservation scenario, there is only one seat and it is shown

as available to two people. When both confirm purchase, the system should give to only one and reject the other request. It should not happen that money is

collected from both credit cards and reserve for only one – the credit card transaction must be reversed for the rejected party. Scenarios like this will be

tested.

7. Stress Testing – cause stress to the software by making expected resources unavailable or causing deadlock like scenarios or not releasing resources and so on to ensure that the software has routines built in to handle such stress. This will bring out software responses for events like machine-rest, Internet disconnection, server timeouts etc.

8. Positive Testing – test the software as specified and not trying any negative acts – to ensure that all defined functions are performing. Used mostly for

customer / end user acceptance testing.

9. Negative Testing – using the software in a manner that is not expected to be used – this will bring out all hidden defects in the software. This is to ensure even malicious usage would not affect the software or data integrity.

10. User Manual Testing – use the software conforming to the user manual to ensure that they both are in synch with each other

11. Deployment Testing – Simulate the target environment and deploy the software and ensure that deployment specified is appropriate.

12. Sanity Testing – this cursory testing to ensure that the components, of software package, are complete and are of appropriate versions, carried out before delivery or before making a software-build.

13. Regression Testing – testing carried out after unearthed defects are fixed

14. Security Testing – testing to determine that an information system protects data and maintains functionality as intended.

15. Performance Testing – testing to ensure that the response times are in acceptable range

16. Usability Testing – testing the software for different types of usage to ensure that it satisfactorily fulfills the requirements of specified functional areas

17. Install / uninstall Testing – test the software on all target platforms to ensure that install and uninstall operations are satisfactorily performed

18. Comparison Testing – testing the product with competing products to contrast the differences for determining the relative position of the product

19. Intuitive Testing – testing without reference to user manuals to see if the product can be used without much reference to user guides

Source: SQA Forum

Test 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.

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 the buffer time and the effort calculated from metrics, and this is the 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.

Source: SoftwareQA Blogspot

TestLink 1.9.1 - Released

TestLink 1.9.1:

New features

- Requirement revisioning

- Requirement history with log messages

- New requirement and test case comparison method

- Expand/Collapse Buttons for trees

- PHPMAILER update (allows SSL or TLS) - googlemail can be used

- Mechanisms implemented to prevent data loss on editing when sessions times out or the user tries to navigate away without saving latest changes

Important Bugfixes (~70 in total)

- better MSSQL support

- Query metrics: start and end date input fields are respected

- minor usability improvements

- event viewer fixed for IE8

Source: opensourcetesting

Requirements and Test Management Repository [RTMR]

What RTMR?

RTMR stands for Requirements and Test Management Repository translated Repository requirements management and testing .

This is a test tool open source software that allows:

manage software requirements throughout its life cycle

describe the scenarios and test cases to ensure the validation of these requirements

run test campaigns targeted

follow all the anomalies encountered during testing:

via the internal fault handler

via an external fault handler (bugzilla, mantis)

The solution includes a system for version management by project, by requirement, by scenario and test cases that keeps track of software changes and can easily cover all regression tests.

Why would a software testing tool?

The test objective is to validate the proper functioning of software to the needs and requirements gathered from users.

It ensures a sufficient level of quality during the development cycle and software life.

The test phase allows to identify such malfunctions, abnormalities or regression that prevent full or partial coverage requirements formluées initially and as functional changes.

The software testing tool comes at this time to structure, organize and target testing (risks, priorities ... etc.).

RTMR Why?

Although fundamental, the profession of software testing will become widespread only recently in the computational structures of small and medium sizes.

Although the panel of test tools grows, existing solutions are often architecturally binding (proprietary software) and require substantial financial investment (initial cost of licensing, training, maintenance) for the structures that need it.

Through RTMR, materializes the idea of an alternative open source solutions based on open (GNU / Linux, PostgreSQL, Qt), a robust architecture (3 others), while providing a rich client interface available on different platforms ( Linux , MacOS X and Windows ).

Source: opensourcetesting