As usual, the swing against testers has gone way too far (again). More technically competent, sure – but advertising for testers, fousing 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.  I find it frankly tedious the swings between valuing, then devaluing, testing.  Even more annoying is this time around, people are confusing the task with the role.  And the role has changed for sure, for the better – unfortunately most have seen it as a chance to cry “testing is dead”, with accompanying subtext of “tester is dead”.  Again.  The day software testing is dead, is the day that testing has it’s name changed to something else that means the same.  The idea of any engineering being completed without testing is utter horseshit.  And spoke either by developers with a arrogant sense of self-worth, and sideline pundits looking to make a make by being “controversial”.  I call it being a sad desperate prat.

Whilst testing is always under the spotlight when project trimming is under discussion, what is never discussed is the wealth of crap developers out there.  When a project goes wrong, the assumption is always it must be problem outside of development.  That is only examined later, usually when too late.  Testing has always been an underdog on a project, and part of the reason I like it – battling ” we don’t like outsiders” mentality is a pleasure, and defending testing’s place also.  As such, it is also an easy scapegoat, especially for bad developers or managers, covering their backs.  Oh yes, don’t fall for the flowery language of Agile, as unfortunately the averahe compnay culture doesn’t allow for such “enabling” or “transparency” or “trusting self-organizing teams”.  Don’t get me wrong, Agile principles are good stuff – almost a no-brainer.  But Agile was supposed to apply to more than “the team” and process of development, it was a new way of working.  I don’t think that was clear enough in Agile world, but maybe simply assumed rather than specified. According to many at the time, Agile manitesto didn’t reference testers – no, but it was designed to be a high level manifesto, and what is mentioned is “quality”.

The “testing is dead” mantras don’t bother me, because those same people will eventually fall flat on their metaphorical behinds.  As I have seen many times over the years. So don’t worry, testing is still alive – and always will be

Plugin Details

• Plugin Name: Post Map
• Plugin URI: http://jaffamonkey.com
• Description: Add coordinates post meta based on location, and display map widget in sidebar.
• Version: 0.1
• Author: jaffamonkey
• Author URI: http://jaffamonkey.com
• License: GPL2

INSTALLATION

Download plugin

Download from wordpress.org

1. Upload plugin folder to Plugins directory of your WordPress Installation.
2. Activate!

On your Add/Edit post form you will see an additional location field. You can type a full address, or simply just a postcode/zipcode (best to add country also).

To display a map, there is a “Post Map” widget, with option to set Zoom level, map width and map height.

“Please call Stella. Ask her to bring these things with her from the store: six spoons of fresh snow peas, five thick slabs of blue cheese, and maybe a snack for her brother Bob. We also need a small plastic snake and a big toy frog for the kids. She can scoop these things into three red bags, and we will go meet her Wednesday at the train station.”

You can hear these words recited 1,300 times at the online speech accent archive at George Mason University in Fairfax, Virginia – and every one is different.

I guess it’s probably a little obvious where this is leading too, in context of a technical blog – a comparison with requirements. While I realise BDD is not the whole solution to development, it does keep focus on key area, which is what the client wants. It doesn’t take long for requirements to become muddied by people’s different take on them. A thoroughly underestimated skill, is writing user stories that are both effective for the client view and the developers guidance. BDD sought to use DSL to bring requirements closer to code, by creating a partly-automated path from a user story (or feature), to automated test script that essentially defined the pseudo code that a developer could use to produce the functioning code.

The theory is easy to sell, but it requires high skills in analysis and coding, to truly work. And never assume BDD to be a whole solution – we are a way off that point yet!

A consultancy has people to retain, and a full business to run. If they don’t have resource, they will usually bring a contractor on board, who flies the consultancy banner. Because they sell themselves as an entire Quality Assurance and testing company, you can be guaranteed on a instant price hike from outset. Once established, they won’t want to leave, unless they have to. The nature of consultancies is create paranoia that you aren’t doing everything you need to.

