Posts tagged as:

SOA

SaaS (Software as a Service) delivers software over the Internet without the end users ever needing to install any software in premise, behind their own firewalls. On the surface doing software QA for a SaaS firm should be no different. After all, you are doing same old testing for an ISV (Independent Software Vendor), it is same old software, with a development life cycle, (well written, planned ☺ ) requirements, release plans, defects, triages, wrangling with the developers, resource crunches and so on; so what can be different?

There is a difference and it is significant. Worse, not knowing it, can impact the quality of your product and credibility to your customers. To understand it first lets see how SaaS is different (For a detailed account of how SaaS is different please read our “SaaS Operational Efficiency” white paper).

How is SaaS different?

  • SaaS is more of a service than a shrink-wrapped software
  • SaaS solution has more stringent performance and security implications
  • SaaS business model enforces an Agile methodology of software engineering
  • There are significant operational costs (infrastructure, software and deployment)
  • A new release (and its defects) is immediately available to your customers, with a very high risk of an error
  • Your customers have a lower risk, cost and impact to switch you and move to a different provider.

The above impacts SQA in more ways than what meets the eye. Following is a list of  key areas QA gets impacted:

  1. Agile Methodology: SaaS firms have so stringent time to market pressures that they are forced to adapt an Agile methodology. With a release happening every month or less, QA teams have to turbo charge their productivity, in order to ascertain good quality level.
  2. Performance and Scalability Requirements: SaaS firms deploy their software on their own hardware. Poor performance exponentially increases the operational costs and in worst situations becomes a death bed for the company. QA teams have to validate the principles of multi-tenancy and test each release for its scalability.
  3. Web Services and SOA: As SaaS software gets deployed behind its own firewall, for most enterprise applications, there are strong needs for data integration. Most SaaS products have a rich WS layer that enables them to integrate with third parties. This actually is a blessing in disguise as it provides an easy interface for QA to test the key business functionality through an easy to automate interface. QA teams however need to know how to best test the SOA platform.  Please read about some specific work we have done around SOA Testing here, here and here.
  4. Test Automation: I believe SaaS QA teams (or for that matter, any agile lifecycle) can not survive without significant level of automation. This includes (but is not limited to) good unit testing, GUI automation, functional tests of key application interfaces (such as your main controllers), SOA interfaces, performance etc.  Having a good framework that extends itself to meet ongoing automation needs is critical. We have blogged about automation here and here.
  5. Security: As a SaaS company you are taking ownership of safekeeping of critical customer data both morally and legally. Any error with security can shut your company down. As a QA team, you have to know and test for major web exploits and plug them.
  6. Release Automation: Just like test automation, any agile methodology can not survive without automated builds, releases and deployments. QA teams have to understand and implement continuous integration process that builds regularly and reports failures in an automated way.
  7. Test Environments and clean Deployments: While the SaaS model is a boon for customer support (they are no longer required to support the unforeseen mess weird combination  of OS, server and software environments in customer IT, they just support what is in their production); it is yet another pain for QA. How do you know what you are testing will work in production? QA needs to have very tight control over deployment scripts and deploy the software in the test environment. The test environment itself needs to replicate production environment closely including all the load-balancing and clustering infrastructure.
  8. Testing for SLAs: So what if the code functionally works and passes performance criteria? Does it meet your SLAs? How do you guarantee your software will not breach a functional, performance or uptime SLA in production? Again it is QA’s extended role to validate for conformance with SLAs.

QA Managers working for SaaS firms have to keep the above points in mind when creating a test strategy for their SaaS product.

VN:F [1.9.10_1130]
Rating: 10.0/10 (5 votes cast)

  

{ 2 comments }

Note: For overall context for this blog please read integration testing with soapUI.

SoapUI Pro has extensive reporting functionality: creating reports on different levels (project, testsuite, testcase, etc.), different formats (pdf, cvs, xls, xml, etc.), easy customization and more. The feature provides three basic types of reports:

  1. Printable Reports : Reports are based on the JasperReports reporting engine, and a good understanding of how Jasper works is necessary to customize the reports created by soapUI.
  2. Data Export: lets you export the same underlying data that is used for printable reports to xml or csv files.
  3. JUnit-Style HTML Reports: to generate HTML reports very reminiscent of the “classic” ant/junitreport reports

