Tesbash 2015 - Workshop Day

I was fortunate to be invited as a speaker at Testbash this year and had a wonderful yet tiring time.  There were lots of community based activities alongside the usual presentations.  The following is based upon some of my notes taken during the event and from my ever fallible memory.

This year Testbash made a change and decided to have a day of workshops however before that there was a pre-Testbash workshop meetup.  Walking in there were many familiar faces and some new ones, it felt like meeting up with old friends.  At these kinds of events I try to make an effort to sit with people I have never spoken to or met before.  There is nothing worse than coming to a meetup for the first time and not knowing anyone or being too shy to talk to others.  Sometimes it can be intimidating for those who are new and seeing everyone engaged in conversation as if they have known each other for years.  

One great aspect of many testers is their ability to make friends and be quite social.  I sat with one group of people who had traveled from Glasgow which consisted of Paul, Christine and sorry I have forgotten the other ladies name.  The conversation centered on testing in financial organizations and trying to implement what they had learnt on the RST -  course they had attended that day with Michael Bolton.  We had an interesting discussion about starting small and expanding out to others and implementing by showing success.   I talked about my experiences in doing this and we agreed that to implement RST learning in big organizations can be daunting but possible.

After this chat I brought out a few games I by chance had in my bag.  We settled on playing Loonacy which is a simple matching game with no turns.  This is a fun game and Christine was really good, Paul not so good.   Then it was time to get my beauty sleep for the big day of workshops.

Building an Itinerary for Exploratory Testing - Karen Johnson

The first workshop of the day was by Karen Johnson called ‘Building an Itinerary for Exploratory Testing’.  This workshop was packed with content and to really do it justice would require a lot more than two hours.  I have attended previous workshops by Karen and always feel relaxed, her gentle style of teaching is amazing and she makes everyone feel inclusive.  This as a presenter is a difficult task to achieve and Karen is one of the best I have experienced.   In this workshop it was no different.  The first part of the workshop involved learning about three different techniques that can help you build up an itinerary for exploratory testing.   Karen started by explaining that sometimes we get stuck coming up with ideas for exploratory testing. Karen stated there are tools available that can help you generate exploratory testing ideas, such as personas, heuristics and tours. 

  

Personas:

The first tool/technique that Karen introduced was personas.  This is where you place yourself into a certain type of person or user.  Rob Lambert has a great article on using personas in testing.  Personas are a useful way to place yourself in to the mindset of somebody else and can provide you with different perspectives on how to test the product.   One key aspect of personas is that they should not just be a one line description; it should be a story about the person with some background information. 

A couple of tools mentioned during this part of the workshop for creating personas included the following:

• Fake Name Generator - http://www.fakenamegenerator.com/
• Random User Generator - https://randomuser.me/

Heuristics

Next up from Karen was Heuristics, mainly ones using mnemonics to help trigger test ideas. I have in the past found many of these useful when testing.  Karen mentioned she has a set of cards that contain a set of these heuristics and mnemonics.

These cards can be found on her website - http://karennicolejohnson.com/2012/07/testing-mnemonics-as-a-card-deck-v2/.  I created an expanded set based upon the idea form Karen - http://steveo1967.blogspot.com/2013/06/test-ideas-cue-cards.html

Another resource that Karen mentioned was the use of The Quality Tree Cheat Sheet -  by Elisabeth Hendrickson, James Lyndsay , and Dale Emery.

People found this one very interesting and useful

Others mentioned included:

• FEW HICCUPPS – Michael Bolton
• Testing Heuristics – James Bach

During this section Karne mentioned Test charters and recommended the book by Elisabeth Hendrickson called Explore it - A review of the book can be found here: - http://steveo1967.blogspot.com/2013/11/book-review-explore-it-by-elizabeth.html.

In this book Elisabeth has a template for exploratory testing charters:

Explore (target)

With (resources)

To discover (information)·

Where:

Target: Where are you exploring

Resources: What resources will you bring with you

Information: What kind of information are you hoping to find?

