What is LinkedIn?

Software Testing & Quality Assurance (QA)

@standqa
Discussions

Promotions

Jobs

About

199,909 members

Join Today

Join

Sign In

Search

Have something to say? Join LinkedIn for free to participate in the conversation.
When you join, you can comment and post your own discussions.

Andrew Kelly Software Test Management & Consultancy

Are testers who can code, really what Agile teams need?
Before I put my question into context I wanted to be very clear that I do think pretty much everyone
involved in IT should learn to code at some point.
I say this because the benefits are not just about completing coding tasks but that the technical
awareness associated with it really adds value in communication, collaboration, risk identification,
and gaining a deeper insight good usage of automation etc.

About this Group

Created: February 11, 2008
Type: Professional Group
Website: http://standqa.blogspot.com

About

Feedback

Privacy & Terms

LinkedIn Corp. 2015

I am also in favour of all team members asking the question where can I add the most value to the
team today and building skills that focus on value gaps, i.e have secondary skills to for all hands on
deck situations.
If you look at the recruitment market in many cases there does though seem to be a focus on coding
and automation skills being required often as the primary skills for a tester to fit in well to Agile
teams.
Here the real question I am asking is whether these companies are looking at Agile teams from an
optimized team perspective and are they missing some of the key collaborative balanced team
fundamentals and benefits of Agile teams.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Pretty much every Agile team that I have encountered has been overflowing with coding skills, is
there any real reason to put an emphasis on adding more coding skills to a team already overflowing
with that skillset?
Are strong questioning, design and investigative testing skills more likely to be what they really
need?
Id be interested to get peoples thoughts on this.
Are your coding skills for activities like automation the primary skills you bring to an Agile table?
Do you see Agile as an increased opportunity to leverage from the abundance of good coding skills
within the team in order to empower you to focus on other activities where your skills are perhaps
stronger than the rest of the team and stronger still because you are part of balanced team?
There will be quite a few people who will have primary and secondary skills in these areas, if they
could comment on the primary and secondary element and also touch on the coding tasks that they
pick up with reference to the consideration that there may be others in the team with stronger coding
skills more suitable to that task.
All comments and different perspectives much appreciated.

9 days ago

See previous comments

Andrew Kelly
@Sheerjit, apologies originally I read too much into your earlier comment but let me go through
a few thoughts on your follow up comment.
On a slight tangent I am not a fan of calling testers QA or quality assurance or the quality
people as I have seen the name on it's own being detrimental to team ownership of quality
ideals.
Going back on topic though part of this discussion is on whether the market has got things
wrong, yes their is a deluge of job adverts looking for the all singing, all dancing, coding experts
with a foundation level certificate in software testing.
I am suggesting that part of this is due to a lack of understanding of testing in the market, not
knowing how to leverage from it and a lot of rose tinted automation magic glasses being worn

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

across the industry.

