Skip to content

Some thoughts…

August 4, 2011

On certification and skills development..

From my personal experience, I believe that certifications may show that you have the ability to study for and clear an exam. But they cannot be proof of the skills you may possess. There is so much debate over certifications on the Internet. However, not many seem to be aware of this!! And are pressurized to acquire certifications. In general, I’ve seen and heard many people not wanting to do a certification just for the heck of it. They want to actually learn the skills and then maybe take up the certification. Also, there are many who take up certifications believing it will enhance their perceived value. It may help them achieve that..but definitely it will be short lived if they don’t have the real skills. Coz lack of skills will be revealed sooner than later.

I took up the CSTE certification for two reasons. I have no technical background in computers; I studied life sciences at college, nor had I done any beginners course in software testing and believed that to be a limitation. I also believed that I could have a better understanding of software testing and could improve my skills based on the study material that would be provided for the certification. Okay, there’s also one other factor; the organization would reimburse the exam fees if I could clear it at the first go! which was the real clincher!! So, when time was not a constraint, I applied for the certification.

Unfortunately, at that time, I had’nt come across this . At the very beginning, the author states that ‘Most of the people in the world who work in software testing have never taken a testing class, read a testing book, attended a testing conference, participated in a test user group. They still get to keep their jobs, and they might even be okay at testing’. Probably, it would have made me think differently.

The study material seemed humungous and I felt overwhelmed initially. Still, I decided to tackle it judiciously and made a plan to cover it in the available 2 months time for preparation. During the course of the preparation, I did learn. Learn, as in, I became aware of a lot of things pertaining to software testing. But sincerely speaking, it did not help me with improving my skills as I had hoped. The theoretical stuff was very much removed from the ground realities of testing and the projects that was involved in. They were like two different worlds with a few intersecting/common points. Nevertheless, I took the exam and cleared with flying colors so to say🙂 and that is because I think I have always been good at comprehension and tackling such an exam was not a hurdle for me.

Where skills are concerned, I have been learning on the go… by actually testing stuff that needed to be tested. I have goofed up quite a few times… not only in testing something [missed out some important scenarios], but also in reporting [by reporting inefficiently, which led to some rework for the developers]… which also helped me to learn. Much later, I discovered the blogs.. the testing related blogs that talk of actual testing..the skills..[ not the ones that tell you about the testing techniques and how to go about achieving a certification] which I could very much relate to. Love the way they correlate little things in life to software testing… or software development in general. Am amazed at how they come up with those!! Not sure if the blogs have helped improve my skills per se, but surely they have helped create awareness, especially about the existence of resources that testers can use to educate themselves and sparked some thoughts… at least occasionally.

I must admit, that apart from some reading, I have not done much to educate myself further. Varied factors are responsible for this, the main being my laziness!! Like you can see, this blog of mine too has been a victim… neglected for almost an year. And this post has been in the making ..like forever. It was in my head.. not even in the drafts here! And I’ve digressed.

Two reasons I began writing this … one, I’ve been receiving reminders that my certification is about to expire. I dont think that it really matters to me now. But, of course, am not sure how people who recruit, will view this. Two, lately, I’ve been reading blog posts and articles that talk about self education for testers which I also think, is the way to go!! So, i’ll end this with a couple of links which got me thinking..

Combating “Tester Apathy” by Micheal Larsen

Alternative paths for self education in software testing  by Markus Gärtner

Bangalore Workshop on Software Testing by Pradeep Soundararajan

Hoping that more and more testers become aware of such resources and strive towards excellence through self education…

Happy Learning!!

STC registration saga!

August 27, 2010

I came across the Software Testing Club via Parimala’s and Lisa Crispin’s blogs. I went through the site a bit and decided to join right away.

I hit the register button. Entered email and password, hit submit. On the create profile page, entered all the required details and hit submit. Expected to be logged in or a page with a mesage thanking me for registering or some such thing. Instead the page stayed as it was. As I wondered whether anything happened at all on hitting submit, I noticed the message ‘Please enter your city/state’. Perplexed, I went through each field on the page and saw that all the details were correct. But could not locate a field to enter city/state.

Confused, I decided to try all over again. I repeated the whole thing right from step one; clicking the register button. But, with no change in the result. I was flummoxed!! The only thought that came to mind was ‘maybe only US citizens can register to this site’ As it was time to leave, I just gave it up and went home.
Surprisingly, at bed time… my thoughts went back to this episode. I wondered what could be wrong. I knew that my assumption of the site being only for US citizens was not right. I tried to think of other things. And then it struck! Maybe it could have something to do with the browser!! I decided that I had to check it out first thing when I get to office the next day.

