Tag Archives: testingdojo

Standard

Posted by

Posted on

August 4, 2011

Posted under

Software testing

Comments

Leave a comment

What did I get out of today’s testingdojo

It’s funny to see how difficult it is to get a group of people, who work with one another daily, to talk freely and share their ideas, even when their manager is not present and they are amongst their peers.

During today’s testingdojo, which again was supposed to last an entire day focussing fully on working with FitNesse, we started off with a talk about what we aim to achieve at our customer’s with test automation. I tried to enthuse the group by pushing them to think about the possible difference between “test automation” and “computer aided testing” and if there are differences, what does one mean and what does the other mean. From there I hoped to get to insight into what they think we should aim to achieve and of course whether or not their ideas make sense to us, as the leads on implementing test automation.

A real discussion on this never took flight unfortunately, moreover, the two people we have been working with closely on the implementation remained most silent of all. I am still not sure what the cause of this silence from their side was, natural shyness, cultural pressure, or something else. Instead I ended up pulling some keywords out of the group and discussing my thoughts on them. Not too bad either, but I do not believe I should have been the one talking this much about the subject.

The second part where I hoped to create a bit of discussion was on what the group believes to be good practices in testautomation. This also took some pains from my side, along with some poking, probing and planting the occasional seed, but some discussion arose on this. After a while one of them remarked that in the end it seemed that all things that can be considered good or best practices in testautomation also fly for manual functional testing.

This insight led me nicely back to clarifying the first point, what are we aiming to do: trying to remove manual testing all together or trying to create more free-space and time to enable them to do more and different manual testing? I do believe I got the picture across that we are not trying to take away manual testing, but rather trying to help them remove repetitive work. Since repetitive testing of the same items and same or similar functionality is quite likely to create a form of feature-blindness.

The term feature-blindness seemed to be a new concept for a big part of the group; however I managed to get this concept explained fairly easy by example.

In the end the morning session was not exactly what I hoped it would be, but it clearly did get the points I wanted to make across. Which were: think of what you want to test, try to describe for yourself why you want to automate something and then read it back in order to figure out whether it indeed still makes sense to automate this. Try to keep your tests small, self contained and reusable. Refactor your FitNesse tests into reusable scenarios, but also keep an eye out on over-complicating things by making everything a scenario, e.g. do not make a scenario for the sake of making it, only create it if you indeed have several identical tests which need different input data. And the most important of all as far as I am concerned in functional testautomation: Keep It Simple and Stupid. Even fancy stuff you should be able to keep simple, readable and brief. If at a first attempt you fail at doing it, don’t worry, move on and come back at a later stage to refactor your test.

One not so nice thing about today’s dojo was that for the second time in a row the second part of the day was rudely disturbed by some very unexpected downtime of our test-environments. We were told in advance that one of the environments would be taken down for urgent maintenance and patching, unfortunately both environments went down during this change which resulted in us sending the group off earlier than anticipated.

Main takeaway for me: I really enjoy doing these knowledge sharing and coaching sessions, I like it a lot and see it as a great bonus to my work as a consultant, especially since it makes me (and hopefully my colleagues) think about why I am doing things they way I am doing them.

Standard

Posted by

Posted on

July 31, 2011

Posted under

Software testing

Comments

Leave a comment

Thoughts while preparing testingdojo follow up

In the first testingdojo at my current client we familiarized the team with each other and of course with Selenium and Fitnesse for test automation.

As I wrote earlier this was quite a succes, all participants seemed to have really enjoyed the dojo and all learned quite some new tricks on how to use Fitnesse to their own advantages as well as the companies advantages. During this first session we stuck to the basics of what can be done with FitNesse, such as simple testcases, use of variables and some basic reusability like login.

All the fancy stuff we have not even touched upon, so my first thoughts were to cover that during the coming, second, testingdojo.

I am however now doubting that idea. Isn’t it a lot more sensible to explain the basics and have them work, as a team, on what is best-practice for testautomation, how can they implement this best for their organization?

Considering the general lack of knowledge in testautomation within this organization I truly believe this would be the best way to go, however question now is of course, how do you keep a session like that interesting? This could easily turn into a very boring, theoretical discussion rather than a properly interactive dojo.

A thought that occurred to me is that we might start off describing the best practices and then pair them up and make them search for ways to get to these best practices as well as reviewing existing automated testcases and refactor them to adhere to these best practice. In order to do this I would of course need to start off compiling my own list of test automation best practices specially tailored for testautomation within this organization and with FitNesse as a background. So far I have come up with the following list, keeping in mind that my group has limited knowledge of testautomation and will solely work in FitNesse:

  • do you know what we are trying to achieve with testautomation within the organization? Are we automating for the correct reasons?
  • before writing an automated test, describe your objective, does it still make sense to automate this test after reading your objective?
  • choose wisely what to automate and what not, be clear on the reason why you are automating someting
  • keep your tests short, readable and simple in order to keep maintenance low and knowledge tranfer capability high
  • make your tests data-driven, try avoiding hardcoded values. In a fast-moving environment like my customers’ it is key to ensure you are not facing failing tests due to inconsistent or wrong data hardcoded in your tests
  • try thinking in reusable functional pieces, keep an eye open for actions you do more than once and see if it makes sense to a) execute this action more than once and b) if this is indeed the case should we make this function(ality) a reusable scenario?

