I still haven’t had a chance to read the full article, but I did watch the video and had to shake my head. The problem? It’s by Atlassian. I mean…has anyone used their products? Not exactly a shining example of high quality.
Someone on LinkedIn used the phrase “conference driven development” recently. I really like that term for it—trying to implement what some other company did or what some conference speaker talked about without understanding the differences in context or, in this case, considering “how’s that working for you?”
I’d like to dissect this in two sections. “conference driven development” sounds a bit derogatory. I would argue this is the whole point of conferences: to learn other ways of doing things, new ideas, new products, etc (along the usual social networking). So this part is something I’m OK with. The other thing what you mention is the non-understanding the differences in context. Yes, that is the problem if people just blindly start shoehorning wrong ideas in the wrong place.
Like @mwinteringham says in his new MoT certification, it’s all about context and one has to learn to recognise it and utilize it correctly.
As for Atlassian software… it’s becoming like old-age Microsoft, where everyone hated it but still everyone was using their software
I would argue it comes down to software customization or should I say, the lack of it by teams and organisations. I’ve been on countless teams that were banging their heads how stupid the sofware is because it doesn’t let them do-this-and-that when the issue was actually they A) didn’t customize it to their needs and B) they didn’t even bother researching what can the tool actually do (a ton of stuff is usually hidden behind premium/licenced versions).
The problems I’ve experienced with Jira specifically aren’t a customization issue—they’re often design issues like “we’ll allow more people than you have licenses for to create accounts, but then restrict access for everyone”, the long-standing display bug where the “Create” button gets covered up if you have a number of plugins, or subtasks only really being half-implemented. It’s also amusing to read the comment history on some of the bugs people submit—one (might have been the Create button but I can’t remember) a project manager closed with the explanation “we’re going to be completely rewriting this part of the system in 18 months or so, so this won’t be valid”. Several years later, the bug is still there
If acceptance criteria passing = 0 bugs then I feel sorry for the customer whose path through the software deviates in anyway from the assumptions in that criteria.
I think that for me was also one of the harder things to get my head around.
I’ve spoken face to face with managers who use the model, I highly respect them and got their point to a certain extent. If they find something not in the AC that’s deemed important it gets added to backlog and given a high priority.
The challenge for me was they felt due diligence from the team throughout would discover these things naturally and without testers were sort of not actively looking for these things. Or they could argue they were actively looking for these things throughout but not with testers.
I’ve seen projects that can work without testers, normally very strong developers and less potential product risk and impact if something is missed.
My own stance is that its a question about risk on whether pro testers are needed or not, they will always add value but are they needed is a risk profile question to me, are the risks important enough.
Whilst I agree that no testers on a project doesn’t automatically mean that important bugs will be missed, in my experience there is enough of a difference in mindset between developers and testers that significantly impacts the thoroughness of product validation. I’ve had workloads sent to me from developers that were completely broken as they had just assumed they would work.
You have some serious people issues. All the stuff you’ve wrote it sounds to me it’s a fault of people and processes, rather than the tool itself:
licenses & access: yes it always pains me to see how much Jira costs the company Having more people than licenses is a big red flag. Company is either too miser to open the wallet or internal team and people delegation of who does what is not clear enough
too many plugins: not paying for licences but paying for a ton of plugins that clog the UI? That sounds like a big anti-pattern too. Most of the time no plugins are needed at all, just smart use of advanced Jira features that come out of the box (of course, “big” plugins like Zephyr, X-Ray etc should be present)
comment history: there are some companies that hate comments so you get 0 comments and 100 Description updates. Then you have those who never modify original Description but instead write 100 comments and u need to spend an hour reading and getting up to speed WTF is to be done in the task Again, process problem
tasks half implemented: people problem.
Disclaimer: not taking a stab at you personally @c32hedge and I’m no Jira affiliate either just taking the opportunity to voice my opinion that for a lot of things that we blame some tool to be the problem, we can fix with better planning and learning of tool’s strengths. But of course, some limitations are such that no magic wand can fix it so we’re forced to switch to a different tool
I think you’re misunderstanding all of my examples:
licenses & access: first, regardless of a customer’s willingness to buy enough licenses, the Jira design is stupid and broken. A much better design would be, if a company has N licenses, to prevent the N+1 user from creating an account at all. Second, as for my company, we happen to have thousands of employees, many of whom never use Jira, and as different sites and teams adopted it there was an inevitable rampup period. It isn’t that the company didn’t want to buy enough licenses—sometimes the pace of adoption simply outpaced the rate of buying additional licenses.
too many plugins: again, whether it’s a good idea to have a lot of plugins doesn’t invalidate that Jira supports having them and should fix their css styling to make the Ui usable when they’re present. Also, I wouldn’t even say we have that many plugins, and also we have multiple disciplines using Jira (including outside of software or even outside of R&D) so some groups use certain plugins that others don’t.
comment history: I was talking about comments from Jira employees on issues entered against Jira itself. At least they do dogfood their own product.
tasks half implemented: I was referring to the Jira concept of “subtasks” where a single “issue” can be associated with multiple issues of type subtask. The subtask issue types are not fully implemented so attempting to use them is a big pain.
I’ll try to look up the specific issues related to these on Jira’s Jira soon.
Tnx for explaining! Wow, reading comments for actual Jira bugs is pretty hardcore
I’d ask you if you have any Jira alternative favorites but that’d already be too offtopic for the original post. I’d say any Jira project that has no test-related plugin is already a bit in the No Tester model. Even standalone Test Management Systems like TestRail have a Jira plugin.
@andrewkelly2555, thanks for starting the topic post. If you had three key takeaways from the discussion and your original question, what would they be?
Thanks Simon, I got a lot of good points and a few to think a bit more deeply on. A few takeaways.
There is definitely a level of confusion from many testers.
A lot of testers seem to be doing activities which developers could likely be doing equally well, perhaps better and almost definitely more efficiently.
It would be easy to assume this is the reason for these models and that perhaps they have just not been exposed to testers with a solid, discovery, investigative and explorative approach. That assumption though can be seen as dismissive so I’d recommend going a bit deeper, face to face with backers of this model that you respect their ability to take different views on board and see if there is a balance to be found.
As testers we do want to defend the value of what we do, we have convinced ourselves but perhaps we need to up our game a bit to be able to convince others of that value, that really needs to be done by doing in my view, words particularly online are not going to convince others. It can be a tough sell and I still struggle with it even with other testers whose testing model differs significantly from my own.
It remains important to be aware of context and details of that context. Zero bugs and 100% automation will sound absurd to some testers as we can see from some of the comments. When people use those terms they usually have narrowed the context to make them plausible in certain conditions, avoid being triggered and try and establish what could make the absurd plausible in the mind of someone else.
I also stand by the view of not getting sucked into an argument on this topic, make your point, determine if they are open to other views and input, if not walk away.
I have a beef with devops enthusiast people on this. The sane ones amongst them are usually the better since they preach a shift left approach that encourages hands on testing as well.
The other, they just claim the code can do everything!
The concept of the ‘No tester model’ is akin to that presented in the book “How Google Tests Software,” which was published in 2012, making it not a recent release.
The book discusses three distinct categories of software engineers: Software Engineers (SWEs), Software Engineers in a Testing Capacity (SETs), and Test Engineers (TEs).
From the top Amazon review of the book :
SWEs write unit tests for the software they write
SETs write tools to enable testing without external dependencies and write automated functional tests
TEs coordinate the overall testing activities for a product and focus on the user by doing exploratory testing
Testers primarily act as facilitators and do not conduct testing themselves.
What do you and/or this book understand under “conducting testing”?
Just the interaction with the product? Design and planing? Discussing improvements with others?
“TEs coordinate the overall testing activities for a product and focus on the user by doing exploratory testing”
This is the opposite of what you said. TEs do also testing. How do you explain that?
I agree with @sebastian_solidwork – HGTS was one of the first books I read when I transitioned from a developer title to an SDET/SET title and I didn’t come away from it with the idea that “testers primarily act as facilitators and do not conduct testing themselves”.
Having more people than licenses is a big red flag. Company is either too miser to open the wallet or internal team and people delegation of who does what is not clear enough
