Co-operative Unit

Rapid Fire Question - What comes to your mind when I say “Co-operative unit”? I was curious to know what people would come up with and tweeted this question. Below are the only 3 responses I got:

1. A team located in the same premises, cooperative bank, a team cooperative with each other (vipsgupta)
2. Football (lnsimha)
3. Amul (sdhanasekar)

I was expecting “Team” as an answer.

Over the years, I watched many teams perform. Some excelled, some merely existed while the rest fell asleep. What is a Great Team made up of? Unity? Collaboration? Strict Manager? A Great Team is made up of Great Individuals who believe in Team Work.

Couple of months ago, I was chatting with a friend who said something like this: “I want to hire a great team” My response was: “You can’t hire a great team, but you can build one”. Building teams is serious business today. We may solve millions of business problems, but if you leave one people problem unsolved, that is good enough to bring down entire business. Here’s a sneak preview into few good/bad/ugly teams.

Real life example: “Solo Ownership”
Solo Ownership team consisted of team members with sole ownership for anything and everything

Key features of the test team
a. Each tester owned a module based on his experience and knowledge of products
b. Not a single tester looked into someone else’s module [even if his module was tightly integrated with some other module ]
c. If a tester found a bug in a module other than his own, he would not report it. He would not even mention it to the original owner [The attitude was “it’s not my problem”]
d. If a reasonably responsible tester found a bug in a module other than his own and reported it, he would be reprimanded. His reporting manager would ask, “Why are you spending time on someone else’s module?” The other module’s manager would ask, “Why are you testing our module. We have our own test team to do that”.
e. Testing happened in isolation most of the time
f. Integration/System testing happened at the end of the cycle during which severity 1 bugs poured left, right and centre.

Real life example: “Young Entrepreneurs”
Each one in this team felt young and believed in entrepreneurial thinking. It comprised a mature set of individuals who thought not just about getting their work done, but helping others to get their work done too.

Key features of the test team
a. Every tester was a primary owner for one module and secondary owner for another module.
b. Every tester reported bugs in any module of his choice as long as he completed testing his module within stipulated time.
c. Testing happened over the shelf – people walked to almost anyone in the team or outside the team if they had questions or concerns
d. Integration/System testing started pretty early in the testing cycle.
e. Job oriented trainings - mostly conducted by members internal to the team to facilitate quick learning curve for new hires in the team.

Real life example: “Mind your own Business”
This team comprised mostly of senior testers with several years of testing experience in their kitty, yet behaved like a bunch of egoistic people. There were a few good people, but tried hard to appear bad because good deeds weren't respected. In fact, good people would often be taken for a ride.

Key features of test team
a. Each tester would do what he liked – mostly after threatening his reporting manager to quit if things don’t improve [by the way, this happened just before the end of each quarter during which bonus numbers would be decided].
b. If critical bugs were found early in the test cycle by a colleague, some team members would say “Dude! It’s no big deal. You are doing your job. After all, that is why you were hired”
c. If a cosmetic bug was missed and customer reported it, team members crucified the corresponding tester and ask, “Were you sleeping? How did you miss such a simple bug? You should get your eyes checked” in a mocking tone.
d. Any delay in dropping builds to testers was OK, but deadline was NOT negotiable.
e. It was mandatory to work extra hours every day. Anyone who consistently spent more than 14 hrs a day in office was a rock star tester and a dedicated team member [Notice the word “spent”]
f. Every problem reported by the customer in any tester’s module meant his bonus would be reduced by 20%. Five such problems and zero bonus. Simple Math.
g. Testers attend trainings so they can sleep for a while and occasionally shout from the top of their voices to show off that they are more intelligent than the rest.
h. And there is no end to this story. It goes on and on …..

Real life example: “We are Family”
Truly a family. There is no distinction between programmers, testers, managers, technical writers and other immediate stakeholders within the organization. Everyone was important and was encouraged to make some unique contribution. Each team member worked closely with rest of the team to meet commonly set objectives. These objectives were directly aligned with organizational objectives.

Key features of the team
a. There was no single rock star team member. All were star performers and pushed each other to excel and perform better.
b. Every complex activity happened in pairs or in groups – which encouraged group learning and on the job training.
c. Team members met at regular intervals to discuss the state of the project they were working on to ensure everyone is on the same page.
d. Programmers highlighted risks pretty early in the life cycle and testers would test early builds to provide immediate information to them.
e. Product owners wrote/re-wrote/reviewed requirements in detail at the beginning of any project and reviewed/modified them periodically with customers and engineering teams.
f. Customers were given monthly demos of working features to solicit early feedback.

