Tuesday, 30 June 2015

Are You Performing Your Actual role?

Audience – Testers, Developers, Business Owners and others who are reading this article
Scenario – Actions and reactions to a rejected defect by the team
Key takeaway points – Amplify your productivity at work by sharing all that you do as part of your role. Ask for sufficient time required to perform each of these testing tasks.


The defect we log is at times not accepted as a valid one. At times it simply is not reproducible.
There are occasions when a server restart can fix a server error encountered on a web page.
But the same is not conveyed to a tester, unless the team has to raise a request every time the server is restarted.

Dev team - Do you keep your testers in loop at all times when you make changes to the delivered code?
Testers - Do you ask for information on what fixed the defect? And say no to accommodating frequent changes to the delivered code.

It is important for the entire team to be able to COMMUNICATE and be INVOLVED wherever and whenever required.

  • Be transparent and help each other maintain a healthy environment.
  • Start by initiating to reproduce a defect with a developer sitting beside you and do so on the test environment. There, the problem is solved.
  • Provide sufficient details to reproduce the defect. Re-produce it yourself. Ask a peer to do so. Ask the dev team to do so on the test environment.
  • Ensure that the team actually investigates the defect before marking it as fixed.
  • Collect testing wisdom as you do this and share the notes with the team.
  • Use a defect tracking tool, to track a defect to its closure.
A tester’s job is not limited to logging a defect but is extended to taking it to a justifiable closure.


Do you feel offended on missing out to implement a requirement or portions of a requirement?

  • Defect is a reflection of quality (low) of the product not a reflection on you/r work.
  • Not being able to find ALL defects is not solely a fault of the tester.
  • Irrespective of developer / tester – it is necessary to understand errors and differentiate human and machine error.
A requirement is raised and prioritized by the business owner(BO) and is signed off by the BO.
If the entire team contributes to prioritizing the tasks then how can a defect or a suggestion waiting for its turn to be fixed be de-scoped by someone other than the BO?
Do you check with the business / product owner prior to de-scoping / rejecting a defect / suggestion?

Business Owner

  • Are you accessible to the whole team?
  • Are you present in a defect meeting?
  • How do you contribute to defect triage?
  • Do you have a say on de-scoping / rejecting a defect /suggestion?
If the answer to the above questions is no then it is important that the BO be invited and kept in the loop of meetings which does require involvement on making decisions to de-scope or reject a defect. The power to de-scoping or rejecting a defect / suggestion suddenly does not shift from BO to a Developer / Lead / Manager.

Back to the question: Are you acting / performing your role?

  • How often does it require for you to work beyond your role and responsibility?
  • Are you really asking the right questions during the interview, regarding the role and your responsibility as a team member and not just as an individual contributor?
  • Does it surprise you, when you are asked to deliver more in a less time-frame?

The above questions will not worry us later, if we take time out to define the role and the responsibility we are endowed with at the time of the interview and what we are actually doing as part of our day to day testing tasks.
  • Record and share with the team, the tasks you performed whenever you overshot a target set.
  • Share what other activities you performed, being in the current role.
  • Ask for time to do all these activities.
  • Provide information on risks encountered, road blocks you met with, research that you did, mitigation's you implemented while performing these tasks.
Are you still penalized for not acting your role? Or promoted for taking too much work upon yourself?
Both can be lethal!

Answer for yourself – Am I acting and performing my role?
Above all – Know that what defines you differentiates you. You are unique because you ask a different question, you solve a tougher problem and you can help solve them.

Allow yourself to act your role

ACT is to – Apply Clever *Tactics
*Tactic - A plan for attaining a particular goal.

Featured in the June 2015 edition of Testing Circus

Friday, 19 June 2015

Testing - A Migration Project

Lessons learnt when working on a migration project - Pitfalls and Preparations

I had not worked on a migration project before. I did not know if testing this project would be same / different from the other projects that I had worked earlier on.

I did learn new lessons when I worked on this project and have summed up the lessons learnt in the form of a mind-map below.

Note: If several web applications are being migrated it helps to track the progress on each relevant component meticulously.

A few other aspects which helped me (in this instance) sail through this project are:
  • Assertive – Being flexible and saying no when needed
  • Asking for help / clarifications in time
  • Learning from mistakes
  • Being practical 
  • Communicating – regularly and effectively
  • Sharing risks early and following it up to its closure (in some instances)

Why mind map?
Because it helps me collate and share the ideas around a centralized topic better than the other modes I have tried.
If it is relevant to what you wish to share and helps you visualize better, try it.

Add on to this mind-map with your learning and / or share your comments below.  Happy testing and migrating! 

Click / tap on the image and zoom to view better or alternatively view the images below. 
Migration - Web application

Identify and Do this