Tuesday, March 27, 2018

Test Driven Development (TDD) and its modern variations

NOTE / RECOMMENDATION - This blog post is to be read with your funny side switched on!

First - lets answer the question - What is TDD?
Directly from https://en.wikipedia.org/wiki/Test-driven_development - Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
American software engineer Kent Beck, who is credited with having developed or "rediscovered"[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999,[3] but more recently has created more general interest in its own right.

However, over the years, fortunately or unfortunately, I have also come across various different techniques (used consciously / unconsciously) in Software Development, to get the work done. Some of them are listed below - in alphabetical order:

BDD = Behavior / Business Driven Development
BDD = Blame Driven Development
BDD = Buzzword Driven Development
CDD = Calendar Driven Development
CDD = Checklist Driven Development
CDD = Chadi (stick) Driven Development
CDD = Constraint Driven Development
DDD = Date Driven Development
DDD = Defect Driven Development
DDD = Document (PRD) Driven Development
EDD = Escalation Driven Development
EDD = Estimation Driven Development
EDD = Excel Driven Development
FDD = Fashion Driven Development
FDD = Fear Driven Development
FDD = Footwear (punishment) Driven Development
HDD = Hope Driven Development (fingers crossed)
IDD = Instinct Driven Development
IDD = Issue Driven Development
JDD = Jira Driven Development
MDD = Metrics Driven Development
MDD = Manager / Management Driven Development
PDD = Patch(work) Driven Development
PDD = Plan Driven Development
PDD = Prayer Driven Development
PDD = Process Driven Development
RDD = Resource Driven Development
RDD = Resume Driven Development
SDD = Stackoverflow Driven Development
SDD = Stakeholder Driven Development

And the last one -
NDD = No-Drive (towards) Development

Any other style of development you have come across in your experience?
Hope you had fun reading the list! 


Saturday, March 17, 2018

Measuring Consumer Quality - The Missing Feedback Loop

I spoke in vodQA at ThoughtWorks, Pune on "Measuring Consumer Quality - the Missing Feedback Loop". 

This talk address the why and how from my earlier blog post on "Understanding, Measuring and Building Consumer Quality". I recommend you read that first, before going through the slides and video for this talk.


Abstract:

How to build a good quality product is not a new topic. Proper usage of methodologies, processes, practices, collaboration techniques can yield amazing results for the team, the organisation, and for the end-users of your product.

While there is a lot of emphasis on the processes and practices side, one aspect that is still spoken about "loosely" - is the feedback loop from your end-users to making better decisions.

SO, What is this feedback loop? Is it a myth? How do you measure it? Is there a "magic" formula to understand this data received? How to you add value to your product using this data?

In this interactive session, we will use a case study of a B2C entertainment-domain product (having millions of consumers) as an example to understand and also answer the following questions:

  • The importance of knowing your Consumers 
  • How do you know your product is working well? 
  • How do you know your Consumers are engaged with your product? 
  • Can you draw inferences and patterns from the data to reach of point of being able to make predictions on Consumer behaviour, before making any code change? 

Video:


Slides can be found here.

Pictures:



Friday, March 9, 2018

MAD-LAB - Capabilities & Features - Agile India 2018

I spoke about "Build your own MAD-LAB - for Mobile Test Automation for CD" at Agile India 2018.

Though I have spoken on this similar topic answering the question - "Why I needed to build my own MAD-LAB?" before at vodQA in July 2017 at Vuclip, quite a few things have changed since then.

Knowing the value of "being agile", a day before my scheduled talk in Agile India 2018, I decided to revamp the content substantially. To add to my challenges, (and thanks to "testing" my slides before the talk in the conference room), I also realised the slide size format I was using is incorrect, and also the projector was not "setup / configured" correctly, making all my slide colours go haywire.

So after last 10 minutes of scrambling before the talk time, I managed to get this done correctly (at least that is what I think now in hindsight.

Moral of the above story - do a test / dry-run of your slides before your audience comes in!

That said, here is the abstract of the talk.


Abstract

In this age of a variety of cloud-based-services for virtual Mobile Test Labs, building a real-(mobile)-device lab for Test Automation is NOT a common thing – it is difficult, high maintenance, expensive! Yet, I had to do it! 

The slides are part of the discussion on the Why, What and How I built my own MAD-LAB (Mobile Automation Devices LAB). The discussion also includes the Automation Strategy, Tech Stack, Capabilities & Features of MAD-LAB and the learnings from successful & failed experiments in the journey. 

Slides

Below are the slides from my talk. The link to the video will be shared once available.




Some pictures