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
Topics
Organization
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
ThoughtWorks
Vijay and Supriya
Test your service not your UI
ThoughtWorks

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

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

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 :)

Comments

Post a Comment

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 Development Ubiquitous Domain Language Focus 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 syst...
1 comment
Read more

Testers and Automated Testing

We all know the value a tester brings to projects and the industry is now finally valuing testers as equals to developers. However, one thing that is often a debate is the input or role a tester has on automated testing. Testers can have a major influence in automated testing without having to write all tests on their own. In my company, testers are expected to be technical and be able to write automated tests on their own. In fact the expectation is to create the Automation Framework too. I am not a fan of testers creating automation frameworks or writing automated tests on their own. I would prefer for testers to pair with developers on any automated testing activity, be it the framework or writing automated tests. Testers understand the application backwards and they are the best candidates to identify what should be tested. Now, by collaborating with the developers, both can make an informed decision as to what can be tested and at what level. For e.g. Some tests are worth wri...
Post a Comment
Read more

Test your services and not your UI

As a tester, i have spent more than 6 years trying to automate tests at the UI layer. As years passed, better automation frameworks evolved resulting in writing more manageable and maintainable code, but the only thing that wasn't getting better was the cost of maintaining these tests, especially when the no. of tests were 500+. There are multiple reasons why i feel creating an automated regression suite of tests at the UI layer is not good. Some of them are Limitations on what the tool can do Time taken to execute these tests leading to longer feedback loop Success rate of tests is not 100% due to latency issues Change in UI and UI flow resulting in an increase in cost to maintain UI tests On the other hand, testing business logic without having to deal with the dumb UI was a concept that a friend of mine at ThoughtWorks, Chirag Doshi introduced to me. He sent me couple of blog links written by Alex Verkhovsky about why is it so hard to do functional test automation at th...
1 comment
Read more