Saturday, April 14, 2007

Both Developers and testers probably have tougher role now in SOA world as things change very fast. One huge monolithic project is now equal to n-smaller projects, which means n-dev teams and n-qa teams. N-number of smaller project consume more resources as compared to one-big project, but the benefit is faster release train and quick turnaround to market and customer requirement changes. Lets look at each of the benefits of SOA and how does it impact Dev vs. QA:

Smaller teams

DEV: More focused teams, faster development possible.

QA: Small Dev team means smaller QA teams.

Shorter release cycles has a lot of implications:

Quality can no longer be pushed to the end

IT needs to me more agile to handle faster production upgrades

QA can no longer take one month to do system tests

DEV must build quality into the code from day-one

Engineering best practices are more critical than ever

Interdependency between smaller projects

Smaller projects must be able to work with each other

Standards play a huge role

Separate QA effort is required to validate interdependency and high level system level business workflows

Many heterogeneous technologies

No more only UIs to test!

Developers must understand all new upcoming technologies.

QA needs to become more technical; Point-n-click of front-end Uis doesn't fly anymore

Test automation (or at least programmatic testing) is more critical than ever; More than 70% of exposed interfaces won’t have any UI

The biggest challenge is people confuse WS-Testing with SOA-Testing. There may be 50% to 60% overlap, but they are different. WS-Testing is just a subset of SOA testing. Check following links:

http://www.developer.com/design/article.php/3588361

http://itko.blogspot.com/2007/03/big-ws-difference.html

QA teams are not used to testing non-UI type interfaces

Manual testing doesn't work anymore. QA must improve its skillset to survive in SOA world

SOA testing requires QA teams to have fairly good understanding of the underlying architecture

It requires QA teams to really understand the basics of different SOA technologies, some of which are: Web Services, EJB, JMS/ESB, REST, RMI, POJO, relational and hierarchical DB, .NET, etc.

QA teams are NOT used to managing test assets. They must follow engineering best practices.

Use of version control systems

Collaboration sites like wikis

SOA enables Agile development which requires QA to work more upstream with development

All of the basic test automation challenges still applies

Test management, test data management

Version control, sharing, nightly test runs

Automated reporting, result analysis, debugging

High reusability, lower maintenance, test mobility

Once teams understand the difference between traditional QA and SOA-Testing, the next challenge that they have in front of them is Test Data Management. Understanding all the data requirement and figuring out how this data will be fed into the test cases is the key.