Opgport.com – a great step for the PM community

Yesterday I attended a PMI seminar on Organizational Project Governance. Although I am not into the whole PMI/PMP thing, I have attended some sessions and got a somewhat overview of some of the things that is included in the PMBOK. The thing is that I can see the PMP thing a little bit like the ISTQB (founded 2002) for testing, but broader in its coverage and somewhat more experienced and older (founded 1969). So why am I even considering looking into these things?

Well, I think that any knowledge is good knowledge. And as a tester, I am always affected or in contact with this kind of management, so why not gain some knowledge about these things. At some point in the future, the knowledge will be handy, Im sure.

The seminar was in three parts, where I was actually one small part myself, presenting the leadership course I have attended (Value based leadership) , going to write about that later I suppose.

Second part was Ted Böklin from Tetra Pak PMO, explaining some of the work areas and templates that he and Tetra Pak uses in his work. Really interesting, although it was somehow at a very high level for me to not understand everything. The PM pit is deeper than you might think=)

The third part was Kjell Rodenstedt and his colleague Thomas Jansson. Together they have really extensive knowledge in the areas of PPPM, a new abbreviation for me, Portfolio Program and Project Management. Apparently they have been doing this stuff for decades, and during their journeys of course gathered plenty of material in their toolbox. So what were they to do with all of this?

This is what fascinated me, they decided to make everything available for anyone on a portal. Their whole toolbox of document templates, processes and everything, for FREE! Project management goes Open Source!

So, without digging deeper into their history, business case or goal with all of this, I just wanted to tell about this incredible step for PM. I am not a big fan of templates and plans and everything, but I think that this is a step in the right direction. Imagine everyone taking their work, create their versions of it, and more and more do it lightweight. The first step is taken, now we just need to cooperate with the PMs to get the most out of the project plans that we really want to follow, everyone!

Check it out: www.opgport.com

Logging: Test tool and system under test in one

James Bach brings up the logging in a system as a tool for the exploratory tester. I really like this, and am going to see if I can straighten out his list to fit my specific project and situation. I have been thinking about this some time now, but mostly about the information within the log entries, and not the logging mechanism itself.

The system I am testing at the moment has extensive logging features, or at least it logs very many things at multiple levels. I use the logging sort of like he mentions, but not relying as extensively on it as it sounds in his post. The system is pretty straightforward relying on one input that creates one single output. Apart from that, there is only logging and status management to keep track of events.

In our case, when testing a part of the system and keeping my eyes on the logging, it struck me that there was a line “check that x has not failed”. This line was very common to see, since it was logged for every event created successfully. But thinking about it, was this entry a useful entry? NO! In my case it was so obvious that none of the developers had been thinking about it, but it was an horrible entry. Why? One of our statuses for events was “FAILED”. So if an event would fail, the obvious thing is to grep for this word in the logs. But having every successful event instance log the word failed would be devastating for any operator trying to find the cause of a failet event.

So what I would like to extend in James’ list, is that of bullet 5″- Event type description: short, unique human readable label” and “- Event information: any data associated with the event that may be useful for customer service or assessing test coverage, this data may be formatted in ways specific to that event type.”

I want to point out the value and importance of having these string fields not interfere between different types of log entries. Like my example above, keeping the word ‘Failed’ away from any successful events at all times is crucial. The problem is that it is so easy to get it wrong. Developers need to think about this when coding, and not only log what the code does, but create the human readable log entry consistent from the user/operator perspective. If something is successful, it does not matter that the code is “checkJobNotFailed(job)”, but the logged entry should verify the success.

Other types of risks with the logging content is of course that of usernames and passwords. If this type of information is logged in a readable way at any logging level, the log files must be handled according to the security policy of this information.

I have made two examples to point out less good logging events. So, what more examples of “good vs bad” log entries are there? Remember that I am not talking about the logging mechanism and its’ good and bad practices like the ones presented by James, but the content of the event entry messages.

Please enlighten me with more input.

Robotium: Android automation testing taken one step further

Even if I have been a little low on posts on technical parts of testing and test automation, this is something of an interest to me as well. For example, I have been doing some ruby/watir/cucumber gui automation testing. I really like cucumber and the intentions it has on communication between stakeholders.

This is actually also one of the intentions that my dear friend and colleague Renas Reda has with his new framework Robotium.

Robotium is a test framework created to make automatic black-box testing of Android applications significantly faster and easier than what is possible with Android instrumentation tests out-of-the-box.

With the support of Robotium, test case developers can write system and acceptance test scenarios, spanning multiple Android activities.

