11

I'm currently working on a small team of a few developers, but even a small team of productive developers can develop a lot of functionality in one iteration (2 weeks in our case). We don't have a QA team, so generally we'll spend the last day or two of an iteration doing manual testing for the parts we don't have automated testing for (we're writing automated tests as we go along as well, but something things are just really hard to automate).

This effectively cuts our development to about 8 days per iteration. For those of you who have worked in this environment, can you offer any advice as to how you handled this? Did you tack on extra days to the end of the iteration? Did you not allot additional time for testing and just develop right up to the iteration? Our goal is to always have deployable software (especially at the end of the iteration) so having these test days seems like a must.

Improve this question
3
  • 1
    Have you considered creating a formal QA/test team? One that works along side/in parallel to the development team?
    – joshin4colours
    Commented Jun 27, 2012 at 2:19
  • Ideally I'd like to, but the budget doesn't allow for it on this project. This current project is wrapping up, but just curious for how people handle this in general for new projects.
    – Jeff Storey
    Commented Jun 27, 2012 at 2:26
  • Similar question I answered: sqa.stackexchange.com/questions/3224/…
    – Sam Woods
    Commented Jun 27, 2012 at 16:14

6 Answers 6

Reset to default
10

I've been the first tester on a team before and seen how they've tested their software before (usually doing a very good job of it as well). For as small as you are, I think that you're on the right track for the most part.

Creating automated tests as you go is great. You may find some benefit to some TDD approaches which ask you to create the tests before you write the code. Definitely can make the tests easier to write.

Rather than everyone taking a day or two at the end of an iteration, how about having one (rotating) dev take time periodically throughout the iteration and test the software. This would definitely cut down your feedback loop. You may then only need to spend 1 day at the end of an iteration testing in that case.

I know that a lot of people are against the idea, but I've seen some small teams take an iteration one and a while, and make it an integration/health check iteration, just checking to see how it is in the big picture.

Can you have a customer on site once a week/iteration to do some of the testing for you?

In the end, I agree with Phil's answer, and it should be your eventual goal, but I also understand that many times it's just not financially/realistically feasible to have a full time dedicated tester in the short term.

Improve this answer
3
  • TDD has been very helpful and for the most part, we really try to automate everything out. We do a lot with visualizations that are very hard to automate tests for so there is a need for some manual testing. We are consistently testing throughout the iteration. My biggest concern is that the last set of changes at the end of the iteration really are not getting the same testing the first sets are (if we want to deploy at the end of each iteration).
    – Jeff Storey
    Commented Jun 27, 2012 at 2:13
  • Just to piggy back a bit on Lyndon's answer since I agree with what he had to say. You might be sure that you are tasking the testing effort along with the dev effort to be sure that it is fully accounted for as a part of each story. The iteration should not be done until that those tasks are complete and the entire story is accepted.
    – Dan Snell
    Commented Jun 27, 2012 at 3:11
  • Dan we are testing individual stories as we work on them but before releasing to the customers I like to do some additional acceptance testing and just some general testing to make sure the different pieces of the system work well together. What would you suggest in that case?
    – Jeff Storey
    Commented Jun 27, 2012 at 3:50
3

Sounds like mini waterfall rather than agile. How do you know stories are done done and not just done ? Get yourself a good tester and fit them in, that's what I'm doing :)

Improve this answer
4
  • We're certainly testing during the iteration as well, not just saving it all to the end. But I feel like checking code in up to the end of the iteration is a little risky. I'd like to have a little test time before we just send it out to the customer.
    – Jeff Storey
    Commented Jun 27, 2012 at 2:11
  • 3
    +1 for 'done done', not just 'done'. That's been a constant thorn in my side when working with other developers when they are more focused on the 'done' part than the 'done done' part.
    – corsiKa ♦
    Commented Jun 27, 2012 at 14:14
  • @Phil, can you elaborate more on how to do testing in agile? Pair together with devs to write unit tests? Split stories into smaller testable parts? Write tests for stories before developers implement them?
    – dzieciou
    Commented Oct 7, 2012 at 20:08
  • One of the devs I work with recently wrote a blog post outlining his approach, might be easier to read that than me write a huge comment. Combine the approach he outlines in the post with me doing exploratory testing around his code and of the stories and you have the approach we try and follow - spin.atomicobject.com/2012/10/03/…
    – Phil Kirkham
    Commented Oct 8, 2012 at 13:23
3

It sounds like you are slotting time for regression testing. A continuous automated testing approach would reduce your testing cycle. I'd look at designing your automation suite around this idea and run it nightly for GUI and service testing (or more if you are ambitious) while running unit tests on all builds. A nightly automated regression suite would probably reduce your need to only a single or half day of testing (like you said its hard to automate everything). Additionally you would get the value nightly feedback on your quality.

Of course, this is a delicate balance. You need to find the time to create, manage, and maintain that. You can see how it can easily lead to recommending adding a tester to your team to help manage that.

Management sales pitch:

  • Adding a tester could reduce your testing cycle by 1 day. If you are running 2 week sprints that will add an additional 26 days of development a year (2 1/2 more sprints). I"m not sure how large your team is, but most likely that should easily pay for the tester's salary. Of course that tester better be a rock star.
Improve this answer
0

To add onto Lyndon's answer, perhaps you could assign developers testing-related activities in a more formalized way. As said before, automated tests are great, so consider making them a development priority along with production code. The assigned developers could write and maintain the tests full- or part-time, and keep them up to date and in-line with current coding standards. Treating test code like production code could go a long away to help your testing processes.

Along with this, if you have developers maintaining automated tests they will likely be doing at least some "manual" testing of the software, which is a benefit. Again, treat these processes like first-class citizens; allow developers or whoever else formalized time to explore and manually examine your software, either for purposes of automation or otherwise. Don't just squeeze in testing wherever there's time; embrace it for learning about your software.

Lastly, if you find yourself thinking "I really think we need a QA/test team", make it a priority. Figure out what works best for your team and follow through on it. Budgets are for all sorts of things, including new staff and resources.

Improve this answer
0

I worked on an agile team where we used a notecard for each story. Once we committed to a story we wrote out the user acceptance criteria on the back of the card. The language used was important because you do not want to provide a solution within a story, so your criteria has to address the problem being solved rather than how to solve it. This made it so that anyone on the team could test it to determine if it was satisfied.

Could you assign a developer who did not work on a story perform that final test once it is done to move it to the "done done" column? I would not change your iteration length if it seems to be working for you. Instead, adjust the number of points you commit to for each iteration if needed.

As we built up our team, we added automated regression testing and used our BA to do the manual regression testing. Eventually we did get QA resources, and I agree with everyone else who tells you what a benefit they are!!

Improve this answer
-3

I am in the same situation while testing we find too many bugs so I suggest u that don't give too much time to developer ask them to develop the application as fast as possible and then u can start testing with the latest built that u have it will be good for u and for your team too TY

Improve this answer
3
  • How is that going to help ?
    – Phil Kirkham
    Commented Oct 6, 2012 at 14:41
  • What if developing as fast as possible creates more bugs? This will increases the amount of time spent in testing + documenting bugs + fixing + (all 3 again). If the developers are creating a code with too many bugs, developing faster will only make the matters worse.
    – Suchit Parikh
    Commented Oct 8, 2012 at 22:35
  • see if we wont be hard on developer then it might happen, that they do not concentrate on their work, one more thing if they can work fine under some pressure then give them some pressure and if they cant then leave it give them as much time as they want, otherwise too many bugs may occur.
    – Tarun
    Commented Oct 23, 2012 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.