For quite some time now, I’ve been using google chrome for my browsing-reading sessions; I love that the browser suggests the url as i type in🙂 And I’d noticed that some sites appeared a little diffrent than what they appeared with IE. That was one reason why I never risked using Chrome for online banking🙂 I have not done a lot of cross browser testing but I have tested applications on different versions of IE.

Coming back to STC registration. Next day, I used IE for the registration process. On the create profile page, when i selected the Country and hit tab,the city/state field appeared! This hadnt happened while using Chrome the previous day and hence the missing city/state.


Rest as they say is history. Ok. Just kidding !! The registration process was completed without a glitch. And I’m now in August company!!!

Team work – its all about team cohesion and cooperation!

May 4, 2010

In my testing career, I have worked for a longer time, in fact almost 90%, on Agile projects that followed the Scrum methodology. One aspect of being a part of Agile teams is that I got a chance to work closely with developers, actually physically located alongside the development team. I have been a part of the dev teams, working on sprint tasks… understanding task requirements, getting clarifications, writing test cases and then testing the tasks as and when they are implemented, as opposed to testing in a separate testing phase. ‘Working as a team’ has made all the difference in the way I think about software testing.

As opposed to the traditional thinking that quality is the responsibility of the testers/QA team, Agile emphasizes that the onus of quality lies on the whole team and not only on the testers. This presented a whole new approach to testing and a new meaning to the role of testing/tester in the project. The way to go forward was with a ‘developer + tester’ attitude rather than the ‘developer Vs tester’ one. As we got together, working on our mindsets and approaching things differently, we realized the value of working as allies who share a common goal; that of completing and delivering a task/feature/defect fix on time and getting it ‘accepted’ by the product management. We were able to provide quick turnarounds, sometimes even when the target seemed unachievable.

The methods of testing varies from the informal quick checks on the dev machines, which is quite unthinkable in a traditional setup, to formal testing providing quick feedback in case of any issues found.

Informal methods do not include scripted test cases. It is something akin to smoke testing on the developer’s machine, before he/she can commit the code. In many instances this has helped us quickly uncover bugs and fix them at the initial stage itself. Lot of time saved in moving the task to and fro with elaborate notes! Here the point to be noted is that – the tester’s credibility no longer depends on the number of bugs reported or logged in the tracking system, but rather in the number of issues averted. I know that this could really be a point of contention for most testers. But that is how I have been able to achieve credibility with the developers in the team; by actually helping them do their job better!!

Working closely with them has also reinforced the fact that, by testing, I don’t intend to catch and expose their mistakes. Rather, the developers have come to realize is that all I’m trying to do is to help them deliver what is ‘required’ by the client/customer. How else can I explain the umpteen times when they have appreciated my effort and actually said ‘Thank You!’ I truly believe that such a thing would be really rare to come by in a traditional setup where developers think of testers as lesser beings and whom they have to fight to vindicate their own work.

The feeling of a shared vision and common goals is something that has got the team through the rough patches. This is something unique to Agile, I believe. It is something that we, as a team, cherish. Another significant advantage of working in this setup is that, as an outcome of my testing combined with domain knowledge, I have been able to provide significant inputs that aid in the development effort, either in the approach or as a pointer to the cause of an issue.

On the whole, I am as much a team player as a developer on the team. And collaboration and communication are what keep the team going!

Signing off with a very crisp and precise article by Lisa Crispin ; it is very pertinent to the things that I have said here.

Defect baselining – An approach to better defect management

April 20, 2010

What do you do when faced with a lot of bugs… especially on the eve of a release? How do you handle this with minimum risk factor?

The Context

The team: 21 members including 9 QA/testers working on development/enhancement and maintenance of a suite of 18 Add-on products for Microsoft Dynamics CRM versions 1.2, 3.0, and 4.0.

Releases: Worldwide releases, supporting all previous released versions (via upgrades) of the products in multiple languages [English, French, German, and Dutch], deployed across multiple environments.

Initially, the releases were very eventful. The testing team went about its job of finding and reporting the defects in a release candidate. The defects were prioritized by the product management and fixes done accordingly by the dev team. The number of bugs used to be overwhelming, so much so..it threatened to cause burn out. This, inspite of all the quality assurance activities, like following coding standards, code reviews, unit testing, and formal testing. There was a growing concern that something is amiss.