Inspired by cucumber, there are great plans to integrate with it or at least create the same kind of BDD syntax in Robotium. And I really like that idea.

Try it out, its open source at google code.

Afternoon bugs

How often do you find a really serious bug the first thing you do on monday mornings? Or any mornings for that matter, when you just started to look at it.

How often is it the other way around, that the first thing you do is trying to remember what you did on friday, to cause that serious issue you found at 4.30 before you were leaving for home and for the weekend?

For me, it is always the latter. Not only fridays, but any day of the week, the most common time when I find bugs is really late in the afternoon, preferably if you are having an appointment or anything right after work. =) But why is that?

I have three possible explanations, that I have been thinking about:

1. You could be testing a really hard-to-set-up system, that takes half of the day setting up before it is possible to test even a little bit. This is the reason for me every now and then. Recently we have been setting up load tests during night, which have failed a couple of times, so the mornings have been devoted to investigate logs for failure explanations and then it has taken some time to reset databases and getting up and running again. Usually with a bug fix or configuration tweak that also takes some time to verify.

2. Exploring the product and its features and areas all day has made you get more sensitive to finding the weaknesses, and poking the system in these spots make the really tricky bugs appear. These might be the most severe afternoon bugs, or the opposite, the ones that are too complex to be a threat to the product and just are hard to fix, with no value added if fixed.

3. You are unintentionally defocusing from the tasks at hand since it is getting late in the day and the lack of energy is carrying your senses in completely other directions from what you have been doing all day. The defocusing strategy is actually something that is brought up in rapid testing contexes for finding other types of bugs than you normally do. Lack of energy just makes you get in this mode automatically during afternoons. These bugs are more too often hard to recreate for investigation, since your lack of energy might miss out on observing the reason behind the bug.

Have you experienced the afternoon bug heuristic? What have been causing you to find them? and specifically, why do you find them at that time?

Pair testing with a developer 2

I have written before about what I think of pair testing with developers. This post is going to give you some more examples of the benefits.

Pair testing is like pair programming, in the way that you get each other to concentrate on the task at hand. Otherwise it is easy to step into sidetracks and staying there for too long. Sidetracks are possible also in a pair, but the time it takes to get back on track is shorter.

This time, I am actually performing the tests together with both of the developers of the system. It is another system from last time, but one of the developers is the same.

Just like the other system, I have learned alot about how the developers think and master the tools useful for this testing, giving me all sorts of perspectives on the product. They are both different in how they think of things, but their knowledge of the system is the same, but anyway they have different ways of expressing how the system works. This is a very exciting setting for me as tester, to gather and filter relevant information to the risks that we are facing.

Another aspect of this product, is that we have a very narrow deadline for production. This has lead to an enormous interest with the product owner, which is spending sometimes hours in a day following our progress of tuning the product for release. This gives also exciting discussions, since he has an even broader view of the users and functionality. He is technical, but sometimes I still have to translate the meaning of words between developers and him, in any direction. This is why I think of communication as a very important aspect in testing. More about that later.

Getting to the point, sitting next to developers when solving a bug, gave me the chance of getting a glance at the workflow in the product code. Usually I try to avoid this deep digging, but since he was holding the weel, I could just watch the exploration of the code. If I dont follow, I can just ask about explanation to see if there are risks to be considered. Yesterday, this actually revealed a bug. When trying to find another bug, I was observant enough about a discrepancy in another part of the code. Highlighting this just made my partner express the words I really like to hear from any developer: “Thats a bug!”

This was followed by an explanation about it, and the most important thing, it was a bug that would have been really hard to find if it had been ruining things later on.

The thing in this case, would be that if this bug had been seen by myself reviewing the code, I would not have been sure about it, and the feedback loop to any developer would have been a very long one, for this type of issue. Typo in a string, would that ruin your day? Well, in this case, the string value was very important, but as a tester do you think about that at all times?

We saved alot of money on the hours we would have been throwing away of finding this bug later on, and I think that is worth the money spent on two persons testing together, may it have been a developer and a tester.

Stubborn as a tester

Today I was thinking more about the persona of the tester. Thinking about the people surrounding me, mostly developers in my project, but also my test colleagues that I hang around at lunch or in some coffee breaks.

A thing that struck me was that pretty much all testers that I meet are stubborn as nothing else. One thing that shows every time I meet my colleagues is that we never run out of discussions, we only run out of time. Mainly this is because none of us agree completely with the others, never! They are probably also the audience on this blog that can have the most different opinions on what I write. =)

So, is this a good thing, bad thing or a necessary thing for the tester? Yes

