Evolving TDD

I had posted an update to my earlier blog post about TDD & its variations. Well, not surprisingly, I have encountered some more variations of this amazing practice. Here is the updated list with the new additions called out.

ATDD = Anti-Trust Driven Development
BDD = Benefit Driven Development
CDD = Cribbing Driven Development
CDD = Control Driven Development
IDD = Indifference Driven Development
ODD = Optimism Driven Development
PDD = Punishment Driven Development
RDD = Reporting Driven Development
SDD = Slide(s) Driven Development
SDD = Short-cut Driven Development

A few variants kindly shared by the community members:
FDD = Food Driven Development
SGDD = Style Guide Driven Development http://styleguidedrivendevelopment.net/

To recap, here is the original list
ATDD = Acceptance Test Driven Development
BDD = Behavior / Business Driven Development
BDD = Blame Driven Development
BDD = Buzzword Driven Development
CDD = Complexity Driven Development
CDD = Calendar Driven Development
CDD = Checklist Driven Development
CDD = Chadi (stick) Driven Development
CDD = Constraint Driven Development
CPDD / CDD = Copy-Paste Driven Development
DDD = Demo 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 = Fake-it 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
MDD = Mandate Driven Development
MDD = Meeting Driven Development
NDD = No-Drive (towards) Development
PDD = Patch(work) Driven Development
PDD = Plan Driven Development
PDD = Prayer Driven Development
PDD = Process Driven Development
PDD = Profanity Driven Development
RDD = Resource Driven Development
RDD = Resume Driven Development
SDD = Stackoverflow Driven Development
SDD = Stakeholder Driven Development
SDD = Swallow-exceptions Driven Development
SDD = Sprint Driven Development
TDD = Trust Driven Development
VDD = Velocity Driven Development

Why not to use PageFactory and FindsBy in Selenium WebDriver

Many users of Selenium WebDriver may be using the PageFactory created by Simon Stewart. However, it is not a good idea to use it.

You may be thinking why should I not use it? It is so easy to use it, and its popular.

Well, here are 2 reasons why you should not use the PageFactory:

Reason #1. Simon Stewart (https://twitter.com/shs96c), the creator of WebDriver, and the PageFactory himself says, do not use it. It is not recommended.

The `FindsBy` annotation isn't recommended, because the PageFactory class is really badly implemented and inflexible, but it's not going away in the java bindings.

The `FindsByX` interfaces are going away. Better to use a `By` locator and use that.

 

https://twitter.com/shs96c/status/1196865907185868801

Reason #2: While Reason #1 should have been sufficient, many people implementing automation using Selenium WebDriver do not know, or did not pay heed to what Simon said. So another WebDriver & WATIR contributor, Titus Fortner (https://twitter.com/titusfortner) explained in detail why using PageFactory is not a good idea in his blog post - https://titusfortner.com/2021/02/03/page-factory-optimization.html. 

 

I sincerely hope these reasons are sufficient for you to move away from the PageFactory and use something more efficient. 

 

TDD and its variations in 2021

Back in 2018, I had written a blog post about Test Driven Development (TDD) and its modern variations.

Today I have some more insights on the variations.

To recap, here is the original list

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
NDD = No-Drive (towards) 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

Here are the new variations I have come across:

ATDD = Acceptance Test Driven Development
CDD = Complexity Driven Development
CPDD / CDD = Copy-Paste Driven Development
DDD = Demo Driven Development
FDD = Fake-it Driven Development
MDD = Mandate Driven Development
MDD = Meeting Driven Development
PDD = Profanity Driven Development
SDD = Swallow-exceptions Driven Development
SDD = Sprint Driven Development
TDD = Trust Driven Development
VDD = Velocity Driven Development 

Have you come across any of the above variants? Anything I have missed?

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! 

Agile Testing & Patterns for a good Test Automation Frameworks

2018 started with a bang! I got an opportunity to speak and share my experiences in 2 rocking meetups.

Patterns of a "good" Test Automation Framework

TechnoWise meetup on 13th Jan on Patterns of a "good" Test Automation Framework went very well, with lot of interaction and discussions along the way.

Patterns of a “good” test automation framework from Anand Bagmar

What is Agile Testing? How does Automation Help?

Then, there was an impromptu meetup setup by a very proactive ISQA community at GO-JEK office in Jakarta, Indonesia on 16th Jan. The topic there was What is Agile Testing? How does Automation help? In this meetup, I also covered aspects of Career Path of a Tester, and QA Skills and Capabilities.

There were many amazing experiences from this meetup -

• The ISQA community is very active. The meetup was setup in literally a few days and there were over 150+ attendees
• The GO-JEK office space is a very fun place. They actually have an auditorium in the office to host meetups and similar activities, apparently, once a week!!
• The questions / interactions with the attendees were very insightful

