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?
In one of his classical pieces “The Art of bugging: or Where Do Bugs come from”, Jerry Weinberg suggests that if debugging is the process of removing bugs then bugging should be the process of putting those bugs in. He then list down a set of bugging possibilities in his typical funtastic way.
Taking his thought further, I think that a Tester’s job should not be just find bugs (and humiliate Programmers) rather one of the prime jobs of a Tester is to improve quality in whatever way. Other testers have suggested some ways and I think helping team adapt a policy of no “Bugging” can be a game changer too.
(the original picture is here: http://pictures-e2.thumbtackstatic.com/pictures/911/c7ux0jzhx0mh3a97_580x380.jpg )
Taking Jerry’s examples, I have picked two types i.e. Gee-bugging and Ye-bugging. Let’s see what they are and how to tackle them.
“Gee-bugging is grafting of bugs into a program as part of a piece of “gee-whiz” coding—fancy frills that are there to impress the maintenance programmers rather than meet the specifications.”
There are many ways to avoid this. One is to help Programmers become experienced one in light of this blog which outlines responsibilities of the senior developer. One of the line says:
“A senior developer will understand that this job is to provide solutions to problems, not write code. Because of that, a senior developer will always think of what they are doing in terms of how much value it brings to their organization and their clients vs how much effort they are putting in.”
So we have to make our Programmers experienced in providing solutions and not writing beautiful code. Peer code reviews can help and practicing Three Amigos will help Programmers understand the complexity of the client world and devise solutions for them.
“Ye-bugging is a mysterious process by which bugs appear in code touched by too many hands. Nobody knows much about ye-bugging because every time you ask how some bug got into the code, every programmer claims somebody else did it.”
In the modern world teams are really distributed and code bases are shared. This can really become a problem unless we implement a world class configuration system that works on Continuous Integration principles. Such that code written by any one is complied continuously.
In our team we have a build process called firebug in which code builds every few hours. Any one who has committed code between two firebug jobs, get an email on successful or unsuccessful build. In this way, a really mixed up code is maintained without any problems.
“By removing what you don’t want, you don’t necessarily get what you want”
So let’s work with our teams and say No to “Bugging” and build what we want.
What other practices you suggest to end “bugging”?
A Tester has to juggle between lot of activities: understand the system under test, learn the domain for which the system is designed, design tests, execute tests, find bugs, report bugs, prepare meaningful testing reports, plan testing, prepare test data, prepare test environment, deploy system under test and so on.
If you look at the above list, it can be categorized in two blocks. First being intellectual or human work that includes learning, designing, planning etc. The other block is the dirty work that every job comes with and doesn’t consume much of your brain cells. The things that I mentioned earlier as Test supporting activities. These are the things that you should try to put them on ‘auto’. With the understanding that tools fit into your testing strategies and not define them, believe me Python is the best tool to do that.
To get you an idea of what tasks I’m exactly talking about, in our current project we have written Python scripts to do the following:
- Download build from the ftp server. The task is scheduled and looks every few hours to check for the latest build. The script downloads it, unzips it, places it at desired location and sends email to all the team members.
- Upload the testing results on SharePoint server. When some of our testing tasks finish, we hand over the results to this script which massages data, makes them more ‘management-friendly’ and uploads at a desired location on SharePoint server so that all can see it.
- Regression testing tasks. One of the required regression for our project is to make sure that latest build works well with existing data. So we have ~250 different type of models that we pass to the build and see if it all goes well. This is again done through a Python script.
- … You get the idea.
(the original image is here)
Now your could argue that any scripting language can be used to achieve the above, so why I’m loving/promoting Python. To be honest, in some earlier endeavors I’ve used VBscript, AutoIt and C# projects to accomplish the above. So all are good but since life is short, these things make Python more loveable are:
- Batteries included. Yes it comes with all you need to play with. Test supporting activities have a lot of a variation to be able to work with XML, Excel, SharePoint, Batch files and so on. Python has a solution for all.
- It’s Portable. The same scripts that run on Windows are running on Mac and on Linux for us. The modern world is so more complex and so more wide that portability is gem of a feature.
- It’s easy. If I can learn and use it, any tester should be able to learn it. And it is also backed up by very active development community that would share code samples and answer your questions if you run into trouble.
Do you have a list of support activities? Have you put them on ‘auto’ and how?
Recently a tester friend of mine discussed one of the classic problems of testing. You are about to release your next version and tested all areas on a “Release Candidate (RC)” build and then you find one issue that is big enough to ask for a new build. Now you get another RC build. Should you test it all as if this is the first RC build? Or should you start from where you left the last build? Or should you just test the fixed issue? Should you test all or test small?
As a hardcore tester, everyone is taught to be suspicious of things. We apply “guilty until proven innocent” formula to everything that we test. And given that we know from experience that in software world one change can upset many unwanted things, the first preference seems to be Test all.
But here is the dilemma. The whole set of tests take many days to complete and time is short. And all those people called Project Managers, Release Managers, Product Owners etc. etc. are asking you after like every hour “How are the testing results? Can we release now?”
Let’s see if we have a case for Test small i.e. only test what has changed. I believe yes and here are the things that you need to achieve this:
Know what has changed
The biggest challenge is that until the testing team has a very good insight into what is built in the system and how it is built, they’ll continue to consume all builds including RC as black boxes. See the figure below that if you receive two black boxed builds, you can’t tell what has changed. But if you can see inside those boxes, you can tell what has changed.
How can you look inside the system?
You need to have all the details of how your source control is maintained. Is it a trunk based development or branch release system? Access to changes made to the code so that you exactly know what happened between the two builds. Many build systems can generate a ‘diff’ report between two builds. Work with the programmers in your team to have those reports coming out with every build. There are tools that can compare two installed versions of an application and even you can write your own tools to know what has exactly changed. Take control of this system rather than waiting for the information to arrive from others.
Now that you are sure what has changed, your test strategy for the latest RC will be just around that change and not a “Test all” strategy.
Unit tests are the safety net
Yes, you know that right. If your programmers start writing Unit tests and you befriend them to support this activity as a testing unit, you can see if all tests that passed on last RC are passing on the new RC, things could be alright in those areas. The bigger is the scope of Unit testing effort, the safer are your releases.
History repeats itself
Keeping a track of what happened in the release cycle until the latest RC is always a good indicator of what will go wrong in this build. Say some of your modules have been working fine in all previous runs of testing and the change is not in that module, you can safely ignore such modules for the latest RC. However if some modules created problems here and there in the release cycle, adding them to “Test small” strategy might be interesting.
How do you tackle this problem? Do you do a Test all or you have discovered some form of Test small?