Our requirement was to show functional test results with complete details in XML/HTML format. Some of the details we want to show as part of XML/HTML reports were:

Description of test case:

  • List of passed/failed test steps
  • Passed/failed assertions in each step
  • Capturing screen shots where failed test step invoked selenium (please read our blog about selenium integration with soapUI)
  • Fetch Selenium logs
  • Providing attachments like screen shots, request/response details in case of failed test step

Others

  • It should show results for different browsers
  • Test results can be publishable on Hudson or on specified web server
  • If published on Hudson result should be consistent for different browser and can be categorized by browser.

We decided that JUnit-Style report is right candidate to meet the above requirement as it provides functional test results in XML/HTML format as well as Hudson understands the JUnit test report XML format.

Now the challenge was to generate reports with complete details as per requirement above because default reporting functionality gives a simplified overview of functional test results. Refer screenshot.

To fulfill all this requirement we need to customize the JUnit-Style reports created by soapUI and that is not supported by soapUI!…

So what did we do?

We did some analysis and found that we can achieve what we need by extending com.eviware.soapui.report.JUnitReportCollector class and implementing custom behavior as per our requirements.

In our custom JUnitReportCollector, we are adding custom behavior in the afterStep method. As we required to show all steps with assertions regardless of they got success or failed, we added one more map to record steps status that are got success

HashMap<TestCase, String> status;

public IsplJunitReportCollector() {

reports = new HashMap<String, JUnitReport>();

failures = new HashMap<TestCase, String>();

status = new HashMap<TestCase, String>();

}

In beforeRun method we added common properties to system out so it can be shown by each test case. At this point we sets name of test case with prefix project.browser so that Hudson can separate test cases accordingly. Check code and Screen Shot below.

public void beforeRun(TestCaseRunner testRunner, TestCaseRunContext runContext) {

TestCase testCase = testRunner.getTestCase();

TestSuite testSuite = testCase.getTestSuite();

if (!reports.containsKey(testSuite.getName())) {

JUnitReport report = new JUnitReport();

String browser = PropertyExpansionUtils.getGlobalProperty(“Browser”);

String project = PropertyExpansionUtils.getGlobalProperty(“Project”);

report.setTestSuiteName(project + “.” + browser + “.” + testSuite.getName());

StringBuffer buf = new StringBuffer(“Date: “

+ new Date(System.currentTimeMillis()));

buf.append(“\nUIURL: “ + PropertyExpansionUtils.getGlobalProperty(“UIURL”));

buf.append(“\nStoreCode: “

+ PropertyExpansionUtils.getGlobalProperty(“StoreCode”));

buf.append(“\nVersion: “ + PropertyExpansionUtils.getGlobalProperty(“Version”));

report.setSystemOut(buf.toString());

reports.put(testSuite.getName(), report);

}

}

hudson_grooup_tc

Next customization point is afterStep method, which takes care of following points.

- Proper formatting result to make readable even if deployed by hudson

- Shows selenium log in case of failed step invoked browser

- Provides screenshot link if available

- Provides failure step’s details file link.

- Shows all steps results irrespective of it is failed or passed

- Show all assertions details if available

