At what point in a sprint should a functional testing resource be involved? [closed]

Closed. This question is opinion-based. It is n开发者_StackOverflow社区ot currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

Our scrum team of three developers has a dedicated tester. At the moment the tester is ostensibly waiting for something to test for most of the first week of our 2-week sprint. We typically do our first release of the sprint deliverable around the Thurs or Fri of sprint week 1. At this point our tester can "test" the embryonic software.

This begs the question in my mind - how much value is functional testing like this adding, so early in the development of the deliverable?

At this stage (end of sprint week 1) in development there are usually significant bugs / functional omissions which would be rectified if testing was postponed by only a couple of days (say to week 2 of the sprint).

What is best practice in this case?

---

While you mention Scrum, a good management practice, you don't describe which testing practice you're using.

If you're using best practices, you should be using Test-Driven Development.

Test-Driven Development means that the testing must be done from the very beginning. The programmers must write tests and fill in classes that pass those tests.

The tester should be writing functional tests on day 1 which the application absolutely fails to pass on day 1. Eventually the application starts to pass those tests and you can call your sprint done.

If you're not doing test-driven development, you should be, and your tester should be writing integration test cases.

If your tester can't code, teach them to code. You must have a tester who can code. And make them start coding functional tests on day 1.

---

A tester could be going through the spec and writing test scripts / acceptance criteria steps.

As a dev is coming up to completing a task but before check-in they can also do mini test reviews, ie a 5 minute eye ball with the developer as they are completing the work can often turn up a few bugs.

There is always testing the existing application (assuming this isnt the very first sprint of a new product) theres always bugs to find.

Then there is triage of existing bugs, are they high or low priority.

Then there is the testing and closing of bugs that developers have fixed.

Of course the most important is making coffee and wiping the fevered brow of any developer who puts his hand up.

---

You have uncovered a problem with your Product Backlog. If you have 3 devs coding for 3 days with no testable/releasable code then your stories are too big. You should notice this reflect this fact on your burndown; flatline->big drop at end of sprint. Integration should be a daily routine with new functionality always available for testing.

---

I agree with the above. When you choose your user stories for the spring, you should start defining how they will be tested

---

How about:

• Automate some of the story tests from the last sprint that were tested by hand

• Automate the setting up of the test data (and/or machines), so that it is quicker to do the next round of regression tests.

• Write the test specs for some of the stories, so that the developers have better information when they get to do those stories.