The modern tester

I choose to healthily ignore the various various debates around the place of the tester, as it hasn’t changed that much. With every wave of new developers, comes along the same misplaced arrogance that they can do no wrong.  The chips have yet to leave the shoulders.  

Why the good testers disappeared

… and why they shouldn’t have. It is relatively easy to see when and why some form of disillusionment occurred in testing world, after a few years of increasing hype around it. There were many healthy discussions around a tester’s place on modern Agile projects, and increased focus on test automation skills. It was when the context-driven school of testing put it’s hands up and fairly stated it could not be considered relevant. After all, what stays still in software development? The whole evolution is based on learning from mistakes, and improving programming. It is an interesting time, because once again testing has to reclaim it’s position, in the new surge of “testing is dead” mantras.

Testing is still alive and always will be

As usual, the swing against testers has gone way too far (again). More technically competent, sure – but advertising for testers, focusing on programming ability alone will get you another developer. And maybe someone who neither a good tester or good developer.

I am quoting myself from a linkedin update, but what the hell – after 17 years in QA, I think my views must be valid enough to quote. 

[Fill in the blank] is dead

Next time someone tells you “testing is dead”, ask them “what are you hiding?”

So who started this annoying pronouncement trend? I think we can safely blame Google (GTAC 2011: Opening Keynote Address – Test is Dead).  If you watch the whole talk, it is more enlightening, and less melodramatic that the title implies. 

Part of the team

I sometimes take what is called a busman’s holiday – which in contracting terms means work away from the management side, and more in actual testing activity. This is valuable for me, as it keeps my skills fresh (and good for company as they get a more experienced tester). It also allows me to see the project from a different angle, to put myself outside of a comfort zone into more direct dealings with other testers and developers.

Why Agile becomes [Fr]agile

Its a bad joke, that’s been around for a few years – usually as comment on how Agile has failed, or is perceived to have failed, down to the methodology itself, rather than people/implementation.

What really frustrates me around Agile is the misuse of roles, and and creative accounting around Agile process.

Operation Chokehold is coming

Christ, spare us all from whining iPhoners!  Interesting (but I am sure random) choice of picture, putting iPhone users in role of  evil Darth vader, and AT&T in role of lowly Empire “cannon fodder”.   I read this article, then read the associated stories and thought – well that makes total sense. Bandwidth is not unlimited, whatever mobile broadband sales/marketing says.  If you think about it, how can it be?  And the millions of Nathan barley iPhone users are clogging up the airwaves with trite shallow data.  So I say f*ck ’em, and go for it AT&T – iPhone users want to try and bring the mobile network down?  Get a life and protest against something that actually matters – this is just shallow, but in keeping with the average iPhone user profile.

Watch out AT&T: Operation Chokehold is coming

The Art of User Stories

User story approach is sound, but as with all things simple, it can end up complicated.  The main reason for this is not observing the fundamentals of a user story.  Also, it is worth keeping in mind a user story AND the scenrios breakdowns should be clear and understandable to ANYONE, whether they are a user, stakeholder, developer or tester.

To address what a user story is, lets start by saying what it isnt:

It isnt a “mini” Use Case
It isnt a complete specification
It isnt a contract (User Stories can be amended at any point – Agile welcomes change)
It isnt intended to be interpreted without a Product Owner (this is simply not Agile)

A user story template can be illustrated as follows:

As a <User or role> I want <Business Functionality> so that <Business Justification>”

Example:

As an Editor, I want to be able to enable my authors to publish articles immediately to live, in order to avoid delays where delays are unaceptable.

This user story can be broken down into senarios, i.e. the different conditions where an author would need publish to live, without going through an Editor.

Scenario 1: When an article needs editing because of libellious content
Scenario 2: When no Editor is available to vet articles.
Scenario 3: Articles delivered from trusted authors external to company.

…… etc.

These scenarios become the breakdown of the main user story, and indication of work required.

Depending on scope of the scenarios, will determine if the User Story can be deifned as an “Epic”. An “Epic” are  compound Stories, that can be broken down into several smaller, more focused stories, and may encompass enough work for several Sprints (iterations).

Some guidelines to writing good User Stories

• Tangible acceptance tests can be written against User Story
• The scope of the User Story is manage-able enough for the team to provide an Estimate
• Is independent and do not rely on other Stories
• Sized appropriately (i.e. have a level of effort which the team can comfortably achieve in the duration of a single iteration).

Permanent work – live life like a 5 year old

If you work in IT, do you do one job or many?  Or more the point, do you think you could do.  Most permanent workers in IT are either seriously under-worked (the majority) or hideously overworked (the talented minority).  I have never had the experience of permanent role in IT, so cannot comment of the differences between the two.  I do know for a fact that contractors/consultants are generally far more productive, as there is service element in both expectation and delivery.

What got me on this was when I added another website project to my linkedin account.  This spawned a number of automated emails from agencies, congratulating me on my new role, and to please consider them when I am next looking.  Rather irritating, but I am over 40 now, so easily done 🙂  The UK are lagging behind as usual on fundamentals, when most of the things we seem to celebrate these days in terms of progress are shallow (this will deserve a whole separate post!).  Permanent work has had its days, and even the younger generation are clinging to this outdated concept.  It is down to a childlike mentality that your employed should provide everything for you, down to wiping your ass.  How about doing a job well – or is that out of scope for workers rights these days?

Should I employ 2/3 people when all I need is a competent 1?

Of course not.

Test, Don’t Test

It’s easy to take testers for granted – the expectations is for testers to contribute to qulaity, while at the same time this expectation suddenly disappears when test results mean bad news for the release schedule. It is always a puzzling position for QA Manager, as part of the role is total adaptibility (within reason) to the project environment and demands. It is easy enough to reel off standards for Agile, SCRUM, RAD – but when it comes to enforcing them, it is amzing how quickly quality standards are suddenly seen as part of the problem by development, rather than highlighting problems.

Having pushed through project releases myself, when I didnt entirely agree with it, I know that working in QA can be sometimes precarious. I would like to think my reasoning for pushing releases through was sound – sometimes a short-term decision is needed to ensure the overall success of the project.