The general characteristics identified for a Technical Tester were:
• Understanding code and how software is built – the ability to look inside the system and not restricted to a black box view of it.
• Strong knowledge of test tool sets.
• Excellent understanding of test techniques and standards. A particular ability in exploratory testing was highlighted as important.
• Some domain knowledge. The domain knowledge included both the business and technology.
• Ability to write good code, particularly frameworks and “tool smith” activities
• Teach/train/coach developers to test.
• Focus on the functional testing aspects.
In summary, the general description seemed to be:
I’m a super genius functional tester!
The group was challenged with the notion of what “values” this person should have (see Kent Bech). This was not defined in the group, but worth considering as a future discussion.
The group indicated that although all of this would be in the “ideal” technical tester, real people would have a mix of these skills in varying degrees. It was noted that the following roles were also complimentary and important with an Agile team:
• Business Domain Specialist Tester: Someone who has a very strong understanding of the domain, particularly a business one. For example this would be some who really understands derivatives trading and the legislation impacting it.
• Technology Domain/Non-functional/Quality Characteristics Specialist Tester: These people would be your Usability, Security, Performance etc. specialists. These people would be from a more scientific / engineering background, with specific technical knowledge.
• Requirements Tester: In the past this would have been known as a Test Analyst. This is a person who would take requirements and deconstruct them into efficient and effective tests. Discussion include the efficiency saving that these people could bring in optimizing the number of tests that would then need to be automated.
• Bug Sniffers: The group described this as “Those people that are just great at finding defects”. Typically this was considered by the group to be people from the business, brought in to “have a go” and good a finding those unusual defeats.
• Exploratory Testers: Specialist testers with strong exploratory testing approach knowledge and practice.
The session then moved onto discussing some of the blockers to performing technical testing. The following points were made:
• Organisation Culture: The culture of the organisation prevents some of the techniques required to be implemented. This includes for example, developers not wanting to sit near testers, not valuing testing, etc.
• Definition of technical: The term technical is used in different ways and a lack of clear understanding of the term prevents the use of the characteristics. This session proved useful in assisting everyone to clarify their own understanding.
• Lack of skills: The people in the organisation do not have the required ability to implement some of the technical skills. The discussion covered such ideas as the need for some organisations to replace existing staff with people with these capabilities, if people were not prepared to retrain.
• Lack of awareness: Teams and organisations do not realise that in changing to a more Agile approach that the skills and characteristics that the staff need to exhibit are different.
• Project in permanent Tactical Mode: The team are continually “sprinting” and have no time to investigate new techniques and technologies that would enable the development process to move out of a tactical mode.
• Cost: Technical testing requires people with significant skills and this costs more.
• Quality: Many organisations work to an unstated quality level. This impacts the work that an Agile team would work to, but by not being explicit this can be misunderstood. The other aspect is that for some organisations, it is cheaper to fix post “go-live”.
The group made a strong distinction between the noun and verb for Technical. The noun applied to a person and the traits that we expect from them. The verb applied to a variety of testing to be run. A major outcome of the session was that:
“You cannot ‘do’ Agile without Technical Testing”
However this does not necessarily mean that you need a Technical Tester. As long as you have a team that can cover the characteristics identified above for a Technical Tester. Anyone within an Agile team can deliver the results of these characteristics. The other factor that was clearly identified was that the context of the project was critical as to what “technical” means to the team.
I ran a session at the Test Managers Forum (31 July 2013) in London. The session was constructed as a discussion forum to understand what the group of senior test practitioners who were delivering in real situations, viewed the technical testing. The group consists of approximately 45 people and the discussion was run over a 75 minutes session. The slides for the session are available here: