In testers meet, I was asked, "I happen to see
overlooking the value of building the testing team and contributions team make
to shipment. Do you see same in your work? How to solve it?"
Before I went ahead to discuss on this, I had silent in
me. I see certain problems are in the
culture and mindset for first. Bringing
a change here is not that easy - culture and mindset. It also applies to
testing teams. It also holds good to any others (or teams) interacting with the
testing team.
Taking the analogy of skilled carpentry work (say, "pepperfry") - we will see how this exists not just in testing but anywhere. But in
testing, it is not changing after decades too. That's the problem causing unbearable
costs and not the actual problem. It's not being attempted to understand by who
needs the testing, in my opinion for today.
A skilled and experienced carpenter can do her/his work
quickly and with values, right? How many carpenters exist today who can do job
at least to level of saying this is the minimal must value and job, I need
without the supervision and initial assistance from skilled carpenters. If seen, the assistance in carpentry work is
not for weeks or months. It takes longer
time depending on the skills, mindset, passion and attitude of person learning
the carpentry. Now comes the context -
there is a list of orders coming in; the skilled carpenter has people who
started carpentry and the people who can do job on consistent supervision for
'x' period of time. If the skilled carpenter puts her/his time in doing the
work day in-out to deliver the orders alone, may be orders delivery will be met
but with diminished values in work eventually? How long the skilled carpenter
can do this i.e. all alone? The skilled carpenter should not assist her/his
fellow carpenters and help herself/himself or people who will be hiring them
for job? I learn, the skilled carpenter
will assist and give her/his more time in closely watching her/his fellow
carpenters while chipping out the core part of the orders. What if the fellow carpenters quit and join
elsewhere? That cannot be stopped by any means. Due to people quitting does one
has to lower the standards of one's work? Do the furniture brands say we lower
our standards of product as we find carpenters quitting the job? NO!
Relate the same to Software Testing and Automation. Including me, we have people in software testing -- who
knows jargons; who knows how to use what they know in shallow or not know at
all; and starters. Here we will have serious people who are interested and also
not interested. Considering the current time (future as well hopefully) of people or team who needs the testing team, isn't that a skilled
tester job to build a team on which they can sustain and rely in coming days?
This long activity i.e. building of testing team can take
years. And in my experience when had a people with right attitude, consistent
efforts and passion - it can take close to 2 to 2.5 years for one. In these 2 to 2.5 years, we can see people
tackling the testing problems if practiced well. But people do change job in 2
years or so, now should I invest in it?
This is one of the invest-cost-value problems which has made Software
Testing to take back seat.
It has gone to least priority when considering of having the
skilled testers and testing team. Because, practicing testing is not done by
most. Later saying this is testing to people boarding the team/org do this and getting the
lower returns and values for team & org. Eventually blame the testing and
testers. One simple example, we are aware of Design Patterns in programming and
know several books/authors who has authored.
Do we know the Test Designs and design techniques apart from black box,
white box, grey box, and any books or authors who have authored on same?
Blinking of brain starts here! I feel
there is no need of better example than this.
Everyone has experience but that does not mean they are
practitioners. This is the trouble with
people boarding into practice of testing. They happen to hear and work upon
hearing - just do this, like this, this much, and as this. Write your test
cases, automate all, bug reports and everything here. If that can be said in
ease, it can be done in much more ease. Why hiring of the testers and having
testing team? Now you know the trouble
and pain points of building the testing team and testers?
The expectation from the skilled (carpenter) tester is X+1,
but the people who gave the job/orders see it is y-X and not far close to X. This is the exact case with people
or team hiring the testers and wanting to see the "proportional" value
right away in the product and to the organization. It can be achieved, if considered just the
skilled (carpenter) tester and for a shorter period of time. But is that the
expectation of people who pay for the all carpenters (testers) doing the job in
a business?
To see the value of a test, it can happen in a release or
few releases. To see the value of testing being done or not done, it can take
few releases. To see the value of having
the skilled testing and their work, on which people rely, it will take
years. I see same applies to programming
team as well. But in programming space we have people who practices it and then
assist boarding people.
In the testing space, we don't have practicing people to
assist the boarding people and existing people, in the right way. This contributes to laggard and continue giving
a low mark to the testing team and testers.
Now is it -- problem of the industry; problem of the org;
problem of the people or teams wanting to have testing teams; problem of the
testers itself? Whatever, the impacted
entities are -- industry, people or team who want to have skilled team and of
course testers too. Help the testers, testing teams and testing practices you have in your org. By this, you are investing. When investing know
if it is done in a right way and on right stuffs. Otherwise, the investment
made today in testing can become blocker cost.
If a skilled (carpenter) tester is working on building the
future carpenters by giving her/his assistance, it is not a simple job! That's
the bigger value. Doesn’t the business find returns one day out of this
assistance? I say it is not simple job.
The skilled (tester) carpenter knows that he/she is not doing in full what
she/he has to do in a given context while continuing to assist other carpenter. But negotiate in open mind with
stakeholders by bringing the understandable and mutually agreeing communication
- what is expected immediately out of carpentry work given or the orders that
came in. If this is done,
half-the-problem is solved when you have skilled testers. Often, this will not happen and skilled
tester too fail here.
The communication of expectation for a carpentry work
coming from different people; to whom should the carpenter look upon and
deliver the asked delivering the work?
We testers and testing team have this problem as well in getting our
work set and delivered.
How to solve?
1. It
needs a leadership in testing at org and in teams. The test leadership, if they are testing practitioners
it is good and boon. But hands-on practitioners might find time constraint to
be in management and hands-on delivery. Yet this is do-able in my experience.
2. Testers
need to pull up themselves and bring the change in-out.
3. Culture
and mindset problem, needs better way of solving and not the software testing
way i.e. how software testing solves problems.
Unless having the faith in software testing and how it solves the problem,
it cannot be used as a relativity in learning to learn and solve the problems.
4. At
the bottom, skilled practitioners will be on the hit list most times.
Unavoidable! But that should not put down the Software Testing community and
practitioners growing. One day you will be recognized, remembered and highly
valued for what you have done. Just make
sure you don’t incur big costs personally by doing this activity. Balancing is
the key here and it comes only by incurring the costs while doing this activity
If not bothered about
·
need to transform into skilled testing
practitioners;
·
org not having/wanting the efficient testing teams;
· continuing the shallow and low returns testing
& automation, which is highly accepted, paid better for doing that and you don’t
care a penny anymore about it,
then do not attempt solving this problem for you, your
team, and your org. It will never be solved. It will just increase the troubles
to all. One day it will be realized and
it will be picked to solve by stakeholders upon having the costs.
Note: I admire how the "pepperfry" crafts its furniture. I
wonder why the same cannot be achieved by carpenters who do carpentry while
constructing the house. I'm left with many thoughts on this and I try in
discussing them with a tester in me.