The question is are you going to put your faith in a consultancy, where resources and longevity are primary motive? Or the consultant, and one who is driven by new ideas, desire to learn and is adept at approaching even the most budget-tight projects with positivity and pragmatism?

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.  Most notably, the talk includes key ideas around why “Test is dead”.  First and foremost, the “Test” referred to in the keynote title, is referencing the role, not the actual activity.  And this does immediately throw into question, why would anyone would even think testing was dead at all.  There are two ideas in the talk, which I believe sum up the change in testing:

• Less people in test leadership – this has been decreasing rapidly, and the ramifications of this have been catostrohpic for the testing world.  For a few years, anyone seems to feel qualified to define what testing is, what the tester role is.
• Tester as role, has become redundant – a fair comment.  Testers do need to become more like programmers, and developers can’t afford to be so smug either.  I see this as a natural merging of the two roles.

The problem with comparing yourself to Google is plain – they have a lot more skills to hand, and you can bet your life the line between tester and developer exists, but blurred together. Not common skill set at all yet. Most modern developers don’t even understand the point of a tester, especially those who have just popped out of a programming certification.  Testing has been outsourced increasingly, though there have been new challenges that arose from that approach.  Hard to manage, and hard to trust.

The desperation to demote testing to non-existent activity has moved beyond tedious. The same individuals no doubt predicting the death of anything that doesn’t fit their predefined parameters, or the deluded sheep that blindly follow the Google model of software development (but without the skilled resources to do so). Some even trying to reword the same phrase, in a different way. But the same message is still clear – there is no need to testers – developers and users are enough. The mantra has some basis in truth that pure testing itself is not enough to be a tester, and the same is true for developer role also. Developing and testing by numbers, is fast becoming obsolete.

There is a repeated pattern in development world, of making largesse claims that other areas that contribute to the successfully project lifecycle are “dead”. When you root through the arguments, largely this argument is justified down to either a new tool or approach. TDD was long used as argument against having dedicated testers, as is BDD – but if you check out any forums you will see many developers complaining about tools or approaches. And mostly not because they don’t work, it’s because of a personal opinion based on an indivdual’s own preferred method of working. There are many developers who do not like creating unit tests, or using BDD tools such as Cucumber or Specflow, because they increase workloads. Yet these, and other tools are routinely used as justification for “testing is dead” mantras.

What I read into the “testing is dead” mantra, is that i masks a defence of a project team’s way of working -whether right or wrong. Testers can be end users or stakeholders – anyone except someone within the team. So why does a project team prefer stakeholder testers? A happy stakeholder can be easily pleased – a tester can not be pleased so easily. A stakeholder is not only testing, they are checking on the progress of the product. And they are doing these things with limited view of what is goijng on. Testers are embedded in the team, so have more information as to the real state of affairs.

An attitude that belies the underlying problem usually within project teams that behave this way. A developer may say on the one hand that regression testing is pointless, given the Continuous Integration method of coding. But what people say doesn’t necessarily reflect what is actually happenning. While the team may be aspiring to Continuous Integration way of coding, without the external view of a tester, it can exist as solely that – an asipration. A tester highlights the difference between the project team sell job, and the reality.  I have seen it so many times – a project touting various nbew tools and approaches, only to be thoroughly disappointed once I look under the project “hood”.  Tools such as Specflow and Cucumber are touted frequently, but mostly languish in use after a while, down to either sheer laziness or simply lack of coherent approach to getting whole project team to use them.

Stakeholders/end-users are important and useful for user acceptance testing. But to make assumptions on your stakeholders beyond user acceptance testing, to treading in a skilled area that requires far more than simple vested interest in finished product, from end-user persepctive. But that is not what this is about – it’s about keeping the business out of the team, and testing is viewed as partial enemy in this respect. We are there to test, report and contribute to the project, but we do not allow ourselves the comfort of feeling that everyone outside the project team is wrong. Everyone on the team should be like a tester – questionning, learning and never making assumptions.  An Agile team member is a cross-functional resource, so are job titles relevant anymore at all?  While the role of “tester” is fast becoming obsolete, testing is an immortal task.

