Chrome Developer Tool

Chrome Developer Tool, a QA’s best friend

Google is an amazing place and it should be no surprise that they develop some pretty amazing tools.

In this post, let’s look at the ‘Chrome Developer Tool’.

Chrome Developer Tool

Chrome Developer Tool comes automatically installed in Chrome Browser and has helped many Developers and Testers (QA). Benefits comes in the form of UI Automation. If you dig deep enough, you can use the Tool to make performance improvements to a website also.

In this post, I have listed some of the biggest benefits of the tool and why you should consider using it.

Under The Hood

You get to have a cheeky peek

Well not really, you get to see the entire thing!

The tool can be accessed via the setting menu. Once you open the Tool, one of the first things you see are the DOM (HTML code) and Styles. This allows you to inspect the body of the page and it’s makeup.

Chrome Developer Tool Element

Wait a second, why is this so important?

For a QA, being able to write UI Automated tests requires that s/he has access to the source of the page. Looking at the HTML source code makes this easier. The QA is able to highlight and select specific elements on a web page. This then highlights the relevant HTML code under the Elements tab.

This allows the QA to cherry pick HTML code that they need to interact with which later allows the QA to write UI tests.


The Networking tab is perhaps a God send from Google.

If used correctly, information persisted in the Network tab can be used to identify a number of areas. This include page load time, causes of slow loads, resource and asset size etc.

This tab becomes very handy for anyone who is either interested or invested in Performance Testing.

Chrome Developer Tool Networking

For instance, it is possible to see:

  • What the largest file size is
  • The queue or order in which files loads
  • If any files resources stop other resources from loading

So what if we can see these files, how is the actually helpful?

Before being able to resolve an issue, you need to understand what the issue is.

Using the Network tab helps to identify ‘issues’. The tab becomes a hot bed to highlight potential performance fixes.


The Audit tab is a good place to start if you want to quickly measure:

  • Page and Network performance
  • Accessibility
  • Web best practices

It very nicely supplements the Network tab.

Chrome Developer Tool Auditing

It is possible to run an Audit on a given web page which returns a number of suggestions. These suggestions are provided by Google.

Suggestions may come in the form of CSS tweaks, cookie size, script load order etc.

Implementing these suggestions could potentially help rank your page higher in search engines and make your website more accessible around the world.


The ‘Audit’ and ‘Networking’ tabs can be used to make performance improvements. However, the Performance tab has a slightly more direct approach.

The Performance tab allows the user to create a profile view of the current page. This essentially allows the user to see the series of events, API calls and resources which load to make the makeup of the page.

This allows the user to measure the first instance a page is loaded and when the user can first interact with the page. It also provides a pretty cool pie chart of the total load time.

Chrome Developer Tool Performance


Google Chrome Developer Tool is a free tool which can be used to make vast performance improvements and help write UI tests.

A QA should strongly consider adding Chrome Developer Tool to their ‘key best tool favorite list’.

Bad Software Testers

Not all testers are the same, some are really bad software testers

By profession, I am a Software Tester, QA and Automation Engineer and I have meet some really bad ones.

With this said, what constitutes as a bad tester? The answer is a selection of poor traits and attitude.

This post is not meant to discourage or dishonour Testers. It is meant to highlight my experience with poor testers and how I approached the problem.

Bad Software Testers

In this post let’s look at some of the key traits which sadly defines what a bad Software Tester is and the solutions that I tried to implement.

The ‘Forgetful’ One

It’s common for a given person to forget things, that is normal. In a professional environment, forgetfulness is something that can not always be ignored.

In this instance the Tester will very commonly forget to make backups of test plans, test data, reports. They will also raise issues and bugs but not supply any steps to reproduce. When asked what the steps are, sometimes their response is that they don’t remember.

Their approach to reporting is usually very junior. This can leads to wasted time in investigations, spikes and other time sensitive aspects.

