Tuesday, April 15, 2014

Concurrency testing made easy

Having a multi tenant application under test, concurrency testing is the next step of the testing cycle. Testing using concurrent users takes a lot of time and usually ends up in defects not fully reproducible because of timing issues (synchronization) thus making automation of these tests a must.

Automating concurrent tests using selenium / webdriver always brings up one of the most common question in automation testing; Do I need a new window or open a new tab? The correct question should be: how do I open a new session? And here is the tricky part of the tests. If you open a new window or tab you will carry the session from the window you started from. Some sites will suggest, “clearing the cookies” but this involves the whole browser not a specific window thus the newly assigned session id is the same on all existing windows and tabs.

The solution to the above explained problem is to start two or more selenium / webdriver sessions. To simplify these procedures we use a specific Stevia functionality in order to instantiate 2 webdriver controllers. The instantiation is declared in a spring xml file we call test-controllers and includes the following:

<bean id="webDriverControllerSession1"  class="controllers.ControllerSession1" scope="prototype"/>
<bean id="webdriver-s1-driver" class="com.persado.oss.quality.stevia.selenium.core.controllers.registry.Driver"
   p:name="webdriver-s1"
   p:className="controllers.WebDriverS1WebControllerFactoryImpl"/>
<bean id="webDriverControllerSession2"  class="controllers.ControllerSession2" scope="prototype"/>
<bean id="webdriver-s2-driver" class="com.persado.oss.quality.stevia.selenium.core.controllers.registry.Driver"
   p:name="webdriver-s2"
   p:className="controllers.ControllerFactoryImpl"/>


Note: The spring framework schema p should be included in the xml file, and the controller factory implementation should be created in the appropriate packages.

Having the two controllers at hand we can use a Stevia annotation @RunsWithController(controller=controllers.ControllerSession1.class) before any @BeforeClass or @Test annotations.

The next big problem at hand is how to synchronize the sessions in order to have control of the test execution; synchronization in java is quite advanced, there are a lot of techniques, to mention a few: Cyclic barrier and Count Down Latch. These techniques involve heavy coding and it is an overkill to use them. The most appropriate way to synchronize the execution of tests for different controllers is to use the dependency attribute provided by testNG.

Lets use a specific example to put things into perspective:

 Lets assume there is a phonebook application where you can create a custom phone book and assign contacts. You can edit or delete the phonebook as long as it is empty. So lets assume that in session 1 a user created a phonebook and in session 2 a second user assigns a contact. In session 1 the user is not aware that an entry has been added to the phonebook and wants to edit the phonebook name. As soon as the user presses the edit button he / she is presented with an error message stating that you are not allowed to edit on non-empty phonebook.
In the aforementioned scenario there are 2 clear preconditions, as follows:
User in session 1 creates phonebook
User in session 2 adds a contact in phonebook
And a test step with the following action and expected results
User 1 presses the edit button => User is presented with error message

The synchronization sequence is shown below:



For the two preconditions the synchronization could be done using testNG BeforeClass annotations as follows:

@RunsWithController(controllers.ControllerSession1.class)
public void createPreconditionsSession1(String parallelTestsFlag) {
     // User in session 1 creates phonebook
}

@RunsWithController(controllers.ControllerSession2.class)
@BeforeClass(dependsOnMethods = "createPreconditionsSession1")
public void createPreconditionsSession2() throws Exception {
    // User in session 2 adds a contact in phonebook
}

@RunsWithController(controllers.ControllerSession1.class)
@Test(alwaysRun = true, description = "Edit phonebook name")
public void testStep_1() {
    // User presses the edit button => User is presented with error message
}
TestNG will execute createPreconditionsSession1 -> createPreconditionsSession2 -> testStep_1

The next big question that comes to mind with this implementation is how do I run preconditions on different sessions for each step? Lacking a before specific test method and the problem that the usage of a Test annotation is adding noise (step is counted to results as pass even if it is a precondition) we need an extra annotation to execute the precondition. The latest SNAPSHOT of Stevia solves the above problem by introducing an annotation to allow execution of a series of pre and post conditions on a Test annotated step. Lets use the previous example and add a step to our test verifying the story “ User from session 1 created a new phonebook. User in session2 adds a contact. User in session 1 presses the delete button for created phonebook.

@Preconditions(controller=controllers.ControllerSession2.class,value={"test3Pre1", "test3Pre2"}) 
@RunsWithController(controllers. ControllerSession1.class)
@Test(alwaysRun = true, description = "", dependsOnMethods = {"testStep_1"})
public void testStep_2() {
    // User presses the delete button => User is presented with error message
}
public void test3Pre1(){
    // User in session 2 adds a contact on created bucket
}

