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?
Last week, I was invited by a group of “soon to be graduated” students of BS in Computer Sciences at FAST Islamabad campus. One of their subjects require them to host a talk by someone from Industry to complete the course. From the list of topics, I chose to speak about “Careers in Software Testing”.
Since on one of my previous tours, I had talked about taking a career in Software Testing, this time I focused more on what happens if you take that route. The main points that were laid down to the audience were:
- Software Testing belongs to the Software Development as a whole. So careers in testing are similar to careers in Software Development.
- The first few years of this career is establishing yourself as a technical resource.
- Once you gain that position, you have two options. One is to become a people’s manager and start rising on the management ladders. The other is to remain a technical hub of knowledge and become the person who defines the technical path of the company.
- The technical paths in Software Testing are various. The latest hot ones are Performance testers, Security or Penetration Testers and Automation Engineers.
Picture taken from Haibye.com.
- If the above looks too complicated or too much effort, try starting your own business and you’ll be CEO on the first day.
- Presented Microsoft as a case study which offers jobs in Testing.
- Covered how testing in Pakistan is growing and growing and growing.
The slides are shared here if you want to take a closer look into the above contents.
Did I miss something? What else we should tell graduating students about career paths in Software Testing?
Usually people draw comparisons between testing effort and coding effort (which some also call Development effort whereas Development is the whole process of implementing requirements which includes testing). To use this as a trick question, I tried asking this in one of the recent interview session:
“For a given feature/user story, Programmer estimates that it will take 3 weeks to write code. How much time you think, you’ll need to test this feature?”
I got answers like:
- At least one week of time. This is based on my experience.
- I’ll ask for half the time as it takes at least 50% of the time to test.
- To be on the safe side, I’ll ask for 60% time as my experience says it usually takes 50% time and then we may encounter more problems in a given feature.
Clearly the tester is thinking of testing effort is directly proportional to the coding effort. Even some people also have 10% unit testing tax formula or some suggesting law of diminishing returns on testing.
For me testing effort is not proportional of the coding effort and the answer is “it depends” :). Let me explain with two experiences.
Few years ago, with introduction of Windows 64bit versions, one of the teams I know took the approach to let their applications run as 32bit applications in 64bit environment. The did minimal changes to announce that their software “supports” 64bit and then asked the testing team to confirm each and every features “works” as expected. Easily in this case the testing effort was way more than the coding effort given that the application was a huge one.
In another project, one of the teams was having performance issues in their system. They decided to flip the design scheme to take it from ‘attaching B to A’ to ‘create A and link with B’ and it took them couple of months effort to change all the code to get in line with this new design philosophy. Once done, testing team was asked to do performance benchmarking. As the UI layer never changed, the set of tests were executed without any issues and new numbers were reported in a few days. In this case testing effort was almost not notable as compared to the coding effort.
So when you are asked next time, “how much time it will take to test?” , you should first understand what the problem is you are asked to test and then negotiate a good number.
Do you ever developed a formula for testing efforts? And do you still want to use it?