People getting into testing now, are having an easier job – not least because there is a lot more discussion and information around the benefits of testing. And a general acceptance that testing has lagged behind modern development approaches, to extent it was covered in other ways. Continue reading
Without knowing programming, they [testers] can’t have any real insights into the kinds of bugs that come into software and the likeliest place to find them
That is partially correct – if you are intent on becoming career tester, you cannot avoid the technical knowledge that role demands. But this article demonstrates a problem with perception, and forgetting there are many benefits to testers, who are not bogged down in technical knowledge. Yes, the stakeholders do their UAT, and generally raise issues that weren’t foreseen in the general SDLC. The above quote is true, but it’s not the whole story – the whole article seems to assume the developer is king on a project. They aren’t, the client is (or whoever is holding the money bag). Developers are generally the most vocal in criticisms of tester skills – but my experience is developers can get very defensive, if a tester does have programming skills (the game becomes harder for them to play ;)).
I have never written that much about the actual experience of being a tester – in other words, I have never analysed what being a tester means. In light of the pleasant surprising Forbes poll on happiest jobs, it made me think of why testing could be a happy role. The survey was based on US figures, and I know the world of technology is generally 2/3 years ahead. While we were still suffering projects in Agile delusion, the US were already in “lessons learnt” zone. I believe that survey result points to the positive surge of appreciation of the place of QA, and acknowledgement that it needs to be taken more seriously as a role, rather than a demoted task.
When I started out, most contractors were generally in older age bracket, as contractor used to mean you had enough experience to warrant the title. Now it doesn’t seem to mean much beyond that you are prepared to work and be paid in that way. Testers were a very different breed to how they are now – far more leaning towards analysis than development. The most important part of a tester was considered to be attention to detail and documentation – how you designed a test case was a basis for judgement, and level of detail over efficiency. What they also possessed with was a pitbull mentality when it came down to chasing up on bugfixes. What hasn’t changed is the never-tiresome bug versus change request debates, or the lack of understanding of the value of a tester. One of my first contracts in Belgium was particularly memorable for the Guy le Roche wearing Doncaster lady who reduced the (inept) project manager to tears one day. She was not technical tester, but what she was expert at was Quality Assurance and was pedantic with requirements coverage. To suggest she was a bad tester, based on judging technical skills is just plain wrong.
The poor old world of QA – no sooner we make our mark in Agile (after being excluded from the party, for being project dorks), then Lean swoops in. And I am already hearing variations on the old “we don’t need a tester” favourite. This phrase is largely used by paranoid developers, or tight-assed project managers. It’s annoying – if you haven’t got a lot of budget, fine – but why be stupid and risk quality? Stupid is the right world – we are working in commercial world, and I wouldn’t want any of my managers demoting quality. Whatever the demands and deadlines, skilled project planning doesn’t simply remove steps to shorten path to the goal. It’s lazy and self-defeatist.
When Agile popped it’s head up, people thought tester as role was on demise, as in Agile the developers and stakeholders do all the testing. This limped along for a while, success largely dependent on competence of development. The surge of projects on the “woollyweb”, led to more companies than ever before were exposed to the software development lifecycle. Though many were in denial of that for many years.
So the modern tester? Never before has so much been demanded of a tester – analysis skills, automation skills, a myriad of technical knowledge, and understanding of project processes. And something traditionally difficult for people who work in the IT industry – communication. Yet though these are the demands, testers of this calibre are not common – you will find a myriad of individuals performing testing in a company, some of whom have no knowledge of testing process at all. This is all down to differing opinions on what a tester is and/or does. Whatever power a tester is given, it is usually removed the instant the tester becomes “difficult”, i.e. stands their ground. The position of Test Manager has always been seen as the lowest of the management roles on a project, and that has not changed that much. In fact, this is probably main reason for demise of role, as testers filled the gap left behind.
Let’s not get confused – testing has ALWAYS been a corner that needs enthusiastic defending. In the general course of development/testing banter, there is serious underlying element of win/lose. A good developer needs a good tester to push against, and vice versa. I appreciate my origins more so now, as when I started, testers had to be both thick-skinned and tenacious. No matter how friendly everyone is on a project, when things start to go wrong, and the wagging finger starts to circle … and QA was common lazy target. And it still can be. I was hoping Agile was going to address the prevalent blame culture, but unfortunately all it did was provide another mask, another tool in the mba-speaking manager’s arsenal.
It’s difficult to see the wood (role) for the trees (contracts) – when you spend most of your working life in a role, it becomes more and more difficult to analyse. Without wishing to blow my own trumpet, I get many comments on how much I appear to know. This is result of a combination of skills and attitude – when I don’t know something, I learn it, and what I do know, I improve upon. Is it less about an ideal tester profile, and more about an individual’s general attitude? We fall into traps continuously around attempting to define things in IT, and this extends to people, which is illogical. I think it’s time to stop trying to profile every damn thing in IT – as a well-qualified tester can also be an appalling one. Testers can be good purely down to attitude – good testers address gaps in their knowledge by filling them, rather than trying to find excuses. Programming and other technical knowledge is unavoidable requirement for testers these days, and that’s a good thing.
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.
Should a tester/developers become a combined entity? Or is this simply representative on the increasing demands on a tester? Stepping back from this boringly over-debated point, there are reasons that the question arises in the first place …From QA Management persepctive, there is weaknesses in the path from user story down to code, and the transparency. Slight deviations can lead to major requirements gaps, and ATDD (or the identical BDD – Bahvaiour Driven Design), is one approach that addressed this on paper – but regards good tools available, they are still very light on the ground.
A lot of developers would prefer to be out-of-range of testers – if you want to get into testing, then be prepared to justify your existence by any means necessary. Developers are awash with different types, from geniuses with Aspergers, to self-taught amateur with insecure chip on their shoulders. It’s not your job to judge, it’s to adapt – testing is always about adapting, and in some ways mirrors the demands of a developer career. But without us in QA, the SDLC can descend into a private club, excluding those perceived as “in the way”. It’s a fine line between squashing developer creativity, or allowing developers to run amok. Of course a decent Scrummaster should prevent this, but we are in the real world here.
I hear and use the phrase “keep it simple” a lot. Yet struggle to follow my own advice. In dissecting Agile, I get lost quickly in various (relevant) tangents, but ultimately the same problems in testing remain. Agile fails to properly specify the role and benefit of a tester, demoted to a developer add-on. And as a lot of developers fail to properly unti test, the tester can quickly become a unit tester. Since when did a developer need a PA? Unit testing is a given, regardless of methodology.
My first instruction in testing 16 ago, was to:-
1. Using requirements document, outline test cases from it.
2. Cross-reference requirement to test case
3. Expand test cases in test script(s)
3. Review test cases every release (for amendments or additions)
5. Always regression test with every release (remember this was waterfall era!).
6. Document every issue
7. Document every release test.
Fast forward 16 years and this approach is still very valid, and adaptable for Agile or any methodology you care to mention. Testers are within the SDLC, but also tracking progress at requirements level. That requires a degree of distance from the daily world of development. The UK is sorely lagging behind in Agile evolvement, caught up in the same mess that started a decade ago.
I am starting to think I am caught up in the same illusions around Agile as I think others are. We have been snowballed by this holy grail of methodologies, leading us to believe that Agile is somehow above all. But it will fail if applied without understanding. As would SCRUM. If developers are working in Agile way, and the SCRUM format is properly applied, then you can see the real machine working. Agile has its own management principles, but I (personally) find SCRUM much clearer in this area.
There is common assumption that is rarely mentioned. It is assumed that developers work Agile by default. Given the amount of coders I come across who don’t unit test, I would say this was a gross exaggeration. When it works well you have cohesion from Stakeholder/Product Owners down to the tester. Agile/SCRUM has just got 10 times harder; how to put a team like that together – and for a whole project.
Though SCRUM implementation issues are not country-dependant, I can say from UK side, there is too much made of benefit of mixing roles. This generally is a benefit for budget savings reason, however misguided. Too often than not you will have a Developer/Scrummaster with a Product Owner (full-time if you are lucky). The Product Owner role is rarely assigned on skills, and it should be, as it is akin to a Business Analyst. One of the dangers is the Product Owner becomes Project Manager. Most likely is development of Waterscrum, when release milestones are introduced, rather than Sprints. This kind of project can be successful – as long as Product Owner has become effective Project Manager.
The development team can code in Agile fashion either way, but Waterfall does not easily sit with Agile.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Especially the last line – changing plans in Waterfall is not encouraged. This was how Agile evolved; to deliver software to the stakeholder in a better way technically, and to integrate changes to plan (for whatever reason), and additional requirements. Translating that benefit to a stakeholder during a project is a lot harder, and that is what the Scrummaster and Product Owner should be managing as a team – not one domineering the other. Waterscrum works because the team adapt (assuming they don’t fight back, of course). The two benefits the development team can retain from Agile is the daily meetings and improved communication line to the business. Generally the psychology behind people working on Agile projects is that they have to be more proactive.
Lets be clear, Waterfall was not wrong – but change needed to happen due to increasing demands from business, and more aggressive schedules. The web and opensource were the main instigators of this change. Agile has turned into a monstrosity, and I have heard so many variations on Agile, and how people manipulate it to suit their purpose. I have mentioned many times how I get fear of dread when I start on project and hear the words in first meeting “We’re working Agile!”. “I’ll see myself out” is what I would love to respond with sometimes, but I enjoy the challenge presented by chaos – or seeming chaos. Although people may get it wrong, sometimes you have a team which transcend this – bizarrely working without a methodology or formal roles. But they have the skills and they communicate. And deliver projects; a little scrappy to the finish line maybe, but the job gets done.
This isn’t that surprising – when human beings aren’t given a goal and/or direction, then they will find one. It’s in our nature. Agile/SCRUM harnesses that natural instinct. And then of course there is always a natural leader. If you think about the roles now, it fits with our primal urges to have goals and find paths to them. SO what do I think is needed in the team as a whole.
A strong Agile developer, at least one in the development team.
A qualified Scrummaster
A RELEVANT Product Owner – if they have decent business analysis skills, all the better
Tester(s) (of course!)
Damn – does that make the Test Manager redundant? Not at all, in fact, beneficial to have a Test Manager in the team, who have a wider scope than simply the daily testing, and provides input at planning stages such as risks, weak areas, testing schedule concerns. Test Automation is too big a subject to bring up here, but it is the only way forward for testing.
I still believe Agile works as a philosophy, rather than the stricter guidelines inherent with SCRUM. Different languages and source control tools can provide differing levels of features and functionality. And coding optimally with re-usability in mind is effective coding, whatever the methodology. So by default, the method of build and release should adopt Agile software development principles.