Tours

The final tool/technique that Karen introduced was testing tours.  This is where you are given a scenario and then use this to guide your testing.  First up was Michael Kellys FCC CUTS VIDS tour - http://michaeldkelly.com/blog/2005/9/20/touring-heuristic.html

• Feature tour: Move through the application and get familiar with all the controls and features you come across.
• Complexity tour: Find the five most complex things about the application.
• Claims tour: Find all the information in the product that tells you what the product does.
• Configuration tour: Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.
• User tour: Imagine five users for the product and the information they would want from the product or the major features they would be interested in.
• Testability tour: Find all the features you can use as testability features and/or identify tools you have available that you can use to help in your testing.
• Scenario tour: Imagine five realistic scenarios for how the users identified in the user tour would use this product.
• Variability tour: Look for things you can change in the application - and then you try to change them.
• Interopeability tour: What does this application interact with?
• Data tour: Identify the major data elements of the application.
• Structure tour: Find everything you can about what comprises the physical product (code, interfaces, hardware, files, etc...).

This was followed by James Whittaker exploratory testing tours

• The Guidebook Tour
• Guidebooks for tourists identify the best hotels, the best bargains, and the top attractions, without going into too much detail or overwhelming a tourist with too many options. The analogous artifact for exploratory testing is the user manual, whether it is printed or implemented as online help (in which case, I often call this the F1 tour to denote the shortcut to most help systems). For this tour, we will follow the user manual’s advice just like the wary traveler, by never deviating from its lead.
• The Money Tour
• Every location that covets tourists must have some good reasons for them to come. For Las Vegas, it’s the casinos and the strip, and for Egypt it’s the pyramids. For exploratory testers finding the money features leads directly to the sales force. Sales folk spend a great deal of time giving demos of applications and are a fantastic source of information for the Money tour. To execute the tour, simply run through the demos yourself and look for problems. As the product code is modified for bug fixes and new features, it may be that the demo breaks and you’ve not only found a great bug, but you’ve saved your sales force from some pretty serious embarrassment.
• The Landmark Tour
• As a boy growing up in the fields, meadows, and woods of Kentucky, I learned to use a compass by watching my older brother. The process was simple. Use the compass to locate a landmark (a tree, rock, cliff face, and so forth) in the direction you want to go, make your way to that landmark, and then locate the next landmark, and so on and so forth. As long as the landmarks were all in the same direction, you could get yourself through a patch of dense Kentucky woods.
• The Landmark tour for exploratory testers is similar in that we will choose landmarks and perform the same landmark hopping through the software that we would through a forest. Choose a set of landmarks, decide on an ordering for them, and then explore the application going from landmark to landmark until you’ve visited all of them in your list. Keep track of which landmarks you’ve used and create a landmark coverage map to track your progress.
• The Intellectual Tour
• I was once on a walking tour of London in which the guide was a gentleman in his fifties who claimed at the outset to have lived in London all his life. A fellow tourist happened to be a scholar who was knowledgeable in English history and was constantly asking hard questions of the guide. He didn’t mean to be a jerk, but he was curious, and that combined with his knowledge ended up being a dangerous combination … at least to the guide. When applied to exploratory testing, this tour takes on the approach of asking the software hard questions. How do we make the software work as hard as possible? Which features will stretch it to its limits? What inputs and data will cause it to perform the most processing? Which inputs might fool its error-checking routines? Which inputs and internal data will stress its capability to produce any specific output?
• The FedEx Tour
• FedEx is an icon in the package-delivery world. They pick up packages, move them around their various distribution centers, and send them to their final destination. For this tour, instead of packages moving around the planet through the FedEx system, think of data moving through the software. During this tour, a tester must concentrate on this data. Try to identify inputs that are stored and “follow” them around the software. For example, when an address is entered into a shopping site, where does it gets displayed? What features consume it? If it is used as a billing address, make sure you exercise that feature. If it is used as a shipping address, make sure you use that feature. If can be updated, update it. Does it ever get printed or purged or processed? Try to find every feature that touches the data so that, just as FedEx handles their packages, you are involved in every stage of the data’s life cycle.
• The Garbage Collector’s Tour
• Those who collect curbside garbage often know neighborhoods better than even residents and police because they go street by street, house by house, and become familiar with every bump in the road. However, because they are in a hurry, they don’t stay in one place very long. For software, this is like a methodical spot check. We can decide to spot check the interface where we go screen by screen, dialog by dialog (favoring, like the garbage collector, the shortest route), and not stopping to test in detail, but checking the obvious things (perhaps like the Supermodel tour). We could also use this tour to go feature by feature, module by module, or any other landmark that makes sense for our specific application.
• The Bad-Neighborhood Tour
• Every city worth visiting has bad neighborhoods and areas that a tourist is well advised to avoid. Software also has bad neighborhoods—those sections of the code populated by bugs. Clearly, we do not know in advance which features are likely to represent bad neighborhoods. But as bugs are found and reported, we can connect certain features with bug counts and can track where bugs are occurring on our product. Because bugs tend to congregate, revisiting buggy sections of the product is a tour worth taking. Indeed, once a buggy section of code is identified, it is recommended to take a Garbage Collector’s tour through nearby features to verify that the fixes didn’t introduce any new bugs.
• The Museum Tour
• Museums that display antiquities are a favorite of tourists. Antiquities within a code base deserve the same kind of attention from testers. In this case, software’s antiquities are legacy code. Older code files that undergo revision or that are put into a new environment tend to be failure prone. With the original developers long gone and documentation often poor, legacy code is hard to modify, hard to review, and evades the unit testing net of developers (who usually write such tests only for new code). During this tour, testers should identify older code and executable artifacts and ensure they receive a fair share of testing attention.
• The Back Alley Tour
• In many peoples’ eye, a good tour is one in which you visit popular places. The opposite of these tours would be one in which you visited places no one else was likely to go. In exploratory testing terms, these are the least likely features to be used and the ones that are the least attractive to users. If your organization tracks feature usage, this tour will direct you to test the ones at the bottom of the list. If your organization tracks code coverage, this tour implores you to find ways to test the code yet to be covered.
• The All-Nighter Tour
• Also known as the Clubbing tour, this one is for those folks who stay out late and hit the nightspots. The key here is all night. Exploratory testers on the All-Nighter tour will keep their application running without closing it. They will open files and not close them. Often, they don’t even bother saving them so as to avoid any potential resetting effect that might occur at save time. They connect to remote resources and never disconnect. And while all these resources are in constant use, they may even run tests using other tours to keep the software working and moving data around. If they do this long enough, they may find bugs that other testers will not find because the software is denied that clean reset that occurs when it is restarted.
• The Supermodel Tour
• For this tour, I want you to think superficially. Whatever you do, don’t go beyond skin deep. This tour is not about function or substance; it’s about looks and first impressions. During the Supermodel tour, the focus is not on functionality or real interaction. It’s only on the interface. Take the tour and watch the interface elements. Do they look good? Do they render properly, and is the performance good? As you make changes, does the GUI refresh properly? Does it do so correctly or are there unsightly artifacts left on the screen? If the software is using color in a way to convey some meaning, is this done consistently? Are the GUI panels internally consistent with buttons and controls where you would expect them to be? Does the interface violate any conventions or standards?
• The Couch Potato Tour
• There’s always one person on a group tour who just doesn’t participate. He stands in the back with his arms folded. He’s bored, unenergetic, and makes one wonder exactly why he bothered paying for the tour in the first place. A Coach Potato tour means doing as little actual work as possible. This means accepting all default values (values prepopulated by the application), leaving input fields blank, filling in as little form data as possible, never clicking on an advertisement, paging through screens without clicking any buttons or entering any data, and so forth. If there is any choice to go one way in the application or another, the coach potato always takes the path of least resistance.
• The Obsessive-Compulsive Tour
• OCD testers will enter the same input over and over. They will perform the same action over and over. They will repeat, redo, copy, paste, borrow, and then do all that some more. Mostly, the name of the game is repetition. Order an item on a shopping site and then order it again to check if a multiple purchase discount applies. Enter some data on a screen, then return immediately to enter it again. These are actions developers often don’t program error cases for. They can wreak significant havoc.

