Roles & Responsibilities of Developer vs. Tester in new SOA world

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
• Dependency on outside components and services
• Loosely coupled architectures allow projects to pick off-the-shelf services
• Some of these services are enforced by government (like DRPL checks)
• Dev and QA must understand the implication and incorporate 3rd party dependency into the overall strategy
• QA must know where to stop; test integration, not the third party service!
• Agile development and testing
• Agile means ability to quickly change with changing environment.
• To be agile, teams must be small and independent
• SOA makes it possible for teams to be agile
• Traditional waterfall processes don't work in SOA
• Teams must understand the difference and adapt new process that enable SOA development
• QA works more upstream with development inside sprints.
  
• Continuous testing is the key!
  

Implication/Challenges in WS-Testing

• 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.
  
• http://almquality.blogspot.com/2006/08/data-driven-testing-ddt.html
• http://almquality.blogspot.com/2006/08/data-strategy-ds.html
• Lastly, the teams MUST follow establish some best practices.
  
• Test Bed Setup - including server farms
  
• Test Directory structure - project workspace
  
• Naming conventions
  
• Data Management,Test Libraries
  
• Configurations,
  
• Versioning
• Reporting