Popular Posts

Thursday, December 13, 2007

Top replies by programmers to testers when their program doesn't work

Found a set of funny replies from Quality Assurance and Testing blog

1. "It works on my machine"
2. "Why do you want to do it that way?"
3. "You can't use that version in your system"
4. "Even though it doesn't work, how does it feel?"
5. "Somebody must have changed my code"
6. "You must have the wrong version"
7. "I haven't touched that module in weeks!!"
8. "There is something funky in your data"
9. "What did you type in wrong to get it to crash?"
10."It worked yesterday"
11."That is not a bug, that was a requirement"

Wednesday, December 12, 2007

Deploying an axis2 service in application scope

If you deploy a service without specifying a scope, it will be considered as sessionless and will be deployed in request session scope. In other words, request scope is the default session scope of an axis2 web service.
When a service is deployed in request session scope, an instance of the service implementation class is created for every invocation. Suppose you want to get rid of that and maintain a single instance of service class throughout the server life time.
Then you should deploy the service in application session scope. Lets see how it can be achieved and tested the service invocation using WSO2 WSAS.

First, create a simple java bean as follows.

public class Employee {

private int Age;
private String name;
private String emp_id;
public int getAge() {
return Age;
public void setAge(int age) {
Age = age;
public String getName() {
return name;
public void setName(String name) {
this.name = name;
public String getEmp_id() {
return emp_id;
public void setEmp_id(String emp_id) {
this.emp_id = emp_id;

Now create the service descriptor (services.xml) for the above class.

<service name="EmployeeService" scope="application">
<messagereceiver mep="http://www.w3.org/2006/01/wsdl/in-only" class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver">
<messagereceiver mep="http://www.w3.org/2006/01/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver">
<parameter name="ServiceClass" locked="false">

Here, we define the session scope of the service as 'application', which will create a single instance when server is started.

Now, include these in a deployable service archive. (Create a META-INF directory and add the services.xml in there and save the archive as an aar)

Next, deploy the service archive using WSO2 WSAS management console. In the WSAS management console, go to "Services and Service Group Management' page and select 'EmployeeService'. Then click on 'Tryit' to test the service invocation.
The all getter and setter methods of the service class are displayed there. Click on setName and enter a string value in the given text box. You will get a NuLL response since it is an request only invocation. Next, select getName and click on getName button. You will get the name you have set in the previous step.

The above scenario demonstrates the creation of a single service class instance using application scope.

Saturday, November 17, 2007

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
Albeit the each QA folk must be equipped with the general testing methodologies (Black box testing, Usability testing, web testing etc..), having the expertise knowledge in the above areas will form a balanced team. Such team should be in a position to carry out any assignment within the schedule in expected quality.

My personal belief is, having a great QA process will do nothing if the right set of skills are not available in your team. A particular QA team may have best automation engineers, but that will not produce good results if their knowledge on the domain or subject matter of the AUT (Application Under Test) is minimum. Saying that, we cannot expect the same automation gurus are trained in application domain will resolve the issue.
Therefore, we should make sure to employ the experts in different QA technologies. During the test planning and design, domain expert could identify the potential issues in the application according to his/her vast knowledge in the subject and include those problems in the QA test plan.
Automation expert will analyze the architecture of the product and plan for UI or some other system level test automation.
A team member with exceptional deployment skills can provide the relevant inputs to identify the installation/deployment specific problems as early as possible. Also, the same person could prepare the QA environment while the other members of the QA team is busy with the test plaiing and designing tasks.

The DB expert is expected to play an important character in a balanced QA team. He should be able to derive test scenarios and test cases by analyzing the data base design of the AUT.

A Security testing expert will verify how secure the AUT by generating test scenarios with his/her knowledge in system/web security.

Finally a person with vast experience and knowledge in various performance tools and benchmarks will facilitate performance/load and stress testing of the AUT in effective and efficient manner.

By discussing the above I should say that the different experts should not work individually in isolate manner. I don't say that the 'TEAM WORK' concept is no longer applicable in a balanced QA team. Each member should communicate frequently by giving their opinions to have a solid QA plan/test cases which will eventually become the one and only one reference in test execution. Everybody must follow the same guidelines paying attention to the assigned area. Each member should take care of the respective technology they are having the expertise knowledge with.

In other words, application domain expert must be responsible for the functional aspects of the product. He or she should derive functional test scenarios by getting the inputs from the other technical experts in the team and execute them in functional test cycles.

After all, I hope you should raise questions like, 'How do we form such a team with so called experts?' 'Are these type of resources available in the SQA world?'

Yes, these questions are absolutely valid! Most QA teams do not even have a subject matter expert rather having various tech gurus. How do we find them? I strictly believe we should create the experts from our own existing teams. We should identify what are they capable of , which testing methodologies they re handling in ease in their daily works and how well the particular skill can be improved. We shouldn't overload each QA team member with all QA methods and technologies. We should identify individuals and provide necessary trainings to improve their knowledge in ONE particular area. So that the non-hypothetical balanced QA team can be realized.

Friday, September 14, 2007

Web application testing with Httpunit

Recently I wrote a tutorial on using httpunit to test Axis2 web module, which was published in wso2 oxygen tank. Httpunit provides a set of APIs to test a web application even without opening a browser, so that httpunit tests can be easily integrated in to your nightly build system. Have a look!!!

Wednesday, August 15, 2007

Guitar tabs for sinhala songs

This post has been moved to my entertainment blog.

Friday, June 29, 2007

An easy way to deploy pojo based Axis2 web services

Ever wonder deploying axis2 web services without archiving them in aars? There is an easy way to deploy axis2 web services directly inside any servlet container. Lets see how this simple deployment can be done..

If you haven't configured axis2 yet, get latest version from here
Simply copy axis2.war file in to the webapps directory of your favorite servlet container. Assuming apache tomcat 6 as the servlet container, axis2.war should be copied to ..\apache-tomcat-6.0.10\webapps. Start tomcat. axi2.war will be deployed inside tomcat.

Now you have to tell Axis2 to expose files in the given formats as web services. It can be done by adding the following custom element in to axis2.xml which can be found at ..\apache-tomcat-6.0.10\webapps\axis2\WEB-INF\conf\.
<deployer extension=".class" directory="pojo" class="org.apache.axis2.deployment.POJODeployer">

This simply says, the files with the extension .class which are placed at pojo directory will be exposed as web services.

You need to create a new directory, pojo inside ..\apache-tomcat-6.0.10\webapps\axis2\WEB-INF.

Now write your service implementation class.

public class myservice{
public String echo(String s){
return s;

Compile and save it under the above pojo directory.

Restart tomcat and access axis2 administration page. (http://localhost:8080/axis2)
You will be able to see the deployed service.

Thursday, June 28, 2007

Creating and deploying Java web services using Eclipse WTP and WSO2 WSAS

Recently WSO2 has worked with Eclipse WTP team to integrate wso2 Web Services Application Server (WSAS) in to Eclipse WTP (Web Tools Platform). This greatly reduces the effort of developing java web services and it will definitely a revolutionary tool for web service developers.
I would like to introduce a few nice features of this user friendly tool, so that anybody can start to use it for java web services development.

In order to use this integrated tool kit, WSO2 web services application server has to be downloaded to your local server. Get the latest WSAS binary distribution from here.
Just unzip it to your local file system. Suppose it is placed at C:\webservices\wso2wsas-2.0.

Now you have to download Eclipse WTP. An Stable WTP build can be downloaded from Eclipse web tools project . I would recommend you to get the wtp-all-in-one package.

Unzip the wtp distribution in to your file system. Suppose its located at C:\eclipsewtp.

Next, you need to add WSO2WSAS plugins to wtp in order to integrate it with the web tools platform. Go to your WSO2WSAS home directory (C:\webservices\wso2wsas-2.0) and run the install.bat under WSO2WSAS_HOME/bin.
It will prompt for selecting one of the two options;
1. WSO2 WSAS Servlet Container Installation
2. WSO2 WSAS Eclipse WTP Plugins Installation
Select 2. It will ask the eclipse WTP Home directory. Enter C:\eclipsewtp
You will see that the installer copying the required plugins to wtp.

Now Start wtp by clicking on eclipse.exe. You should see WSAS startup icon at the tool bar if the WSO2WSAS-Eclipse wtp integration was successful.

Now WTP should be configured to identify the WSAS runtime. Go to Window-->Preferences-->Webservices-->WSAS Preferences and specify WSO2WSAS_HOME directory(C:\webservices\wso2wsas-2.0). You should get the 'WSAS Runtime loaded successfully' message.

Click on 'WSAS server start' icon at the eclipse wtp tool bar.
WSO2WSAS server will be started in a separate command window and "WSO2 Web services application server instance started successfully" message will be displayed.
You can access the WSO2WSAS management console inside the eclipse WTP internal browser.

OK.. Thats all for installing and setting up your java web services platform. Lets write a simple web service and deploy it on WSO2WSAS.

- Create a new dynamic web project (New-->Web-->Dynamic web project)
- Select Target runtime as WSO2WSAS in 'New Server Runtime' (Second step of the new dynamic web project creation wizard)
- Write service implementation class
public class Testservice {
public String echo(String s){
return s;
- Now right-click on the service class in the package explorer pane and select Web services-->create web service
- Web service creation wizard will be displayed.
- Don't forget to change web service runtime to WSO2WSAS in the first step of the wizard.
- Click Finish

If you access WSO2WSAS management console through WTP internal browser, you can see your web service is deployed there.

You should realize how WSO2WSAS-Eclipse WTP integration reduce the java web service development effort and provide a user friendly IDE for JAVA web service developers.

You can find more information on WSO2WSAS at WSAS home page

Sunday, June 24, 2007

QA in open source projects

Quality assurance is a traditional activity in software development life cycle which starts from the inception stage of a project and flows through design, execution, release and maintenance phases. However these type of clearly defined phases cannot be realized in most of the open source projects. Rather defining SQA activities in to different stages, agile QA approaches emerge to facilitate quicker development and release cycles.
It is always not possible to define a properly managed quality assurance process in most of the open source projects. Strictly defined deadlines, properly documented requirements and designs, well planned releases are essential supporting components for having a good QA process. However most of the above (Sometimes none of the above) tasks are not done in open source software development. Due to these circumstances QA cannot control the whole process.
Is it possible to maintain an effective QA process in open source projects? Is it possible to adhere to a schedule even if a development process is not defined? How does QA control the open source product releases? Any QA engineer who involves in open source projects may raise these question.
I tried to find out answers for the above questions.

Maintaining a QA process

Most of the QA processes consist of the following phases.

Test requirements identification
Test design
Test execution

Due to the poorly documented open source software requirements, QA test requirement identification may be difficult. However QA can start this activity through wikis, mailing lists and they can publish the identified test requirements in a QA test plan. QA test plan will be the primary source of the quality assurance test activities which are going to be executed throughout the project. Also, Live updates on QA test plan is possible if it is wiki based.

In commercial software projects, QA test designing is performed by referring to the requirement specification. The use cases are converted to a set of test scenarios and which are used to derive test cases. How are tests designed when requirement specifications are not available? QA Test designing is an endless activity in most open source projects. The initial set of test cases are designed using the basic project requirements which are captured from the discussions happening in mailing lists and wiki pages. These are refined when a build is released for verifying the basic functionalities of the product. Subsequently more scenarios are captured and test cases are derived using them. But it is not the end of test design. More and more test cases and scenarios are identified when more functional builds are released for testing.

Test execution is a two-fold activity in open source projects. Initially QA team does ad-hoc testing to check the basic functions of the AUT (Application under test). Then the execution of test cases is carried out. If a new scenario is captured while performing the ad-hoc tests, it is amended to the QA test case document. So that, QA team is equipped with a comprehensive set of test cases when the final builds are available for testing.

QA Scheduling

Following the defined activities and maintaining the schedule are important features of a good QA process. However in open source world, schedule is haphazard. Projects are not governed by strict deadlines and plans. Because of that, builds are received randomly for QA testing. There is no strictly defined 'First Build to QA' date. When a set of features are done, QA gets a build for verifying the implemented features. However these random QA builds are really important for QA team to capture more test scenarios while studying the product.
Usually release candidates (RCs) are delivered for QA testing 2-3 weeks before the final product release (This depends, of course :) . Release candidates are equivalent to the official QA builds which includes almost all the functionalities. QA team conducts thorough functional and regression tests in these RCs. The effort and duration for testing a particular RC will be subjected to change even if it is planned initially due to the randomly added features and changes in the final release date.

Controlling product releases

In most commercial projects, an approximation about the release can be obtained through the QA metrics. Defect severity index, defect density provide a better indication of the project status and product stability. However, this is not exactly applicable for open source projects. Last moment changes are happened and regression issues are introduced. However it is really important to set an acceptable release criteria for any opensource project. For example, release will not be accepted by QA team unless blockers and critical bug count are zero. Also QA has to convince developers to resolve all the open bugs and update the status in defect tracking system. This will provide a clear indication on the release status.

Saturday, June 23, 2007

Using Apache Jmeter to test axis2 web services

I wrote a tutorial on apache JMeter and axis2 web services two months back and which was published in wso2.org. It describes the basic scenario of writing a Java service implementation class, Deploy it in a servlet container and send a soap request to the web service using JMeter and retrieving the response. Have a look!!