Once this was finished Karen then got everyone into groups and asked them to come up with test ideas using these techniques and tools to test a website or a mobile application.

Observing the groups it was interesting to see that some used mind maps to document their ideas, others used lists, and some created test charters using the template by Elisabeth Hendrickson and one group story to create user stories.  Whilst observing it became clear that many of the groups found the cheat sheet a useful tool for coming up with ideas whilst others found the tours a good way to come up with novel ideas to test the application. 

At the end Karen brought all the groups together to do a debrief.  During this part of the workshop many came to the conclusion that each of the techniques that had been introduced provided them with far more test ideas that they could have thought of without the techniques or tools. Some of the discussions focused on which technique people preferred with many having a presence for either tours or heuristics.  It was asked why people did not like the personas as much and the majority stated it was hard to come up with people for the sessions; however in their own contexts it may be easier.

To conclude this was a fantastic introduction to some great exploratory testing techniques given by an experienced and knowledgeable presenter.  The style of training that Karen used in the workshop was a calm and unassuming one which made everyone warm to her and the session.  If you get an opportunity to attend a workshop by Karen I would highly recommend you do so.

Creative and Critical thinking workshop

The next workshop I attended was the Games and Tools to Encourage Creative and Critical Thinking within Testing one.  When I say attended I meant presented.  I cannot say much about the workshop in terms of attending it; however I do hope people enjoyed it.

