Community Testing - Another good practice to gain confidence on Quality of your Software !!!

During one of the projects during last year, our testing team was most stressed up with lot of activities. During the mid cycle, all of us in Testing team realized that we have too many bugs to regress and lot of feature testing pending. If we opt for regressing bugs, we have risk of finding new bugs very last in the cycle.
So we had to balance the things, but as all of us know that saying something like following is very easy but practically things can be very different in testing -

- Let's balance bug regression and testing, when there is a cap of having bugs less that 20 in your court. And most of the tester have more than 35 bugs.
- Let's test on these platforms as well, as it's a quickest thing to do.
- Let's test this bug on Win-7 in Japanese language and Standard User etc etc...
- Etc... (I don't want to rude to the Managers or Developers who use such sentences :) )

Another challenge was Integration testing which was planned to start from coming week. This kind of situation can occur in any project which is more buggy in initial stages.
Now when an individual tester starts working on ToTest bugs, it used to become hard to find more time to test new features or functionality.
So Team came up with an idea to have a time slot of 2 hrs everyday when all of the tester will meet in the lab and will be testing their own features. We called it as Community Testing and found various advantages of this:-

1. It helped each QE to do dedicated testing of their features and in turn all of them had good confidence.
2. This Exercise also helped in accelerating Integration testing, as each tester had an opportunity to discuss their overlapping feature areas to make appropriate test scenarios on the run.
3. More productive as it was more disciplined.

Now in our teams, Community Testing has become a part of every Test Plan people enjoy doing it.


*** My Personal View - In every project a stage comes when meetings, bug discussions, investigations, emails start taking too much time and hardly any time to do focused testing of our regular features.
Community testing gives an opportunity to forget about all these things and do focused exercise for gaining confidence. Within few days every tester starts feeling good. While in other scenario, when s/he spend multiple days doing bug regression, meetings etc... they loose confidence and get stressed up.

COMMUNITY TESTING is a rocking concept in my opinion. Share your opinions through comments.

Return on Investment and Payback of TEST AUTOMATION

Of all the reasons, the most relevant and easy to convey to top management is the return out of Automation :-

- Gives consistency to the project by regular feedback in quick way.
- Helps in pushing the boundaries of the software.
- Give more time to testing team for focusing on other aspects of Quality for final release in market.


With this quick recap of all recent articles, we shall we discussing the hurdles for Automation !!! But need to wait for tomorrow...

If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.

Automated Test-Suites are Great Documentation !!!

Agile Software development approach use examples and tests to guide development. When tests that illustrate examples of desired behavior are automated, they become 'Living' documents of how the system actually works.
It would be already recommendable to add appropriate comments with relevant description to your Automation Scripts. But anyway results out of input values to Automated framework is a good enough proof of documented functionality of a particular Software.

It's very hard to keep static Documentation updated all the time, while in case of automation this problem never occurs.
Automation is a wonderful way to ensuring that we tested our updated code because keeping our results in PASS always need upgradation of our Automation Scripts as per new code changes.


If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.

Least Influential Testers and Quality People with very High Influence - Which one is better ?

Yes, Testers with very high influence and with least influence can be bad for a particular project. Situation becomes worst when Developer working with such testers are not bothered about arguing on things and don't have strong opinions.

Why this came to mind and how I am concluding this?

Today I was sitting in my office and overheard a conversation between a tester in my team & relevant Developer. Tester had logged a bug which seemed to be as-designed. Developer gave one reason that it's discussed in a meeting and should be as-designed. On this Tester got annoyed and said - "I was not in that meeting, I guess. And with workflow makes perfect sense" ... and gave some reasons in favor of that. Developer was just listening and agreed to what that Tester told him. Developer didn't give  second thought on the reasoning given by tester and conversation happened in the meeting.

This is a typical example of Highly influential tester working with a Developer with less influence, weak onions etc. This way Developer end up doing/fixing things, what is suggested by Tester. Usually Testers have very strong opinions and they kind of convince other folks easily. For such Testers, Developers should be more attentive and in case of doubt, Developers should get opinion from Managements and product Managers who are responsible for product requirements.

Conversations become more interesting when more influential developers work with highly influential Testers  :-)

