We all in the “Testing” field in one or other ways have learned after a point in our careers, that finding bugs in the products is just not enough. There can be many ways we could have learned it. May be by reading others work and how it has helped them do better, or by going through our own good and bad experiences after putting our findings on the table. Here I am with my understanding and learning from my experiences.
“WE” model:
I have heard about many models of the industry going around. But have we thought that may be no model will help us until it fits into the basic “WE” model. By “WE” I only mean if the model we are following is helping us moving ahead, and is not the root cause for keeping us away from our goals. Failing in “WE” model can be very dangerous for the product’s present and future as well as the work environment, and would end up us having unhappy co-workers roaming around, who might be happy to hate each other, and worse may be see each other even fail(what is that slang “I told you so about” btw?). When we fail to understand each other while working together in a team(and not as a team yet), see that how hard it would become to understand customers and users. Before understanding users’ need, isn’t it required to understand each others need. We talk about user’s emotions and their importance in the product, while we fail at the co-workers’ emotions while developing that product. Isn’t it funny, what we actually want and look for into the product is absent in ourselves and the environment we work in.
It is therefore very important to understand each other. For that we might have to start listening to each other instead of turning ourselves into a noise for others. May be we have to show that yes, we trust you, but here is what we might have to consider. Showing respect for what somebody is bringing to the table builds the team spirit. Sometime somebody not bringing anything to the table is also a sign where we have to look within and ask ourselves Why? Why? Why? before asking them about the same.
Softwares – as most would agree, are some kind of solutions which would help users to achieve their goals. Goals – most of the times, are actually very simple, for example I want to fly Ahmedabad or eat chinese food, and that is a very simple goal. It is the road and the journey to the goal which are complicated most of the times. So in order to simplify the problem and build simpler but effective solutions we have to trust and respect each other. By trust I don’t ever mean to accept anything at face value, and by respect I also don’t mean to butter superiors and take others abuse. Trust and respect are key to collaborative culture and software is not about individuals. Team member should be confident about what will certainly NOT happen after putting their work on the table.
When I found that my opinions and suggestions are being welcomed and asked for in the team, I realised that my other co-workers would also have some and they don’t know yet may be that theirs would also be so welcome. So I started asking for others opinion and suggestions before putting mine forward. These little conversations are what builds up team environment and gives us a collaborative work culture
Collaborating over Bugs:
A few general statements we use often in conversations, what they might sound like to others or how they might get interpreted at the receiving end.
“I found a bug” – Self boosting, Show is not over yet
“Fix this bug NOW” – Commanding me, Does he has the power?
“It’s a totally buggy code” – Adds Fear, What do I do?
“I don’t get it” – Either he or I(ok not me) lacks product understanding
“It’s a clear bug” – Making Noises
“You don’t get it” – Doubts my skills, how dare you say this
“I need time to test this” – Never satisfied, Don’t know the logic, what else will he test now?
So the gaps between communication adds the impressions and adds extra emotions even when they were not the part of our feelings while conversing. This suggests that testing the product and finding bugs is not just enough. In order to let the bugs rest in peace successfully we have to consider the journey they have to go through. Bugs are not just give and take between a developer and tester. I always see bug as an opportunity because they do say a lot, that helps me to collaborate over them and not hate them. That is the reason I don’t see myself as a bug hunter. We develop, we find things, we collaborate and we meet our missions. I am not sure if I get everything right about a successful collaboration but the key point I guess is “We don’t actually need to understand coworker’s work, but instead understand the co-worker, meaning listening to what they are saying and why they are saying”. Focusing on the basics help simplify the complex things. To Develop Software we all need to travel in the same boat, and saying whose side has the holes and who is responsible for the holes won’t do much help
Things help me collaborate bugs/features:
- I am not the authority to decide what to fix and what not and when.
- I don’t feel sad about bugs not being fixed(okay sometimes I do a little),
- Not being sentimental about bugs helps having open discussions
- Others are trying to do their best, so do not judge others work or pass statements
- There involves many things in deciding bug’s faith. I report, give feedbacks, suggestions and opinions, I don’t judge or decide
- I might have misunderstood their take, and briefing them about what I have understood actually from the conversation helps clear things
- Don’t be Sorry – indicates mistakes and misunderstandings are natural, and are not taken personally
- Thank you – indicates I am feeling grateful
- It’s Great -indicates I appreciate your work
- Let’s do this -indicates Let’s work together
Below are some funny conversations I actually had and have learned my lessons from. Today they really do sound funny but at the very early stage of my career they were not
Conversation 1:
New Developer(afraid of counts): This bugs is a duplicate
Me: This appears on different screens and both have different scenarios
New Developer: You don’t get this, I have coded it so I know a bit better Ma’am!
Me(in my mind): Where is my gun!
Conversation 2:
Project Leader: We’re shipping user portal so I want this tested by 1 pm. We don’t want any bugs on Admin portal
Me: okay!
Me(Adds data to admin site to get it displayed on user portal and finds lots of bugs meanwhile on admin site): Let me add them now
Project Leader(Appears angrily at desk trying to create a scene seeing huge bug list): Are you done with User portal?
Me(Giving a chilled response) You said you want it by 1pm, right? You’ll get it
Conversation 3:
Me: As you know I will be on leave tomorrow
Test Manager: Plz make sure to meet Project leader and give status information
Me(Goes to Project Leader and tells him about my already granted leave): I am leaving in few minutes
Project Leader: What is the status
Me: There are still some major bugs not resolved yet
Project Leader(Angrily): What were you doing till now, why didn’t you report them earlier
Me: I have already reported them well in advance, and your developer knows it
Project Leader(realised it’s his poor but dear Developer, so smiles at him): Okay No Problem, We will fix this, don’t worry
Me: Goes on pre-planned vacation
Conversation 4:
Me: When are you fixing this, I am being asked again and again about this bug
Senior Developer 1: I have to discuss this with Developer 2
Me: Okay
Me(After a few days, to Developer 2): Did Developer 1 discuss with you?
Developer 2: No! we have not managed yet as we work remotely
Me(To Developer 1 again): Plz discuss this with Developer 2 as he says you haven’t yet
Developer 1: What are you trying to achieve? Leave it to us and we will take care.
Me: I am trying to achieve just what I have been employed for. So plz be professional next time you talk to me
Developer 1: I am sorry, but you don’t have to worry for this, Leave it to us
Conversation 5:
Me: We need to trim before|after spaces as they would create problems for users if they enter unintentional spaces with usernames and password
Developer: This is what we could do in a budget given
Me: Okay, but you understand that the username and password would not work if spaces are taken literally, this will deny user everything.
Developer: Yes, okay we will fix it sometime later
Conversation 6:
Me: This is a bug, and user doing this even mistakenly would end up in a soup
Developer: You know that users are not supposed to do that, and if user does stupid things, he gets stupid things
Me: Okay, I just hope we don’t have such stupid users
I was one who earlier used to think why can’t I say what is right, and what should be the expected behavior when I actually know much about the product than anyone in the team. But over the years it feels how childish I behaved then. Now I guess I have a much open mind and like to collaborate rather than arguing and proving who is right. When you have mind, use it to discuss things, why argue 🙂