For more details of some of the content I wrote a series of article (seven) the first of which can be found here: - http://steveo1967.blogspot.com/2013/03/creative-and-critical-thinking-and.html

Some of the tools and techniques used during the workshop:

• Disruptus - http://steveo1967.blogspot.com/2014/01/using-games-to-aid-tester-creativity.html
• SCAMPER - http://www.mindtools.com/pages/article/newCT_02.htm
• FiLCHeRS - http://www.csicop.org/si/show/field_guide_to_critical_thinking/
• Huh, Really, So – Video - http://www.youtube.com/v/8TX6rzz60xQ
• The 5 Whys - http://en.wikipedia.org/wiki/5_Whys
• Rule of 3 – Weinberg - http://s0ftwaretesting.livejournal.com/1430.html
• Thinkpak - http://www.amazon.com/Thinkpak-A-Brainstorming-Card-Deck/dp/1580087728
• Disney method - http://www.idea-sandbox.com/blog/disney-brainstorming-method-dreamer-realist-and-spoiler/
• Technique for producing ideas - http://www.scribd.com/doc/242701702/A-Technique-For-Producing-Ideas-Poster-pdf#scribd
• Story cubes - https://www.storycubes.com/

After this session I needed to relax a little and gather my thoughts so I did not attended the next workshop

Next there was an open session where we played some games.

I introduced the following games:

• Zendo http://www.looneylabs.com/rules/zendo using Ice Dice - http://www.looneylabs.com/games/icedice 
• Loonacy - http://www.looneylabs.com/games/loonacy
• Dobble - http://www.amazon.co.uk/Asmodee-Dobble-Card-Game/dp/B00NELITFK
• SET - http://www.setgame.com/set

If you want to learn more about these games then if you see me at testing events let me know.

