World Quality Report 2017-18

An interesting and exhaustive report (about 76 pages). Also, you can download your country or Region specific report as well. For example, I have downloaded report for Australia and New Zealand which is a modest 2 page one.

Produced jointly by Capgemini and Sogeti, in conjunction with Micro Focus, the World Quality Report is the only global report analysing application quality and testing trends across multiple industries in 32 countries.

World Quality Report 2017-18: Key Findings

  • Back to basics focus on application quality shows testing has come of age in the new context of agile applications
  • Test automation: on the way to smart, intelligent, and cognitive QA
  • The challenges with testing in agile development are increasing
  • QA organization evolving to meet bi-modal needs
  • Test environments and test data continue to be the Achilles heel for QA and testing
  • Test budgets fall but are expected to rise again

World Quality Report 2017-18: Key Recommendations

  • Increase the level of smart test automation
  • Transform QA and Test function to support agile development and DevOps teams
  • Invest in smart QA and Test platforms
  • Define a test platform strategy on an enterprise level
  • Define QA analytics strategy on an enterprise level


Download your copy of the report from this link,


Fundamentals of Scrum

What is Scrum? What does it mean when someone says, we are following Scrum methodology?rugby-673462_1920

Originally, the word Scrum is from the Rugby game and as per Wiki, it means “an ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side. The ball is thrown into the scrum and the players try to gain possession of it by kicking it backwards towards their own side.”

Essentially the Scrum that we are talking about is a framework for managing Projects and teams in an Agile way of working which involves a Scrum Board, Sprints or iterations etc. (An iterative, time-boxed approach to implementing agile)

When someone says that they are following Scrum, it means they are following the below basic pieces of Scrum.

1.      Daily Scrum or Stand-up: This generally, a 15 Mins time boxed event which Involves team members talking about the three basic questions for the benefit of whole team like, what did I accomplish, what is my next plan of action, any blockers or Impediments. This is not a Status update meeting but, the whole idea is to give the team members an information for their benefit, understanding and to shout out for help etc.

2.     Scrum Board: It is said that a picture is worth thousand words. Well, there are no pretty pictures but, Cards denoting the work that’s being done and team members working on it, which is usually denoted by a picture of their chosen Avatar. For, example I can choose the character of a Batman or Joker as my Avatar.

3.     Iterations or Sprints: Between 1 to 4 weeks. The expected time period for the start and finish of a task within a Project.

4.     Relative Sizing: Of available work, typically in a Fibonacci Scale of 1,2,3,5,8,13,20 etc. Decided by voting of team members or an individual member.

5.     Retrospective Meeting: Which involves the Scrum team get together and discussion of the results of Iteration – retrospectively. Helps a team to understand things like, what went well, what did not, things that Needs Improvement etc.

6.     Writing User Stories: Goes up on the Cards that are displayed on the Scrum Board. The wording is typically, something that is easy to read and understand the task. As a, abcd efgh (Test Analyst, Business User / Owner),

I want to, abcd efgh..,

So that, abcd efgh.. followed a list of Acceptance Criteria.

7.     The Scrum will have, Epics, User Stories, artifacts, Ceremonies and meetings like, the sprint planning meeting, Daily Scrum, sprint review meeting, and sprint retrospective meeting etc.

Much more can be said and written about Scrum, but I think this is enough for now.

Customization of a COTS Product


Here is an interesting and humorous forward that I received in WhatsApp. On a serious note, things can go wrong and these things do happen. Customer asks for something and receives a very different product. That looks like what was asked for but functionally useless. This is where; the importance of testing comes into picture. Testing is not a simple checking and marking of cheat of cheat sheets but, requires the a Test Analyst to think outside the box, Exploratory testing, using ones experience, challenging or verifying the requirements which are ambiguous and finally, use ones common sense.

Client: “Our next requirement, we need an elephant”

IT Team: But why don’t you adjust with a buffalo, even it is big…. and black?”

Client:  No, we need an elephant only.

IT Team: Fine, I understand your requirement. However, our system supports only a buffalo…

Client: We need only an elephant!

IT Team: Ok, let me see if I can customize it for you”

At the Offshore Development Centre:

BA – Client wants a big black four-legged animal, long tail, less hair.  Having trunk is mandatory. The same was documented, signed off and sent to, offshore for development! Based on requirement all features are supported in base product (as buffalo), for trunk alone a separate customization is done.

Add on to this, testers completed their System and Functional testing and passed the product.

Finally, when the customization was shown to client for UAT, and the client faints.

* COTS: Short for commercial off-the-shelf, an adjective that describes software or hardware products that are ready-made and available for sale to the general public.

Root Cause Analysis in Software Testing


Here is an interesting verse from the ancient literature of India, where a travelling Monk makes a Root Cause Analysis of his life situation as below,
The Monk said; “These people are not the cause of my happiness and distress. Neither are the demigods, my own body, the planets, my past work,or time. Rather, it is the mind alone that causes happiness and distress and perpetuates the rotation of material life”.

The value of Root Cause Analysis is indispensable. Few years ago, I was working as a Test Lead and sole Test Analyst for a project. A new Module for an existing system was being developed.Then, the time came when the deadlines have become shorter and there is pressure on the developer to deliver the work. I started finding and raising a number of Defects which started to delay the process of migrating the new product to the* UAT environment.There was panic and people started questioning “what is causing the delay?”.That was the time, when I decided to add this field called Root Cause Analysis to the Defects Module of Quality center.
As displayed in the table below, I have classified the Causes into different Categories and when ever, I log a defect, I would simply select the Root Cause field
which could be one of the following like, a Design Error, Code Error, Test Error etc.I would generate this report from the Quality Center for my Triage meetings or
the Project team meetings and immediately the Root Cause can be obvious from the Classification and basically, would give a clear picture to the higher ups – where
to see and focus their attention.

Wikipedia defines Root cause analysis as:

Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. “

“RCA initially is a reactive method of problem solving. This means that the analysis is done after an event has occurred. By gaining expertise in RCA it becomes a pro-active method. This means that RCA is able to forecast the possibility of an event even before it could occur.”

All defects logged in *ALM – QC needs to be classified for root cause as below,

Root Cause Classification Description
Requirement The defect was caused by an incomplete or ambiguous requirement with the resulting assumptions differing from the intended outcome.
Design Error The design differs from the stated requirements or is ambiguous or incomplete resulting in assumption.
Code Error The code differs from the documented design or requirements or there was a syntactic or structural error introduced during coding.
Test Error The test as designed was incorrect (deviating from stated requirements or design) or was executed incorrectly or the resultant output was incorrectly interpreted by the tester, resulting in a defect “logged in error”.
Configuration The defect was caused by incorrectly configured environment or data
Existing Bug The defect is existing behavior in the current software (this does not determine whether or not it is fixed).UAT – User Acceptance Testing * ALM – Application Life Cycle Management which is basically, the newer version of HP – Quality Center which is the Software Test Management tool.

*UAT – User Acceptance Testing

* ALM – Application Life Cycle Management which is basically, the newer version of HP – Quality Center, a Software Test Management tool.