Return to Answer

###Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

###Why is there too much QA work for your team to handle?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.

Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

Why is there too much QA work for your team to handle?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.

###Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests that (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

###Why are there not enough QA people in your team?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.

###Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

###Why is there too much QA work for your team to handle?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.

###Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

Note also that in order to produce quality code, developers should anyway write unit tests and do at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

###Why are there not enough QA people in your team?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.

###Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests that (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

###Why are there not enough QA people in your team?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.