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
·
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
}
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.
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);
}
}
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
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?
