Agile and The Role of Test Engineers - Part 2



In my previous post I shared my thoughts on the role of test engineers in agile projects. How can test engineers - who have no experience in agile methods, start working in agile teams? What makes them successful? What enables this transition? Is it easy or hard? These are the questions many of us have in mind.

Two Key Factors
How easy or difficult it is to enable test engineers play this role in agile projects depends on their potential and drive. Factors such as knowledge, skills, competency, etc. determine the potential of test engineers whereas factors such as motivation, enthusiasm, courage, commitment, focus etc. determine the drive in them to accomplish something. With potential and drive as two primary dimensions we get to understand four categories of test engineers. In fact, this classification can be extended to any profession that involves knowledge workers.

High Drive - High Potential
Engineers in this quadrant are ‘Passionate Achievers’. In our context, they are passionate on software testing. They learn and share. They experiment and explore. They are equally motivated about manual testing and test automation. They write excellent manual test cases. Also, they gain expertise in test automation. With experience, they become subject matter experts and consultants.

High Drive – Low Potential
This quadrant is known for ‘Position Takers’. With varying degree of potential from medium to low, they take their position according to market trends. They learn just-enough to catch up with the buzz. They are not driven by their passion to learn new tools, scripting languages and testing techniques. They go behind opportunities. Often, their ideas are not original. Most testers in this category are salaried workers or contractors. The do what is barely sufficient to retain their jobs.

Low Drive – High Potential
Low drive and high potential team members are ‘Passive Followers’. They are laidback and unenthusiastic. Meanwhile, they do not stagnate but continue to remain laggards. They learn new things when there is a big push. Many of them are manual testers however they are not self-led to learn test automation. In most cases they have the capability to self-learn. However, they need a clear road map and support for learning new things. Also, they expect returns before they learn and experiment.

Low Drive – Low Potential
Test engineers in this quadrant are ‘Petrified Checkers’. They may have good experience in manual test execution. However, most of them do checking rather than testing. They are petrified or scared to learn new tools, scripting languages and techniques. Most of them chose testing as their career because they wanted to avoid coding. They do not learn new things in spite of adequate support and push. They are good workers who can contribute to sustaining end-of-life applications and products. They are complacent in their current competency and role.

Testers in the first quadrant (High-High) fit in very well whereas testers in the second and third (High-Low or Low-High) need some counseling, training and support to transition. Testers in the last quadrant (Low-Low) find it very difficult or challenging. They seldom make themselves a good fit in agile teams.

What do you think?

Agile and The Role of Test Engineers - Part 1



What is the role of test engineers in agile software development? Many experts have spoken and written about the need for test engineers in projects that follow agile methods. We need test engineers in agile projects and it is worth discussing their role. The role of test engineer in agile world is different from their role in traditional world. It is no longer a role that remained relevant in the past.

The Role
Test engineers are part of agile development from the very first iteration. What do they do differently? They participate in iteration planning (or sprint planning in case of Scrum) and ask questions to clarify requirements. They participate in estimation.

They create test data. They work with developers in connecting with all possible test scenarios. They review code when it is needed. They do exploratory testing.

They do not wait for all stories to meet the definition of done. They test every build. The do it from all directions and stop testing only when they are unable to proceed. In other words, they do not work in silos. They do not run a predetermined set of test cases and raise a red flag when majority of them fail.

They become close associates and supporters of developers. They don’t find fault and go to business users without collaborating with developers.

They are no longer manual testers. They contribute to test automation. They are script developers. They don’t limit to consuming requirements and translating them to test cases. They go beyond that limit by asking relevant questions. They anticipate risks and bring them to table for discussions.

They are no longer focused only on processes to complete testing activities. They are collaborators and have the intelligence to customize processes in order to deliver value to stake holders. They don’t limit their work arena to functional testing or integration testing. They think about all forms and types of testing found in Brian Marick’s agile testing matrix.

They don’t hesitate to fix few defects when there is crisis as they are prepared to go beyond the call of duty. When we have test engineers with these qualities, yes, we need them in teams that follow agile methods.

More Info
A detailed discussion on this topic is available in a white paper titled ‘Agility for Testers’ written by Elizabeth Hendrickson. Happy reading!

Questions
How can test engineers - who have no experience in agile methods, start working in agile teams? What makes them successful?  What enables this transition? Is it easy or hard?  In the next part of this blog, I have shared the two key factors that determine the ease of transition.