Few more thoughts resulting in a bit more of gyan --- "Technical Tester"... This seems to be the buzzword going around. I have heard countless teams and managers complain that their test team is not technical enough and every one feels the need to build that bit of "technology awareness" to create technical testing teams.
Well, at the outset, if I am to have a bird's eye view of the large picture - today's Indian engineering colleges manufacture graduates and while half of them end-up as developers, the other half ends up as testers. Today's project management world has effectively created the abillity to classify each member of the project team as a developer or a tester. (Though the Business Analyst, Architect, Project Managers are also a part exist in the team --- they are
mostly looked more as developers or testers for a most part of the project).
Now, I dont see anyone asking around for a "technical developer" (while everyone are looking around for a "technical tester"). To share with you, a few bits from my memory on my perception of a technical tester and as to why this problem is so much prevelant in today's world....
I truly believe that the prime fuelling factor for launching the birth of the requirement of a "technical tester" is the present lack of Technical Developers in today's world.
Though most of you might not agree with me on this, and the statement can become highly controversial, I believe that our search should also be for a "technical developer". To understand more on this, let us try to see what we want "ready-to-test" code to accomplish and what it actually accomplishes, in most of the cases today.
What does "ready-to-test" code expected to accomplish?
A few points that come to mind immedieately are as follows:-
1) Ensure that the current requirements are met.
2) Ensure long term scalability
3) Meet all security conditions, so that the code cannot be hacked
4) Ensure that all security breakages that the technology cannot do is done by the sourcecode
5) Ensure good performance of the source code
6) Meet the obvious boundary and negative test conditions
7) Ensure that there is no existing feature that is broken
8) If any reusable component has been built and can be used for the solution, ensure that this component is consumed by this solution - Ensure that the wheel is not re-invented.
9) Effective usage of logs for logging appropriate errors
10) Good exception handling techniques for error handling
11) Good coding techniques to handle deadlocks, (wherever applicable)
12) Effective usage of the programming language (for example, in .NET, usage of the string class for string concatenation instead of the + operator)
But in reality, What does today's "ready-to-test" code available for the testers actually accomplish?
In most of the cases, the source code would just meet the business requirement. Most of the other issues would be swept under the carpet and will not be available in the first build that is available for the testing team. The problem statement is that today's "ready-to-test" code that is made available for testing does not even attempt to fix most of the other problems.
Looking at the above, I am of the opinion that more than 75% of today's developer community write code to fix the business problem, without worrying too much about security conditions, performance, scalability of the application to grow over time, writing code for the satisfying simple memory management requirements, or even satisfy the simplest of negative test conditions. Today's developer community have complete lack of understanding of an operating
system, how the programming language interacts with the operating system and about other features of memory management.
But, surprise surprise!!! the tag of a "non-technical developer" is not bestowed on them mainly because of today's critical project deadlines, and the beautiful ability of our project management teams to turn a blind eye to all these attributes that cannot be seen. If the code solves the problem, it is given to the test team as "ready-to-test" code.
What happens when this code is available for our tester?
Now, the tester, sharing the same background as the developer (he would also have been from the same college or training institution), and with the same knowledge as the developer, will turn a blind eye of not testing these conditions that cannot be seen. Now, when some client or user sees some such condition as above, they term that the test team is not technical enough and the entire project management team starts their focus on the technology training of the testing team, whereas the problem to be solved lies elsewhere.
What is a Technical Tester?
Few more on my thoughts below on what is a technical tester...
1) Just a normal tester - There is no thing as a technical tester. What we mean by a technical tester is a true test practitioner who understand both the business and hte technology.
2) Someone who understands the business context and the domain - It is very important for the tester to undertstand the business domain of the project. He also needs to understand the business context. What is the business context? That is the fundamental reason as to why the project is being executed in the 1st place. When the business context is understood, that will go a big way in prioritizing his list of test cases.
3) Someone who understands the technology - It is very important for the tester to understand the technology on which the business solution is being built. Every technology has a lot of advantages and dis-advantages. For example, a solution built on the Microsoft .NET platform need not be tested for memory management (since the technology takes care of most of memory management), while the tester would need to write scripts to test software built on a pre-.NET platform for memory management. The tester needs to understand the technology, and write effective test cases to ensure that the software code also closes any gaps which are still unplugged in the technology, apart from cases to test the solution.
4) Ability to write code for testing - A true technical tester would understand the different ways available to test the software. He would not rely just on the UI needs, but will also be able to write simple code to test the application.
5) Ability to breach security - Now, I am not saying about his ability to breach the networking security layers. But this is more about his ability to breach the security holes offered by lack of coding in the source code. A technical tester would be able to go through the source code, have a good understanding of the programming language and should be able to design test cases to break this.
To summarize, we would need to re-look at our habit of labelling anyone who talks very minimal technology as a "technical tester". The ability to Google has made it possible for anyone to google for a few terms, churn out a lot of gyan such as "SQL Injection testing", "Cross-site scripting", etc. and get the label of a "technical tester", whereas in reality, it takes much more than that and one who has the ability to understand the technology and domain, and then structure his test cases and "type of testing" accordingly would be 100% deserving of the label of a "true technical tester". Everyone else, who has ever tested a software product during their time on our planet, have every right to call themselves as the "Fake Technical Tester!!!". Happy Reading!!!!!
No comments:
Post a Comment