So do I have a view of what testing in modern world should be? Or is it really about presenting it in a more modern context? Probably largely the latter. Re-inventing testing seems a tad self-defeatist, as tied in as it is with development. The Agile team included anyone contributing to the project, outside of management – it didn’t omit testers, or by same token, it was dismissing developers. The important part of being a modern tester is ability to integrate with the team. And contributing to the team effort – evaluating requirements, maybe a little help with development, building up more tests for effective CI, improvement of requirements process. The modern tester should have more in their armoury than ISEB, or following a guide they found on the web.

I enjoyed recent BDD projects, and for myself, this illustrated the place of modern testing, and not just in BDD context. The idea that requirements to code process is an entirely collaborative one, and one which demands more skills than traditionally required. In order to move forward, we need to learn new things anyway. Testing languished in the sidelines, because it was too easy to avoid change and learning, and still find plenty of work. Testers need to voice up more – developers defend their areas with gusto, so why not testers?

There is a lot to learn for a new tester, so senior testers are vital to ensure a newer tester is not swamped which can happen quickly, if testing requirements change/expand rapidly. Then a measurement of experience is needed to evaluate what testing needs to be done, and this is learnt by experience. You can define guidelines for actual testing, but as soon as you nudge to areas of test management, it is prudent to be cautious.

HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. This is the main reason that it is difficult to implement Web sites that react intelligently to user input.

We are still tied to a web infrastructure, desgined primarily for text, and “souped up” by various other technologies (ActiveX, Java, JavaScript and cookies etc.) It’s archaic, it’s tedious, sold as magic when it is in fact a smart evolution of networking, hardly worthy of the romantic futuristic ideal.  Apparently anyone who has a  new web service venture by anyone under 30, is the new “Mark Zukerberg”.  That alone is a damming statement, as facebook is still firmly rooted in old-style web 2.0 control freakery.  Nothing is forever and http is no different. At the moment it is being used (ironically) as covert information gathering, i.e. mostly text.  I have no doubt there are advances and alternatives already, but the “big boys” have a lot more uses, to screw out of the old system yet.

For a partnership to work, all parties must place a higher value on the advantages of shared work and risk than on the efficiency of making unilateral decisions and keeping all the loot.
Perils of Partnership

It’s always a gamble working on new venture with business partner, and I have always struggled to meet my match (so to speak). I know my weaknesses. In website design, I lack visual flair. I lack salesman, but very competent in managing client expectations. The problem I have found is that what I do naturally, other find hard – which is to learn, and accept learning is a contant progress. This resistance to learning can prominently manifest itself in a “I just want to manage/coordinate” attitude, as if that ability doesn’t have same requirements. Stand still long enough, eventually you will get run over. This attitude leads to a strange imbalance where the partner who is struggling to be a partner, attempts to manage the other. Doomed to fail, as that goes against the very nature of partnership, or indeed any relationship.

My lesson was to ignore the “sell”, and wait for proven ability. And it usually doesn’t take long. Whereas I will naturally cross boundaries, to fill natural gaps left by start-up hierarchy and responsibilities, the partner may quickly resist moving out of their perfuntory assigned title. As any self-employed person will know, most people like the idea of taking a gamble on an interesting start-up idea, but most will quickly lose interest once they realise it is way out of their comfort zones. It’s not for everyone, as most are used to a “Mortgage-driven” mentality, which is naturally self-oriented. Think of those armies of perm staff out there plodding in careers, or making a career out of responsibility avoidance. Not all of them, but those are the ones that keep companies moving and exploring.

Starting a business with a business partner can usually cause more problems than it solves. This is usually the case when the partners are unable to agree on the same thing, the amount of responsibility for each is different, and the direction of the business is different as well. These differences can cause a business to fail quicker than anything.
Problems with Having a Business Partner

So my search continues. I operate very well as a one-man band, and have a wealth of expertise, experience under my belt. In addition to a wide network in development and testing, to provide support is more specialist areas. Maybe my search is futile, as it seems the way I have always worked and operated, appears to be more in tune. Consultancies can quickly muddy the picture of what a client requires, as financial rewards is measured in terms of scope of work that the client can be convinced they need. And as I have never agreed with the weak “all’s fair in love and business” (a phrase adopted by the winner, naturally), I cannot agree with this model in any event.

References:

¹Perils of Being In Business with Women
²Perils of Partnership
³Problems with Having a Business Partner