Skip to main content

vodQA-2 A grand success

ThoughtWorks, pune recently played host to the vodQA-2 event, a technical conference which brings testers from various organizations under one roof. The turnout for the event was way better than vodQA-1. The topics too were great and so was the quality of speakers. This time the event had lengthy talks, lightening talks and also a talk on TWIST, a ThoughtWorks product which is a testing tool.

This was what was covered during vodQA-2

Full Length talks
Deepak Gole & Saager Mhatre
Automated acceptance testing for iPhone
Sapna Solutions
Parul Mody & Vijay Khatke
Cloud Testing
BMC Software
Ashwini Malthankar
Effective use of Continuous integration by QA
Vijay and Supriya
Test your service not your UI

Lightning Talks
Satish Agrawal
Leadership and Innovation in a commoditized industry
Persistent Systems
Anay Nayak
Fluent Interfaces and Matches

Fish bowl topic
Transition from Manual to Automation Testing??
All speakers and attendees
Parallel Track: Ananthapadmanabhan R
Twist : Evolving test suites over test cases

There was a well conducted fishbowl session too which was discussed in detail with inputs from a lot of participants.

I was overwhelmed looking at the number of people who attended the event. There were easily about 100 people who were keenly taking down notes during the presentation and also flocking the presenters after their talk got over.

Overall i was very impressed with the way the event was organised. Kudos to the organising committee of vodQA.

Looking forward to vodQA3 now :)


Popular posts from this blog

BDD is over-rated

Over the past few years, I have tried to justify the use of a BDD (Behavioral Driven Development)  framework to express my tests, but not once have been able to say BDD has helped me address a  problem which writing tests the non BDD way would not have addressed. I do understand the value BDD brings to the table, but in most projects that I have implemented BDD on, we have tried to provide a solution (BDD) to a problem that does not exist.

Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more)
Collaboration between Business and DevelopmentUbiquitous Domain LanguageFocus on the behavior of the application Now, more often than not unless your business is co-located with the team, collaboration is not the easiest.

The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the system in a language that…

Motivation of tester types

In my testing career span of close to 7 years, i have come across various testers. Every tester has unique skill sets and things that motivate them. Based on the various tasks a tester has to do on a daily basis or during a project, I would like to categorise these testers into 3 types
Manual tester Automated testerHybrid testerManual testers are mainly non-technical and are focussed more on testing applications manually. These types of testers have good domain knowledge.

Automated testers are technical testers who mainly deal with tools to help them test applications. They are given a set of test scenarios and all they need to do is automate these scenarios.

Hybrid testers are like superman. They are expected to do whatever is thrown at them and it is these types of testers that are in demand these days.

Now the interesting aspect is what motivates these testers in their day jobs. Lets take a look at this in the form of a graph where x-axis represents the various activities involved in …

Can projects do without Business Analysts?

My  last 2 gigs were a bit different to the usual ones from a team composition point of view. The bit that was different was that there weren't any Business Analysts on the team. My initial concerns were who would gather requirements? Who would analyse stories? Who would negotiate scope with the business? Who would be involved in Scope Management? Who would be our proxy customer?

The above questions got me concerned, but it wasn't as bad as i thought it to be. The customer was co-located with the team and we had easy access to validate our understanding on business rules, scope, sign-offs etc.

Our team composed of an IM, Devs and Testers. The IM was managing scope with the customer and getting the priorities. The team would then sit with the business to understand what the requirements were and we would create Epics and then further break them down into smaller chunks of workable stories. A thing to note here is that all roles would put their BA hat on and identify gaps if an…