Here are slides shared in the meetup. I will share the link of the video as well once available.

What is Agile Testing? How does Automation help? from Anand Bagmar

Patterns in Test Automation Framework at STPCon

I spoke about Patterns of a "good" Test Automation Framework at STPCon 2017. Here are the details from the talk.

Abstract

Building a Test Automation Framework is easy – there are so many resources / guides / blogs / etc. available to help you get started and help solve the issues you get along the journey.

However, building a “good” Test Automation Framework is not very easy. There are a lot of principles and practices you need to use, in the right context, with a good set of skills required to make the Test Automation Framework maintainable, scalable and reusable.

Design Patterns play a big role in helping achieve this goal of building a good and robust framework.

In this talk, we will talk about, and see examples of various types of patterns you can use for:

• Build your Test Automation Framework
• Test Data Management

Using these patterns you will be able to build a good framework, that will help keep your tests running fast, and reliably in your CI / CD setup!

Session Takeaways:

• Patterns for building Test Automation Framework.
• Patterns for Test Data Management, with pros and cons of each.

Slides

Patterns of a “good” test automation framework from Anand Bagmar

Pictures

Agile Testing & Patterns in Test Automation Framework coming to Singapore

I will be doing a 1-day workshop on Agile Testing and also a talk on "Patterns of a Good Test Automation Framework" as part of Unicom's World Conference Next Gen Testing Summit on Oct 13-14 2016 in Singapore.

See the site for more details, or contact me for more information on the same.

Sharing the pain in Automating with Protractor & WebDriver

As mentioned in my earlier post titled "Taking Protractor to the next level", on 25th June 2016, Nikitha Iyer and I spoke in Selenium Conference 2016, Bangalore, India on "Sharing the pain in Automating with Protractor & WebDriver".

The video is finally available and I am now able to share (see below) all the details of the talk from one post.

Abstract

There is a saying ..."Sukh baatne se badhta hai, dukh baatne se kam hota hai", translated as - "happiness increases & sadness reduces on sharing with others".

We want to take this opportunity to share with our experiences - the good and the bad, in the journey of building a Test Automation framework for an AngularJS based application. 

We will learn, by a case study, what thought process we applied on the given context (product, team, skills, capabilities, long term vision) to come up with an appropriate Test Automation Strategy. This Test Automation strategy covered all aspects of Test Automation - Unit, Integration, UI - i.e. End-2-End tests (E2E).

Next, we will share how we went about narrowing-down, and eventually selecting a specific Tech Stack + Tools (Javascript / Jasmine / Protractor / Selenium-WebDriver) to accomplish the Test Automation for the product.

Lastly, we will share the challenges that came up in the implementation of the Test Automation, and how we overcame them. This will also include how we managed to get the tests running in Jenkins - a Continuous Integration tool. 

This discussion is applicable to all team members who are working on Test Automation!

P.S. We will be attempting to make a sample protractor-based automation framework available on github for anyone to use as a starting point for setting up protractor-based Test Automation framework.

Slides

Sharing the pain using Protractor from Anand Bagmar

Video

Taking Protractor to the next level

As I got onto a project early this year - my paths crossed again with Protractor / Angular / JavaScript. Despite my past experiences with this tech stack, I needed to remain positive when approaching this challenge.

In this case, the context was quite different. That said, the challenges, though reduced compared to my first attempt at using Protractor effectively, were still around. 

I had posted a set of questions on my blog, various LinkedIn and facebook groups - and got a lot of suggestions and advice how to proceed. Thanks to all of them, it did make my life easier.

Then, as part of Selenium Conference 2016 held in Bangalore on 24-25th June 2016, my friend and colleague - +Nikita Iyer and I spoke about "Sharing the Pain of Automating with Protractor & WebDriver". The intention was multi-fold:

• We wanted to share what challenges we had faced on the team when using Protractor, and also how we overcame certain challenges. This was to help others in similar situations to learn from our mistakes & solutions.
• We also wanted to learn from the attendees what other challenges & solutions they had come up with in their experiences with this Protractor tool-stack.

I am very happy to say that we were successful in achieving both these objectives quite successfully.

Below is the details from the talk.

Abstract

There is a saying ..."Sukh baatne se badhta hai, dukh baatne se kam hota hai", translated as - "happiness increases & sadness reduces on sharing with others".

We want to take this opportunity to share with our experiences - the good and the bad, in the journey of building a Test Automation framework for an AngularJS based application. 

We will learn, by a case study, what thought process we applied on the given context (product, team, skills, capabilities, long term vision) to come up with an appropriate Test Automation Strategy. This Test Automation strategy covered all aspects of Test Automation - Unit, Integration, UI - i.e. End-2-End tests (E2E).

