Monday 9 March 2015

The role of testers in an agile environment

A version of this article was originally published on StickyMinds website in November 2014 - http://www.stickyminds.com/article/role-testers-agile-environment.  This article is the full unedited version of the article.

In my experience there is a common drive to move towards an Agile (http://agilemanifesto.org/) software development framework.  As with any change in the way people are asked to work there is much confusion and for some a little bit of fear.  People are being asked to step out of their comfort zone and embrace a constantly changing, dynamic way of working. One role within the agile world that has been pushed back and forth is the testing role.


What do think the role of a test is?

A quick unscientific search of the internet returned the following roles:


As can be seen from the search results a wide and diverse range of roles are returned from searching for such a simple set of words as “tester role”.  My thoughts are that there could be a connection between the misunderstanding of what agile means to testers and the confusion as to where testers ‘fit’ in agile development teams.  The purpose of this article to look at the problems of ‘confusion and fitting in’ that testers appear to be facing at the same time offer suggestions that may be of use to testers in dealing with their confusion.

I would like to start with a look at why there appears to be some fear and a little distrust of agile, from my experiences, amongst some testers.

Some of the headlines I have seen over the years which state there is no need for testers within agile teams, or that a developer can do the role of a tester in agile teams, or that testers slow down agile because they come at the end of the process could be a source of problems testers appear to face.
For example headlines such as:

There have been many questions both within the testing and agile communities. Is there a need for testers in agile environments? One of the key concepts of agile and developing quickly is the need to have automation in place; therefore there is more of a need for coders to create the automation than there is for testers to manually test the system.  Lately there have been many discussions regarding the question that testers should (Or MUST) learn code.

To counter this, James Bach comment to the article above suggests there is more for testers to do than only learn code:

His brother does not know code nor does he wish to but he is the Director of testing at EBay.  He has other skills that are important for testing. 

Testing has traditional been seen at the end of software development (waterfall -
http://en.wikipedia.org/wiki/Waterfall_model) with the responsibility of:

  • Proving the requirements are met,
  •  Ensuring that it works (checklist)
  •   Finding bugs
The agile manifesto states (http://agilemanifesto.org/)

·        Individuals and interactions over processes and tools

What this means for testers is that there is a need to act as a member of the team and to engage with others within the team regardless of the title you or others possess.  If you see a task that needs doing and you have the skills to do that task, then just do it.

Agile means you are part of the team and should try to be involved from the beginning of the project. It will necessitate having the ability to switch context and ‘hats’ during the life-cycle of the project.  I will look at some of these roles, and how you as a tester, can be involved to support and assist the team. 

The following are only a few examples of the inexhaustible number of roles you could be taking on.

Test Architect

“While the system requirements/user stories are being captured and discussed testers should try and ensure they are in on these design discussions.”
Chapter 12 – Explore It – Elizabeth Hendrickson

Testing does not start with execution of the application. It starts at the beginning of the project during the design phase. There are many occasions where testers appear to be excluded from design meeting. The reason why this appears to happen maybe unintentional but could be because traditionally testers have been missed off the invite list for these design meetings.  If this is the case for you then as a tester you should try and find ways to be included.  These meetings are useful to find out what design decisions are being made and most importantly where the team feels there could be some concerns or complications.  These are great opportunities for testers to pick up on and make notes off, since these areas of ambiguity could be excellent sources of information.  With these snippets of information you can start to model the system and create some initial ideas that you may want to explore once the system is available for testing.  A mind map is a great way to model the system and your initial ideas.  Those areas of concern could become areas that need some careful exploration. 

During the meeting you should be ready to ask “What if…” type of questions.  An example being:

‘What if a user did this? ‘
 Or

‘What if this component is not available?’

Whilst design discussions are happening you should try to create a model of what you think the system will look like.  If you find yourself being confused about the information being presented or you feel something does not appear right then this is the moment to ask questions to clarify.  The answers you get could be useful for noting as areas to explore at a later date. Offer suggestions for how if things are completed in a certain way it would be easier to test, look for ways to make the system design testable. 

Consider from the information provided what could be checks and make a note of possible automation tasks. It would be worthwhile starting to write down ideas for automation such as suggesting unit tests or acceptance tests that could check the design ideas put forward. 

If there are areas with uncertainty, such as to how it could or will be implemented, this would be a great area for you to explore once developed. It is recommended to make a note and maybe create a test charter (Charters will be discussed in more detail later) in your test plan using the previously mentioned mind map.

Test Automator
It is important to point out that to be a test automator does not require the need to write code or be a skilled programmer.  Knowing how to write code might be a useful skill to have if you feel it will benefit the team, perhaps it is something you could look at learning if you have an interest.  Alternatively if you do not have an interest in learning to code it would be a good idea to at least try to learn the syntax of code. This does not require you to be able to write code but being to read it could be useful skill to have within the context of the agile team. 

Some of the framework used extensively for test automation use English phrases and words.  Some example frameworks include


The frameworks follow similar approaches for creating automation, the code is written as glue to support the scenarios, which are written in English. Who writes the code and who writes the scenarios is not defined in agile environments, anyone with the skills can contribute to that task to get it ‘Done’.

For cucumber the scenarios are created in the following format:

·        Given: - The purpose of given is to put the system in a known state
·        When: The purpose of When steps is to describe the key action
·        Then: The purpose of Then steps is to observe outcomes

If you have multiple ‘given’,’ when’ and ‘then’ you can use ‘and’ and ‘but’
For example:

  Scenario: Multiple Givens
    Given one thing
      And another thing
      And yet another thing
    When I open my eyes
    Then I see something
      But I don't see something else
These step definitions can be written in many different programming languages such as Python or Java and the level required to write these types of definitions is not too intense and based on JUnit (https://github.com/junit-team/junit/wiki ) (if using Java).

For example:
Scenario: Some cukes
Given I have 48 cukes in my belly

Glue code would be
        @Given("I have (\\d+) cukes in my belly")
        public void I_have_cukes_in_my_belly(int cukes) {
        // Do something with the cukes
        }

More information about step definitions can be found here: http://cukes.info/step-definitions.html

If you feel you want to learn code from a testing perspective I recommend the excellent book by Alan Richardson – Java for Testers (https://leanpub.com/javaForTesters)

If you do not have any desire to write code you could support the team by looking at what could be created as a unit test (such as limits and boundaries that have been defined) and ensuring that these are given to someone on the team who can code these unit tests.  This could be something as simple as putting together a spreadsheet listing all your unit test ideas and getting this reviewed within the team. 

If you find you have an interest then only one more step to writing some JUnit assertions (https://github.com/junit-team/junit/wiki/Assertions

Example use of assertions
@Test
 public void testAssertions() {
 //test data
 String str1 = new String ("abc");
 String str2 = new String ("abc");
 String str3 = null;
 String str4 = "abc";
 String str5 = "abc";
 int val1 = 5;
 int val2 = 6;
 String[] expectedArray = {"one", "two", "three"};
 String[] resultArray = {"one", "two", "three"};
  //Check that two objects are equal
 assertEquals(str1, str2);
  //Check that a condition is true
 assertTrue (val1 < val2);
  //Check that a condition is false
 assertFalse(val1 > val2);
  //Check that an object isn't null
 assertNotNull(str1);
  //Check that an object is null
 assertNull(str3);
  //Check if two object references point to the same object
 assertSame(str4,str5);
  //Check if two object references not point to the same object
 assertNotSame(str1,str3);
  //Check whether two arrays are equal to each other.
 assertArrayEquals(expectedArray, resultArray);
 }
}

If you want to learn more about JUnit then there is a free tutorial pdf document available here: - http://www.tutorialspoint.com/junit/junit_tutorial.pdf

Test explorer

Within Agile environments there is a limited amount of time for testers to test manually, it is critical that their time is used wisely. Testers should not be spending their time ‘checking’ the system manually based upon what they already know or expect of the application, this should be automated,. Testers should be trying to uncover the unexpected, looking for interesting items that could provide useful information to others within the team.  This does not mean following scripts or check lists, more a case of using the information gained from being involved in the design discussions and from communicating with others within the team.  Using this information to uncover where there is ambiguity in the system or areas where people have raised concerns or questions.  These are strong indications that there could be issues that are as yet uncovered in these areas.
Testers when exploring need to be observant, taking note of interesting items and future questions.  Being an explorer is about mapping the system as you go and then re-assessing your voyage as you discover exciting and interesting bits of information.   As testers we need to uncover assumptions and incorrect or missing information.  Mostly importantly we need to find out what it actually does rather than what we believe it does or how it has been documented to behave.

This does not mean that we should approach this in a random, unplanned or unstructured way.  Being an explorer means you do need to have a plan.  Your plan does not have to be in too much detail but just enough to get you started.  As you uncover more about the system you update your plan with the new evidence you have, your exploring should be structured and chartered.

Example charter format
Explore
 with
 to discover        
Explore it – Elizabeth Hendrickson http://pragprog.com/book/ehxta/explore-it

To aid your management of testing you can  use session based test management - http://www.satisfice.com/sbtm/ in which each charter becomes a session which is then used to help estimate and track what has or is planned to be done.  This works well in agile environments and can be a useful tool if using Kanban style boards. (http://en.wikipedia.org/wiki/Kanban_(development))

We have given this section a title of test explorer; however it does not mean that this is the only role they perform when exploring.  As a tester in an agile environment there is a need to be able to switch hats from planner, to designer, to manager, to tester, to explorer and so on.  The definition of exploratory testing, as defined by James Bach, helps to make sense of these different roles when we actual do some testing:

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution.
James Bach - Exploratory Testing Explained – 4/16/03

Test reporter

One of the tasks I feel is most overlooked within agile development is the sharing of information and knowledge.  From a testing perspective it is normally simplified down to a set of irrelevant metrics of pass or fail, test cases run or not run and how many are left to run.

Agile is about defining what is done within the context at that time.  The tester should be reporting useful and valuable information such as:

  • Issues or bugs they have uncovered.
  • Areas of concern or stuff that could block them from doing more testing. 
This is only a small example and there are much more that a tester should be reporting. To enable this type of reporting the tester needs to be communicating as much as possible with the rest of the team, keeping them informed of what they have found.  A great indication of a good test reporter is when it comes to scrum meeting there are no surprises from testing for the rest of the team, since the tester has already had conversations with others on the team.

Normally these conversations are about clarifying assumptions and ambiguity or confirming it is a defect before raising it on the bug tracking system.  The tester in these situations needs to be:

  •  a salesperson (to sell the defect)
  •  a negotiator (to get things done and change the priority)
  •  a user (to see things from the customer/user perspective)
  •  a journalist (able to record the facts and only the facts)
  •  an investigator (are we sure we have all the evidence, is the evidence correct)
  • a scientist (does my evidence match my theories?  If not do I need to adjust my theories?)
  •  a psychologist (have the ability to under the biases that others in the team have and make the team aware of them)
There are many other roles that a tester could do within the reporting side of testing but again that is not important, since it is the fact that the tester is there to support and help the team no matter what the task may be.

It is vital when reporting that the tester does not fall into the publishing of graphs and pretty pictures bias.  In agile environments it is important to notice and investigate trends so gathering metrics over the term for a single project is useful but trying to compare project like for like is dangerous since there are too many variables team dynamics to be able to do a fair comparison. So when reporting testing it is better to tell the story about what has and has not been tested and based it upon what you have uncovered.

Conclusion

The purpose of a tester in agile environments is about:

“Getting things done rather than roles”

As a tester you should try and act as a service to the project and ask yourself:

“What can you do that is best for the team or for the project?”

There are many other roles that a tester carries out during testing, such as acting as a coach, or mentoring others within the team.  A service provider both within and outside the team, a sage or confidant and a person who is willing to listen as well as challenge others for the benefit of the team.

One useful list to use is the 10 principles of testers from the Lisa Crispin and Janet Gregory book - Agile Testing: A Practical Guide for Testers and Agile Teams - http://www.amazon.co.uk/Agile-Testing-Practical-Addison-Wesley-ebook/dp/B001QL5N4K

  • Provide continuous feedback.
  • Deliver value to the customer.
  • Enable face-to-face communication.
  • Have courage.
  • Keep it simple.
  • Practice continuous improvement.
  • Respond to change.
  • Self-organize.
  •  Focus on people.
  •  Enjoy.
How many different roles can you see for testers in this list of ten principles?

To conclude:

  • Look for ways to show how testing can add value to the project
  • Agile is about team not individual effort
  • If you have the skills DO IT rather than say not part of your role
  • If you have not got the skills think about this as a learning opportunity
I will end this article with something to think about

The role of testing in Agile is Organic and Dynamic

Are you a dynamic and organic tester?

No comments:

Post a Comment