Fortunately this trait is common for Junior Testers and is remedied automatically overtime. The best approach here is to guide and train the Tester.

The ‘I Don’t Want To’ One

We have all encountered someone who possesses the mentality of saying ‘I don’t want to’, sadly this can be a common trait amongst all level of Testers.

Anyone who broadcasts this type of attitude usually differs any work given to them and are not strong team players.

This said, they also favor tasks which appear to be easy, straight forward or where someone else has done the leg work.

Resolving this can be challenging. The approach which I have seen to work best is to simple talk to the Tester and try to find out why they are not happy to pick up tasks.

Most of the time it is due to a lack of confidence, domain knowledge or a lack of willingness to work with people who seem very dominating. For me, talking has always helped to resolve this attitude.

The ‘I Did This, I Did That’ One

The ‘I did this, I did that’ trait belongs to someone who is more concerned with the work that they do and do not take the time to care or appreciate the effort that others are putting in. This particular trait makes it difficult to work with the Tester.

Testers with this view are usually found in Waterfall environments. This is because Waterfall promotes the idea of working in batches, in patches but not in sync.

To resolve this, I usually approach the Tester and try to understand why they appear to have strong feelings about what they and others did. Usually it comes down to their view on ‘what is fare’.

I try to resolve this by simply listing out the tasks that they and others have done however the focus here is not to compare. Instead I do this in hopes of trying to build a bridge and say that no one task can be sufficiently completed by only on person.

With time, this leads to a greater understanding of ‘US vs ME’.

The ‘My Way Or Highway’ One

It becomes very difficult to work with someone who is strongly passionate and adamant about their views and believes, especially when they are not open to ideas.

Sadly, this is usually found amongst the more senior members on a team. Through experience, senior Testers’s can sometimes ignore simple solutions and try to employ more difficult and complex ones.

Working with someone like this can almost always feel like a battle. It feels like a fight of diplomacy, ideas and sacrifice.

Passion plays a strong part in almost all discussions when speaking to someone who has very strong views. When trying to deal with someone like this, I try to convince ideas and thoughts for only some discussions and give into the many.

The idea here is to slowly win the confidence of the Senior Tester which in time becomes a strong relation. With some luck this leads to more comfortable discussions with an open mind form both parties.

The ‘Whatever’ One

There is always someone who is so relaxed and chilled that they do not care unless their salary is on the line.

Usually this means that the person does not take an active role in trying to resolve issues, take part in conversation or pro-actively investigate better solutions to existing problems.

They are very content with their current tasks and are more than happy to just coast along.

I have always found it to be a challenge when working with someone like this. My approach has been to try and give the Tester some small responsibilities. I have found that this helps to motivate the Tester to think about the problem and be more active in other roles.

The ‘Whatever’ attitude appears to disappear when the Tester’s see their contributions and efforts are valued.

The ‘I’m Not A Developer’ One

Having to look at code as a Tester is becoming more and more common however this becomes a problem when the Tester is just not happy about looking or reading code. The Tester in this instance is more than happy to get someone who is a little more intimate with coding to look at it instead.

This means the task takes longer and this could potentially hold up progress on other tasks.

I have found that pairing, training and teaching are the best tools to help someone get up to speed with coding.

Software Testing is Tough

It’s long, it’s hard but it’s worth it

Software testing is tough. Software Testers find bugs, write tests, firefight issues, teach, are expected to learn quickly and as a result it can become a difficult experience.

A Software Tester can constantly face many hardships, let’s have a look at some of them.

Hardships of a Tester

On a day-to-day basis, here are some of the key struggles that a Tester may face:

Testers VS Developers

At times, it may feel like a Tester is constantly having to stand their ground, make their point and convince Developers about bugs and non-functional issues.

Firstly of all let’s make one clear point. Testers and Developers are important for different things. The real benefits comes from the synergy of both roles.