Well, if the tester would not stick to his opinion when advocating a bug, no bugs would be fixed when mr-I-never-do-mistakes-developer is on the other side. In this case the stubbornness has to be used for taking the leap towards the analyst or customer. But if its a bug that emotionally struck the tester, and he is being stubborn about it, it could damage the project just as much, if not more than the bug itself.

If the tester was not stubborn enough to continue testing the product, even if no bugs are found in a long time, the most serios and complex bug found at the end of a really long and complex test run would be still unfound. The same goes for the stubborn tester popping the why stack whenever there is anything fishy in the product. But of course, this would also become annoying for whoever has to answer these questions all the time.

I would say that all testers are, and need to be stubborn on their questioning. More stubborn than the products/people/processes around them. That excessive stubbornness and questioning makes a good tester.

Exploratory Testing – Testers way to being agile?

When I first skimmed this headline and then the post, I thought that this guy had the same thoughts on the subject as me. But reading it a couple of times made me realized that the post was not about the same as I was thinking about at the time. Although I acknowledge everything in it as good stuff, and very much on the path of DET (Developers Exploratory Testing) that my colleague Davor spoke about at Öredev in Malmö and ExpoQA in Madrid this year.

With my post, I have a slightly different perspective on it, which has been growing in my mind and discussed in some different settings with some friends.

The other day I asked a dear friend/colleague of mine what he thought of when I said the words:
“explore>learn>adapt and then explore again”
He directly responded with: “Thats agile!”

To be clear on this, he is a very knowledged and skilled developer and scrum master, but like many developers he still has the eyesheds of not looking too much at the testing perspective on things more often than sometimes.

So what is the difference then between being agile as a tester and doing exploratory testing? And why does my colleague associate the same words with being agile, and big parts of the testing community would say its ET. I dont see much of a difference actually. In James Bachs rapid software course this is the summary of what ET is: “by treating learning, test design and test execution as mutually supportive activities that run in parallell throughout the project. ” To me thats pretty much like the shorter and more concise wording I asked my friend.

In a project I am in now, I have to deliver a test specification as a product of the testing. So how do I do? Well, I explore the product in some way to learn how it works, design my tests and document in my specification and at the same time execute and adapt to my next step of exploration. I would say that in my case, I am doing ET, and those are the exact words I asked my friend about. The funny thing here is that the wording had to be neutral from the word test, for him to understand the meaning of them being agile, but for the testing context they are the same as ET, at least in my opinion.

I know that most people that think of ET, think of a scenario where the exploration is done manually through a gui, like on a web page. I acknowledge that as ET as well, but I think that this common understanding of ET comes from the simplicity of describing it like this. That kind of description I think is the most common among developers trying to understand ET.

The harder thing to understand about this, is to see the testing as the iterative feedback loop that it actually is, which responds to the feedbacks of developing with TDD or actually any agile process. The loops are just different in size and visibility. In my project some of the loops are 5 minutes and sometimes it takes a whole day. For exploring a web site, the feedback is mostly about seconds.

To conclude the post, why not just call exploratory testing being an agile process approach to testing, instead of an approach to testing within an agile process. The latter being the most common description I have seen when talking about agile testing. You see the difference?

Scrum Master Tester

I have a long list of topics for blog posts I want to write. However there never seems to be enough time. Also, I have realized that having halfway written posts and not finishing them because of my quality mind is stopping me.

I found a really nice blog where I somehow see the whole picture as the same, and I will get back to tester troubles later. One of the posts go right to the spot on what I believe in this case. Having a person with the skillset of a tester as Scrum Master, couldnt that be a good idea?

I want to be clear that I see the scrum master role as a full time job in most cases, so the person should not be appointed any “testing tasks” in the project.

Why tester as Scrum master?

Well, test driving your sprints would result in having quality in mind from the start when composing user stories together with PO or customer. This would create better testability and better overview understanding of the system.

I see both testers and Scrum Masters as information hubs in a way that no developer would think. They need to be able to communicate in all directions, project management, management, developers, customers etc. Through the diplomacy you need as a tester, usually there is a grown confidence speaking any cultures languages and adapt to the situation which is discussed.

I know that I have many other ideas around this subject, but hey, lets see if anyone has a comment on this so far.

Öredev 2009

Last week I attended Öredev for the second time. Somehow I was thinking that I was going to blog about everything that happened there, but I soon gave up on that. I am going to say some short things on all the things I attended during the conference in this post, and then probably dig deeper into some of those thoughts in later blog posts. This was my schedule at the conference, I should say that this is not the same as I planned/thought I would attend.