Next, we will share how we went about narrowing-down, and eventually selecting a specific Tech Stack + Tools (Javascript / Jasmine / Protractor / Selenium-WebDriver) to accomplish the Test Automation for the product.

Lastly, we will share the challenges that came up in the implementation of the Test Automation, and how we overcame them. This will also include how we managed to get the tests running in Jenkins - a Continuous Integration tool. 

This discussion is applicable to all team members who are working on Test Automation!

P.S. We will be attempting to make a sample protractor-based automation framework available on github for anyone to use as a starting point for setting up protractor-based Test Automation framework.

Slides

Sharing the pain using Protractor from Anand Bagmar

Video

- will be updated once available

Pictures

The recurring pattern of Patterns

On popular demand, I spoke in TechJam, the 2nd time around on Tuesday, 21st June on "Patterns of a 'good' Test Automation Framework, Locators & Data".

This time, the TechJam team at IDeaS used a different setup - a new conference room, with live-streaming via Google Hangout. It was indeed a great setup - with around 40 people able to sit and participate in discussions for over an hour - about Patterns in Test Automation.

Slides

Patterns in Test Automation from Anand Bagmar

Video

Pictures

Patterns of Test Automation in ATAGTR2016

I spoke about "Patterns in Test Automation Framework" in ATA's Global Testing Retreat 2016, held in Pune. For a change, I did not need to travel out of Pune to speak in a conference :)

Here are some details about the same:

Abstract

Building a Test Automation Framework is easy - there are so many resources / guides / blogs / etc. available to help you get started and help solve the issues you get along the journey. However, building a "good" Test Automation Framework is not very easy. There are a lot of principles and practices you need to use, in the right context, with a good set of skills required to make the Test Automation Framework maintainable, scalable and reusable. Design Patterns play a big role in helping achieve this goal of building a good and robust framework.
In this talk, we will talk about, and see examples of various types of patterns you can use for:1. Build your Test Automation Framework2. Test Data Management3. Locators / IDs (for finding / interacting with elements in the browser / app)Using these patterns you will be able to build a good framework, that will help keep your tests running fast, and reliably in your CI / CD setup!

Slides

Patterns in Test Automation from Anand Bagmar

Video

Feedback from attendees

Here is some feedback I received from the attendees:

Few remarks that we received from the attendees:

1.          Learnt business driven page objects

2.       Thoughtful presentation. Sound knowledge

3.       Very clear and concise. Meaningful framework

Patterns in Test Automation presented at Agile India 2016

I spoke about Patterns of a “good” Test Automation Framework, Locators & Data! in Agile India 2016 in front of a packed room of Developers, Testers, BAs and POs.

Below is the abstract, slides & video of the talk.

Patterns of a “good” Test Automation Framework, Locators & Data!

Building a Test Automation Framework is easy - there are so many resources / guides / blogs / etc. available to help you get started and help solve the issues you get along the journey.

However, building a "good" Test Automation Framework is not very easy. There are a lot of principles and practices you need to use, in the right context, with a good set of skills required to make the Test Automation Framework maintainable, scalable and reusable.

Design Patterns play a big role in helping achieve this goal of building a good and robust framework. 

In this talk, we will talk about, and see examples of various types of patterns you can use for:

1. Build your Test Automation Framework
2. Test Data Management
3. Locators / IDs (for finding / interacting with elements in the browser / app)

Learning Outcome

• Patterns for building Test Automation Framework
• Patterns for Test Data Management, with pros and cons of each
• Patterns for managing locators / IDs for interaction with UI

Slides

Slides are available here:

Patterns in Test Automation from Anand Bagmar

Video

(My attempt of capturing the) video is available here:

Official video will be linked when it gets available.

Protractor for Angular apps?

Already asked these questions in the vodQA group on LinkedIn - but thought to repeat the same here as well - in case someone else also reads this, and has some thoughts.

I am experimenting (again) with Protractor for automation against Angular-based web-apps. This time around, my comfortness with Javascript is better (by a couple more % than before) - so I am better prepped for this challenge. 

That said, I am interested in knowing a few things on this:

• Has anyone in the group worked with protractor recently? 

• What has been your experiences in working with it? 

• Who are the roles involved in the automation implementation, execution and maintenance? 

• What are the typical utilities you built in this framework?

• How have you been modelling you page-object pattern with JS / protractor based frameworks? Or, is there some other better set of patterns for JS that should be used?

• How did you build your page objects? How did you build and manage the composition / nesting of pages? Did the method of a page return an appropriate page object?

• How many tests exist in your framework? 

• Do you run your tests in parallel?

• Do your tests run in CI? If yes, which driver do you use? Protractor site discourages the use of phantomJS. 

• Would it be possible to share some (non-confidential) examples of how you built your Page Objects? How are your specs written? Any example of that possible to see?

• Did anyone manage to run their tests against Safari / IE11 as well?

