What I learned at Test Coach Camp 2012

First of all, I had a blast at text coach camp!

I am very happy I made that decision last Friday. Before coming to San Jose I had not applied to go to the Test Coach Camp. I was going to explore the town and its surroundings to adapt to the time difference before CAST. I had dinner with the TCC participants and got to know they had some last minute drop-offs. So I was encouraged to go through the application process, which I did later that night by creating this mind map for application.

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.

Ö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.

About communication – pressing send

When actually starting to think about this blog post I found myself thinking of all these things that are important about communication. And the more I thought about it and wrote things down, it just kept getting more and more. A never-ending subject. Lets try from the beginning, and drive it towards testing in projects.

In wikipedia there is a definition of what communication is: Communication is a process of transferring information from one source to another. Here we have information and transfer as the keywords. The transfer is often depending on the type of information that has to be transferred.

There are as many ways to communicate information as there is information to communicate. The ordering of words in texts, expressions in the face when talking etc. How to communicate information in the most effective way is a balance where almost everyone misses some steps every once in a while. It is about being accurate but at the same time concise. Sometimes there is need for mass communication and sometimes it just has to be precise and accurate. You might say adapted to the setting of who is the receiver and what the purpose is. At university I had a course in technology aided communication, which was held by the philosophical department (yes, really). There we discussed the quality of information and how different media like speech, sms and email require different things from the users and how they provide different pros and cons for the kind of information transferred.

When working in projects, I want to say that there is a need for constant flow of information for the collaboration within team members can be the most effective. Everyone knowing about the prerequisites and changes in the project makes a smoother workflow. But who takes care of everyone knowing everything? And is it really possible to get anything done if everyone should take part of all information?

All information in a project has different kind of media. We have written documentation such as documents and wikis, marketing material like posters and commercials, current status information like time lines and taskboards, communication tools like email, messengers and blogs, customer communication like minutes of meeting and oral discussions….etc. (You get the point)

But what is the most important? Today I thought about it again, and I think that I actually found a somewhat good answer to it.

How would communication or information look if we did not execute or perform it at all? Well, in our heads the information consists of thoughts and pictures. If information is written down, it stays in the place where it is written, should it be a piece of paper, whiteboard, in a text document or in your email drafts. The information does not become communication before you actually communicate it; ask the question or tell about the idea in your head, put the postcard in the mailbox, show someone the paper note or whiteboard, actually pressing the send button in the email client or even publish the text to the blog (and tell someone about the link to it). I would argue that even if it will become alot of information, the most important thing is to communicate it in some way. If it is important it will end up in a safe place for the project. But even so, I would say that the first thing would be to discuss it with someone.

As a tester in a project this is were the value of the overview information comes in hand. By having a finger in every pot of the soup, you can sometimes lift a finger of information and gently flavour another pot with it. By knowing customer viewpoints, you can drive developers in the right direction and by knowing development contraints or issues there is a possibility to guide the customer in the right direction regarding backlog etc. I am not saying I want to overhear every conversation (well, almost), but with everything regarding something that comes close to design decisions or agreed upon features. With a setup like this there is a great possibility for the project to let testing drive the project with quality in mind throughout the cycle. But is this the job of a tester? I know that some would argue this to be the role of the project manager/scrum master (not to be said that I think they are the same). I would like to point out that I think the a tester would do perfectly as a scrum master in a scrum team. But that is a whole different blog post. The point would be that with this overview, comes a responsibility to press send on information from one pot to the other when needed, and that can be challenging. But it is also a lot of fun, in my point of view.

Pair testing with a developer

At the moment I am the only test resource within an agile team  of about 10 people. I am very new to the environments while the developers are much more experienced. At least that is what i think.

The team is an outsourced resource, and responsible for about 12 different smaller products towards a big organization. The products could be said to be somewhat a foundation for the rest of development within the company. Since there are so many different products, the developers also have some more responsibility to some of them. Since I started here, I have been testing two of the products briefly. One of which I was testing today…

I had the privilege to do some testing together with a developer.  Before this I have been reading up on the existing documentation of that specific product, and come up with something they want to call test specification, but I would more call it test ideas/heuristics formulated in a document to make people happy. I have also had the document briefly reviewed with another developer which gave very much more value than he could have thought.

Me and the developer actually sat together by the computer, following my heuristics. And here was the funniest experience: Since the product is delivered to other developers for use in their development, my pairmate actually answered both questions from his development point of view, and that of a user of the product. This made the situation even more comfortable for me as a tester, since I just had to ask the right questions, without having to know what to ask, and he would fill in the blanks, and then he would answer the question himself. That way my questions were very much of the character how things should be explained. All I had to do in the meantime was taking notes on key features and what happened, and also keep track of the “test specification” so it was up to date with what we actually did for testing the product. I was using my pairmate pretty much as a testing tool and oracle at the same time.

Since my view of testing is on a much higher level than that of my pairmate, there was somewhat of a frustration using the high-level tool I wanted to use for smoke testing and verification. This tool is developed by another department in the same company, and does have alot of time-consuming steps before answers to the heuristics are visible. With this in mind, I had to minimize the use of this tool and use it efficiently. It also helped that my developer had his own tasks on his laptop beside him when having to wait for the system or for me taking notes.

As a conclusion, I had many good experiences from this kind of testing:

– I got a much deeper insight into the product after this session. I could actually do some testing myself from other heuristics later on, with for me before unknown shortcuts and solutions to problems that occurred during the pair session.

– It made me understand the actual usage of the product in a better way, since this was a development product and my pairmate was a possible user of the product as well. That made me realize that some of my test heuristics actually were useless and would just add costs if used in testing.

– Using my brief domain knowledge but good testing skills and thinking, we could together create a confidence in the product and its state of quality to a satisfying degree. We both could point out issues with the product, very often without the other one noticing also. This is because we see things differently.

– I had the chance of educating a developer briefly in the art of testing, thinking a little different, making him realize himself about where bugs can be found etc. This is something every good developer should have, some brief knowledge in testing.

– And of course, the statement of all statements about how effective pair programming is: we were focused on our task all the way through. Since you are working with someone else, both are thinking about the task and pushing for finishing it. My own view on this is that you of course dont bring up your mail or blog feeds while having someone looking at the same screen as yourself, and this of course gives a productive setting. This has to be complemented with some breaks now and then of course.

Do you have more experiences from testing together with developers? Your view on this?

How much context is enough when blogging?

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.

My new blog!

Yaye! I have a blog. It is actually my first real personal blog just for clean blogging. But what do I mean with that? Well, I have had two travel diaries on other places, but those of course died when I got back home. 

My friend Christian has been bothering me for a very long time to get a blog, so here it is. Maybe not completely his achievement, but I have the last couple of weeks felt that there are actually things that I need to write somewhere, so why not a blog.

Starting a blog gives some questions at first, what language to use? what to blog about? how personal blog do I want? These are some of the questions that I have been thinking about and have stopped me from starting one. I mean, what topics to touch? Do I want it personal, and risk future employers to distrust me because of the blog, or too impersonal, so none of my friends will actually read it? I guess I will just have to have a balance between the two. What do my first readers want to read about? Please tell me…

Another one is the language. I mean, I am Icelandic and living in Sweden, and I choose English? Well, I actually thought about it, and I have too many friends from everywhere that neither speak Swedish nor Icelandic. And in my own opinion my English isn’t that bad. If anyone has problems with that, please tell me.

Any topics suggestions?