In the evening there was another meetup “Pre Testbash Meetup” where over 60 testers got together and chatted.  The best part of Testbash is not the workshops or presentation but the community feeling of these meetups.  I met old friend and found new ones.  Guna (https://twitter.com/alt_lv) was a shining star and someone who is fun to talk about anything not just testing.  We end up talking about my tee-shirt whichwas based upon the work by the artist Jenny Parks - http://www.jennyparks.com/.  In fact Guna tweeted afterwards about the artist, what a great memory! I bumped into many testers I had not seen in a while including Vernon ‘tutu’ Richards (https://twitter.com/TesterfromLeic), Danny Dainton (https://twitter.com/DannyDainton) Dan Billing (https://twitter.com/thetestdoctor) and many others sorry if I have not mentioned you.

One interesting person I chatting with who I feel is a future testing star was Emma Keaveny (https://twitter.com/EmJayKay80).  Her story into testing is a wonderful and emotional journey.  I do hope one day Emma will start a blog post and tell others her inspiring journey.  I am sure it will be an interesting read and contain colorful language. 

I did not expect this post to become so big so it has become two parts, the workshops and the key presentations.  Watch out for the key presentations post soon.

The Dark side of Continuous Deployment

A short post!

In the software development world there is a drive towards continuous deployment of software which in the majority of cases in a good thing.  The good side is the reduction in costs, faster feedback from users and quicker release of features and bug fixes.

However my experiences of using software in which there are constant and frequent updates provides me with some concerns.  Have you ever downloaded an app for your device that crashes upon starting or has new updates each and every day?  How does this make you feel?  I for one get very frustrated when I get up in the morning and my phone says x number of apps have been updated.  Or that the same app I have updated 3 times previously in the last week!  Suffice to say this app have been deleted and I no longer use it.

There is a common phrase that appears to have been forgotten in the rush to continuous deployment and using users as testers and that is "First impressions count"  If you come across a piece of software which you have purchased and it is buggy or does not work in the way you expect you may feel cheated.  All software has bugs that is to be expected, my worry is that we are paying for software which has not been sufficiently tested by skilled testers.

There is a major movement to automate 'testing' within continuous deployment practices.  This implies to me that those who promote and suggest this may not have an understanding of what testing is and the value it provides to the quality of software.  This is a big assumption for me to make but I am experiencing more and more examples of software being released to users which is not good enough and with a little bit of testing could have provided a much better user experience.

I am not saying to stop doing continuous deployment but within the development cycle there should be some level of human testing to provide information about how the software is behaving.  This is not meant to say have a dedicated testing phase but ensure that testing activities are added into each and every release. Continuous deployment is a wonderful tool to enable quick and easy releases however it should not be used to release poor or sub-standard software that relies on users to provide details of issues, especially software that a user has purchased.

The key problem to me as someone who works in business is that if you release poorly tested software and it is noticed then the chances are they will not come back and you will lose their customer.  If this happens again and again you may find you do not have a business, social media is powerful in allowing those who experience bad software to make it know very quickly to a huge amount of people.  Can your business take that risk?

RANT over.....

Over to you the reader, what are your thoughts on this?

Further reading:

Testing vs Checking refined - James Bach
Continuous Deployment - Agile Alliance
Why continuous deployment - Eric Ries

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:

http://www.wordle.net

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:

• Why Facebook does not have any testers http://www.zdnet.com/blog/facebook/why-facebook-doesnt-have-or-need-testers/7191
•   Agile team with no dedicated Tester Members – Insane or efficient? http://programmers.stackexchange.com/questions/215511/agile-team-with-no-dedicated-tester-members-insane-or-efficient

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.

• http://testobsessed.com/2010/10/testers-code/
• http://steveo1967.blogspot.co.uk/2012/11/testers-should-learn-code.html    
• http://blog.smartbear.com/testing/dont-fear-the-code-how-learning-basic-coding-can-boost-your-testing-career-2/
•  http://thesocialtester.co.uk/testers-need-to-learn-to-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

• Cucumber (http://cukes.info/), 
• Gherkin (https://github.com/cucumber/cucumber/wiki/Gherkin) 
• and Fitnesse (http://fitnesse.org/).

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

https://github.com/cucumber/cucumber/wiki/Given-When-Then

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?

A Coaches Guide to Agile Testing - Growing Agile - A book review

There are a variety of books that testers can choose to read about testing, however there are not many about agile and testing.  I came across the book "A coaches guide to agile testing" by Karen Greaves and Samantha Laing after reading a review of it by Lisa Crispin on her blog.  As someone who works with agile teams I had been looking for a book which could help me get the message across about the testing activities within agile teams.  This book was the book I was looking for.

The book is written as a collection of workshops which you can either use as they are or adapt and change them for your audience.  The format of the workshops follow the same technique devised by Sharon Bowman in her book "Training from the Back of the room" called the 4Cs plan.

• C1 – Connections: To get participants to connect with each other and the trainers, and to connect
• participants to what they might already know about the topic
• C2 – Concepts: Some facts and theoretical concepts about the topic
• C3 – Concrete Practice: An activity or simulation to experience the topic
• C4 – Conclusion: An opportunity for participants to evaluate what they have learned about the topic

Karen and Samantha introduce you to the concepts of the 4Cs and how they are used in each of the workshop sessions.  At this point it is worth mentioning that along with the book there is a trainers kit which contains template and slides for you to use when coaching.

The first few chapters of the book concentrations on introducing the 4Cs method of training along with what materials you may need and some suggestions for how the room should be laid out.  This then goes into an example of an 'ice breaker' for the first session and provides some useful information on setting agreements (rules)

The book really starts to discuss the agile testing subject from chapter 3 onward.  Personally I would like to have more in here, maybe something on retrospectives and test estimation would be really useful.  Hopefully Samantha and Karen will add to this book at a later date.  Chapter 3 introduces a workshop about the 'Agile Testing Mindset'.  I have used the exercises in this chapter to uncover what peoples perception and assumptions are about testing.  It provides some great insights and soundbites that can be used when discussing agile testing with others.  I especially like the following:

Agile is an activity not a phase

The chapter also discusses what is the role of a tester when testing and I found the following system a very useful one when informing people what the role of a tester is.:

"Don't try to break the system, instead help build the best possible system"

Other exercises within this chapter include being a tester rather than a checker and what the difference is.  Is it the testers job to find or prevent bugs?  Overall this chapter provides some useful material in helping dispel the myths and assumptions around what testers do.  For me this one chapter was worth the purchase of the book.

Chapter 4 discusses and provides exercises around the Agile testing quadrants.  It uses exercises to explain why the agile testing quadrants can be a useful tool to help classify different types of testing.  This chapter is a good introduction to the agile testing quadrants and how each quadrants has some elements where testers can provide a contribution.

Chapter 5 introduces automation and looks at some of the pitfalls agile teams fall into when attempting automation. It provides information on the automation pyramid and gets the team thinking about the right place and level automation should be aimed at.

The next chapter looks at the input of testers into scrum meetings and how they can add value.  This chapter is useful for those who feel that testers struggle when teams introduce scrum,  For me this chapter was a little weak in some areas and maybe it was because the title was misleading.  It maybe better to have a title of agile meetings rather than scrum.  This way it can cover the sprint planning, grooming, retrospective and also investigate the concepts of Kanban,

The book finishes with a recap of what has been learnt and asks you to go back and look at other material and resources you have come across during the learning journey that you could look at next.

The book is quite short containing  around 50 + pages but within these pages is a wealth of material and information that anyone involved in agile testing will find useful and informative, The book is not only for coaches it can be used by the reader to provide themselves with an understanding of agile testing.  What I did before I went and used some of the activities described in the book, was to go through each of the exercises myself and learn more about my understanding of agile testing.  This I felt was a valuable aspect of the book it was not just telling you what agile testing is it was providing you with ways to uncover what you already know and what you can learn about agile testing.

I highly recommend this book to anyone who is working in agile teams and want to learn more about agile testing.  As a bonus it provides ready to use teaching material so that you can then go and practice what you have learnt with others.  Included in this bonus material is a ready made slide deck for you to customize and use in your coaching.

The one part of the material that stood out for me was the Agile Testing Manifesto that Karen and Samantha have in their slide deck.  To me this sums up the agile testing approach.