• What about soft asserts? Did you implement this?

• I saw a strange issue when running my test against chrome - I got the element is not clickable at xxx coordinates. However the same test ran against Firefox and phantomjs. Anyone seen this before?

• Given that protractor site does not recommend using phantomJS driver much, anyone used xvfb for running their tests in CI?

• What reporters do you use?

The story of a 'small' vodQA ending up being 'x-large'

We are extremely happy to start the new year with YASV (Yet Another Successful vodQA) event, this time with the theme - Agile Testing Workshop, conducted on 9th January 2016 in ThoughtWorks, Pune office.

Why the theme - "Agile Testing Workshop"?

Over the past few years, after having worked on numerous projects, interacted with a lot of clients (and their partners / vendors), and gaining insights from speaking with individuals & teams in conferences & organizations, we (the vodQA Pune team), realized that a decent portion of the Software (testing) Industry lacks decent / good understanding of Agile and effective Testing on Agile projects / teams.

So, we decided to conduct the next vodQA in Pune - focussed on Agile Testing to answer questions like - "What is Agile and what does it mean to Test on Agile projects / teams?"

Highlights

• When we started planning for this edition of vodQA, the plan was to keep it very lean - in planning, execution and participation as well. For this, we planned to keep this vodQA 'small'. Little did we realize it would end up being a patiala peg.

• What started out as an event aimed at 30 attendees soon shot up to 180+ RSVPs on Facebook to 160+ confirmations and eventually we had 85+ attendees. Including ThoughtWorkers, we (again) crossed 100+ people for vodQA Pune! - There went a lot of our 'being-lean' out of the window!

• This event was completely driven by the Facebook group (from announcements to registrations to updates).

• We had a quite a few attendees travel from out of Pune for vodQA (ex: Mumbai, Nagpur)

• This was one of the most vocal, enthusiastic and interactive audience vodQA Pune has seen. They shared their experiences and asked a lot of questions as well.

• True to our objective for this vodQA, we ensured there was sufficient time between sessions / workshops to facilitate discussions and answer specific questions from the attendees.

• We had impromptu fishbowl discussion on certain Parking Lot questions.

• After the first session of the day (Agile Game), the attendees celebrated (it was over) by bursting the balloons - early Diwali some would say … :)

• You can see the tweets, comments in the vodQA group on Facebook and pictures here.

• A huge shoutout to the organisers who were constantly tweaking their execution methods, days before the event as our expected turnout gradually rose from 30 to 100+.

Agenda and Slides

Topic	By	Slides
Welcome note	Anand Bagmar
Agile Game	Abhay Dalvi, Vardhan Bhatt & Vikrant Chauhan
Tea break
What is Agile Testing?	Amit Gundiyal & Prasad Kalgutkar	http://www.slideshare.net/vodqanite/what-is-agile-testing-56891493
Effective Strategies for Distributed Testing	Preeti Mishra	http://www.slideshare.net/vodqanite/strategies-for-distributed-testing
Lunch
Testing the Mysterious Sphere	Anjali Wadhwa, Ashwini Ingle & Preeti Mishra	http://www.slideshare.net/vodqanite/testing-the-mysterious-sphere
Break
Test Automation - Principles, Practices	Vardhan Bhatt & Vikrant Chauhan	http://www.slideshare.net/vodqanite/lessons-learnt-from-test-automation-principles-practices
Tea + Snacks break
Patterns in Test Automation (Framework + Data)	Anand Bagmar	http://www.slideshare.net/abagmar/patterns-in-test-automation

 

Feedback

• Ur event is successful when attendees r so involved that they forgot to tweet abt it till d lunch brk :) #VodQA #VodQAPune #ThoughtWorks

• Overall workshop was wonderful. Presentation and content was good. Helpful to understand and implement in our current process.

• Agile testing game taught us to focus more on quality than quantity & take feedback as soon as possible from the PO

• Though I am not working in Agile env currently, I understood whole session and got to learn something.

The always rocking vodQA Pune team!!

vodQA Pune team

Starting 2016 with vodQA in Pune - Agile Testing Workshop

Over the past few years, after having spoken in a lot of individuals & teams in conferences & organizations, I realized the understanding of Agile and what does it mean to do effective Testing on Agile projects / teams is very poor.

So, we at ThoughtWorks, Pune, as part of vodQA Pune - Agile Testing Workshop, start 2016 with the objective of connecting with our peers in the Software industry to discuss and understand - "What is Agile and what does it mean to Test on Agile projects / teams?"

We have planned and organized this vodQA conference in a very Lean and simple way - announcement, registrations, agenda and updates - all directly from our vodQA group in facebook.

This edition of vodQA will be held on Saturday, 9th January, 2016 at the ThoughtWorks, Pune office on the 4th floor. For more details, see the vodQA event page in facebook.