Sadly, this silly thought of Testes VS Developers is simply unhealthy. This sort of thinking breeds segregation and isolation. Therefore, this helps to encourage a very ‘blame’ and ‘fault’ culture.

Unfortunately I have been exposed to this, most noticeably in a Waterfall environment. In a Waterfall environment, since the whole development is done in stages, there is little to no day-to-day interaction between Developers and Testers. This can lead to a very us vs them mentality.

Fortunately, Agile completely promotes a mixture of Developers and Testers therefore somewhat mitigating the idea behind Testers VS Developers. In an Agile environment, Testers VS Developers becomes Testers AND Developers.

Regression: The Silver Bullet

What is Regression?

For starters, it is not there to ensure that an application is bug proof. Regression means one single and simple thing; is everything still working, has a new issue been introduced. Sadly, not everyone understands this.

In some instances, Regression is seen as the ‘Application God Process’ which will catch-all the bugs, find all the holes, makes everyone super happy.

What do I mean by this?

Simply put, a misunderstanding in Regression stems from people, not the process.

In an ideal world, Regression should not be a laborious, long or a difficult task. It should be quick, painless and swift. People on the other hand have a magical gift to turn Regression into a nightmare.

On a whim’s notice, Testers are asked to consider new browsers, new devices, add a hundred more test scenarios, consider extra testing to cover for other teams etc. It feels like people forget how draining Regression can be.

Performing Regression is an important aspect of a Testers life. However, I have seen (first hand) how difficult it can be when last-minute requirements, favors and the need to test everything makes things difficult.

Proxy PO and BA

Overtime time, since Testers go through the application more times than ‘failure of unstable UI tests’, Testers become domain knowledge experts.

Initially, a Tester mostly needs to work with Developers (and other Testers) to test an application and ensure that it works. Overtime the role can become more challenging.

It becomes more and more difficult to devote time towards actual testing. Instead you may find yourself in meetings, talking about plans, strategies and much more. On the surface this is a great thing. This gives the ability to influence decisions, technology and perhaps a promotion.

Hence this drags the Tester away from their actual work i.e. to test.

Software Testing is Tough! Well, Is It?

Most noteworthy yes, Software Testing is tough. Seems like Testers are team players, how could Testers not be?

Developers, Testers, PO, BA all need to work together to convert a well thought plan into a delivered product. If the processes are taken care of, the team will be happy.

Testers are part of the backbone of any software development team and should be treasured.

Failing Fast

Failing fast leads to one thing, Success

It is important that your code base, continuous integration, tools and even your processes are able to fail fast. Human’s are a different consideration.

Why should a given process fail fast? What value is there in failing quickly?

Failing Fast

The greatest value in failing quickly is perhaps the ability to react to changes quickly.

Why fail fast? Failing quickly helps to resolve issues quicker since they are surfaced sooner. Let’s have a look at some of them:

Bug Cost

The earlier a bug is caught, the cheaper it is to fix

Wait, what does that mean? Cheaper in what sense, money, time, fingers?

Depending on the stage at which a bug is captured, the cheaper or quicker it may be to fix. It is therefore in your interest to fail quickly.

Let’s assume that a developer is working on a feature branch which is yet to be ‘merged’ into the master code base. Assume that a bug was found on the branch before the code was merged. Now let’s assume the same bug was found sometime after the code was merged.

In the above scenario, would the bug be easier and potentially quicker to fix before or after the merge? Does it even matter?

You can bet your bottom that it absolutely matters!

The sooner a bug is found between planning and deployment, the quicker it is to fix. Having to fix a bug with less code and less overhead makes it easier and quicker to fix.

Failing quickly directly impacts bug cost

Test Pyramid

What is the Test Pyramid?

The Test Pyramid is the principle of rationally dividing up the number of ‘types of tests’ one may write for an application. This is what the pyramid looks like:
testing pyramid

The length of each slice in the pyramid represents the number of tests you would write.

