Software testers should be technical AND business oriented

Ok, the percentages are more of a gut feeling, but can be close to accurate... less then 50% of all software testers (global) have no idea how to program and from experience (that includes numerous companies as well as discussions with colleagues and friends in other companies). 

It seems a bit odd since the testers do test the software and therefore should know how the damn thing was build. Or do they? One can also argue that a tester does not have to have any affinity with programming, coding and other development terms, but that he has to test whether the delivered software does what the customer asked for. And in a way these people are completely correct. Testers do have to show the customer that the software works according to the requirements set up or at least approved by the customer.

Then why should a tester know more about programming and be less business oriented? My personal opinion would be that when you know what you are testing, you know where to put your testing effort. This is what a tester is for; be in the middle of it all, know everything about anything within the software project. 

The testers should know the following;

  • How the software was programmed; what language was used, what are the strengths, but mostly; what are the weaknesses?
  • How is the infrastructure organized; Which other tools are connected or influence the newly developed software, which parties are involved, what is the live span of the infrastructure, etc
  • How is the architecture organized; a bit the same as the infrastructure, but deeper. Testers should read this design before testing starts. even better; we should review it to find mistakes in an early stadium!
  • What unit tests were executed and what was the result; unit tests usually are executed by developers, but mostly never read by testers. If you know the problems found within these tests, testers might create cases related to these findings in order to find the biggest risks.
  • Look over the developers shoulder when he tries to find your bug in the code; this will give a big insight in the way not only the software was programmed, but in the way the developer thinks as well. Testers are smart enough to understand code (even though we have no idea how to create it *KIDDING*), so we can help developers in this as well.
  • What other projects are running; this is not exactly technical or has anything to do with coding, but knowing this, we as testers might find risks of mismatching or upcoming problems developers did not think about. For example; if one projects is working in .net, another is in COBOL and these have to be integrated.....do I need to say more....
 I could go on and on, but I think I’ll leave it at this for the moment. The point is made….

So in a nutshell of what has been written above, 

"Testers should be focusing more on the technical side in order to get the correct balance between technique and business"

 

Comments

  1. Afaq AliJuly 26, 2010 at 2:58 AM

    Great direction !

    To add a little more to it ... the testers should peruse all the related documents and should be aware of all the 'revision history' made in them, especially the FRS ... it does add a star in your vigilance as a tester. Nevertheless,liked your personal opinion, the most :)

    ReplyDelete

Post a Comment

Popular posts from this blog

Multitasking causes further delays in projects ( a logical deduction?)

Image
Multitasking, which is defined as simultaneously working on multiple tasks , exacts a horrible toll on productivity ! Clark and Wheelwright (1993) studied the effects of multitasking and found that the time an individual spends on value-adding work drops rapidly when the individual is working on more than two tasks. (some people are immune to this like Spock ( then again the vulcans will argue that this is illogical ), Robocop , Data , Jamie Madrox (well he can duplicate himself so its not exactly multitasking : P ) etc...) Logically, it makes sense that multitasking helps when you have two things to work on. With two value-adding tasks, if you become blocked on one you can switch to the other. It is also logical that the above figure shows a rapid decline in time spent on value-adding tasks after a second task. We’re rarely blocked on more than one task at a time; and, if working on three or more concurrent tasks, the time spent switching among them becomes a much more tangib
Click for More >>>

People who switch from process based to non-process based organizations

Ok, first off, as per the title, non-process based organizations mean companies, concerns etc that do not FOLLOW completely/partially a specific lifecycle for something. They also include such establishments that " advertise " that they have a so & so certification and/or they have such & such SOPs but when it comes down to the hard reality of it, they choose to ignore them. Definition done. Now, there are major establishments that actually do what they are supposed to do in terms of following a software development lifecycle as well as adapting their own operating procedures to best suit their work and make continuous improvements to cater existing issues as well as future prospects.  In my geographical location (country wise), these are normally big companies which have been running since way before I was born and some which sprouted up recently. Some have tons of employees, some have enough to form a football team, some don't even have that but what the
Click for More >>>

I love it when a plan comes together --- what the heck is planning?

Image
 “Planning is everything. Plans are nothing.” Estimating and planning are critical to the success of any software development project of any size or consequence. Plans guide our investment decisions: we might initiate a specific project if we estimate it to take six months and $1 million but would reject the same project if we thought it would take two years and $4 million. Plans help us know who needs to be available to work on a project during a given period. Plans help us know if a project is on track to deliver the functionality that users need and expect. Without plans we open our projects to any number of problems.  (I bet everybody knows this already) Yet, planning is difficult and plans are often (more or less) wrong . Teams often respond to this by going to one of two extremes: they either do no planning at all or they put so much effort into their plans that they become convinced that the plans must be right and anything done, even slightly, not as per plan is taken a
Click for More >>>