I’m going on meeting people who are into the IT industry but do not distinguish between quality assurance and quality control. Many of us say that QA is testing. I think this is partially because of "tradition" – we tell a word and know that we are understood correctly, and this is Ok. But I’ve noticed that often this “traditional” usage is not always accompanied with understanding of the formal terminology.
When we have finished producing something, we control its quality. In case of software development this activity called testing. Based on the evaluation of the results of quality control we can learn and adjust our process to ensure better quality in future projects or iterations.
So when quality control is usually performed by testers only, quality assurance involves all members of the process. Managers contribute to quality assurance by developing and keeping instructions, guidelines, etc. up to date and making sure that employees follow the process. Employees’ quality assurance duties are commonly limited to following processes but it is good practice to encourage them to contribute to quality assurance more, for instance by proposing improvements to procedures.
Do you know people who don’t know the difference?
Jan 15, 2008
What QA Really Means
Posted by Nikita Knysh at 7:44 AM 0 comments
Labels: terminology, testing
Jan 10, 2008
How to Test a Web Service
As a web service is something that has no user interface, we can’t interact with it without a special tool. That tool should allow composing XML requests via its own user interface. Commonly such user interfaces are text editors where you write your XML requests and controls for posting requests to the server.
Why not just unit tests?
Unit test is essential for every piece of program code. In many companies there is even a convention that code that did not pass unit test is not given for testing by quality control people. Unit test is simply part of development, not testing.
The minuses of considering passing unit tests enough acceptance criterion for a web service are:
- Unit tests are developed by a developer. Usually by the same person who has developed the application being tested. If a developer misunderstood a requirement or made a mistake in program code, many of his faults will be duplicated in the unit test.
- Classical unit tests are designed to test internal program code. But what is needed is to generate and run SOAP requests to web service methods. So if follow terminology that will be not unit tests but automated tests. And automated testing is activity carried out by testers, not developers.
- Project structure. As in every well-established testing activity, I’ve started with test specification. The main part of a test specification is test cases divided into test areas. SoapUI allows structuring your test project into test suites (the same as test areas in my test specification) that contain test cases, which can contain test steps. This structure is well-managed in SoapUI – you can add, modify, delete and change order of every item in the structure.
- Test cases. SoapUI provides enough convenient tools to manage and run your test cases, and view SOAP responses to your test requests.
- You can perform Load Testing.
- Automation. But what if your web service contains too many methods with too many input and output parameters? It may take several days for each complete test of your web service if your tool does not provide functionality to automate your testing. SoapUI supports Groovy Script – a scripting language that is very similar to Java. I’d classify it as ‘light Java’. You can write scripts to access the database which is used and / or influenced by your web service. You can automate validation of your web service’s response against you input. You can automate the output of validation results into a file (which could be just a text file of HTML depending on your choice). And you can run an entire test suite with one click, which, combined with your validation and output automation scripts, allows you to perform entire test of your web service in minutes.
Free vs. Paid Version.
Paid version provides more convenience and is very good if you do not have experience in programming or scripting. For example, instead of finding out how to connect to a database in the free version, you can buy paid version which contains a special type of test step – "database connection". Read more at the product comparison page.
Summary.
Testing should be performed by somebody anyway it requires resources in any case. Of course project manager can assign developers who can write scripts similar to unit tests but testing not only internal methods in program code but making correct test requests via SOAP protocol. But since testers are responsible for testing why not use tool that does not require knowledge of complicated technologies like .NET? A tester who has some experience in programming can organize and perform test activities efficiently with help of SoapUI.
Posted by Nikita Knysh at 4:12 AM 23 comments
Labels: groovy script, howto, SoapUI, testing, web service