Closing comments
While writing this blog post, I wrote a little section called Outcome for each team and how those teams excelled or disintegrated. During review, I realized everyone who hears about these teams knows the outcome. Why bother calling names? Let's bother about building teams. Eh?

My ex-manager Dipankar Roy had tremendous influence on me with regard to team work. His belief in team work helped him build not just extraordinary teams, but amazing professionals as well. He once said “Any team is only as strong as its weakest link”. It doesn’t matter how many are star performers, how many won quarterly awards or how many excelled. Even if one team member is slow or not on par with rest of their crew, the entire team slows down and heads downhill. The key to any strong team is to empower ‘weaklings’ to become star performers. Remember, these so called ‘weaklings’ are not on par with the rest simply because they don’t know that they don’t know. You read it right. They don’t know that they don’t know (MOSTLY). The moment, they are nurtured and valued, they’ll outgrow the best of star performers. Empower people to transform as stars. Whether they shine or become dust is their choice.

Regards,
Parimala Shankaraiah

P.S.
Weakling is an offensive word. The reason I used it here is to emphasize how people who are slow/passive in the team are considered almost worthless by their immediate leads/managers. These very same weaklings can deliver beautifully if mentored by true leaders who believe in people power. Some leaders create magic with people. They value each person’s interests, ambitions, goals and help align team goals such that every team member feels respected and contributes to the team. Only true leaders can do that.

Belling the Cat - Learnings from Testing Contests

There is a huge rise in testing contests in some parts of the world. Many testing conferences today facilitate testing contests, quiz competitions, puzzles solving sessions and many more to draw people’s attention at conferences. Several crowdsourcing companies today offer short term testing projects as contests and award testers appropriately for reported bugs. If you are a tester, you love what you do and you have disposable time with you and willing to make some quick bucks, why not participate?

I have participated in many testing contests in the last one year. It’s been quite an experience. I would like to share my learnings here as it might help some of you who follow suit.

What do testing contests offer?
Quick Learning
Learning a product quickly and reporting problems within stipulated time is a challenge. Testing contests offer such an environment. You are expected to learn as much as possible and test the product. Zero Documentation available. Some of us feel miserable. Zero Documentation? It’s impossible to test. If you are working for a large organization, you must be familiar with Feasibility analysis, requirements specification, functional specification, technical specification, test design specification and technical documentation. If you are working for a tiny startup, all you would have is a bundle of code which looks like a 2 month old foetus; If you are a little fortunate, you might be blessed with a developer whom you can talk to; if you are a little more fortunate, you may have that guy next to your cubicle. Your luck factor ends right there. What if you neither have documents nor people to tell about the product. Self Learning. This is one of the most wonderful ways of learning till date. Self Learning nurtures creativity, exploration, investigation and critical thinking. Testing contests encourage self learning to a good extent.

Time Pressure
There’s not a single tester who wouldn’t crib about lack of enough time to test [except testers who have learned the art of coverage and risk mitigation]. Testing contests offer this pressure too. BUT, participants hardly take pressure. Its just a game for them. They neither have fear of missing a bug nor do they worry about getting laid off for lousy work. At the most, they won’t win the contest. Outcome: Calm and Relaxed Mind. This helps them think critically about how to test the product. Contests offer a lot of time for testers to think without worrying about time. Weekend Testing participants can tell you better how enjoyable testing experience is when testers test without anyone sitting on their heads for status or numbers.

Fault-Safe Environment
Contests offer a fault-safe setup where one can exercise individual skills without rebuke. Success in contests is not about winning alone, but the journey one goes through to reach the destination. Testers should cash in on their knowledge and enhance their skills on such platforms. One of my ex-ceo Josh Pickus often said, “Never be afraid to fail. Whenever you fail, don’t fail to learn from your mistakes”.

Exposure to variety of products
Where can you get exposure to different products at your fingertips? Softwares used in medical devices, online library management, applications on mobile devices, banking - anything that you would not have tested before. At workplace, many testers end up testing same product for 1-3 years, sometimes maintaining them for many more years. There’s nothing wrong with that, but learning about products addressing different customer needs is interesting and fun. When such an opportunity strikes, one should not let go of it.

Collaboration with other testers
Some products in some contests require collaboration from multiple users. For e.g. if there is a chat feature, unless the same user is logged in on multiple browsers/machines, it may not be possible to have real time chat sessions. Such scenarios facilitate collaboration with other testers who not just help themselves, but help others too. I collaborated with Bharath in one such competition and tested some shared features together. This virtual pair testing took us through a journey of loopholes in the product. We found many interesting bugs and each one different at my end and at his end. Both were happy not just because we found more information about the product,but because we unearthed them in such a short time as we worked closely with each other. That was a great lesson on collaboration.

