ABSTRACT: Do you consider Testing a profession? This paper explores what attributes make a professional tester, and consider what we can do to help promote this.
The Test Professional
I regularly hear this question and I’ll start by stating I absolutely believe it that testing is a profession, and I do indeed consider myself a professional. Anyone who knows me would realise that I have very high standards for myself and believe that the bar should be set high. At the same time I do, however, acknowledge the fact that there are many testers, junior and senior ranks included, for whom the term “Professional” is a very loose interpretation.
On reflecting over history and thinking about which events helped and or hindered the advancement of the concept of a “testing professional”, the single most detrimental event for the professionalism of testing was Y2K. It seemed that anyone, from any walk of life, could effortlessly jump on the money-spinning event, which seemed to epitomise the flurry of activity to prevent a seemingly likely catastrophe, while earning a lot of money. Most people in those days quite frankly had no idea about how to test. Although a lot of those have since left testing, there are some that still remain, broadly grouped together under the ubiquitous term of User Acceptance testers.
So, what is a Testing Professional? What attributes, behaviours and skills should they possess?
First and foremost they need to be able to communicate, both verbally and in writing. Most of what a “tester” (I use the term tester generically, regardless of seniority or role, who participate and complete testing related activities) does is to communicate, but more importantly it is how effective they perform that communication.
From the very first engagement they need to talk to stakeholders to “flush out” and understand, frequently poorly written or non-existent requirements. Sitting quietly in a requirements walk-through, may or maybe not be appropriate, depending on the situation, but walking out of that walkthrough without pages of questions for clarification tells me that you’ve just wasted your time and that of your employer. The ability to be able to articulate those questions meaningfully and to the point, back to the relevant stakeholders is a critical success factor for a tester.
The ability to review test input documentation during static testing to provide quality feedback is a very different skill to just “reading it”, which unfortunately is how more testers interpret the concept of a review. The review process is a constant and consistent activity, which continues through planning, test analysis and design; and execution. The skill required to log defects clearly so the problem is clearly identified, understood and more importantly how to clearly reproduce it (if indeed it is a reproducible defect) are critical skills.
During any testing project the art of reporting, is just that, an art, akin to a skill in which the tester knows, what information their stakeholders wants to know and can deliver it in a clear and concise way. A tester needs to be able to know what’s important and have clear understanding of what is important to their stakeholders. This is the fundamental skill of being able to identify and highlight the testing product and project risks, including stating the residual risks throughout, and at the end of testing.
A tester must understand that their role is to provide information for others that present the relevant facts about the product quality so that the stakeholders can make a judgement on whether the product can be shipped. To my way of thinking articulating the number of test cases complete and defects found does not give the Business a feel for the quality of the product. Instead we should be reporting coverage to requirements which have been annotated with their value by the Business.
This is slightly different when using Agile methodologies, where the whole team has accountability for quality, not just the person considered to have the skills in software testing. Irrespective of methodology, framework or test process, testers require professionalism.
Investigation and Analysis – The 5 Whys
We have frequently heard the term, “to have a dog with a bone mentality”, loosely interpreted is once they have they bone they don’t let go! For a tester, this means, if they see something that does not look right then they need to look deeper. Look at areas around or connected to the issue and make sure they understand the extent of it before starting to log a defect. Often other project members will try to deflect their activities. Maybe the Project manager suggesting that they need to get through more test cases for example, but they need to keep investigating. We all know that if there is one defect in some functionality or area of the system, then there will likely to be others “lurking” nearby. Understanding defect clustering is one of the tester’s best tools.
But while exploring is an effective technique, you also need to know when to stop and move on to testing the next piece of functionality. Testing coverage is also an important consideration and key risk mitigation strategy. It is critical that testers know how to apply the correct testing technique to produce maximum coverage with minimum testing. We all know that it is impossible to test everything.
As you progress in your career you seem to develop an instinctive knowledge of where a defect will be. I can pretty much find a defect within the first five minutes of starting to test whether it be in a document or a piece of code. Of course this is not just magic; it comes from years of experience and building up your own personal defect taxonomy which is something that is continuously updated. Not only do I do this from my own experience but also from discussions with colleagues through sharing of experiences.
Linked to this is an analytical mind. The ability to follow a path through to its conclusion by executing each possible scenario and sometimes even those that you think are impossible (which are practical within the parameters you have to work in). The s kill of a good tester is one that can create the right set of test artefacts irrespective of domain knowledge. The debate on whether you do or don’t need domain knowledge should be less important than the question of whether you are able to read a set of test input documents and derive tests from these. Even more important, if these input documents are not of sufficient quality to enable test cases to be derived, then you must be able to derive a list of meaningful questions to gain further information. Domain knowledge can be an inhibitor to the analytical mind, as it predisposes you to make assumptions that 80% of the time you haven’t even realised you’ve made. A mix of both on the team, I find to be the most effective.
A practical application of testing techniques is a mandatory skill, not an optional one that seems to be more frequently the case. There are far more test techniques available then simple boundary value analysis (BVA). Everyone in testing knows that you cannot test everything. The right technique applied in the context of the requirement is going to make the testers both more efficient and more effective, creating better quality tests then simply applying the same technique over and over.
It is amazing the numbers of testers I see that do not even have a basic grasp of the available techniques, for example, I would advocate the use of at least some exploratory techniques even if working within a traditional project. When analysing and designing tests, there also needs to be some consideration as to how long you will have to execute these tests. So many times when I am performing a Test Process Improvement review, I see hundreds of tests that have been written, but were never likely to get executed. In Lean methodologies this is considered wastage. More
important, it’s a large waste of time and money! Many of them when you really review them critically, are duplicates or very low value tests. Prioritisation even during test preparation is important.
Time management and planning
Critical to a tester is the skill of time management and planning. Whilst the Test manager should be competent enough to defend their estimates and therefore their plan we all know that projects slip and it is of ten the testers, particularly during execution, that are asked to get the project back on track. Testers need the ability to make considered changes to their plan daily as priorities change, new information is understood or defects block further testing. We cannot test everything in full, so we need to understand what we can test and more importantly, be able to estimate how long it is going to take?
Finally I want to raise the topic of certificate which seems to be creating a lot of discussion at the moment. I do a lot of work on various ISTQB and ANZTB (my local board) committees. Whilst there are things that I would like to see improved, certification is one benchmark that can be used to start a conversation. No decent hiring test professional would use this as the only indicator of skill and competency. When hiring, there is a need to review CVs and match the candidates to the specific requirements of the role. The certification simply indicates that the tester should have a minimum level of knowledge, which I can use as the basis to start asking questions. The certification creates an expectation of the knowledge they should have from gaining that qualification. Being conversant with the certification and it’s expected levels of knowledge and understanding, I can quickly assess if they have understood the learning and are able to apply this in a practical situation or have just learnt it parrot fashion with no real understanding of how to apply it. There is no substitute for varied roles and learning whilst on the job however, certification does indicate some willingness to want to improve.
In conclusion I believe that testing is a very rewarding profession where there is plenty of opportunity for continuous improvement and career development. With on the job training, the vast amount of information available online, and generally readily accessible local user testing groups, a tester should have no excuse not to be increasing their knowledge throughout their entire career. Who wouldn’t want a job where they get paid to break things every day!
I would encourage testers to put back into the community in which they work. Share your knowledge, offer to mentor, or find some way in which to contribute. There are plenty of opportunities to write Whitepapers and present them, submit articles, enter into conversations (blogs are useful if you cannot do it in person), or offer to help on Testing Bodies. If testing wants to be considered a Profession, then we need to act with integrity, present a united and consistent community, in which diversity of experience breathes into our profession, that grows through a shared goal to be professional.