[Date Updated] Announcing the next vodQA event in Pune

[Date updated to 17th March 2012]


After a long delay, ThoughtWorks is happy to announce the next edition of vodQA - THE TESTING SPIRIT! on 17th March, 2012 in ThoughtWorks Pune office.


Watch this space for more details.


Contact me if you are interested in helping make this a great event!


Thanks.


Anand

Assertions and Validations in Page Objects

A colleague recently asked me a very nice set of questions - 

• "Have any of you designed tests with assertions happening in page objects and not in the tests? 
• If yes, have you faced any specific problem with this approach? 
• What would be the drawback in moving the assertions inside the page's methods."

Here are my thoughts on this.

Test Framework Design

I follow a few principles when designing my test framework:

• Test code should be of Production Quality!
• Since the test code should be of Production Quality, it means it needs to be designed and built using design patterns.
• This well-designed test framework should have proper abstraction layers. These abstraction layers help in many different ways:
• Decouple test specification from test implementation
• Provides greater level of re-usability
• Easier in re-factoring
• Easier to maintain and evolve the framework
• Easier for all team members to ramp-up and work in a collaborative way on specific abstraction layers.
• Evolve your framework functionality and implementation. Keeping the end goal in mind, develop the framework as per requirements at that point in time. Do not attempt to build all the functionality in a single shot. More likely than not, you will end up building something that is not going to satisfy the future requirement.

See the diagram below for reference on different possible layers of a Test Framework.

What is Page-Object pattern?

Page-Object pattern is one of the powerful ways of designing a good, reusable, extensible and maintainable test framework. 

This article as great explanation and examples of Page Objects (http://code.google.com/p/selenium/wiki/PageObjects)

Assertions and validations in Page Objects?

The page object is a code representation of the actual page. It has accessors and modifiers (getters and setters) for various objects in that page. It only knows how to perform actions on the page object, and retrieve data / values from the page. 


If there is any problem in the page under test, or the page object representing the page, then the test will fail automatically (in most cases) because of functionality mismatch. 


Assertions / verifications are essentially business rules for the product under test.


The page-object should not have assertions or verifications in them. The business rules of the product do not belong in the page object layer, but instead in the layer above it.

In many cases the business rules remain the same where as the underlying implementation evolves. If you have the changes isolated and decoupled, then updating the framework becomes easy and much quicker. this also makes more sense in larger and distributed projects where everyone may not be on the same page.



I refrain from having any form of assertions in the page's object. It mixes the pure implementation of visibility of the page's functionality with the business logic. This in turn makes both, the framework and the tests brittle.

The impact of having these rules and guidelines of how the test framework is structured is greatly seen as the framework matures and when new people come on the team, the learning curve is not as steep.

If the project is small, or if the test framework is going to be thrown away after some time,  then you can probably get away by building the framework any which way you want. 


Thinking that I will take the easy way out for now and then will come back to "do this right" is a trap!!! More often than not, you are never going to get time to come back and make things right. So might as well, spend a little extra effort in the beginning and build your test framework the right way! Remember - "A stitch in time saves nine"!

Poor motivation

Effective Strategies for Distributed Testing - slides available

I finally figured a way around the problem PowerPoint was giving me in converting the slides for this presentation to pdf format. 


The slides are now uploaded in slideshare.net  and available here.


The video recording of the webinar is available here.

vodQA - NCR

I am very happy and proud to share that vodQA conference is going national. 


ThoughtWorks will be hosting its first vodQA out of Pune ... this time in Gurgaon on 3rd December 2010.


I will be pairing with Manish Kumar on a topic "Distributed Agile Testing for Enterprises"


See this page for more information.

Effective Strategies of Distributed Testing - recording available

On 9th November, 2011, I presented my first webinar with my colleague - Manish Kumar, on the topic "Effective Strategies for Distributed Testing".


We spoke based on our experiences and shared tips and strategies on various different themes, like 
- agile testing principles that matter!
- need of distributed teams,
- testing challenges in distributed teams,
- mindset, 
- communication, 
- collaboration, 
- tools & technologies,
- ATDD,
- test automation,
- and many others ...


All distributed teams are working on the same product ... hence it is extremely important to treat all these distributed teams as ONE TEAM!


Watch the video recording of this webinar available here. 


(http://testing.thoughtworks.com/events/effective-strategies-distributed-testing).

Effective Strategies for Distributed Testing - webinar

Come, join Manish Kumar and me for a webinar on 9th November, 2011 on "Effective Strategies for Distributed Testing". 


We will be sharing tips and techniques on how you can make testing in distributed teams more effective.


More details on the webinar are available here.

Asking the right question

This Dilbert strip says it all!!


For those not able to see the link it correctly, here it is:

If you don't ask the right question, the topic can digress in any direction ... resulting in waste of time and effort of all involved.


So remember - its not just important to ask questions, but it is more important to ask the right questions!!

Does extrapolation in estimation work?

How do you estimate test automation efforts for building a regression suite for functionality that is already in Production?


The approach I am following is:
> Get some level of understanding about the domain
> Look at a subset of existing test cases of varying complexities and sizes
> Estimate the effort for each of them and also identify the complexity involved in each, with the risks and assumptions.
> Identify some obvious spikes / tech tasks that will be needed
> Extrapolate the estimates
> Add 10-15% buffer in the estimates for unknowns.


And presto!! .... I have my estimates for the task on hand.


Is this approach right? 
Is extrapolating the estimates going to give valid results?
What can be different / better ways of getting the results required?

To test or not to test ... do you ask yourself this question?

For people involved in Test Automation, I have seen that quite a few of us get carried away and start automating anything and everything possible. This inherently happens at the expense of ignoring / de-prioritizing other equally important activities like Manual (exploraratory / ad-hoc) testing.

Also, as a result, the test automation suite gets very large and unmaintainable, and in all possibilities, not very usable, with a long feedback cycle.

I have found a few strategies work well for me when I approach Test Automation:

• Take a step back and look at the big picture.
• Ask yourself the question - "Should I automate this test or not? What value will the product get by automating this?"
• Evaluate what test automation will truly provide good and valuable feedback.
• Based on the evaluation, build and evolve your test automation suite.

One technique that is simple and quick to evaluate what tests should be automated or not, is to do a Cost Vs Value analysis of your identified tests using the graph shown below.

This is very straight forward to use.

To start off, analyze your tests and categorize them in the different quadrants of the above graph.

1. First automate tests that provide high value, and low cost to build / maintain = #1 in the graph. This is similar to the 80/20 rule.
2. Then automate tests that provide high value, but have a high cost to build / maintain = #2 in the graph.
3. Beyond this, IF there is more time available, then CONSIDER automating tests that have low value, and low cost. I would rather better utilize my time at this juncture to do manual exploratory testing of the system.
4. DO NOT automate tests that have low value and high cost to build / maintain.