Credibility
Win or lose - Testers build credibility as they take part in more contests. Such credibility gives them not just more practice, but more and more contests go their way. If that works out, they might even end up getting some free lance projects to test - in their spare time. What more do you want? Wake up folks.
Contests are open for everyone alike. This throws you open into a group of diverse people whose brains are wired differently. This facilitates a one of the kind experience by allowing many less experienced testers or students to take guidance from experienced testers. This also provides a great opportunity to mentor other testers who need help.

Consistency in quality of bugs
Contests don’t accept your bugs as they are. Each bug is validated, prioritized and weighed against the criticality of fixing it. That brings us to valid and invalid bugs. Its hurtful when bugs get rejected. However, each rejected bug teaches a lesson, not of ridicule, but of realization. Taking part in contests can help you by allowing you to think about the validity of each bug before reporting it. This way, testers can learn to weed out invalid bugs from their queue. This helps get rid of ‘report anything and everything different as a bug’ thinking.

Varied Test Combinations
Unless you have worked on One Man Army projects where you are the only tester, you wouldn’t know that testing under different configurations (operating systems, browsers etc) can reveal amazing things about these products. Contests usually offer a choice to choose from different test configurations where you can learn and experiment based on your skillset/expertise. You can also choose to test using a completely new approach and get bowled by your performance.

Test ideas and bug ideas exhaustion
I happened to take part in a few contests where scores of bugs were already reported. My first thought was, “Oh! Most of the bugs are fished out already. I don’t think I am needed here”. I took these opportunities as challenges and said to myself, “Let’s see if I can find anything new here”. I was surprised by the variety of choices I had to test. Sometimes, I chose different test techniques. Other times, I tested on different operating systems and browsers. In some cases, I tested for different language support options, search engine optimization support, looking for broken links etc. At the end of this exercise, I was happy as I found many problems in the product which I would not find if I was one of the earliest testers on the contest. Filing straight forward bugs is a cakewalk. Filing hard to notice bugs is a uphill task.

And don't forget the test ideas you might get for future tests when you read through existing bug reports of other testers. That is a gold mine of knowledge as well. Are you game for it?

Challenges in a testing contest
Filing bugs - left, right and center
Contest instructs your brain more often to Win. To win, you can do anything. If you can win more by cheating instead of playing fair, why not do that. Many testers get lost in suchemotions and report anything that they think is a deviation from the product. This trend makes programmers life difficult which many testers fail to understand or in simple terms ignore. Another common problem is poor bug reporting skills. Some testers produce lousy test reports in a hurry to find more bugs. Sure. find more bugs and report more. But work on your writing skills. Don't degrade them further. Let me tell you, bug reporting is an art in itself.

Severity vs. Priority
This is another common problem where testers report low severity bugs as higher ones. In cases, where testers are not aware of whether a particular type of bug is severe or not, assigning a severity based on their experience and belief is fine. In situations where testers are instructed to find only certain types of bugs, if other types of defects are reported and at high severity, it would annoy the product management team for sure.

Not sticking to the mission
When there is a mission set for any contest, testers should stick to their mission. They shouldn’t deviate from the mission. Though deviations are unavoidable, sticking to the mission and executing tests within the mission gives more focus to that contest can be more productive. Testers often miss out on these things. In most cases, they tend to ignore which is not a good approach to contests.

Winning streak
Increasing bug count for winning the contest than providing quality information about product is a wrong doing. Though testers can win many contests this way, not reporting quality bugs can eat into our own credibility. Again, reporting symptoms as bug clusters may hamper credibility. Success is not just about winning, so its high time testers take contests in the right competitive spirit and put up a fair fight with the rest of the crew.

Duplicates
Testers file duplicates without looking into similar bugs reported already. How much time does it take to quickly look at defects before reporting one especially in a crowdsourcing environment. Many testers say that they get bored to browse through already reported bugs. Imagine the plight of programmers who have to go through every bug 2-3 times assuming at least 3 testers are testing one product and most of the bugs are duplicates.

Stake holders late entry
Bringing in stake holders very late into the project who then instruct testers to shift focus to other testing approaches or test techniques do more harm to the contest especially if there was no mission set at the begginning. It is a good idea to throw open stake holders and testers into an open room where they discuss the requirements, expectations and risks involved in the products. This will bring more success to the contests in long run.

Testing Contests I know of
If you have come this far, you must be wondering where you can find paid/unpaid testing contests to nurture your testing soul and also make some extra money. Some of these include 99Tests, uTest Bug Battles and Software Testing Club (Flash Mob Testing). These days, many testers on twitter offer free testing challenges as well.

Next time, you come across a contest, please give it a try. If you have already participated in some of these, I would love to hear about your experiences. Let's talk.

Regards,
Parimala Shankaraiah