When we are kids, we like to believe that world is a simple place.
Our teacher in playgroup or prep or nursery classes would tell us that “Sun rises from the East and sets in the West”. We like this simple concept because it is in accordance with our daily observation and more importantly it is an easy concept to digest for a kid of just a few years age.
As we grow, we are told that Sun is not rotating but it is our Earth that rotates which gives us an effect of Sunrise and Sunset. As we get into higher classes, we are told that Earth also rotates around it’s own orbit and Sun has many other planets. We are then told that Solar system is just one of the so many Galaxies in the space. We are told that we are living in an ever expanding Universe and we are told of something known as Black Holes and theories of Big Bang. We are told that we are not certain if we are expanding or moving to a certain point or we are just hanging around. This very complex nature of the Universe is simplified for us as kids to believe that world is easy: “Sun rises from the East and sets in the West”.
Similarly when we start our professional study or professional career, we like to believe that world is a simple place. There are some rules that if we follow, we can be successful in our business. If we add these magical lines in our CVs, we’ll get our dream jobs. If we network in these best ways, we can excel in anything we want to achieve. We tend to believe that there are some “best practices” that if we get to know and master them, we’ll be the champions in what we do.
This is as simplified version of the world as simplifying the Universe to Sun rises and Sun sets.
The only best practice is that there is no best practice
This Dilbert strip was taken from here: http://theleanthinker.com/2013/12/31/the-problem-with-best-practices/
What we forget when we are in search of best practices is that world is a complex place. Each individual has it’s own strengths and weaknesses, each of us operate in a different region of the world in contrasting cultures, each of us have different values and different meanings of the outcome. What works for me may not work for you. What we need to do is to understand the situation, apply some practices, evaluate the results and keep tweaking them.
You may be tricked to say that see here is the best practice:
Understand the situation, apply some practices, evaluate the results and keep tweaking them
If you are thinking in this way, this is due to the reason that we don’t want to leave our childhood and we love stories and we love simplified versions of the world. The above is not a best practice.
What are your thoughts on best practices?
Having no tests means you have a challenge with the Quality of your solution. Having thousands of tests means you have challenges of test management.
Yes, like testers and development teams, tests have to be managed.
So often we find claims on different tools’ websites that “we have thousands of tests running all the time to ensure quality” but let me today take you inside the life of that world.
As I talked about this problem of putting some tests to “Ignored list” to make the build passing all the time in my post about Continuous Integration, when tests reach a big number the number of Ignored tests also increase and a campaign has to be launched regularly to clear them. The tests in this list come due to three reasons:
- Tests are failing because test code is bad
- Tests are failing because production code is bad
- Tests are fine; they just take too long or have other dependency (data/hardware) that prevent them to be run on build servers.
For the bad test code, a public shaming (a.k.a. peer pressure) email that list down authors with biggest number of ignored tests help. Keep on sending those emails as the some people are more “shame-proof” than others.
For the bad production code, make sure the issue is reported in bug tracking system and elevate it’s status. Do mention to the team that if we fix them, we get two benefits: a) Bug count reduces and b) test count increases.
For the third category, some strategy is needed to run those tests after the build on regular basis. For example, we ignore all Performance tests from the build as they take too long. Then we run them each week and compare them with benchmarks to see if results are good. Bad results are then shared with the team.
Tests that you think run but they don’t
The machinery to include all tests in your repository is a piece of code and it can have bugs too. When you first write and commit your tests, you assume that they run each time yet they don’t.
In one of the audits that I did on my project recently revealed that about 10% of the tests were “not in the system”. The build files had some commented portion that happened due to some reason and then stayed there. There were some assumptions about the folder and files which were not being honored by all tests after some changes. Bringing them back in the system gave us some additional coverage right away.
What do tests do?
The quality of tests remains questionable as unless you see what each test does, you can’t say how good your tests are. But there is always the first step of doing code coverage.
Having thousands of tests doesn’t mean that you have good coverage and all methods are being tested. In the audit that I mentioned above, we found out that our overall LOC (lines of code) coverage was still 50%. Another thing that we found was that:
Module A has 500+ tests with LOC coverage 70%
Module B has 500+ tests with LOC coverage 40%
So just looking at number of tests, you can’t guess the coverage. A note here is that coverage is also not a perfect measure of quality but as I mentioned it is a good start until you can review each test.
Do you have thousands of tests in your project? What kind of challenges you have to deal with?
The Manager Responsible for Release (let’s call that person as MRR for rest of this post) has to make the decision to ship the product and is keenly watching the Iteration Review. Programmers have finished demoing the implemented features and the situation looks good so far. The testers start their part and this is what MRR get:
“14 new bugs reported in the Iteration out of which 8 were of highest severity. 26 were verified and closed. There are still 4 open Defects.
Out of 18 test plans executed, 13 are passing and 4 are failing with some issues reported while 1 is still to be executed.
Smoke testing was done for each of the 4 builds in Iteration and 3 passed whereas 1 failed.
Performance tests were executed on the Release Candidate build.
That’s all from the testing team.”
Confused as MRR wants to make a decision, the person un-mutes the mic on the conference call and asks: “Tell me if we are good to release the build demoed earlier in the Review?”
The test lead says: “That decision is not Testing’s rather it is yours. But if you ask us, we say may be.”
The MRR loses confidence in the testing team in particular and in testing in general (along with losing the temper).
Does the above scene look familiar to you? That a testing status is entirely a report on the testing activities with too much focus on numbers? And do as testers, we need to change our tactics? I think yes.
What do testers do? They provide information about product under test, to expose risks for the team.
In the above example scenario, does the tester provide information that exposes risks? Obviously not. Let’s revisit it and see how activity report can be used to do this.
What is the risk?
Before you prepare your testing report, you should be very clear on what risks are there in management’s mind. These could be in the line of following statements:
- What if the product it not released on time?
- What if the product is not stable enough to be released?
- What if the product is too slow to use?
What information Management needs about that risk?
Management is looking for information in the report and not data (data vs. information). Let’s convert the earlier data and convert it into information:
“There are 4 open defects and they are all related to View Profile feature. Given that this is our first release where Users will mostly be working with their Profiles, they possess a threat to the release if not fixed. 1 defect is of high severity which allows to view profile of any user through modified URLs and fixing it is of high value but of not much cost. The other 3 defects are related to some cosmetics which are important but can be let go if needed.”
Now the MRR feels much informed and says: “Great. If we can fix that and do a round of regression, we should be able to ship in 2 days”. All say yes and life is good (at least for now).
Can you think of similar statement for the test plan results or smoke test or performance results in above example?
All the jobs of software testing brings some joy to life but without argument, the most entertaining moment is when a tester finds a bug.
In the job interviews for software testers that I have been doing for a long time now, one of my questions is: “Tell me about your best ever bug?” Most of the times, the tester’s eyes would glow and they would share the story in the greatest of details. Those are the moments they remember in details because they enjoyed it.
But why do we enjoy to find a bug? No, it is not due to the reason that it allows us to prove that testers are not un-necessary part of the team or outsmart the Programmers. But it is due to the fact that:
Each bug is a discovery of a land never found by anyone else before. It is that unique path in the application under test which was not traveled before. It is a situation that is never triggered before. It exposes the risks that were never known to the team before and brings a new perspective to the release cycle.
(the original photo is here: http://disneyinfinity.wikia.com/wiki/Joy )
The other reason that makes the testers happy is that a bug discovered before release makes the team safe from it being found by the outside world. A bug found means fixing it will make the release more solid not just by fixing that problem but by making a conscious effort in the area exposed by the bug.
And when you explain the bug to your team members verbally or through a bug tracking system, it adds an element of story telling. Oh boy, telling a story is always fun because you are telling a tale that the listener has never heard of and it is full of surprises. Another similarity that I present to my team members is that:
“A bug is to a Tester, what a verse is to a Poet”
It is a creation from non-existence, a source of pride and a statement never said before.
What has been your most enjoyable bug so far? Do you see other reasons that make finding bugs so happy moments in a tester’s life?
This is a guest post by Ruma Dak *
Be it personal or professional life, we receive and give feedback more often than we realise! Like lot of other things, feedback can be very relative and it’s impact and effect depends a lot on perception. It wouldn’t be wrong if I say that most of the times, we do not know how to receive feedback in a positive manner and give feedback in a harmless way.
Let’s talk about giving feedback first. Focussing more on the professional side of things, feedback is an important tool/medium to let people know about their performance. The way feedback is given influences the benefit it can provide, if any. When you are a giver of feedback, the most important thing to remember is that feedback is about peoples’ action or work and not about their personal selves.
It can be very constructive if it is specific and delivered in a clear, concise and respectful manner. A feedback should be complete so it can deliver the intended message . BIPO model can be used to deliver a feedback, where BIPO stands for :
Behaviour: Explaining the behaviour for which the feedback is given for.
Impact: Impact that the above behaviour created.
Preferred Behaviour: What was the expected behaviour, this would generally differ from Behaviour in some way or other.
Outcome: What is expected after feedback is accepted and acted upon.
When giving a feedback, it is very important to provide an alternate to highlight the scope and benefit of improvement. Make sure your feedback motivates the receiver and not demoralise or insult him/her.
(the original photo is here: http://blog.aasaanjobs.com/wp-content/uploads/2014/05/feedback.jpg )
Receiving feedback is something not everyone is good at. It’ very easy to feel offended by a ‘not-so-positive’ feedback and take it very personally. When on the receiving end, one should be open, sincerely interested and accepting of the feedback. Listen to the feedback carefully and spend time analysing it if required. Feel free to ask questions, have a healthy discussion and take it as an opportunity to identify the ‘unknown’ about you and try to make the feedback work in your favour.
If the feedback is positive, try to set it as a standard for yourself and take negative feedback as constructive criticism. Be thankful to the person giving you the feedback always.
Seeking feedback: People often don’t realise that feedback can be explicitly asked for or they shy away from doing so! Seeking feedback fosters communication and makes people feel valued. It’s a good way of making people say things which they would not willingly do. When you try something new at work, ask people about how it was? Generally, in such cases, you will receive the response to be something like ‘Oh! you were great’ or ‘Yeah, pretty good’ . Ask people to point out at least two things which you can improve on or do slightly better. I have tried this myself so many times and its always helped me get some great ideas. Free-of-Cost! And when you seek a feedback, you are indirectly giving an implicit feedback that the person’s opinion is valued! How cool is that!!
Apart from the above, there will be times when you will receive unsolicited feedback out of the blues. Welcome it as well with open mind and try to make the most out of it!
So, whether you are giving, receiving or seeking feedback, be thoughtful, respectful and thankful. Lastly and very importantly, always prefer face-to-face communication while doing so.
Finishing off with a quote from Ann Marie Houghtailing:
Feedback is a free education to excellence. Seek it with sincerity and receive it with grace.
* Ruma is a tester-blogger friend based in Australia and blogs at http://rumadak.wordpress.com . She is an expert Tester, a bookworm, a traveler and also talks about life philosophy on her blog. Read more about her interests on her blog’s about page.
If as a People Manager, I have to give you one tip that would be to hold regular One-on-One meetings with your direct reports.
Usually the talk of holding these 1-1 meetings revolves around the modalities of scheduling like should we do it on weekly basis or once in a month. Or revolves around the modalities of how much you should talk vs. how much your direct report should talk. All of that is irrelevant. What is important is that the purpose of holding such meetings is to understand each other better.
It is not the team that consists of super stars that succeeds, but it is the team that knows each other well.
(the original photo is here: http://icirr.org/content/importance-one-ones )
Here are some other benefits of holding such meetings from my experience on top of this understanding:
Feelings are conveyed
In a typical workday, conversations revolve around getting things done. Technical discussion spring from task updates and project planning meeting consumes the day. You talk to your direct report many times but the focus is on the “Work” or “Task”. As you move into a specially scheduled 1-1 meeting with your team member, the focus immediately shifts to “Humans” and “Feelings”.
So I typically ask questions like these in such meetings:
“How do you feel about your current assignment?” or “Are you excited enough with the challenges we are offering?” or “Do you feel happy if we ask to work with team X?”
When your direct report answers such questions, you get a lot more understanding of the “human” on the other side and how that person “feels” or “operates”.
People feel special
Regardless of where you are in the hierarchy of your organization, your team knows that you are the busiest (and perhaps most costly) person in the team. So when you set everything aside and allocate time for your team members, they feel special and they feel acknowledged. Motivation then just becomes a side effect of such conversations.
That is why it is important to hold these meetings at some conference room rather than on your work desk to avoid any distractions. And that is why cancelling a scheduled 1-1 meeting sends a very wrong and opposite message of being special.
You share your feelings
Though it is value in having different personalities and having people of different capabilities in your team, it is always good to have them behave in the way you envision your team.
One of the quotes that I like from “The Casino” movie in which Robert Di Nero tells his direct report:
“There are three ways to do work. The wrong way, the right way and … my way”
As your team members express their feelings and talk about their emotions, it is always good to express your feelings. Acknowledge the things you like and mention the things that you don’t like in a way that they don’t feel badly but feel positively to change them.
Are you practicing 1-1 meeting in your team? What lessons you’d like to share?