In short, the principle here is to write many unit tests, some integration and very few UI tests. Enough theory, how does this help to capture failures quickly?

The lower the test form, the quicker it runs!

Unit tests run faster than integration tests, integration tests are quicker than UI tests and UI tests are the slowest horse in the race. Let’s not get into the why or how, just take my word for it.

If we accept this concept, then this directly can help us to fail quickly. For instance, if we capture a bug on the unit test level, it would be quicker to fix since we found it quicker.

In conclusion, if a bug is not capture in a unit test and instead a UI test, it may be more expensive to fix.

Learn Quickly, Make New Mistakes

Failing quickly provides an opportunity to learn quickly

If you are able to fail quickly, this helps to promote learning.

As a result, the probability of repeating the same mistake should decrease. Consequently, this also means the probability of making new mistakes should increase.

In Agile, this is an important concept. This effectively means to quickly translate an issue into a learning outcome.

Failing Quickly, Any Real Benefits?

It should be clear that failing quickly does hold a lot of benefits, the biggest perhaps being able to adapt to changes.

We should absolutely leverage existing concepts such as the Test Pyramid to quickly capture bugs and reduce the cost of fixing them.

Some of the greatest inventions have come out of failures, it should be in your interest to fail quickly. Your future self may thank you.

Stand Up, Are You Doing it Right

A Stand Up is powerful, only when done right

Most of us have experienced taking part in one, have you had bad one?

The Traditional Stand Up

Let’s quickly establish the fundamental rules:

  • For starters, you must physical stand up at a set time every day
  • You must answer the following three questions:

    • 1. What you did yesterday?
    • 2. What you plan on doing today?
    • 3. Are you blocked on anything?
  • Your answer to the above three questions must be relevant to everyone
  • Finally, you refer to a board which helps to reflect the progress of tasks and / or stories

The above are all hallmarks of a quick, clean and valuable Stand Up. However, some bad habits can pollute the form.

Here are some interesting behaviors that I have observed over my career:

Virtual Stand Ups

Part of the philosophy of physically standing up in close proximity to your peers is to help encourage quick discussion.

A Stand Up is not designed to help people get comfortable. When conducting a virtual Stand Up, this almost goes against the thinking behind it.

Now, let me be clear. I am not knocking the idea of virtual Stand Ups. Sometimes you are simply not able to physically make the Stand Up in person and as such need to sign or log in virtually.

It is however important to mention that virtual Stand Up’s may encourage taking more time than needed.

Sit Downs

Sit Downs is a trend that I have seen, sadly.

In this instance, everyone is encouraged to sit down as opposed to standing up (assuming you are physically able to Stand Up). When a number of people get together and sit down, can it be considered a Stand Up?

I think physically Standing Up is vital to the theory of taking part in a Stand Up. It is not supposed to be a place where you get comfortable and relaxed. It is a format in which you deliver very quick and precise information whilst also being conscious of the time.

20 Minute Marathons

This is perhaps the worst that I have seen. In this instance, the Scrum Master appears to take turns talking to each member. As opposed to letting everyone quickly go through their updates, instead small discussions take place. The Stand Up is not a forum where you should have long running discussion.

What’s worst, anyone who actually wants to simply get away to their desk is not able to since everyone who is taking part is yet to speak.


This is a little new, perhaps very radical.

The approach here is to hold a plank whilst giving your updates. I came across this method in a particular place and it was a very interesting approach.

The idea behind it was to encourage everyone taking part to only contribute words and sentences which answered the above three questions. This approach certainly made it a lot quicker and cleaner. However, this also made it more difficult. If not for all, then certainly for some.

The downside to this was the fact that contributers were sometimes more concerned with out-planking each other instead of listening and making contributions.

Is it worth making something more difficult in favor of getting it done quicker?

Clean Stand Up Benefits

The traditional approach of the Stand Up is great. It works very well, really helps to deliver vital information in a quick, small time frame and also provides the opportunity to quickly plan for change. It seems the traditional approach works for the most part.