Note: The second phonebook (delete action test step) is created in the preconditions section along with the first phonebook (edit action test step).

So having these powerful annotations in stevia you can manipulate any test script execution without sacrificing any of the testing standards. As a result the quality is amplified to a new level by having test step pre and post conditions independent of your testing framework (Junit or TestNG).


Read More

Friday, April 4, 2014

Stevia enhancements and documentation

Stevia

Lately, we've been using Stevia a lot; we're also extending it as much as possible (no promises, but phantomjs is in our crosshairs lately). By talking to the community, it has come to our attention that people are having difficulty to start up a Stevia project. To that extend, we've created some content to give you a boost:

  1. Our SNAPSHOT javadoc is regularly published in Github Pages,
  2. We've setup Travis continuous integration and our build is currently
  3. We have a brand-new, all-shining Stevia Quick Start Guide.

We hope that the above additions will give you a helping hand. If not, feel free to send us your bugs/comments via the issue tracker in Github. We're listening.
Read More

Wednesday, February 19, 2014

Page Objects are not enough

The Page Object design pattern is one of the most popular patterns in test automation just because it promotes test maintenance and unifies the way QA teams work. As the pattern dictates, a page object is the representation of an html page using objects. The objects contain the html element addresses (Xpath, Css or DOM) and the user actions on them as methods (press, input, select, etc.).

Although the page objects pattern is widely accepted, our work experience showed that it is inadequate in fully describing an html page because it lacks the ability to represent the business logic of the page. In order to solve this problem we use a complimentary entity to the page object, the business object.



The business object is a class containing the business logic behind the page. An example of html page business logic is the validation of the mandatory fields of a form. The page object by its definition could not contain the aforementioned logic it can only carry the info that pressing the submitting button an error is raised without reasoning. The business object compliments the page object in having a method for trying to submit a form without the mandatory fields completed and an error is raised. The complimenting nature of the business object stands because the business objects uses the page object’s methods to assemble the logic thus its methods are a collection of page object methods.

The breakthrough of this approach in the representation of the html page is that it keeps a clear separation of the logic from the html elements introducing an abstraction layer for the business object thus separating future changes in the page logic from its locators. In addition it may introduce reusability (a business object may exist in more than one pages hence page objects). Using the previous example a possible subtraction of a mandatory field does not affect the page object only the business one thus the change is marked in a single place.


In a later post I will try to expand on how to implement our business objects and what we do in special cases such as repeating pages with in the software under test.

Read More

Tuesday, February 11, 2014

Gray box testing is the way to adapt for automation testing

When we finished the design of our objects for setting up the preconditions of an automated test case we showed it to one of our developers and his first reaction was “it is the same with the app’s domain model”. This comment made me think that knowing the application internals would be extremely useful in developing correct test scripts.  Knowing this had me thinking that the gray box testing would be more appropriate in our automation tests than black box, thus a switch to that direction is worth considering.

Why is gray box more appropriate in automation and not manual testing? Because any automation tester will have the technical skills to understand the internals of a software application and to prepare the appropriate testing code to interface with available hooks or services, something that a manual (non-programming-savvy) tester would not have.

As a case study I used the current project I was working for. In this project there was a front end used as an emulator of an external system. The front-end app is retrieving data from a database. Black box testing ignores were the front-end app gets its data as long as the displayed data is correct. While this is acceptable for any functional test case, the big picture is revealing shady areas of operations. For example for large amount of data we need pagination (more effort and man hours out of the developers), in parallel testing there are significant delays due to concurrency issues (front-end was not designed initially for heavy duty traffic) and in some cases there was data loss misleading the testing team into opening false defects.

Switching in gray box testing to identify the internals (understanding how data is written to database and how it is queried by the front-end) was simple with the usage of some Spring connectors to read the database. The advantages were the following:

  •           No more maintenance for the front end emulator
  •           Parallel testing speed up
  •           Single point of failure (database not emulator)


Switching to gray box testing made our scripts more robust and lifted the maintenance effort from the development team therefore becoming more suitable for our needs.  Expanding the gray box testing technique allowed us to start using services like JMX to communicate with the app in more accurate and direct way, leading in testing various paths inside the app’s code that were not exposed to us initially. This assisted us in revealing not functional but bottleneck-related bugs of the software.

Gray box testing is the way to go for any automation tester because it can reveal potential bottlenecks inside the code before the performance test does and because it simplifies the way test scripts are created. Gray box testing pushes you to learn more tools to hook into the app thus expanding your software development skills thus becoming a better automation engineer.


Read More