Tuesday, April 9, 2013

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 any while breaking down the stories. The business was open about design and the way the functionality would work and not crib about things, like specific error messages, or look and feel. A lot of that was left to the team to decide on what would work best for the product.

We would have shoulder checks with the testers and then at times also validate with the business if what we were building did meet their expectations or not. What could have been done better was to involve the business more often during shoulder checks in-order to further reduce the feedback loop.

In this case, the team themselves were proxy customers for themselves and would in a way validate on behalf of the business if what was being built was fit for purpose or not. As mentioned earlier, regular feedback from business helped keep us in check.

But, would this model work for all projects? Perhaps not. Gigs which require hardcore analysis require specialist BAs who focus on analysing the requirements. Building an Insurance portal which has so many business rules would require some detailed analysis which would require a dedicated role to just focus on ensuring the analysis is spot on. I totally believe in the value a Business Analyst would bring to the project. But it would be interesting to work on a project where the domain is complex, but there is no BA on the project.

Sunday, April 7, 2013

Why is Testing/QA another lane on your card wall?

A typical story card wall on most Agile projects would have the following lanes
  • Ready for Development
  • In Development
  • Ready for QA
  • In QA
  • Ready for Customer Sign-off
  • Done
Having this lane structure gives the impression of the team working in silos. It feels like the developers work on developing the story and hand over an artifact to the QAs to now go and test and then whatever happens after that is their (QAs) problem.

In my previous projects, we have tried to combine the In Development, Ready for QA and In QA lanes to one "In-Progress" lane.

The benefits of doing this were
  • The responsibility to move a story to done was now owned by the team and not a specific role.
  • Developers, Business Analysts would help with testing if testing was a bottleneck.
  • We could set Work in-progress limits, so as to implement a pull model, where only as much work is done as can be consumed.
This approach helped the team manage the flow of stories across to Done in a more sustainable way.

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 writing at the UI level as the tests which are written on the underlying layers do not cover that. This also gives both tester and developer confidence on the test coverage.

As a result of this, the tester need not waste time testing all those weird cases manually as they have automated tests to validate them and the tester can focus on other edge/weird/negative/boundary cases which could detect some defects.

Also, another benefit of this is that the testers would be able to learn better coding techniques by pairing with developers and have a better understanding of the codebase. This would help them to read the code better and possibly find defects by reading code as well.

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 system in a language that fits the domain.

However, time with the business is minimal and most has to be made of the little time we get with them. Having to validate our understanding on what needs to be delivered, the priorities etc take up most time, but asking the business to read our automated tests is something I have found difficult to get buy in on.

 In spite of trying to explain the value BDD brings to the table, the business would not consider this as an important task. And finally, the team ends up writing BDD tests, which is an additional abstraction layer which needs to be maintained.

I have tried on many projects to get the business to validate our understanding of what needs to be tested by sending across our BDD tests, but without much success of the real values BDD actually provides. These days, BDD is used just because it is the IN THING and everyone is doing it, so why shouldn't I do it? I have been able to successfully express my tests in a very domain specific language without having to use BDD and also maintaining the key principle of automated testing "Separate Intent from Implementation".

I would use BDD only if my business is co-located and these BDD tests are used by the business to validate that the story is "Done".

Sunday, October 10, 2010

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 tester
  • Hybrid tester
Manual 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 the life of a tester and y -axis represents motivation levels.


As we can see, the motivation levels of manual testers for technically oriented tasks is fairly low and that of automated testers is high. It is the opposite for automated testers where their motivation is fairly low for tasks that are less technical.

However, the hybrid testers seem to be motivated consistently across all tasks and this is what makes them stand out amongst the herd of testers.

So in order to provide value to teams, testers should strive to become hybrid testers

Thursday, October 7, 2010

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

Monday, August 23, 2010

Taboo game

A colleague of mine Anand Bagmar and I were conducting a QA-bootcamp (training) for some fresher and lateral tester hires in our organization. During the second day, we thought of having an ice-breaker in the form of 'Taboo' as a game. As we played the game and were observing the participants playing, anand and I realised something. There were many aspects of the game that testers adopt in their day-to-day jobs as testers. After the game ended, we asked everyone to come up with their learnings from the game. This is the list they came up with

Team Work
Interference
Focus
Leg-pulling
Expression / Communication
Distraction
Time management
Strategy
Observation
Persistence
Support
Rotation / Shared Responsibility
Build Trust
Conflict Resolution



 The above list almost completely if not fully, covers all the aspects of what we as testers try and adopt to get our job done in the best possible manner. 

We thought of this as a very useful exercise and decided to incorporate it in every qa-bootcamp.