Monday and Tuesday I took the Certified Scrum Master course, with Jim Coplien and Jens Östergaard as teachers. I think I already know quite alot about scrum in theory and practice, but it was good to take the course to fill in some gaps. It was really good to have some scrum projects behind me, so I could get some answers to questions I have been thinking about. Another big thing about taking the course is that now I am actually able to discuss the course and how it should be used. Jim and Jens were really great to have as teachers.

Monday I went cold sea/hot sauna bathing with some of the participants/speakers. It was really nice relaxing with dinner accompanying it. I got the chance to meet with the lovely couple Marc and Lee Lesser, talking about awareness and many other interesting things. Marc held a really good keynote as a start of the whole conference, about Accomplishing more by doing less. I think everyone attending his talk appreciated what he had to say about noise and how it keeps people from doing what really gives value when accomplished.

During tuesday evening I was at Malmö city hall for speakers dinner. We had a real goose dinner, swedish (Skåne) way.

My first real day of the conference was a show of the diversity of the conference. Attended some javascript, groovy/Jruby and some agile. The other days were then completely devoted to agile and testing in particular.

I am really into the testing as such, but somehow I always tend to keep myself to the more softer parts of it. May it be bad or not, but I really think that the most important thing is to get the right product through good communication. Not until then you are actually able to ask if it is right. That actually WAS a bias for me when putting together the test track. During the conference I got more and more confident in that it was the right speakers, with the right sessions speaking.

The diversity of test speakers was for me obvious in one way, but not in others as I spoke to some other people about it. I really think they connected to each other in a nice way. The softer skills like communication and thinking about software and then towards the more hands-on tools for communication and agile testing project solutions and further on to the bigger projects solutions for regression testing. I am going to write about some of the sessions later hopefully. What I really wanted to make clear, is that I really see all testing sessions connect to each other.

Now I think that I am going to read up on some of all the blog posts that have been written about the conference, and then write down some thoughts myself. Somehow I think I need to sum up the connection between all the sessions.

Alot to do lately

I have been busy with alot of things lately, keeping myself away from spare time blogging. So I just thought I would tell briefly about some of the events/working tasks that I have experienced, and would really enjoy some feedback on what is actually interesting enough for you, my readers to read a blog post about. So please comment on the things you want to know more about.

First out, I was on a nice competence weekend last weekend with Testway, were we gather all of us for friday morning – saturday lunch, learning new stuff and share knowledge. This time we had three main areas to talk about:

Lean test optimization
This is a product in the company portfolio, where two of us in a couple of smaller steps (workshop, analysis and tryouts), start with the current test process of a customer and make it more lean, removing obvious waste in a first iteration. Using baby steps of improvement in the current setting is easier than changing the whole process at once. The product consists of a complete first baby step during a week for the customer.

Cloud and testing
There is an obvious change within the industry towards using cloud solutions for hosting and running applications in the cloud. There are a couple of different settings to choose from depending on your needs. How can the whole concept be used for us as testers?

Selling consultancy services
Mainly about how we as a company are marketing ourselves and selling our services.

Apart from these things, we of course touched all the other amazing and exciting things to discuss during the weekend.

Monday I attended an internal workshop about The kanban game with Björn Granvik. This very interesting workshop Björn is going to have at Öredev together with Scott Belware. Starting with an introduction to Kanban and the concepts, we continued playing the game, getting a feel of the process itself.

Wednesday I attended another part of the course “Agile for experienced project managers” with Leadway. This is a course that is going to be taught in public, I think sometime in november. Tell me if you are interested in attending, Ill tell you when it is. This part was about how to scale agile and project dependencies. It also included a short story about how this can be done in practice.

This involved parts from a seminar that I attended three weeks ago with Petri Haapio, talking about Scrum implementation at Nokia Networks.

Then of course I have my daily work, which at the moment includes both Ruby/watir cucumber test automation of a web application as a Test Automation Launch Pad product and some big systems functional and pre-delivery testing at a larger company. These could both be full time jobs, but doing them both at 50% has been possible.

Apart from these things I am in the program committee of Öredev conference, responsible for the test track. That has also been taking some time.

That was a summary, and not even everything is mentioned. And I actually do have a private life as well, a little. I will add some pictures to the different topics later.

So please go ahead and tell me what would be the most interesting to read about, and Ill focus on that for a blog post. I have a somewhat problem focusing sometimes. I like the context switching even if it doesn’t give me the efficiency I want.

Öredev is coming up next week! Please register if you havent already, it is going to be awesome! Meet me there and discuss something exciting….