public void afterStep(TestCaseRunner testRunner, TestCaseRunContext runContext,

TestStepResult result) {

TestStep currentStep = result.getTestStep();

TestCase testCase = currentStep.getTestCase();

if (result.getStatus() == TestStepStatus.FAILED) {

StringBuffer buf = new StringBuffer();

if (status.containsKey(testCase)) {

buf.append((String) status.get(testCase));

}

if (failures.containsKey(testCase)) {

buf.append((String) failures.get(testCase));

}

Get report file and screenshots if available to attach. Hudson doesn’t support html formatted Stack trace but provide link for URL so we had provided plane text with URL of attachments. Here to check whether screen shot is available or not we are checking property of test case which will programmatically created by our custom groovy script which Invoking a seleniumRC test from soapUI (Please read our blog about Invoking a seleniumRC test from soapUI)

String screenshot = testCase.getPropertyValue(currentStep.getLabel() + “screenshot”);

String reportFile = getErrorReport(currentStep, runContext, result);

buf.append((new StringBuilder()).append(“\n” + result.getTestStep().getName()).append(

” Failed”).toString());

buf.append(lineBreak());

buf.append(showFile(reportFile, “View Details”));

buf.append(lineBreak());

//buf.append(“Absolute path: ["+reportFile+"]“);

buf.append(lineBreak());

buf.append(showFile(screenshot, “View Screenshot”));

buf.append(lineBreak());

Show Complete Message Logs:

buf.append((new StringBuilder()).append(

XmlUtils.entitize(Arrays.toString(result.getMessages())))

.append(lineBreak()).toString());

if (testRunner.getTestCase().getSettings().getBoolean(“Complete Message Logs”)) {

StringWriter stringWriter = new StringWriter();

PrintWriter writer = new PrintWriter(stringWriter);

result.writeTo(writer);

buf.append(XmlUtils.entitize(stringWriter.toString()));

}

failures.put(testCase, buf.toString());

}

Here is the code to show success steps information as well as all assertions

else {

StringBuffer buf = new StringBuffer();

if (status.containsKey(testCase)) {

buf.append((String) status.get(testCase));

}

buf.append(“\nTest Step: “ + currentStep.getName());

buf.append(“\tResult: “ + result.getStatus() + “”);

if (currentStep instanceof Assertable ) {

Assertable requestStep = (Assertable) currentStep;

if(requestStep.getAssertionCount()>0){

}

}

// any prior test-step failed!…

if (failures.containsKey(testCase)) {

String str = (String) failures.get(testCase) + “\n” + buf.toString();

failures.put(testCase, str);

} else {

status.put(testCase, buf.toString());

}

}

}

Screenshots:

– failed test case (failed UI test step)

seleniumts_before

After Customization

seleniumts_after_n
After Customization it shows failed test step with complete details, link to screen shot if it had invoked selenium as well as test steps that got success with assertions details. Next screenshot shows how it reports if deployed in Hudson.

seleniumts_after

VN:F [1.9.10_1130]
Rating: 9.4/10 (10 votes cast)

  

{ Comments on this entry are closed }

Note: For overall context for this blog please read integration testing with soapUI to understand why extending soapUI to work with Selenium is ever necessary.

A selenium RC groovy script which is one form of customizable edition of the recorded selenium IDE can be invoked in the soapUI. It is useful to perform various tasks in soapUI like as follows:

  • As a test step
  • To control testcase flow based on output of previous steps
  • To trigger the execution of test steps or test cases
  • As a data generator
  • As extended script libraries for common functionalities.
  • To write the results of test steps or test cases to an external source

Selenium RC and IDE

Selenium Remote Control (RC) is a test tool that allows user to write automated web application UI tests in multiple available programming languages against any HTTP website using any mainstream JavaScript-enabled browser.Selenium RC has two processes:

  1. A server which automatically launches and kills browsers, and acts as a HTTP proxy for web requests from them.
  2. Client libraries for multiple computer language.

The RC server also bundles Selenium Core, and automatically loads it into the browser.

Firefox extension calling Selenium IDE (Screenshot001) is used to record the functionality of the web site. It is easy to use and powerful tool for controlling, automating or testing web sites. It has record and playback feature that can be used to automate any thing in the web sites.

000011

(Screenshot001)

Selenium IDE has feature to save and export automated task in Groovy script (Screenshot002) which in turn can be used in soapUI.

0021

(Screenshot002)

For Selenium IDE users, Selenium RC is ideal solution to write tests in a more communicative programming language. So, to be more expressive, compatibility and for extra assertions recorded scripts are exported in Groovy Scripts.

Groovy Scripts

