As we battle with this pandemic and also while trying to move into a new Normal. It is right to say a big thank you to all the Quality Assurance people of this world as they have always been the front liners in every sector. Imagine ventilators malfunctioning during this pandemic or a closer scenario is the monitoring machine displaying the traversed graphs reading.

The new Normal is the beginning of a new era, a change in processes, more complex workflows and unfortunately a demand for a product time to market similar to that of a speed of light. This means less time to develop, complete CIT, move to SIT and finally UAT. Currently a large number of corporate organization struggle with the fast pace of Agile workflow because testing is positioned at the right side of the flow, can we say this organizations are doing FRAgile (Forcefully Required Agile) or WAgile (Waterfall Agile).

Let’s take a look at some reasons why this is happening:

• There is no time for testing to do exploratory testing and/or/then scripting. Funny right?
• Testing is not giving attention during Agile meeting, oh typical example there is only one field on Jira to estimate and it is for developers.
• Here comes my scrum master in her loudest voice, “Why are these tickets not assigned to the testing team and it stays in develop”. And that is the jury supporting testing in the retrospective court.
• Testing has no versioning for scripts and can’t match with development versions.
• Lastly, no unit test.

In the list above the most important item that cuts across our development cycle and a vital catalyst that can move us closer to the achieving and adapting new normal demand is UNIT Testing. So, let’s get agile, below is one important user story in our SDLC.

As a developer I want to write unit test to have a code coverage of at least 75%.

Funny how this user story on Unit Test and acceptance criteria remains in the backlog for most companies.

A quick view into why this backlog item never gets cleared:

• Developers have little or no knowledge of principles of testing, yeah, the task is unit TEST not unit DEVELOPMENT.
• Also how do I write a line of code and then have to write 2^n test cases for each sub-component of my code.
• Time is not on my side, I will complete all my tasks and write Unit tests later, but we all forget time waits for no one and project teams want more task delivered to save money.

Well we can ignore 2 and 3 for now but 1 totally seems valid in most cases.

Below is a typical example being Developer of the year (DOY) who:

Do QA people understand code? Yeah, we do. My DOY has not pushed this code without unit test and marked the task ready for testing, but really this task is ready for Unit testing and not ready for testing.

A look into ready for Unit Test from develop:

• The unit tester will have to create 3 new subtasks to write a unit test for
  • Duplicate entry by pushing an existing data into the database.
  • Database connection error by using an invalid database port/Ip which will be in the unit test for the connection method/function. Interesting right?
  • Write error by adding an extra field that does not exist in the database into the collection for insert.
• On completion, the task can now be marked as ready for QA testing.

A look into task at ready for testing from develop:

• The QA person her is testing at the system level because we already have two components the DB and The API code. On the Average he/she will encounter 1 if not 3 of the defects highlighted above before proceeding to System test. In some cases, the defect is logged as “Error while creating users or User API not creating users”.
• The developer has to rerun a test to see what and where the bug was introduced and if we have a 2hrs turnaround time to fix defects then we are looking at a loss of time estimated to be 2^3 or 8 hours (1 full day of development)
• And once this is not resolved we then start system testing not taking into account that the tester also lost 8hrs.

Yes, I know you are thinking but we never estimated the time spent on unit testing. If we look at the 3 tasks in the unit testing above, we can see that each task could range about 30 min to 1.5hrs hence we set our margin to 1hr per task. We can see that we could have save 5 hours of development and 8 hours of testing which means we could have saved the team 13 hours of work. Ask my business-oriented product owners they are already thinking, “yes, this is the way to go”.

Just before we conclude, a quick look at reusability of the unit test. If a unit tester has written a function/method to test duplicate entry with arguments(data), that same function can be reused in System testing by passing new sets dynamic arguments to create the data which save testing teams time and reduce the effort estimation for testing.

A simple assumption is:

• If reusability saves 25% of the 13 hours then we 3h 15min more saved resulting in a total of 16 hours or more, that is saving the team 2 days effort of the team member which can be used for other tasks.

Finally, from the unit test tasks it shows that unit testing is n^1 number of tests where n is the number of failure points and in practical UAT is 2^n or 2^(n+b)where n is the number of fields/options and b is the number of business rules in the current flow under test. After this mathematics that we have done where does SIT stand and what level are you testing, are you doing SIT or UAT as SIT? stay tuned…