Archive

Posts Tagged ‘agile’

Agile Testing – Unicorn perspective

February 1, 2013 Leave a comment

So for anyone not attending Agile testing days 2012, unicorns actually became the theme of a great conference through the collaborative work of peers. It refers to the differences and similarities between /the real world/™ and the unicorn world.

If you haven’t read the previous posts in this series, please do. Also do keep in mind they refer to extremes of perspectives.

Bridging communities
Agile Testing – Traditional testing perspective
Agile Testing – Agile perspective
Agile Testing – Programmer perspective
Agile Testing – Project management perspective
Agile Testing – Context driven testing perspective

About the extremes

My friend and Scout colleague shared with me this great analogy when it comes to discussions about things that people care a lot about. At that time a couple of us were talking about the whole global warming controversy, but it applies to many similar debates, like the one about Agile testing. “How come it is so hard for people to discuss these matters without ending up in a ditch and not getting up?” Read more…

Agile Testing – Context driven testing perspective

January 15, 2013 20 comments

The context driven school of testing is a good representation of my personal normal state of mind when it comes to my profession. I really like to hang out with like-minded people that are outspoken about belonging to this community of testers. I also recognize many of the people within this community to be interested in and are practicing good Agile testing. When I started to write this post I also realized I gave it a shot 3 years ago, when I still hadn’t wrapped my head around context-driven. But although my knowledge and experience has changed a lot during that time I still think the post is valid in some sense.

Before continuing, read my previous posts in this series:
Bridging communities
Agile Testing – Traditional testing perspective
Agile Testing – Agile perspective
Agile Testing – Programmer perspective
Agile Testing – Project management perspective

Context driven testers

Similar to the Agile movement, the context-driven school has a set of principles (http://context-driven-testing.com/), followed by explanations to them for clarification.  Read more…

Agile Testing – Project management perspective

January 3, 2013 2 comments

Project managers are very different from programmers. But then again, there are also many similarities when it comes to their relationship to testing. In this post I will mention the PMI community as well as facilitation communities Innovation Games and Gamestorming. The biggest reasons for my learning within these communities relates to leadership.

Before continuing, read my previous posts in this series:
Bridging communities
Agile Testing – Traditional testing perspective
Agile Testing – Agile perspective
Agile Testing – Programmer perspective

Project managers and facilitators

Like the programmers, also project managers as a community is very diverse. Even worse, their craft extends beyond software development to all other businesses. Read more…

Agile Testing – Programmer perspective

December 28, 2012 3 comments

I meet programmers everywhere I go, it kind of goes with the job as tester. They are of very different caliber and mindsets, so just as with my other posts in the series, I will generalize alot. There are many good programmers out there, and many of the people I have worked with really care about these things, just sayin.

By the way, read the other related posts:
Bridging communities
Agile Testing – Traditional testing perspective
Agile Testing – Agile perspective

Programmers

I do acknowledge that there are different programmer communities, although when I have engaged with them they look very much alike from my tester perspective. Read more…

Categories: agile, testing Tags: , ,

Agile Testing – Agile perspective

December 27, 2012 4 comments

Did you miss my previous posts that relate to this? Consider reading these as well. And yes, I will be exaggerating in this post as well.
Bridging communities
Agile Testing – Traditional testing perspective.

Agile communities

I did explain some parts of the Agile perspective after I had been to the Agile conference. Some of my experiences also come from the local Agile communities like Agile Skåne, Öredev and my company Jayway. I will mostly relate to the global community here. Read more…

Categories: agile, testing Tags: , ,

Agile testing – Traditional testing perspective

December 19, 2012 9 comments

If you haven’t read my post about bridging communities, please start there.

In many of the places and discussions I have been this year, people have been trying to define what Agile testing really is. And it is quite interesting that even 3 (almost 4) years after THE book on Agile testing came out, people are still trying to define what it is. What has interested me more is the fact that I’ve seen the area evolve in different communities, and that is what I want to share. I will talk about some extremes in communities, so forgive me if I step on toes. I am emphasizing other peoples opinions to make my point. Read more…

Bridging communities

December 17, 2012 9 comments

I love communities, hanging around smart people that have their main interests of which they are really passionate and also often very good at. Personally I prefer blending into different communities, getting some of many different things rather than to delve very deep into something in particular. I think its my curiosity and kind of systems thinking mind that wants to stay up to date with a lot of things. I also like to keep my spectrum broad with regards to the knowledge I take in, and then I can filter the good parts myself. Read more…

Working with expectations – Software quality characteristics game

April 10, 2012 5 comments

When working with our mission of creating an organization wide test strategy I was thinking about quality related problems we have in some projects. I realized that the expected quality is not explicitly stated anywhere. This means neither customer nor development team are aligned about which level of quality is expected to be delivered when done. I needed something to achieve a better awareness of quality requirements and a light weight way of stating them explicitly. Read more…

Elaborating on DET – ETDD evolving?

January 5, 2012 11 comments

I got some positive response about DET that I wrote on my blog and in my CAST session proposal, so I thought I would elaborate a little on where I think this could be going. I will probably cover more hands on aspects in the coming weeks, but I really want to explain a vision I have around it first.

How about including the business stakeholders?

In my current project, I started to involve our main business stakeholders in our test sessions from the start when I got involved. And they have gotten really excited about attending once a week. Read more…

Organization wide test strategy – Step1 – Deriving our quality values

December 1, 2011 Leave a comment

This post is originally posted on our company blog, any feedback is greatly appreciated.

Our company has moved more from delivering individual consultant services to taking whole in-house product commitments delivered as a service to our customers. During the last months we have also been in a process of re-evaluating the core company values. Through this values work it has been clear that we want to feel proud about the quality delivered to our customers.

The transition in itself has evolved in a good agile manner, where a bigger quality initiative was a natural step forward. My first task was to investigate the current (not explicitly stated) quality values and propose an organization wide quality vision which has been lacking. This post will explain what I have done so far and the further work on it. The further work consists of defining models and activities to use in an implementation of our values.

Since quality covers many aspects of software development, it was clear at an early stage that our present status was not always that the product itself was of bad quality. Sometimes the development team think the quality is bad but the customer is happy, and sometimes the other way around. It actually goes down to managing the expectations of all stakeholders (team, customers, end users etc) and maximize the perceived quality accordingly.

Read more…