- I respectfully disagree. What you need is a versatile person who can work as a developer and in the process teach your developers what they all need to knowMessage 1 of 42 , Feb 2, 2006View SourceI respectfully disagree. What you need is a versatile person who can work as a developer and in the process teach your developers what they all need to know and do to be responsible for quality as a team.Making any aspect of software development the responsibility of just one person makes the team less agile. That includes:- Quality- Understanding requirements- Testing- Automation of testing- Automation of continuous integration- And even, the DBA workOn-the-job cross-training is the way to go.Steven Gordon
On 2/2/06, Dave Churchville <dchurchv@...> wrote:
--- In firstname.lastname@example.org, Obone Kanobe
> Hi All,
> I currently lead a small team of 7 developers and one dba. We work
on small to enterprise size applications using J2EE and PHP. I would
like to hire a QA engineer to join the team. However, my boss told me
that he thinks its better for me to get an additional developer than a
QA engineer. He believes that rather than hiring a QA engineer, I and
my developers should be responsibilities for all QA activities.
> I was wondering what you all think about this subject?
> Also, if you agree with me, then any pointers on how to make my case
to the boss will be most apreciated.
Hmmm...just posted a blog entry around this topic. You really, really
want to have someone with a pure QA/testing mindset who isn't a
developer. If there are other people in the company that can do this,
great, otherwise I'd go with a versatile QA analyst (maybe who can
write automated tests, do business analysis, write specs, or something
- ... I know :) But that is exactly my point. When all of the people refuse to work together, customer, business unit, analysis, the quality of the product willMessage 42 of 42 , Feb 7, 2006View SourceSteven Gordon wrote:
> On 2/7/06, David H. <dmalloc@...> wrote:I know :)
>> I do agree that people need to realise that most quality issues originate
>> higher up. Most of the time when the requirements are gathered.
> In Scrum, when are the requirements "gathered"? Who participates? It's not
> like a waterfall process where we can go blame some analyst.
But that is exactly my point. When all of the people refuse to work together,
customer, business unit, analysis, the quality of the product will suffer.
Often enough some software department has to deal with developing software for
a domain they know nothing about. Yet there is no insider they are allowed to
talk to. Now what will that do to Quality ?
> It would be a process smell if the team depended on the QA person to ask theActually I was more thinking that the QA person is there to kick off the
> difficult questions while all the developers just sat there daydreaming
> about how they were going to code it.
important act of questioning yourself. I do look at this from a more
philosophical point of view than a technical one. Everyone can be the QA
person in a team and I hope that all of us have a QA person in us. I know that
I do QA aspects whenever I am Scrum Master for a project. However it helps
when someone steps up and states. "Yepp I will have an eye on it, maybe more
so than others"
> If the developers cannot ask the right questions, the solution is not toYes, see above, I do believe we agree here.
> depend on somebody else to ask them, but to integrate somebody into the
> team who can show them how.
> Integrating that person into the team wouldOnce more, yes, yes, yes :)
> mean they do not do all the QA work and they do not just do QA work. If you
> do not integrate that person, then the cross-training will be much less