Groovy:

  • is an agile and dynamic language for the Java Virtual Machine
  • builds upon the strengths of Java but has additional power features inspired by other languages.
  • supports Domain Specific Languages and other compact syntax so that code is easy to read and maintain
  • makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
  • simplifies testing by supporting unit testing and mocking out-of-the-box
  • seamlessly integrates with all existing Java objects and libraries
  • compiles straight to Java bytecode so you can use it anywhere you can use Java

Groovy scripts can be widely used in a soapUI for different functionalities.

SoapUI

soapUI is open source desktop application for inspecting, invoking, developing, simulating/mocking and functional/load/compliance testing of web services over HTTP. In a given framework, soapUI is used for testing web service.

Following are the functionalities of the groovy scripts in soapUI:

  • As part of a Testcase with the Groovy Script Test Step, allow tests to perform virtually any desired functionality
  • Before and after running a Testcase or Test Suite for initializing and cleaning up before or after running the tests.
  • When starting/stopping a MockService for initializing or cleaning-up MockService state
  • When opening/closing a Project, for initializing or cleaning-up Project related settings
  • As a dynamic DataSource or DataSink with the corresponding DataSource/DataSink test steps
  • For creating arbitrary assertions with the Script Assertion
  • To extend soapUI itself, for adding arbitrary functionality to the soapUI core. User can create his/her own script libraries for common functionality which can be used shared by the Testing team.

Benefits of Groovy Scripts in Test Automation Framework

In Test Automation Framework, we have used groovy scripts mainly:

  • As a test steps. (refer below screen)

0061

(Screenshot003)

  • As a dynamic DataSink. (refer below screen)

0072

(Screenshot004)

  • Before and after running a Testcase or Test Suite for initializing and cleaning up before or after running the tests. (refer below screen)

008

(Screenshot005)

  • To involved Selenium RC scripts for extend soapUI, we have created own script libraries for common functionality which can be used shared by the Testing team. We have further customized it by creating a jar for the same i.e. scripts.jar and kept it in the soapUI setup at “C:\Program Files\eviware\soapUI-Pro-3.0.1\bin\ext”. (refer below screen)

0091

(Screenshot006)

When tester will run the soapUI project either from Test Automation Framework or from soapUI Pro, it will take the extended script libraries from scripts.jar file.

Conclusion

Using test automation framework, a tester can execute the soapUI test suites or test cases automatically segregated by categories and browsers. Framework is customizable by updating the extended soapUI libraries for common functionalities. It will actually help the user to create a groovy script for commonly used functions and then bind those scripts in a jar file so that user can use in soapUI. While executing soapUI, it will automatically use customized selenium groovy scripts with assumption that selenium services are running.

VN:F [1.9.10_1130]
Rating: 8.5/10 (2 votes cast)

  

{ 16 comments }

At two recent engagements we had to solve SOA integration testing problem. Simply  put, in a heavy SOA environment, our tests had to verify web services (SOAP  or REST) and additionally, for the validating the end to end scenario,  there were MORE than web services involved in the same scenario.  For  example, we had to incorporate GUI testing, or invoke a POJO or validate  something else using a DB script in the same test. For instance ,  you  could create a user using a web service and validate that the user can  login to the system under test using the web user interface.

Clearly this needed us to invoke a GUI test tool (or  framework) while doing a web service test. Our solution involved using  soapUI as the main container for our tests hooks for other tools. We  integrated following tools  with  soapUI

  • Selenium RC  for web based testing
  • Java interface testing (invoking a basic controller like java object – to test and validate some business functionality)
  • DB Unit

SoapUI was a natural candidate for us as it  was already being used by either the development or testing team for our  clients. Secondly, as these were tests with in a SOA environment, soapUI  was a great tool to home all the tests.

Our specialized  steps with in soapUI test invoked selenium or a Java interface or a DBUnit  based test  and asserted using the native assertions provided by  these tools. We will have a series of blogs here tagged with soapUI that  explain how we achieved it. Stay tuned …

Here are the links to these blogs:
Invoking a Selenium RC test from soapUI

Customizing soapUI reports

VN:F [1.9.10_1130]
Rating: 9.3/10 (4 votes cast)

  

{ 3 comments }