Archive

I wrote a comment on Janet Gregorys post about Programmers as testers, and still feel I have to elaborate my comment a little more with the concept of testing vs checking and how these differ. While Janet already cleared out in a more recent comment that we are talking about two different things, I think it is of great importance to have these differences in mind when talking about testing, especially in the Agile development context where the word testing has become a word with many different meanings in various discussions. Read more…

Recently my consulting company migrated all our email accounts to google apps. Even if the main reason was to get the emails on a new platform, this was a good step for our entire infrastructure, where I found a good and easy-to-use tool for my testing and note taking.

I have touched this before, and now I think its time to bring it up again. Any story needs a context to fulfill the purpose of people understanding it. This is true for any story, may it be in testing or blogging or anything else for that matter. This is a tough one, since you never seem to be able to explain enough of the context in a blog post.

Recap

In my last post , I actually tried to explain some of the context that I saw as an important part of the posting. In that case, no reader can be sure that the explained context would include more of the unsaid context, and is required to ask for clarifications of this context. That is what happened when James commented on it:

When I got a comment on my last post, I realised that I had to make myself more clear on some assumptions. Some of them were made on things that I have been thinking about lately, but not discussed with very many people. And I havent blogged about it.

Project

In any project, there are things you need to get done for the project to succeed. In software projects in particular, my view on success is when the software developed brings value to someone of importance. Projects have a budget, usually in money, time or labour of some sort. These have to be distributed among people/equipment to achieve a set of tasks until value is brought by the system.

People

Software development is a huge domain with lots and lots of different people that are concerned by the software that is developed. We usually call them stakeholders, direct or indirect stakekholders. Indirect stakeholders is pretty much any person on the planet since we are living in our small ecosystem called earth. In software projects we usually only refer to the closest indirect stakeholders and the direct ones. All stakeholders usually have roles within or around the software project.

Roles

Human beings need to have labels/folders in our brain to function in a normal way. Otherwise we would be overwhelmed by information if for example every person we meet required its own folder since we are unique. In software development we have a whole lot of roles. Usually everyone can envision people with specific roles doing certain things within a project. Some examples of roles would be (in no special order):

As you can see, from the top of my head I got a good amount of software development roles that are involved in or surrounding projects. I also assume that no project have all of these roles defined.

Tasks

What is really important in a project is the tasks that need to be done for the software to deliver value. There are many ways to organize, visualize and manage task flow in a project. Usually certain roles or people are tied or expected to do to certain types of tasks. But in the agile context, anyone within a team should be able to do any task. That includes all types of people that are on the team. But is this the best thing to do? Should a usability expert write database queries? The product owner develops the back-end API? The tester helps the customer to write down user stories or acceptance tests?

Which tasks are included in a role definition?

Context, context, context! Of course the tasks that need to be done for a software system to start delivering value varies for every project. The people included in a team also vary, which means that knowledge and skills are different in all contexts as well.

The tester role

When I talk about the tester role in a project team, I usually refer to a person that fulfills and executes the tasks needed to achieve quality of delivered software. Those tasks are usually a good blend of tasks associated with QA, test automation, BA, testing, configuration management etc. But what tasks are expected from a tester like that? That question needs a context.

The project is a member and event registration system with backend, customised member browsing that relies on login privilegies, data uploading, invoicing interfaces towards economy system, customisable registration forms that deliver data separately towards the main system, email template creation and sending etc. You got the point.

Project team consists of 6 people for 20 weeks, in 2 week iterations. One of these is a dedicated tester. The customer is an organisation that has regular members and every now and then organises these events. There is a dedicated person within this organisation that is responsible for this project investment.

What should a developer in this project expect from the tester?

What do you think a developer usually expects from the tester?

What kind of skills are required by the tester?

What kind of tasks will the tester do? Start/mid/end of the project?

As a somewhat inspiration to your answers, take a look at this post by Michael Alexander, where he brings up what testers should be good at, but how should the skill set be used in this project?

“I have heard a little on Kanban, which somewhat could be called an evolved agile or at least something in that direction. What i now am interesting in knowing is if these ideas, that are sprung from lean very much, affect or should affect the view of testing. What I do know, is how I would like to perform testing in the agile context. So what about kanban? Does it change the agile testing even more?”

The above quote is how I started this blog post some time ago. I didnt know how to continue in a somewhat professional manner. Part of that was because I had not gotten any picture in my head about how kanban works.

Yesterday, I attended the monthly Agile Skåne meeting, and one of the topics that was brought up was kanban. Since I was not the only one that didnt have so much of knowledge in it, we got a crash course in the form of a success story. While listening, I got some kind of vision of it.

Since I have been working alot with scrum, I had to ancor this kanban thing in scrum. I will now see kanban as scrum with the shortest sprints you can have, the size of a story. Then I will take into account another thing from kanban, the value stream context, which in my perspective means having only two places on the board that are allowed to have piles of cards, that is “Wishlist” and “Value for customer”. Having only these piles, while other categories like “implemented”, “tested”, “ready for test” or “ready for deployment” are not allowed to stack cards, you will get a flow of value towards the customer without leaving stories behind as untested.

While thinking of this, I realized that one issue with agile testing that has been bothering me for some time, and still does, will be easier in kanban. Why does testing in a scrum team many times end up in the discussion on “definition of done”? This is exactly one of the bigger issues I see when testing in the agile context. With this and the value stream context of kanban in mind, I realized that the fact that you extend the number columns on the board past the “sprint demo done” will visualize the testing in a more obvious way. This has the positive effect that the agile tester does not have to advocate testing as hard as sometimes is the case within developers. In the agile context, you can always add some columns when realizing where you want done to be, but in kanban this is default, meaning that the tester does not even have to argue for getting the “To test” column on the scrum board.

By only looking at this aspect of it, and imagining a little more about the kanban context, I would say that kanban is better suited for test than agile and scrum are. But I think Ill have to get back to this later on when having more knowledge of kanban.

As of starting this serious blogging again, when I want to write about real experiences during my day, there are of course some factors that have to be stated before talking about what I really want to talk about. For example I need to mention testing situation, team, product elements etc. all of which are the good heuristics for any given testing project. But how much of the context is needed? And how much can I leave out without being irresponsible in my posting?

I have a couple of blog posts on the way, to kick start this blog, but I would really like some input on this before digging deeper into the blogging. As a tester (I see this as a personality and requirement of a tester), I want to be very exact in the context, but being that I risk to overpost needless information. And that sounds like overspecifying systems requirements, of course. This will also cause the posts to be too long for anyone to want to read them.