Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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.

share|improve this question
1  
Have you considered creating a formal QA/test team? One that works along side/in parallel to the development team? –  joshin4colours Jun 27 '12 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 Jun 27 '12 at 2:26
    
Similar question I answered: sqa.stackexchange.com/questions/3224/… –  Sam Woods Jun 27 '12 at 16:14
    
Thanks, appreciate the input. –  Jeff Storey Jun 28 '12 at 1:31
add comment

5 Answers 5

up vote 8 down vote accepted

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.

share|improve this answer
    
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 Jun 27 '12 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 Jun 27 '12 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 Jun 27 '12 at 3:50
add comment

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 :)

share|improve this answer
    
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 Jun 27 '12 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 Jun 27 '12 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 Oct 7 '12 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 Oct 8 '12 at 13:23
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
How is that going to help ? –  Phil Kirkham Oct 6 '12 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 Oct 8 '12 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 Oct 23 '12 at 6:17
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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