If the traditional approach works, why change it, why break it?

I Pushed a Bug in Production

It’s inevitable, at some point you will push a bug in production

Statistically speaking, at some point you will push a bug to production. It may be something small, it may be something big. It might be a small UI issue, it may be a rather large functional issue. Sadly, at some point it will happen.

So, how can we stop this, how can this be mitigated?

Stop Bugs going in Production

Unknowingly, I have pushed bugs to productions. Not my most favorite confession but it has happened. It wasn’t the most joyful of feeling, but you live and learn.

Here is a list of actions I live by to help reduce instances of bug getting past me, into production.

Play ‘The 5 WHY’ Game

This is perhaps one of my most powerful techniques. The ‘5 WHY’ approach is simple, you ask yourself 5 WHY based questions which help to diagnose the root cause to a problem.

For instance, let’s assume a bug around user login made it into production.

  • 1. WHY was the user not logged in?
  • 2. WHY was the user account not recognized?
  • 3. WHY did the user account have a duplicate user ID?
  • 4. WHY was the database able to store multiple user accounts with the same ID?
  • 5. WHY was the ID code generator not producing unique ID’s?

Following the above line of question would help to identify a flaw in the process. Perhaps if there was an automated test for ID generation, the bug may not have gone through to production.

The ‘5 WHY’ game has helped me to think about bug prevention in production. It has also helped me to triage situations where a bug has gone through.

Catch It, Automate It

Not a super fan about this particular approach but one of the best ways to ensure that the same bug does not make it through again is to write an automated test for it. This approach may however unnecessarily balloon the number of tests that you have. You may write many tests which run every time but not add much value since they are trying to capture something very specific.

On the other hand if we don’t write a test for it, it may go through again. That’s something no one would want on their conscious.

Big Bang Integration

Test your code with everyone’s code. Do not merge directly to some master code base, merge to a release code base and test it. If your release code works, put it in master.

A very simple approach to stopping bugs going to production is to pretend it did not happen, one way to achieve this is with multiple code bases. At any point in time, the production code that is running will be the latest version of master. In an ideal world, the master version is deemed stable and functionally working. When pushing new code to production, it is better to push a release version instead.

Pushing a release version somewhat reduces bugs in production. If the bug is found, you can quickly change back to a version of your code which is deemed better.

Process Failure, Not People

The biggest and most important thing to identify is this:

Bugs in production is not a result of a person’s failure, its the fault of a Process

Sadly at some point, most likely during a blue moon, you will push a bug. You are human, you will make mistakes or more likely you will miss things.

It’s is far better (and perhaps more healthy) to remedy ‘preventing bugs in production’ by putting in place a process which can help to prevent it.

Processes may include:

  • Writing automated tests
  • CI jobs and pipelines
  • Release processes
  • In closing, in an ever growing Software Industry, trying to prevent bugs in production is pretty much impossible.

    But we can give it our best.

Agile Pairing Power

Agile pairing, takes two to tango!

Once upon a time, I too did not see the benefits of pair programming. I saw work duplication, invasion of privacy and moments of broken concentration. And then something happened, I saw the light!

Why did I suddenly change my mind?

Benefits of Agile Pairing

Let me tell you about my sudden ‘Change of Heart’.

Is Team Work Better?

Why have two developers working on a task when one would get it done faster? This is how I used to think.

I had just joined a new company and was ‘encouraged’ to speak to developers instead of reading introductory documents. Being the new guy, I did not have much choice. I decided to sit down and ask questions.

I thought this would hamper the developer, to my surprise it did not. In fact, anyone that I spoke to or pair programmed with was more than happy to help. Going further, without realizing it at first I was actually introdusing myself to the entire team in a more ‘intimate’ fashion.

I found that I was picking up things a lot quicker, having my worries and doubts resolved quicker but more importantly I felt part of the team on day one! Why have two developers working on a task when one would get it done faster? Not sure how valid this statement was anymore.

