Producing waste

Today a colleague pointed out that Agilistas produce a lot of waste. Since it's in the core of agile to reduce waste, this seemed like a strange statement. So we discussed a bit :-) I pointed out that we produce less overhead documentation than other people do, as can be found in almost all presentations about agile.


He then told me he didn’t mean in the projects themselves… Agilistas are responsible for a whole lot of blogposts, tweets, Google+-posts, etc. and he labelled it waste. Of course I responded that using ­social media is an act of being social. A trait of all true Agilistas, since we value communication. Using social media gives people the opportunity to read and reply in their own time and we win time by not using it for mindless discussions. This silenced him for a moment, but he’s still not convinced. Luckily I know the silence means I got him thinking.

Soft skills

Testing is a profession! As a profession it requires skills in testing techniques, domain knowledge for the specific case you are working on, etc. A often underappreciated skill is communication. From the test perspective you need to communicate with a lot of different types of people, where each type requires it's own approach. This seems simple, but is harder than it looks. It's not only the type you need to be aware of, but also the person itself. In some cases a direct approach is the way to go, where in other cases you need to dress up your comments. Be aware of what you say and to who you say it!

Agile and test planning

Agile is often used in combination with scrum, thus resulting in multidisciplinary teams and short release cycles. If we take these two points as a given, how do we adopt our test planning to be able to keep working? First I'll describe a way to work, then I'll give some pointers to take into account during the sprint planning.


Specification
When detailing the product backlog items, make sure the whole team has the same understanding of it. After the first detailing, developers can start creating and product owner, tester and analyst/designer can go over the specifics of the detailing. Then designer and tester can start making their corresponding designs. When done creating the specifications designer and tester review each other's work to see if they described the same system. Any open questions after this reviewing should be resolved with the product owner.


Execution
Start executing test scripts as soon as possible. Share testing knowledge with the developers, so that they benefit from this knowledge when creating the unit tests. Make sure you stay informed about what is delivered to the test environment and then prioritize your test cases according to what was in the last delivery. Usually when the pressure on test execution starts to build, the analysts/designers in your team will be less busy. They can help you execute the script you already designed. When developers have time left, ask them to automate the tests you want to run in continuous integration or regression.


Bugs
Bugs can be solved quicker and with less documentation than in non-agile projects. Discuss bugs you find within your team. In this way all members learn about the bugs found and help each other to find solutions. If the bugs get fixed directly after you find them, it might not be necessary to document them. This results in less time tracking bugs.


Sprint planning
With the sprint planning, keep in mind that you need time for specifying, executing, automating and retesting. To fit everything in the small amount of time, use specification techniques which result in a small number of test cases with high coverage. Make sure that developers also incorporate time for unit testing and for fixing bugs. In the case you will not do the automation yourself, make sure that the responsible person (sometimes the developers) will plan this time.
Experience learns that setting some milestones for a sprint, e.g. first delivery start or code freeze, help the team to finish the sprint successfully.

Locator problems

I'm still exploring using Selenium with page objects. For webelements that have an id or name tag it is easy to define the locators, but I'm having some problems creating a locator for some links. The xpath reference to the link, nicely supplied by FirePath, results in a "Unable to locate element".  The link I'm trying to locate is in the format:

<a href="xxx/yyy/" title="yyy">yyy</a>

I'll just keep trying to find how to locate it. Next to that I'm going to start working on FitNesse.

Selenium

Recently a collegue, Daniël Gollings, showed me Selenium. As an enthusiastic about test automation I was interested directly. So I started to follow the step-by-step tutorial he made. I downloaded all the needed compenents and started with Selenium IDE. Since I have a background in programming, I quicly switched to Selenium RC to be able to apply better control of the automation. The ease of setting up tests amazed me.


Recent conversations with Roy de Kleijn and Martijn de Vrieze, reignited the Selenium-fire. After following a webinar about page objects, I understand the concept. Now only experience can help me with applying the concept. Hopefully I can use my knowledge in a couple of assignments and broaden my knowledge.