I have enjoyed such conversations during my career many times ! But believe me, it gives better results if both tester and developer discuss it constructively without thinking in terms of effort, time etc. Also it gives a wonderful experience for both the folks and help in improving their negotiation skills.

Now let's come to other thing when Tester is not very influential. Not being very influential doesn't mean anything bad, but Tester with least influence should not accept comments from developer or any other team members, if not convinces. And should try to follow the standard processes to share the opinion through Bugs, Email-discussions and let management take right decision rather accepting some comments conveyed through informal conversations.

Many times, Senior Developers give some technical reasons which may not be right from user's perspective. And if Tester is not convinced with those reasons, there is no point accepting things only because you can't influence others opinion.

Hope I conveyed my thoughts in right way. Please feel free to share your opinion about this through comments !!! That will be most appreciated.

Higher Management at Software Companies - Dare to accept the mistake and try to correct on your own?

I am not sure if title of this post is clear or not. I wanted to pose this question to Higher Management in Software companies and also wanted to know about %age of managers who dare to accept the mistakes and try to correct themselves.

Here are basic things I want to highlight through a basic story :-

- As a Lead/Manager, do you panic in bad situations?
- As a Lead/Manager, do you take responsibility of any mistake or just pick someone from your team to point all the fingers?
- As a Lead/Manager, what do you think about your responsibilities?
- As a Lead/Manager, How many times, do you lead by example in bad situations?
- As a Lead/Manager, how many times you give 100% credit to your team for any achievement?

In most of the projects team dynamics are unique but still there are some common things, out of which some are good for healthy work enviornment and some are not. Most of the times things keep running on right path unless deviated by various external situations. Have you started getting confused?

Here I am going to tell a short story of an incident when one of an important member of corporate management find some problem with an alreased version of software. During his usage found that a particular behavior in software is not very intutive and wanted to know the logic of it's design. He sent an email to director who is heading the software engineering team for that product.

Director called a meeting with Engineering Manager and Quality Manager of that team.Both of them had almost no clue why this feature is behaving like this. Please note that it was a problem when things were giving correct results and the workflow are not intuitive.
Just after the meeting Engineering Manager asked Quality Manager, this behavior seems very wiered and why didn't we catch this problem. Although Quality Manager was not very convices and he felt that behavior was decent. It was more of perspective problem.

Before we start with next part of the story, let me throw some light on the issue raised ! Actually this was 7th release of the software and so called problematic area was there in the application from first version of the software.

Both the managers thought about it and got to know that feature was designed 4 years back for first version of the software. Co-incidently the quality engineer who tested this software in first release was still working on same feature and he was an expert of that area. Quality Manager calls him and ask why this behavior is so wierd rather asking the rationale of the design. Although the Tester explained each and everything, s/he was not able to relate why this question was asked after 4 years of this design. Lots of other meetings happened that what should the team do about it. Many folks even talked about releasing an update by changing the behavior.

During one of these meetings some of the Managers conveyed that they were never aware of this particular thing and this should have been taken care long time back. From this point, the tester was very disappointed and tried to figure out details related to this behavior and s/he found following details:-

1. S/he found an email where design proposed by Product Management was very well appreciated by all the Manager however the feature development and testing team had some concerns with this design. As it was not useful for 15% of the users and this software had lacks of users acorss the country.
2. Tester also found a bug which had all the statistics with a proposal of giving two workflows to use the feature and the other one was the expected by the VP. And this bug was deferred by these Managers only !
3. Few more emails where reference of this behavior was discussed in detail.

WHAT WOULD YOU CONCLUDE OUT OF THIS AND HOW THE RESPECT METER REACT ON THIS?

Now here are some basic questions that arise :-

1. Was this a so big issue?
2. Was there any need to discuss this thing in so much detail?
3. Shouldn't these managers figure out details for conveying it to higher management without much Panic?
4. was this something to discuss with so much parties involved?
5. Can a Manager say that he was not aware of software behavior?
6. And lot many others...

I think I started with something very sepcific and lossing track... So I am stopping here for you guys to think and will share the next part soon :)