Clearly this was taking time, I may have slowed others down. However, was my introduction to the team a really big time impact? I felt it was quicker for me to be a productive part of the team by pairing. I started to see Pair Programming as a way of on-boarding.

Are Code Reviews faster?

My way of programming as always worked. Books, blogs and conferences helped influence how I once programmed. I suddenly found myself speaking to developers and writing code with them, in the process learning a great deal more than books and blogs. This wasn’t entirely surprising but I did find myself asking why I had considered books and blogs a ‘better source of learning’ when compared to a fellow colleague.

Going further, I started to revisit ‘my way of writing code’. I started to write code which felt easier to read, to understand and to manage. The interesting thing about this particular evolution of my coding standards was that it was not imposed on me. In fact I saw the change and a need to ‘upgrade’ my standards.

Did I self improve because I started to talk to others?

Is Velocity impacted?

Going back to when I was not the biggest fan of pair programming, my biggest concern was the impact on team Velocity. This goes back to the notion of one task by one developer vs one task by two developers.

Let’s assume that a developer is stuck, what do they do? The developer can’t ask another developers since everybody is in the ‘one person one task’ mindframe. Most likely if your stuck, you go and get a coffee, take a walk, come back the next day and tackle it again. Failing this you ask someone else.

Now let’s assume a pair were working on the same task. The probability of one developer getting stuck is significantly less since there are two developers. Pair programming in this instance can help to solve problems quicker.

Before I adopted pair programming, I searched online for solutions every time I got stuck. I tended to ask colleagues as a last resort. I guess I did not ask, I thought it would slow down someone else. Not sure why, it toke me some time to realize that being stuck is the same as not adding towards the velocity.

In a very round about way I discovered that pairing actually increased velocity.

Is it worth it?

The big question, is it worth Pair Programming?

Let’s list the possible disadvantages of Pair Programming:

  • More man hours to get a task done
  • Ego and attitude play a part – this can result in enforced code vs quality code
  • The idea of a ‘driver’ and ‘passenger’ does not breed creativity

And now the advantages:

  • Better learning
  • Higher code quality
  • Problems resolved quicker

What do you think, do the advantages outweigh the disadvantages?

I thought so!

Some People Hate Cucumber

This may come as a surprise to you, some people actually hate Cucumber.

But, do you know why?

Why Hate Cucumber?

Over the years of trying to encourage poeple to adapt Cucumber, here is a list of the most common ‘reasons’ that I have had in response:

It’s An Overhead

When asking colleges to adopt Cucumber as a tool to help remedy the bridge between BA’s and Developers, “Cucumber is an overhead” was the response I got back.

The first time I came across this response, I was a little confused.

How is Cucumber an overhead?

Overtime I figured out that this was simply a reason not to write scripts and directly write code. For a developer, it is usually enough that the requirements are captured in a task tracking board. Having to write feature files which then call code can seem a little ‘middle man’ redundant.

It makes more sense to write small, quick tests and run them in CI. It can become an overhead to write feature files which call code to run tests.

It’s Not A Testing Framework

Cucumber is not a testing framework, I can write a post on this one statement alone.

In short, Cucumber is certainly not a testing framework. It is a framework which can be used to supplement testing, it is not purpose built for testing. When asking a developer to use a framework for testing, they would expect a testing framework. Cucumber in this instance is not.

At the point of hearing this response, I do wonder the justification of the statement. It does make sense to focus on testing frameworks for testing problems. On the other hand, Cucumber can be used to enhance any framework for testing. It can help to implement BDD, clean reporting and bridge any technical gaps between client and hosts.

Bad Memories

Well, this is an interesting one!

How do you convince someone that a technology, when used correctly, is a good idea. And how do you convince that same person when their past experience with the same technology has not been very good (credit to the previous person who tried to introduce it).

