Archive for February 2009
Our Services
Our independent software testing services provide validation and verification for websites, portals, and web applications. We offer highly professional testing expertise coupled with personalised service that translates into value for money for you, as our client.
We Offer
A complete range of testing – system testing, integration testing, functional testing, regression testing, gorilla testing, heuristic evaluations, user acceptance testing, conformance testing, interoperability testing, design check, content check, cross browser/OS testing and performance testing. Flexible resources – develop a testing solution for your needs, both at our facility or in-house at your office.
So you like what you’ve seen about the services we offer and want to get a closer look at what we can do for you and your business. We are happy to show you the difference that QC BOSS can make and we are sure that you will be pleased by what you see.
Our dedicated team of skilled software testers, Offshore QA Lab, provides a full range of quality assurance services (QA), including software quality consulting, test planning, test execution and reporting, control of software development processes.
It is known that software quality and its conformation to requirements, standards and objectives underlies the effectiveness of such product. Our Offshore QA support software provides QA for both small and large development projects.
What we do
Offshore QA Lab is engaged in the software development process at each stage to assure the quality of a software product and processes involved. Our QA services encompass:
Review of
Software Requirements / System Specifications / Project Plan / Software Architecture / Databases Structure / SRS / FSD / BRD
Software Testing
System testing, integration testing, functional testing, regression testing, gorilla testing, heuristic evaluations, user acceptance testing, conformance testing, interoperability testing, design check, content check, cross browser/OS testing and performance testing.
You are free to discuss and choose all or any of the software quality assurance services upon your needs and requirements.
Why QC BOSS?
Your website diminishes in value when there are errors and bugs – usability issues, functional issues, broken links, wrong grammar, spelling mistakes, alignment problems, performance issues etc. Send your site to the QC BOSS. We will give it once-over – we’ll test it!
At just $6 an hour, you couldn’t ask for more! You are just one step away from making your website the most effective it can be. Have it tested.
Why you need Offshore QA Lab
QCBoss customers make use of our offshore QA services when:
- Independent audit of the software development services of a present offshore service provider is required
- Technical support cost reduction of an already developed software becomes a challenge
- Product quality enhancements are required to increase overall business profitability
- Onsite/near shore software development process requires a dedicated offshore QA team
- Access to unique experience, specific testing platforms, and for some other customer-specific needs
Key Benefits
When working with our Offshore QA Lab, you are offered to gain the following benefits:
Staff
No language barriers: Each member of the Offshore QA Lab speaks English and has proper skills. When organizing a dedicated QA team, you are free to review the CVs of software testers and choose the most appropriate skills for your project along with personal interviewing and necessary tests.
Flexibility: Synchronization of our working shifts with business hours in your company.
Business
Cost reduction: Our offshore software testing services for only 6$ per hour.
Team size adjustment: QA dedicated team can be scaled or downsized as per your business needs.
Planning and management: If necessary, you can remotely perform a full control over software quality assurance process planning and resources management.
Mistakes done by Developers when they do Testing
Drawbacks of Developer’s Testing Technique’s: Developers do not allow a lot of time to test their programs. Because of this they often just test with ideal data that fits into the specified parameters. In other words the developer is only testing the program to see if it is doing what it should be doing, and they are not testing to see that the program is doing what it shouldn’t be doing. A program needs to be tested outside its parameters to see if it gives the proper response or error message to such data. To get the product out to the environment on time, programmers run test that they already know will work. A test engineer once said to me that “if the program only works on a day when the temperature outside is 80 degrees, the programmer will wait for an 80 degree day on which to test.” This may seems extreme, but it is something that I have observed in my internship.
When working with a project for any amount of time, those involved in getting the project to deployment have developed a biased toward the project. When those accountable for getting the project out to the customer on time and on budget are the ones to test the program, it is certain that certain things will not be checked in order to save time. I remember on one occasion the programmers failed to test the printing option, because “it had always worked before.” This program was for calculating certain data and putting it into report form, without the printing option this program became useless. So, because of their past experience with the program and their desire to get the product to deployment, the product came out on time and on budget, but not with the quality that it needed to be beneficial to the company. Testers are not biased to the product and will test the product fully, because it is their job to find the faults, before it goes to deployment.
The programmer knows his or her code inside out, however they also know how to get around flaws in the program. The best example that I can give is for installation of a new program. Programmers are a creative lot when it comes to passing their own product. There was a programmer that was confident that his product was ready for deployment, however during testing we were not able to install the program using the setup.exe file. His explanation of this was that there was a registry key that needed to be modified before the setup could be run successfully. The testing facility was not about to pass a product that required the user to edit the registry. The programmer honestly thought that this was an okay work around for the product’s failure. Outside testing is best in this situation, because the developer doesn’t realize that the mistake in the installation was something that needed to be fixed within his own program.
Many programmers test their programs locally on there own machine and they seem to forget that the program has to get to the user somehow. Some user will have the program installed from a CD, which is the most like how the developer tests his or her program, however in many cases the program is going to be pushed down from a network, offered on the web, or passed around on a networked drive. When the developer is not prepared for this, files can be lost in the distribution method. Independent testing resources are the best way to go in this case, because the have solve the problem of the “developer’s machine” and the will have the network for testing the push from the network without involving the production server. The developer forgets that there is more than one-way to receive a program and if not all methods are tested, one of them is bound to fail.
The first thing that I learned was that a developer’s computer has the latest and greatest software, fixes and upgrades, which the average target computer’s environment user does not. Having tested the product thoroughly on his or her own machine, the developer is ready to deploy the software to the entire environment. The problem with this is that the developer is usually running the software on only one operating system build (version) and is using a server that is only supporting a handful of developers. This is not a true test of the program’s ability to perform on machines of different processor speeds and operating system builds. The developer, who does not have the resources for such testing, should request testing from an outside source to ensure that the program is going to run in the environment with minimal errors. Environments are much more complex than the developer’s personal environment that he has created for himself; Networks have more than just a handful of people on them. Running things off of the network slows the response times of all programs, but if the program is not efficient enough, it should not be deployed.