On careful analysis of the problem at hand, we figured out that a lot of defects had been in the system since quite some time and were not a direct result of recent development and enhancements. Moreover those bugs really didn’t bother the users. This could be most probably because the bugs didn’t affect or hinder the way they used the system. Or maybe they were able to find a way around.

That is when we got around to the idea of baselining the defects that are present in the system. During the next regression cycle we documented the defects that were found, in an excel sheet and cross checked these with the defects that were already logged in the project management tool. Well! it was one huge exercise.. but worth it.

At the end of this exercise, facilitated by the information collected, we were able to classify the defects

* Duplicates – a number of duplicate issues were logged in the tool So we removed the duplicates. It served in cleaning the system as well as in reducing the bug count!!

* Reopened issues – defects that had been closed in an earlier version but were opened again

* Legacy issues – defects that were already found in earlier version and still in open status (the ones with lowest priority)

* New issues – defects seen only in the current regression

* Redundant issues – those that were ‘open’ but had become irrelevant in the current system due to changes in functionality/expected behavior

We deleted the duplicate and the redundant defects. This resulted in a cleaner tool and a considerable decrease in the number of defects! The legacy issues, we listed in what we called the Baseline defects sheet. It had information like defect number, defect title and the version number in which it was reported. So we were left with only the reopened and the new defects to deal with🙂

When this information became available, it was a huge relief to everyone concerned. The numbers now looked more manageable. It helped..

* the product management in better prioritization

* the dev team to focus on defects that would be prioritized for the release

* the testing team to focus on better testing of the system

Going forward, the Baseline defects sheet became a very important QA artifact; a ready reference that saved us a lot of effort and time. Defects found in regression were cross checked with the Baseline defects sheet. We did not log or report the bugs that were already in there. This considerably reduced the number of defects, i.e, the defects that were actually opened or introduced during the current sprint. For every release, the lower priority known issues along with the version number, were added to the baseline sheet. Overall, this helped in optimum utilization of available time and work force and decreased the stress levels in the team.

Eventually, the releases became very stabilized.. in fact they became non events! We sometimes managed to release a couple of days prior to the published release date. Seems too good to be true? This needs to be seen to be believed!! Of course this was not entirely due to base lining of defects. There were other factors involved too. But this was a huge contributing factor and in the bigger scheme of things it led to what is called as ‘sustainable productivity’🙂

Hello!!

April 5, 2010

Finally… starting off on this journey!

I am Priya, a software tester by profession. I landed a software testing job by some strange coincidence of events… but stranger is the fact that I seem to understand and know testing intuitively. I do not have an engineering background and have never attended any testing course either!! I just went with the flow.. and I learnt and imbibed stuff quickly as though they were never alien to me. Earlier on, I got interested in Agile methods and read a lot of blogs on Agile. Recently, I have discovered some blogs on software testing and they are just too good to ignore… I’m not mentioning them right now.. but I’ll make a neat blogroll in time..as this blog evolves. 

Though I write a personal blog  and am aware of the benefits of blogging, I have been reluctant to write a professional blog… maybe because it requires a lot more dedication and thought focus. But now I’ve finally created this blog, thanks to some wonderful inspiration on the blogosphere!! Two posts that  I read earlier this year have been instrumental in making me take this plunge. One is Rajesh Shetty’s ‘Why some smart people are reluctant to share?’ and the other is Pradeep Soundararajan’s ‘Why testers should blog?’ . These posts were insightful and made me think in this direction.. I could relate very well to what they have said/reiterated in their posts. I don’t claim to be smart or a good tester… but I realize that I have some experiences that I can share… so, here I aim to do just that.

I’m glad that I’m doing this … coz I think its ‘Better late than never!!’

I am hoping that it will be useful and insightful for me, as I go on… and maybe it will of some help to others in the community as well!! Though I must warn that this is not aimed at giving testing tips or even promoting best practices.  

And .. a few words on the blog title.  I’m a ‘test enthusiast’. I think of software testing as a thinking persons job, and in fact the process of understanding software requirements, thinking of the test approach and the exact test data… all things related to testing .. I find these interesting!! I rarely ever get bored of testing a piece of software, I am neither deterred by slow machines nor by the number of iterations I have to repeat a test in order to deliver  the right stuff, though it sometimes is exasperating!! But then again, I must admit that I have not been as passionate as the testers who do ‘weekend testing’ and attend testing workshops !! I’m hoping to do better in the coming days🙂 For now,  I wish I’ll be disciplined enough to blog on a regular basis.