Nothing to do

I never knew life was so easy. Imagine someone telling you “Hey, you don’t have to do anything”.

Feeling good? Who doesn’t?

Today, on a rainy Friday evening, I thought I will do some reading online. You will be thinking that this guy starts by saying about doing nothing and does something else.

Well, unplanned activity sometimes yields great results. Just like those un-planned leaves give me brickbats from my people above me.

I was reading a Blog (don’t ask me the name) and that lead me to a website (don’t ask me the name again) which had lot of information on Testing. I could read it online or download a zipped file. I was destined to do the latter and never knew something was in store for me that I had not seen it before. Not sure how many of you have seen this.

I clicked on the “Download Zipped File” icon and there came a File Download dialog staring at me, asking me if I want to Open, Save or Cancel.

I chose to “Open” the zipped file. I could find a PDF File inside which could expectedly be a treasure trove of information.

Instead of Opening or Copying the PDF file, I Cut the PDF File and pasted on my desktop. To my surprise, I saw something I have never seen before.

Two dialogs appeared. One said “Deleting From Archive…” with a “Cancel” button, but I really could not understand what was getting “deleted” and where from did the “Archive” come into picture. The other dialog gave a smile on my face as if someone was running a feather on my ears. This dialog is very close to my heart as it said “Nothing to do.”

Nice to see “something” asking me to do “nothing”. But the dialog had a title “Compressed (zipped) Folders Error” and told me to do nothing with an OK button. I was curious and dying to click the OK button to know what could happen next.

When I clicked OK, something disturbed me even more. After seeing the above two dialogs, I thought I was in for some trouble. But that was not the case, thanks to my planetary positions on a Friday evening. The PDF file was actually saved on to the Desktop. If you see my desktop Cats, even they are surprised to see the saved file. Don’t they look surprised?

Wow…What a Bug I encountered on a rainy Friday evening when all other testers had gone home to spend a time with their families and friends.

You know what, sometimes it pays to stay back on Friday evenings and explore the un-explored. Having said this, a meeting with two campus minds a few days back, comes to my mind. I met them and spoke to them and trust me, I was talking to a campus mind for the first time so closely. It gave me a feeling that these minds are our future. They have all the energy and raring to go. They made me feel so happy with their presence. I spoke to them at length and told them that they had made the best move by choosing Software Testing as their careers as they seemed very passionate about testing.

After seeing the above Windows Bug, our Campus Minds will feel that they have made the right choice of becoming Testers. Testers of today could be Testing Legends of tomorrow.

Will anyone dare say “Nothing to do” to these legends?

Communication leads to Test Coverage, not just Requirements.

How many of us thought that Test Coverage is important? And Test Coverage comes just from Requirements?

We are always behind Requirements...Requirements...Requirements and just Requirements. We expect the Requirements to be in the form of a MS Word doc and may be a PDF and may be a PPT and may be an Excel and nothing else. We are so used to these few things that we see nothing beyond these.

What else could lead to Test Coverage?

We often ignore Communication. Communication is a tool, an important tool for your test coverage. Oral Communication, Written Communication and sometimes, even SMS could be a communication medium to record the Requirements for test coverage.

Not all Requirements could come from Requirement docs, not always at least. There are instances when customers have emailed the stakeholders with some additional requirements that were not covered in the actual requirements document.

Usually, we have calls with our Customers to discuss so many things. The Customers could be from across the geographic locations. Understanding them, their voice, their language, their accent etc. makes the difference and how well we convert them into our understanding for the test coverage, matters most. I have even had a chat conversation on a communicator to discuss things that have been possibly be a "Requirement".

The medium of communication is not important here. What's important is how well we gather the "communication" and document it and then share it as just "Minutes of Meeting" or a Word doc or a Scenario/s or even a test case/s.

There is no right or wrong way of understanding requirements as long as it suffices the Business Needs of the Customer.

16 August - Indian Software Tester's Day - Sounds Good ?

Happy Independence Day to all Indians across the Globe.
And Happy Independence Day to all Indian Software Testers across the Globe.

What does freedom mean to all? Freedom to do anything within the purview of the Law. In the software testing context, freedom to a tester means to do anything within the purview of the scope of testing, and sometimes, beyond that.

Any software tester needs that freedom to achieve a goal. Goal is Quality. Tester needs freedom to explore everything and unearth bugs. Tester needs a free hand to explore, experience and experiment the application under test.

I am somehow against holding a tester responsible for duplicate or rejected bugs. That's against the freedom of a tester. What's the big deal with a duplicate bug or a rejected bug. The customer is equally responsible for the quality of application. The tester is not responsible when the requirements are not frozen (freezed)(finalized)(baselined), the customer is.

The customer or the stakeholder should understand that a tester is there to test the application and find bugs, not to face enquiry committees for duplicate bugs, rejected bugs, leaked bugs.

Unless the tester is a free bird to test what he wants, how he wants, any barriers would discourage a tester to do a good job in testing. Let alone do a good job, a tester would think twice before plunging into a testing job.

16 August should be called as INDIAN SOFTWARE TESTER'S DAY, a day after the Freedom day of all Indians.

Thoughts?

Jai Hind!!!

SOFTWARE QUALITY – IT TAKES TWO HANDS TO CLAP

This point of view tries to define the common pitfalls of Software Quality and the stakeholders’ involvement in achieving the quality objectives of any Software Development Engagement. Quality per-se cannot be achieved with just planning without action, the action from all the stakeholders. The author tries to find out who should be the stakeholders for achieving quality objectives and if the current set of quality initiatives taken by organizations is sufficient to reach the goal or will the organizations have to re-think on their plans.

SOFTWARE QUALITY – IT TAKES TWO HANDS TO CLAP; the title looks vague. But in reality, it is not as vague as we think. As a tester, I don’t think it is vague. What are the “two hands” that we are talking about? Well, one hand is the “Customer” and the other hand is the “Service Provider”. By saying that, does the title still make sense? Enough is said about co-operation between two business entities. But, will there be success when both work in tandem? The answer to this is a plain YES. Software solution will reach its peak of Quality with co-ordination and understanding between the Customer and the Service Provider. We may wonder then that this happens every time but there are cases where customers are not happy with Quality of the solution. Probably, they would have stumbled upon severe production bugs. We know that we used the right processes, right approach and right mix of everything. But still, there is no “quality” as perceived by the Customer.
The domain, the technology, the software model, the people, the process, the testing and quality initiatives – these are all necessary phases of any Software Development. Each of these is focused from the day one of the Software Development Life Cycle. I am sure then the Customer too is an equal stakeholder in the entire process. After all, the customer pays for the service. But we often miss something or rather many things during the process of execution. Some of the important factors that we often neglect are:

 Attitude
 Communication
 Tracking
 Follow up
 Understanding
 Approval
 Recognition
 Resources
 Tools
 Documentation
 Process
 Technology


The order could be different in each case. The list could grow with each experience. But these form a major chunk of misses that could be possible “fatal errors”.

Bug Burji

All about Testing (not your patience) Software and the Bugs and Burji. The stories and what not.