The dark art of testing in agile

***I am now back at Software Education teaching and consulting around testing and agile . I’ve just recently rewritten our Agile Testing course (ICAgile accredited) and this is my blurb on the course before I teach it on the 7th October for the first time (see http://www.SoftEd.com). Also I haven’t written anything here in a long time and being prompted by something else I sent to Lee Hawkins, I thought I would post this here as well***

Testing is like the dark arts. It hides in the shadows of projects probing silently, mocked openly and looked down with disdain by those who think they know better. But do they?

Testing was seen like this even by testing consultancies as they espoused the rhetoric that testing is simplistic, mechanical and artifact driven. The implied idea was that ‘any one can do testing’ was prominent. Fortunately two communities began to challenged these ideas. The context driven community broke the fallacies of mechanical, simplistic testing to human based, skill based, thought provoking investigations of self, product and relationships. The second community was the agile community who helped challenge the ideas of heavyweight documentation and adherence to process to one of experimentation with short feedback loops. With this came a more technical approach to testing using tools to assist (though sometimes there is an overreliance on these tools).

Our agile testing course looks to combine these two communities together by building key skills around critical thinking, using heuristics to build solid testing models and focusing on quicker feedback and leaner documentation. In turn, building these key skills then help testers to be better equipped to understand the agile context. Testing in an agile context requires quick, critical, skilled thinking and combined with some technical understanding enables testers to answer this question – How do I add value to my team today?

Our agile testing course is very hands on and experiential and looks to increase testing skills that help you become better in your role and add value. Testing is no longer in the shadows – it is front and centre and is our mission to help you to become indispensable to your team.

The question for you though is – how much better do you want to be as a tester?

Advertisement

Whom shall I serve?

Tweet – Mike Talks – KWST#2 – June 2012

Whom shall i serve?

A song, a hymn, or a reminder as to who our customers are? Who do we serve and why is that important?

During KWST#2 (June 2012, Wellington, New Zealand), the discussion about whom  we serve came up.

Mostly, the answers tended to support the obvious conclusion (to me at least) that whom we serve could be:-

Our employer(s)
The project manager
The developers
The business
The test manager
The test team
The project team
Our family

And these are all valid customers/people/organisations/groups that we give service to in some way. But there is one other element that sometimes we don’t consider…

Ourselves

Whom shall I serve? I think first and foremost it is ourselves. We are responsible for our own work, for our own ethics, our output, our own learning, our own interactions with others, our own interactions with other testers and our own interactions with the software testing community.

Sometimes we take a high degree of responsibility for one or some of these things and sometimes we don’t. What may be important is that we come to understand that we also serve ourselves and by seeing ourselves as a customer (if you will) then it allows us to appreciate who we are as a tester, what we can deliver, what skills we have and what we stand for.

Too often I have seen testers wilt in the face of criticism (and scrutiny for that matter) from management attempting to justify testing or test artifacts or activities. Knowing what we stand for gives us a moral ground to argue from. Unfortunately, it doesn’t mean that everything will be *perfect* because we are conscious of our position but at least we know our tipping point.

So how do you deal when reaching your tipping point?

Well, that does depend but some of the ways that I have used have been:-

• Educate those that may be pushing you towards your tipping point – (in my experience, it is typically a manager)

• Listen to those pushing you to your tipping point – (it is possible that we don’t understand their context)
  

• Use your influence and credibility to help educate

• Employ a stealth approach – (one project I was on, the project wanted test cases (with expected and actual results) and use what they saw as structured testing. While we spent time giving them what they wanted, the majority of the issues during test execution came, not from the test cases, but from an undeclared exploratory approach. OUR plan of attack became give the customer what they wanted, educate them along the way and use good exploratory testing to find valuable information *quickly*. The test cases in this instance were our checks, the exploratory test charters, our tests. The stealth here was from discerning the clients context,employing what became a blended approach and not necessarily letting management know that this is what was happening.)

• Leave – (this is most likely the extreme option but sometimes it is more beneficial to/for you to leave a project/employer/organisation than having to adhere to rules that may not make sense. I have done this, it was a challenge but I’m glad I did it.)

So, whom do we serve? Ourselves first (it’s not as selfish as it may seem) and then those mentioned above. Putting ourselves first means that we are taking responsibility for the quality of our own work which means in turn, we are better placed to serve our customers.

Entaggle – a website built on reputation

Elizabeth Henderickson has create a new website called Entaggle which allows users to tag another user with a reputation tag. I think this is a brilliant idea and in our testing community this may hold more *weight* than a traditional cv.

Check it out!

The Joy of Being Amongst Fellow Testers

I recently delivered a presentation on Session Based Test Management to the Auckland Test Professionals Network. It was my first presentation. It was fun and I really enjoyed being there.

For me though, the enjoyment factor came afterwards in talking and discussing software testing with other testers.

I noticed something.

There were some testers that had come to learn something. Not everyone did but I’m sure most took away at least one idea or thought. And my thought is this – why don’t we (software testers in New Zealand) actually share our knowledge a lot more?
Some of us blog, a number attend SIGIST meetings, conferences etc but we then either sit on that knowledge or we’re not sure how to share it. IF we grow our community, our discipline then we all benefit!

I was talking to Farid Vaswani and John Lockhart amongst other wonderful testers there. They were very willing to share their own thoughts and ideas on testing and we had a great discussion and explored multiple testing ideas.

Which created a second thought – since we geographically limited,and we are not able to mentor or share and discuss ideas easily in a physical sense, there are a myriad of ways to achieve this online. So i created a Google group called Software Testers New Zealand. And while it’s aiming for a New Zealand flavour, it is in no way limited by country. So if you are outside of New Zealand and wish to become part of this growing community, feel free to join and share your ideas and thoughts!

By doing so, lets mentor each other and take the best from each other.

Happy testing!