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.
Reduce testing cost by QA outsourcing
Labels: Qa hourly rate, QA outsourcing, QA salaries
Leap Year Testing
A bug has been discovered in the Community Technology Previews (CTP) of SQL
Server 2008 related to leap year. The result of this bug is that SQL Server
2008 services will not start during the 24 hours of Feb 29 GMT.
This issue affects customers using any version of SQL Server 2008 on any
supported operating system. Although there is no known impact on SQL Server
2005 or prior versions at this time, we are continuing research on all
versions.
* Do not start or stop SQL Server 2008 Database Engine services during the
24 hour period of Feb 29, GMT
* Do not install or upgrade SQL Server 2008 during the 24 hour period of Feb
29, GMT.
So how my site visitors testing their product for leap year bugs?
Labels: leap year bug, Leap Year Testing
Selenium core vs Selenium IDE vs Selenium RC
I got a chance to use this valuable tool which is light weighted and user friendly. It can be used by any technical or non-technical users as well. I really love this tool.
Selenium IDE is a plugin or call it an extension to Firefox, just like Firebug, Chatzilla but with a different functionality and purpose altogether. The recording mode plugin is not available for IE.
Basically Selenium IDE records its tests in HTML and then uses those tests to execute through browser. But users can covert HTML script to ruby,php,phython,C# or java by Options->Format.
But when you need them to execute the tests altogether as a test suite then follow the link change the test according the requirements and also modify different execution mechanism as required.
http://wiki. openqa.org/ display/SIDE/ Automating+ Selenium+ IDE+tests
Selenium Core and Selenium RC are used to execute the recorded script.
If you application does not work on Firefox or if it is not intended to work on Firefox according to the requirements then its better to use Selenium Core.
Some useful resource like tutorials and downloads on the net for beginners
http://selenium. openqa.org/
http://en.wikipedia .org/wiki/ Selenium_ %28software% 29
Labels: Selenium core, Selenium IDE, Selenium RC
I missed a BUG
Most of the testers/QAs are concern about external issues that they have missed. Carrier wise external issues are not good for testers profile inside their organization. More external issues may destroy the testers reputation within organization. On the other hand it is not fair to put 100% responsibility of external issues to testers. Why testers miss bugs?.
1.Lack of project management.
2.Not enough time to test.
3.Requirement change in last moment before releases.
4.Lack of domain knowledge.
5.Lack of QA/test resources.
6.Poor requirement specifications.
7.Limited time to acquire domain knowledge.
8.Selecting automation testing in the earlier stage of project. ( Where manually testing is required.)
9.High coupling with developers. ( testers who depends of developers to get domain/technical knowledge may influence by developers.
10.Not enough motivation towards testing. ( more open bugs, ignorance of QA team within organization, lost of existing functionalities due to new bugs, less salary.... )
11.Developers/QA/tester attitude towards bugs.
Surely, there are more to add for above reasons list, Above points can be categorized in to two.
1.Self factors
2.Organization factors.
Anyway most of the above factors caused due to lots of sub reasons. Head of the organization or middle layer management should take actions to treat the organization factors. Immediate supervisor should care about the testes self factors.
I would like to mention one of my story here. Last week I found a bug which was missed in first release of the project. Luckily that bug was found by me after the release. If external user report that bug, things may have got worse. The project is small one so it can be tested by one QA resource. “Unnecessary text” is appeared top left had corner of the screen. Actually text was an e-mail password of one of our developer. Mistakenly he has type it in JSP file . I have been testing that project around one month before the release. It is shame of me. Why I have missed this idiot UI bug? What are the precautions that I can take to eliminate this kind of bugs in future.
Main Reasons (My excuse)
1.UI theme has changed 3 days before final release. So little time to test new UI theme.
But could have found this bug If I had used JSP/HTML/CSS validation tool. Yes it is good to learn by mistakes. And it may be more than good to share that mistake with others (to learn by others mistakes)
Some of the tool that you can use for this kind of work are given below.
http://validator.w3.org
http://jigsaw.w3.org/css-validator/
J2EE verifier tool – JSP validation.
I have heard that Australian wicket keeper Adam Gilchrist going to retire from cricket due to the reason that he missed a catch. According to him what I should do?
Cross Browser Testing
It is critical to test across many browser and operating system combinations because the page can look different in each scenario. Another concern is the screen resolution and color depth. A page might look good at a resolution of 600 x 800, but parts of it might get cut off at 640 x 480. Different color depths should be used on the test machines also. Colors might vary unpredictably if a browser-safe palette is not used. As a QA, we should look for:
Color of links
Broken images
Low color contrast
Spacing in tables
Text wrapping issues
Margins
Alignment, formatting, and size of text
Alignment of controls such as radio buttons and check boxes
Switch Javascript off
Switch cookies off
Switch plug-ins off
Switch images off
Printing - Do not forget to test printing of your Web pages by printing on a variety of popular printers. Printing can be unpredictable, particularly with frames. Keep an eye on what is printed, the readability of content, and the speed of the print job.
Be sure to use clean machines when you start testing and make sure no plug-ins are installed. If the plug-ins are already installed,you might miss a defect that has a dependency on the plug-in. There should always be some test cases that involve using a browser as it is first installed,with no extra components.
Netscape Navigator requires a plug-in.Netscape users must be aware that the plug-in is required and should be given instructions on how to install it. (Anyway Netscape is a dying browser)
View in text browser (Incidentally the Opera browser has a built-in text-browser emulator)
Suggestions to Improve Testing.
1) List down the modules to be tested.This include functional and non-functional testing
2) List down the functionality that you will not test either because of incompleteness of module, data dependency or hardware limitations etc.
3) Pl. get formal approval from your manager for the activities/schedule that you are planning.This will endorse your deliverables and validity.
4) Make sure that you have the defect tracking system in place with severity norms and owners defined.The defect logging format should be approved by your manager.
5) Make sure that you have set of data that will help you in testing various test scenarios.If data is not available, pl. check how you can generate the same.
6) Make sure that you take daily back-up of your test logs and discuss progress and issues with your management team every day.
7) Keep talking with developers. That will help you to increase product understanding.
8) Release notes from Developer team to Testing team will be entry criteria to start testing activity. The release notes will include information like the defects fixed in the build, any work around ,features not addressed.
9) Multiple iterations of testing will bring up new defects. Periodically update the test cases checking the possibility of new scenerios.Once the defect probability starts reducing in further testing iterations, this may be the indication of product getting stable. Introducing multiple testing heads will also help to filter new defects.
10)Try to set the processes with help of your manager. Eventually that will be helpful in long run.
process defect and shipment defect
If a defect is detected in testing department while testing the application is called in process defect.
After release the software if a client finds the bug in their environment (production environment) then it is called as post shipment defect.
Labels: process defect, shipment defect
Balanced QA team
Balanced team.. may be a traditional management term. However, I am trying to understand the term in quality assurance perspective. In my experience most of the QA teams do not consist of the right set of skill combinations required to get the maximum out of available resources. First I believe the following members should be included in a balanced QA team.
- Domain/subject matter expert
- Test automation expert
- Deployment/build expert
- Security testing expert
- Performance testing expert
- Database technology expert
I have came across this nice blog post written by Charitha. I totally agree with what he says in the post .
Labels: Balanced QA team