In this your assessment of where a lot of companies are and the solution they believe they need
is correct, feel free to jump on the coding bandwagon at this point as in the short term the skills
will match what a significant proportion of the market "believes" it needs.
This topic is highlighting that most companies already have all those coding skills within the
team and adding even coding skills to a team overflowing with them as opposed to adding deep
testing skills and knowledge may actually be folly which in turn means much of the market is
looking at things in the wrong way.
I say short term because I believe companies over time with less optimal results will recognize
this and with things like the "Internet of things" which will mean that every project has more risks
to "investigate and explore" as they build the product the market and recognition of what they
really need for deep testing skills and knowledge will increase.
This will happen either very slowly through failure but can be fast tracked through tester
knowledge sharing, value demonstration by doing and mentoring of non-testing stake holders by
testers.
At no point in this discussion have I mentioned a silo'd test approach, I absolutely agree uncollaborative independent testing is not an efficient way forward, I think testers should have the
skills to be able to test when a product is thrown at them without access to developers or reams
of written requirements but I do not believe it is an optimal approach. Given we are talking about
Agile here it is not relevant to this discussion.
Either way I agree a lot of testers are in a risky position do to the disparity between what a
significant part of market believes it needs and what it is really believed to actually need from
those who know the field well, hence the discussion.
2 days ago
Joel Hendershott
I feel like the statement "Developers should not test their own code and hence why we need
Testers" has no real place in an Agile development team.
While I agree the developers and 'testers' should both be pushing for quality, that the Quality
Engineer, or QA or Tester or whatever, should be the owner of quality. A person who truly
understands the intricacies of the program, the needs of the consumer and the driver of the
business. This person not only lends the ability to:
Dive deep into exploratory testing and find bugs
Dig in code to identify pain points early
Provide feedback as a user as well as an software professional

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Write automation early, as well as regression steps after the initial test phase
In the agile world we should be pushing testing closer to dev. This could be done through Test
Driven Dev. This could be done through pair programming. It can be done with Testers writing
their acceptance criteria and automating them before the code enters their hands. Even pulling
code from branches to test in a vacuum before going live to a CI or test environment.
All of the things listed above require some sort of understanding of code. However coding as the
primary skills is not a requirement. A solid scrum team can have developers coding, while QA is
writing acceptance criteria, our process uses Cucumber. When the code is ready for QA eyes,
then the developer can take the AC and write the code to automate that. Now you have the
'owner of quality' ensuring that exploratory, functional, and regression testing is completed, as
well as ensuring that automation is a solid 'definition of done' while not actually knowing how to
code at all.
I have been trying to take an honestly look around and wonder what the future looks like for us
testers. With Utest, and testers overseas I do wonder where manual QA will fit in this. I almost
see that the full time hires by a company will be Test Leads with Automation skills, and most of
the deep testing can be covered by more eyes at a much cheaper rate with crowd/out sourced
testing. When previous it was the outsource that was writing the automation.
I don't like that way of thinking but it seems like that's the direction in our company, and others
I've talked to, especially around Silicon Valley.
1 day ago

Augusto Evangelisti
This is a very old one but very much in topic
https://mysoftwarequality.wordpress.com/2013/08/10/should-developers-test/

1 day ago

J. Sean Wilson
Thinking about it now, how about this distinction:
When coders test, they test in support of their coding.
When testers code, they code in support of their testing.
We all expect in an agile world, that developers are responsible for testing the code that they
produce BEFORE they call time on the work and hand it over to whomever is going to be testing
it for release.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

Equally, we expect, more and more, that testers are responsible for coding scripts to enable
them to test what they need to test, or for writing requirements for others to code the scripts
they need.
It really is a fundamental difference and it goes back to that initial couplet.
Sean

1 day ago

Augusto Evangelisti
J. Sean, you say:
"When coders test, they test in support of their coding.
When testers code, they code in support of their testing."
I suggest instead, when anybody in an agile team tests, he should test in support of their
customers.
Agile teams deliver customer value, they don't deliver code, they don't deliver defect reports, they
deliver customer value, let's focus on that.
1 day ago
J. Sean Wilson
I need a "mom and apple pie" button :)
I totally agree with that Augusto, but it would be impossible not to. Of course we have to code
and test in support of our customers. We write requirements, create prototypes, generate
documentation (only as needed), and eat pizza all in support of our customers. Everything we
should be doing should be in support of the customer.
I'm really looking for a way to differentiate the coding that testers might do, and the testing that
coders might do. And there is a difference much of the time. Although, I would further suggest
that the greater a coder who tests is, and the greater a tester who codes is, the less
distinguishable their work product becomes.
For the most part though, when we are asking development focused members of an agile team
to test their work product, we are asking them to do something different than we are asking test
focused members of an agile team to do when we ask them to write automation.
Sean

1 day ago

Kiran Badi

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

