Changing the tester DNA -From tester to Software Development Engineer in Test (SDET)

Bernd Bornhausen, Senior Manager QA, TD Insurance [NYSE: TD]

Bernd Bornhausen, Senior Manager QA, TD Insurance [NYSE: TD]

The roles of testers in enterprises are well defined and embedded in enterprise wide policies and frameworks. Based on the background of the resources or the type of testing they are most knowledgeable of, testers are divided into different teams or departments per role having different responsibilities or authorities: system integration testing, business or user acceptance testing, functional test automation, API automation. These departments were created under the cover of “segregation of duty” or “for audit reasons”. Interestingly enough, unit testing has been assigned to the development team which in turn might have led to not focusing on unit tests when talking about quality insurance. Inadequate unit test coverage is the result of this and a deep divide between development departments and test departments. Attributable in part to the above-mentioned separation but also to the fact that resources for the functional and business tester role have been recruited from the ranks of application support agents or business users, technical skill set within these test teams got diluted or even eliminated.

Today’s appetite for a quick time to market, frequent changes while not compromising on quality has the test department managers facing a dilemma in how to deal with this: on the one hand they cannot afford to lose the application knowledge gathered over years within the department, on the other hand they must satisfy the need for technical resources. To solve this dilemma, we must create awareness and willingness within the test team to build new skill sets or to rebuild what has been lost over the last couple of years. The first step is to describe the target state. Listing all desired skills of the future test resources along with a desired depth of skill. The next step is a capability assessment focusing on the desired technical skill set compared to the target state. The resulting GAP analysis is the basis for a role-based training map for test resources. Not only could resource managers better describe their training needs to upper management but also each individual tester would be enabled to build a personalized development plan based on this map giving him more flexibility in his development while satisfying the overall need.

The Manager Responsible For The Quality Assurance Has To Ensure That The Testers Have The Right Skills. With Agile And Devops In Mind, Automation Skills Are The First To Surface

The above-mentioned orientation of companies promotes the adaptation of Agile and DevOps practices within the enterprise resulting in a change how test resources are organized. Needed skill sets do not change whether you chose to organize using a centralized, a decentralized or a hybrid organization with applications, projects or products in mind: The manager responsible for the quality assurance has to ensure that the testers have the right skills. With Agile and DevOps in mind, automation skills are the first to surface. Programming skills like Java or Python, tool-oriented skills like Selenium, REST-assured or any other tool used in the organization are the ones to follow.

Getting existing test resources trained on these skills highly depends on the background of each resource and the willingness to learn something new. A good approach to this is to staff any new position with an external resource possessing already these skills. Forming of lunch and learn groups and job shadowing helps to build up the knowledge within the existing test resources. In case the existing test resources do not possess programming know how, the learning curve and effort is much steeper. Formal training coupled with online courses jump starts the development; best progress will be achieved when the resources develop the appetite to invest their own free time on top of the company provided training.

Programming skills alone will not help the team to thrive. If the resources learned their testing skills on the job at the time they were recruited from their business or support positions, it is now a good time to include testing related training; hopefully the concepts of equivalence class partitioning and boundary analysis are not completely new to the team as often these techniques are used without knowing the official name. Building on these, more advanced techniques are to be trained or refreshed: pair wise testing, state transition or path coverage to name just a few. Non-technical testers are attracted by Black-box testing techniques as these are more UI focused and the application is easier. White-box testing techniques on the other hand are far more complicated to teach to non-technical testers. With the overall shift from manual to more automation these techniques are the ones the manager wants to focus on. Knowledge in white-box techniques coupled with programming skills will allow the test resources to work together with the development resources on increasing the coverage and quality of unit tests. The combined knowledge allows to implement DevOps best practices and tools. Shift-left is a term commonly used nowadays to help describe this approach: bringing testing closer to the start of the development life cycle. To avoid a common mistake and only focus on bringing testing and development closer together, training on approaches like Behavior Driven Development (BDD), Test Driven Development (TDD) or Acceptance Test Driven Development (ATDD) should also be considered to include the business side as soon as possible. Using a common language like Gherkin for all three of these approaches helps to bring business, development and testing together to form one team with quality in mind.