Pankaj Nakhat's blog : All About Agile Testing

I have been practicing Acceptance Test Driven development for years and since last few years I have been using BDD . BDD is a collaborative process to engage with business at the same time offering other benefits in Automation testing. There is no doubt BDD has changed the way we collaborate in an Agile team but also enhanced communication among stakeholders.

Some of the challenges I have seen while working on various projects, which I learnt from on my journey to do Behaviour Driven Development.

Process challenges

1. How to get business engage with this Idea of doing Testing  ?- I am sure this is easier said then done. How do I get my business stakeholder to engage in this process ? This scenario is like a sales scenario where you want to sell a great new product, but the problem is features are not immediately obvious.  Yes its about selling,  before its benefits becomes obvious.   Good thing about is BDD is natural language of expression, so getting involved is easier. BDD Scenarios makes so much sense in terms of a requirement. You can drive a product by an example in your own language, which is great. Its a great comfort when the Gap between requirement to development is negligible. Technical and Non technical people are speaking same language and you can validate your product in the very same language .
2. How to be consistent with the language  used in BDD ?  The whole idea of this process is about using a language which all stakeholders can understand and make sense from ? But one of the smells of BDD is using multiple style to define your behaviors. And result is simple, people are not consistent with their language of communication, so further consequence is mis communication and chaos.  Reason is simple “a” thing in my behaviors can mean few different thing. Other aspect of the same problem is different level of abstracted language people use, should I define my behaviors at 10000 ft or should it be more granular ? Well this depend  on the context, I don’t mind any approach where the language speaks the language of the problem we are trying to solve and its consistent.
3. Who should write the BDD ? I think it doesn’t matter who writes the BDD Scenarios. As long as different stakeholder participate in the process, and it is used as paradigm of communication it does not matter who writes it eventually. I have heard people getting in to discussion whether QA/BA/SME should write the acceptance tests. I think idea of doing BDD is to share the responsibility and getting everyone engaged in this process.
4. How to maintain my Acceptance tests going forward ?  I think the most important challenge in doing Acceptance Testing using BDD is, how does change in feature/code/data be managed. How the change should be managed in the acceptance tests? How not to fall in big trap of technical debt when big re factoring comes along and acceptance tests are well forgotten ? And I think most teams falls apart on these challenges more often then not. I have seen developers changing the acceptance tests without liaising with BAs and QAs when pressure of delivering eventually mounts. Similarly I have seen QA/BAs not managing to change the acceptance tests to reflect the change in feature. So basically challenge is to follow the same process when things are tight. Every change in feature should be managed as if its a new feature and should have a respective acceptance tests, agreed together with different SMEs.  Individual people on team should refrain making changes to acceptance tests, event though it may look trivial.Sometime it is difficult to trace acceptance tests against requirements, as in there is no obvious tooling in place to support trace the requirements against the tests. And if you are working on a large project it can be a nightmare to do so.  In this case having some means of tracing mechanism in place definitely helps. It can be as simple as a spreadsheet or usage of story maps if you are using tools like jbehave.

 

DSLs have been buzzing around for a while now, and I thought of putting some thoughts together.

DSL – Domain Specific Languages, what does it mean for Testing? What are the benefits..

Over the years automation testing has changed from record and play back mechanism to more structured, framework oriented approach. Benefits were evident Test were readable, Scalable and Maintainable.

But there was more needed to be done, as most automation tests would turn in to over head rather then assets.  Framework based approach was good..but came up with its own sets of problem. Some of them were Code like tests, which meant they were not human readable and needed either hours of

documentation to make them explicit to humans.  So if the application changed underneath both test and documentation needed to change. And after a while these will not match each other by any means.

Frameworks like keyword driven testing enabled naive to write Tests, however created the problem of highly non abstracted tests.

Since the introduction of methodologies like Agile, it was inevitable that those problem needed to be sorted fast. Tests needed to be changed quickly with often changing requirements.

DSLs allows you to write tests in your own domain..be it banking, Online Gaming or Travel Industry.  Which means tests are human readable and highly contextual to domain.

For example – I need to write a Test for a baking application for testing a Scenario of Transfer of a fund from Account A to Account B.  Note, I am talking in terms of any specific tool here, and that I will keep up for a separate post.

<Test>

1. Login in my online banking application with user “A”
2. Go to transfer funds page
3. Check initial balance it should be “£ 500″
4. Transfter amount “£100″ to account “B”
5. Check final balance , it should be “£ 400″
6. logout from the application.

</Test>

In above example , Test exactly looks like manual test scripts but there nature is Executable in whatever technology and tool we choose.

What problems does it solve?

• Maintenance is easier now as test are human readable.
• Adding and Amending a step in Test just requires finding the right step, rather then changing the implementation  (In Most of the cases).
• For example – In above Test I need to add a new requirement of a welcome page after login. We simply introduce another DSL step after step1 “Verify user is shown welcome page with him name on it”, and rest of the test is still unchanged.
• Test can be extended easily to do more comprehensive end to end test.
• If the application changes underneath in terms of UI Objects , tests will remain unchanged, only the underlying implementation will change.
• If a business process changes completely, changed can be accommodated easily by changing the DSL definition. For example in above Test the transfer process changes and now required another level of authentication before transferring the funds. We would change the definition of Step4 to ‘Transfter amount “£100″ to account “B” and enter authentication password for user “A”‘

DSLs can also come with its own challenges, which I would like to discuss in my next post.

[quicksubscribe]

DSL, DSL Automated Testing