@Brett,
>>>However, I will say that it is more a team effort to reach the best choice and refinement
should be a team effort. That is you get skills for BA/Tester/Architect/Designers/Business all
collaborating to come up with the best requirement. Each skillet brings something to the table.
Remember the Three C's - Card, Conversation, Confirmation and the emphasis is in
"Conversation"
I like it and love your reply. 3 C's I think its scrum way.Yah I believe in Conversation,but I believe
in having conversation with right person who has right skills and who is accountable and
responsible for it. So if requirements is missing or having gaps, I would have conversation with
BA's and then probably will have team involved in it as well.What do you think of this approach
?
1 day ago
Kiran Badi
@Andrew,
Are testers who can code, really what Agile teams need?
I would say yes, if you doing lot of manual testing in agile, its considered as failed agile
implementation.If you are scrum master and if your team has done lot of manual testing in your
sprints, then most likely you will be shamed by your peers and you don't want that to happen
right ?
>>>Pretty much every Agile team that I have encountered has been overflowing with coding
skills, is there any real reason to put an emphasis on adding more coding skills to a team
already overflowing with that skillset?
Well it depends, but if coders are available and budget is available, probably I would add more
and bring down the sprint duration to 2 or probably less than that. We can show more value to
customer:) .. The only caveat I see is that they should be really skilled and experienced
programmer.
>>Are strong questioning, design and investigative testing skills more likely to be what they
really need?
Well strong questioning ,design and investigative skills are welcomed,but its more like
democracy, if majority in the team supports your questions and believes that they are valid and if
you win majority, then probably questions are welcomed else they need to keep quiet.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

>>>Are your coding skills for activities like automation the primary skills you bring to an Agile
table?
It depends, but majority of cases, I would say yes unless you are into some research kind of
stories.
The only role I see in agile which does not require coding skills is scrum master or maybe agile
coach.All day you need to do something like this,
https://www.youtube.com/watch?v=oheekef7oJk

1 day ago

Kavitha Gopan
Hello,
I was just going thru these discussions just to know whether my perceptions matched with the
outside world.
Well, should QA team really have a coding skill to be completely agile? From my experience of
~ 7 years, i can say that QA does require coding skills but that is only to meet the automation
requirements.
For working in Agile, QA does have a lot in their plate, like to complete the testing of that chunk
of code for the sprint, to be one of the amigo for look ahead, to completely understand the
customer expectation so that guides the developer to not divert from requirements, to give
valuable feedback during retrospection and so on.
1 day ago
Andrew Kelly
@Kiran, interesting thoughts.
I tend to steer clear of the term "manual" testing, take the CSI comparison with the tester being
the lead investigator, they are out in the field asking a lot of questions and they decide they had
better send of some blood samples and finger prints off to their lead technicians
(automaters/toolsmiths/coders) for analysis, would you see the need to call the onsite
questioning element of the investigation the "manual" investigation? Perhaps it make more
sense just to call it the investigation with the leveraging from the technicians/tools as required?,
the same reasoning in my view applies to testing.
With regards to this statement "if your team has done lot of manual testing in your sprints, then
most likely you will be shamed by your peers and you don't want that to happen right ?" ignoring
the manual word based on my last comment it is worth in this case differentiating between
testing and checking.

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com

If you are not leveraging from tools and skills within where appropriate to do a whole load of
checking activities then I agree someone is likely to call inefficiency.
If people though are shaming others for doing highly skilled testing and finding ways to actually
do more of this in the fast paces of continuous delivery by getting the right balance of skills in a
team and utilizing the coding skills already in the team for things like automation then I suspect
it could very easily become a dysfunctional environment.
A lot of teams do not really understand testing and fail to leverage from it effectively, these
teams often focus primarily on the checking aspect and a lot of the recruitment adverts seem to
reflect this focus on checking.
Where they do really understand the value of the testing element the ability to squeeze in more
of the high value testing rather than less should be applauded and not shamed. In no way am I
undermining the high value of checking but I am differentiating it because it can be automated
and importantly it can be automated by the coders or the tool smiths or the testers with coding
skills in the team.
1 day ago

open in browser PRO version

Are you a developer? Try out the HTML to PDF API

pdfcrowd.com