I am fully confident that I have left out quite a few (even more) important points, however the team itself will need to come up with a list of what they believe is going to be key in making testautomation a success within the entire organization, that is what a testingdojo is about, working together and learning from oneanother.

Standard

Posted by

Posted on

July 20, 2011

Posted under

Software testing

Comments

Leave a comment

My first experiences organizing a Testingdojo

A bit of background

While working as a testconsultant at an investment banking firm on a testautomation implementation with FitNesse we were in need of more customer engagement.

The custom fixtures for FitNesse were in place, a base test set in FitNesse had been written in FitNesse, regular runs of these tests were in place and showing beautiful green results. The time had come to get our customer more closely involved again in order for them to add the Acceptance tests and build up a solid suite of automated tests.

Our first attempts at getting people involved led to a few added testcases, but not a feeling within the team that this was going to help them a lot.

The audience

The team we had to work with is a fairly diverse group, ranging from a person who has quite a solid knowledge of coding and working with Selenium to a functional tester with little or no technical knowledge or interest in programming.A group so mixed makes life difficult when trying to engage them all, or so I thought.

When looking for possibilities to get them all together and work on FitNesse tests together I considered several options, such as a workshop kind of setup where we would feed the team the information. However experience has shown me that feeding information is not the best option when you want to actually teach something to a group of people. The most effective way to get them all learning and seeing the benefits we would have to get the whole group together, interacting and playing with the tools. Thus I came up with a testingdojo.

Preparation

In the past I have participated in all kinds of interesting things such as dojo’s, hackathons etc, but never had I participated, let alone organised a testingdojo. All my previous experiences were software development related, with a group of relatively like-minded people.

I started reading up on the base ideas of what a testingdojo can be on the web, starting at testingdojo.org. The base idea behind a testing dojo is similar to that of a codingdojo: you put a group of people together, clarify the roles and expectations, set a challange or goal for the duration of the dojo and set off to work.

Considering the different levels within this group I decided to pair the participants up by their level of interest and base knowledge of FitNesse. In other words, someone without much base-knowledge of the tool was paired with someone with with a fair amount of baseknowledge. This way they were capable of showing oneanother new ideas and insights, especially since the people without the base knowledge also generally did not work with a testautomation tool before. They were a clean slate.

Besides the pairing setup I also prepared a set of testcases they could use as a starting point, I have noticed that within this organization people enjoy getting given a clear direction rather than having an open target. These testcases were also designed to be datadriven and sensible to repeat often, since they all touch the core of the business.

The dojo

The dojo was planned for an entire working day, this in order for everyone to have a chance to get enough experience in and raise their questions.

We started the dojo off with a brief introduction of why we all came together, what the idea behind a testingdojo is and most importantly, what FitNesse is, how it works and what you can do with it. One of the main takeaways that I ensured kept coming back during the entire day was that Testautomation is a tool, it is not a goal. At first this raised some eyebrows and the inevetable questions, but while working with FitNesse during the day the group started to see the point.

Once the introduction of the day was done people set to work with a few rules clearly laid out:

for the duration of this dojo silence is bad. Talk, have conversations, explain to your partner what you are doing, why you are doing it and what you hope to gain out of it.

there are no stupid questions. The only stupid question is the one you do not ask. If the answer you get is not clear enough, seems not to answer your question or does not suffice otherwise for you, keep on asking for clarifications until you get an answer you can accept.

a FitNesse testcase is DONE when it is on the server, in a logical spot within the suites and has 2 consecutive succesful runs.

The goal set for the group was: farmiliarize yourself with FitNesse and evaluate it, determine the added value this tool can have for you and how you can use testautomation. Create testcases that will be useful in your opinion to have running in a testautomation suite and will make your life as a tester easier.

The outcome

Beforehand I expected we would need to do a lot of coaching and helping to get started as facilitators of the dojo. My expectations were proven wrong thankfully! The pairs hit it off very good, the people with no or hardly any experience were at the keyboards playing with Fitnesse and writing tests while the other halves of the pairs, as observers and recorders, were indeed busy asking questions, coming up with ideas and suggestions, explaining what is and what is not useful to do with testautomation.

The people with little or no experience, by the end of the day, were enjoying themselves a lot writing testcases and seeing them run succesfully. The people with quite some experience also seemed to quite enjoy the feeling of having tought someone else a new skill, besides having gotten new insights into what other testers think is an important testcase.

Overall we all had the feeling this has been a great excercise both in learning some new skills, seeing more sense in testautomation and bringing the team closer together and collaborate more as a team, rather than as a group of individuals.

Next steps

We have already planned a second testingdojo session in which we will continue this line of working and thinking, this second dojo will be focussed more on the specifics you can do with FitNesse, such as working with suites, scenarios and make a test fully and truly datadriven, how to debug your test and stabilize it etc.