Sadly, I have had the ‘pleasure’ of talking to developers who have had a bad experience with Cucumber in the past. This effectively implanted a negative picture of the software. Luckily, given there is an open mind, it can be easy enough to re-implement or re-try the application. Perhaps turn around the ‘hate Cucumber’ thinking. Alternatively, good luck.

So, What Now?

Well, if your passionate about Cucumber and really want to introduce it into your work place, don’t force it. Never try to force the notion. Instead, try to spike a small project and then demo it. You never know, you may convert someone.

Good Automation Framework

It’s easy to build an automation framework that works. It’s tough building a framework that works well.

What is an Automation Framework?

The need to have an automation framework should always come from a ‘need to a problem’, not a ‘want to a solution’.

The concept of a framework is to provide a foundation which can be extended for further use. When talking about frameworks in the context of Automation, the same rule applies. Let’s take a real world scenario:

Manager: We need to write some tests, what do we have so far?
Developer: Depends on what tests you want. We have Unit tests which give us a good coverage, not many UI tests though.
Manager: Ouch, does not sound very good. Can you write some tests?
Developer: I can, I will get back to you sometime next week.
Manager: Why not know?
Developer: Not sure what the requirements are? I need some time to figure that out. Not sure if our current structure supports UI tests.

Framework Requirements

So, what is actually happening in the conversation above? Firstly, the Manager is asking the Developer to write UI tests. The Developer wants to firstly understand the requirements, check for support and then write UI tests.


  • How many tests should the developer write?
  • Actually, should the developer write tests right away?
  • Should the Developer instead take a step back and think about what sort of tests to write?

The answer to the above questions will most likely help paint a picture of the problem. When building a framework, it is important to understand what the test are expected to achieve. For instance:

  • Where should the tests run?
  • How should the results be reported?
  • How often the tests should run?
  • What language should the tests be written in?

Assuming you have an answer to the questions, this will help identify the requirements. Achieving and implementing the list of requirements results in a framework.

In short, a framework is a list of features and mechanics which are needed in order to achieve something, in this instance writing automated tests.

Desired Capabilities

With all of this said, let’s take a moment to discuss some of the most key features of a framework. Here is a list:

  • Speed
  • Maintenance
  • Scalability
  • Extendability
  • Error / Debug

Let’s take each of the above in turn and quickly discuss:


Writing one test that takes 10 seconds to run can be seen as a good use of time. Writing 100’s of tests which take hours to run can make the framework very redundant. The speed factor here is ‘how long do all your tests take to run’.

Ideally, your framework should support mechanics which can help to reduce the ‘total execution time’ of all your tests. Parallel execution of tests is a great way of decreasing the total test run time.


Implementing patterns such as the Page Object, writing clean code and writing code that everyone understands helps to maintain the test framework. Writing dead code, duplicated code, confusing code converts maintenance into a nightmare.


It is important that your framework is scalable. For instance:

  • Being able to extend your test to run against any given environment
  • Parameterizing your tests
  • Configuration

…make your code more scalable. For instance, if your tests are only able to run against a given environment, this decreases the value of your tests. This also means your tests can not run against other environments.


Being able to:

  • Extend your framework to ‘support different technologies’
  • Run your tests in any CI environment
  • ‘Plug in / out technologies’

…makes your framework more extendable. Not being able to do this would result in your framework relying on specific technologies which can lead to security, reliability and general ‘out of date’ issues.

Error / Debug

What value does a test provide if you are not able to identify the issue if it fails? What value does a framework provide if you are not able to cleanly exist in the instance of systems errors? These are very important questions to answer since they help to aid when errors occur. This also helps to debug your current framework’s code base.

Theory and Principle

With all this said, what’s the point of trying to build a good framework? Why not just build a framework that does the job ‘good enough’?

Well, assume you were handed a framework with no room to change it. You had to ‘work around’ the framework in hopes of writing stable tests. How would you feel if you felt that you could enhance the framework but actually did not have the ability or authority to make the changes. Not a very nice place to be in.

