Is Testing, a boredom?

I am writing this blog because I’ve been dragged by a post in the Google testing blog that has this same topic. I believe I am the right person to write this because I currently pass through the phase what the blog discusses on with a 2+ years of budding experience in the software testing field.

June 4, 2007 – The corporate world gave me a red carpet welcome and I was honored as an IT professional by my current employer. After a week of rigorous training on process and products the firm holds, the day that decided my destiny came. I was given the choice of red and blue pill as Neo had it. I was asked to choose my path in the whole SDLC cycle by my HR, though they clearly knew, the first two phases in it required a lot of domain and technical expertise relatively. I chose the red pill – testing and am here before you writing the experiences in these two years of my choice.

Software testing is always a fantasy for me as I loved spotting faults in others works. Yes, I just loved them like a gambler in Vegas trying to hit a jackpot by counting cards! But then I realized it was not about finding faults but finding facts. Testing is something I chose for my career. Thank god! I atleast had that option open for my life. I was put into product testing when I first entered the job where I had the greatest guru of all my time to teach me what and what not in testing and sometimes in real life too. I’ve been an enthusiastic tester then, trying to figure out what is the purpose behind my choice. Almost a year passed by, on just thinking about the choice I made. I literally felt “Testing is boring”, may be this is not my cup of tea. Hence I tried learning development and satisfied my entire quest to do more and do new. But still it is testing I chose and I am not a guy who want to move away from the choice that I made though I regret for what I’ve taken.

March 6, 2008 - This is the time where I had a call for Automation testing. Automation seemed to be an oasis for me in a dry desert of repeating the same process of preparing test plans to fight with developers on Sev1 issues. All these recurring events passed through the dawns and dusks of my life and now I feel like I am reincarnated to do something that is new and something that could persuade my point of holding my choice. I was like a kid who got his first bicycle on his 7^th birthday (I think I got mine then!). I took this bicycle out, learnt cycling after so many bruises and became a master, that I drove it leaving hands one day.

During this golden period of my era in Automation testing, I was ruled by a king whom I admired a lot. He is the one who molded out a mature mind in me. “I was like a crazy dog running behind cars” then. He made me to stabilize and focus in what I need. He is the one for whom I dedicate all my articles even this one and he is the one who wanted me to write.That’s the man I just want to become and I always wanted to be with. As they say “Every dog has its day!” and as the saying goes, the dark day came. He was plugged out of the organization and now am alone in this world of miseries.This is where I got my enlightenment of my path with all his words still with me. Passing all those happenings in my corporate life for two years I realized the fact that “Testing is not truly boring!” It is the simple psychology of human to consider something boredom if it becomes a routine in his life. I just made it up to change my routine and I understood it’s not that I have to change the whole job, but it’s that I need to change the routine am in. Like a rejuvenated knight, am back on track to do this job and I still love my choice.

After all it is my call and I believe I’ll live it up to the moment to see and write “Testing – My choice and My life!!!”

S-Ox Testing unveiled!

S-Ox

I suppose this is the buzz word around us recently and everyone believe that this is the best procedure in town to implement and of course increase the productivity and reduce the cost. This article will speak on what this buzz word is all about and how does it differ from others, what we normally gaze through and work on.

S-Ox Testing:

S-Ox is a famous auditing procedure named after Sarbanes Oxley, which talks about financial controls of an organization. The S-Ox auditing procedure covers various sections and obliges the organization to follow the control measures for managing the financial aspects of the organization.

So how is it related to IT?

Though the term relies on the act of financial reporting, IT being the backbone of an Organization’s finance at present, has to be addressed with this. Under S-Ox, the audit process extends into areas that have a pervasive effect on the ability of the company to perform accounting and financial reporting. Since most business processes are supported by IT directly or indirectly, your project team will make the decision whether or not to create documentation integrated with the business processes or separate documentation for IT. Either way, IT processes that support the applications will also need to be documented. Thus S-Ox plays a role and this article will explain the implementation of S-Ox into IT.

S-Ox relies on control objectives and continuously monitors the activities that are needed in meeting the same. Hence understanding S-Ox is so simple. The motto behind S-Ox testing is that are we performing all that are needed in meeting what is required. I hope this is the motto of all testing and only the implementation varies. So how S-Ox testing is implemented?

Implementing S-Ox Testing:

S-Ox testing as any other testing process can easily be implemented and will yield you a great outcome of what is being developed. Once the documentation as stated above is done, team will have to work on “Control objectives” of the complete project. The real purpose, the basic requirement well drilled down, the objective of a product in various dimensions is called a control objective.

Now after framing a control objective, control activities are identified. Control activities are so simple, the activities that are required to address the objective and possess the risk by which the objective won’t be met. I believe the complexity of this can be reduced with this example:

Say, the control objective is “no unauthorized access”. Now the ‘control activity’ has to address what if there is a breach? What time frame would it take to identify it? This could be the risk and counter measures are to be identified. Then we go for implementing the test plan thereby knowing what the risk is and how do we address it. This will eventually increase the scope as well as coverage of testing which obviously will improvise the quality of the product and that too in low cost.

This article is referred from unrecognizable web pages at many parts which helped me out actually to understand this, which was in a typical auditor language.