Now let’s assume you had the privilege of building a framework which others would consume. If you build a framework that is very rigid, there is a chance you will be requested for many changes. No one wants to write tests in a framework which itself is fragile.

Building a framework which is:

  • Agile
  • Able to adapt to changes
  • Easy to write and debug tests
  • Easy to add or remove technologies

….makes everyone’s life easier.

I have had the pleasure of working with both good and poor frameworks. One has made my job easier and pleasant. The other, not so much.

Let’s TDD and BDD

What is the best approach of writing tests?

TDD vs BDD. Have you heard of either Test Driven Developer (TDD) or Behivour Driven Development (BDD)? These are perhaps the most common and most used practices when it comes to writing tests. Firstly, let’s discuss why anyone would want to follow a testing practice. Why not just write tests in whatever manner you want?

To Practice or Not To Practice

Let’s assume you do not follow any practices or principle. This means you are probably very happy about your tests, assuming they run and pass. Let’s also assume no one else will ever have to maintain your tests.

Now let’s assume you don’t touch your tests for six months, there is a good chance you will not be able to understand your own code. This is because the approach you toke was a very ‘in the moment’ approach. This sort of approach can be very fragile.

On the other hand, let’s assume you did follow some principle or structure that is well known in the software industry. Since your following a universal language, there is a good chance that you and others will be able to read and understand the structure and purpose of your tests.

Following a test principle means that we can maintain structure, formula and purpose of a test. It means we can give reason and purpose to a test.

What is TDD?

TDD is the practice of writing a test before writing the implementation code. We write the test and run it expecting the test to fail. The reason the test would fail is because the requirement the test is checking for does not exist. Once the implementation has been written, re-running the test should now result in the test passing. Writing a test before writing the implementation code, this practice is TDD.

Enforcing TDD into your testing process makes it easy to establish what the requirements are. You can easily capture requirements in the form of tests. The tests can also act as a exit criteria for any given task. Also, if TDD was followed throughout a project, if a test fails then this would be the same as saying that a requirement has failed.

What is BDD?

TDD was invented to help capture and manage requirements however TDD tests were designed to be written as low level tests. For instance Unit and Integration tests are low level tests. With TDD, this still did not help anyone other than developers understand what the captured requirements are. This is because low level tests were understood by developers, not Product Owners (PO) or Business Analysts (BA). This is where BDD steps in.

BDD tests are essentially ‘English’ friendly scripts which can be written by anyone using Gherkin. Gherkin is a very simple language which can be used to express a scenario. For instance:

Given <a condition>
When <an action or event happens>
Then <expect a response>

The above is a simple view of what a Gherkin scenario would look like, scenarios such as this can be written by anyone with any technical ability. Let’s enhance the above scenario a little:

Given I am on the login page
When I enter valid logic credentials and press the login button
Then I should land on the accounts page

It should be clear that the above scenario can be written and understood by anyone. The requirements captured in the scenario above can also be shared with anyone.

The biggest benefits of BDD is to help bridge the gap of technical abilities between a BA, PO and Developer.


TDD vs BDD. Clearly, TDD and BDD are both great techniques to incorporate into your testing process as they both bring different benefits. One allows you to capture the requirements in tests before writing any code and the other helps to universally broadcast understanding. They both help to maintain tests and testing requirements The biggest benefits one can gain from these process is to use them both together.

In a given project, the BA would write stories or tasks in a Task Tracking tool for teams of developers to pick up. This usually translates into tests written by developers. On the other hand, if BDD tests were written by a BA before any code was implemented, this would follow both BDD and TDD. Ideally, writing high level tests before writing any implementation code should clearly give all team members the expected behavior to be implemented.

TDD vs BDD is a very wrong assumption. Both of these concepts should not be seen as competing factors, instead they should be seen as factors which compliment each other.