Debugging & Testing Regimes for Small companies

dubbeat

Hi,

Id like to get some advice from people who develop for small companies (less than 10 people).

I work for a really small company and we're having serious problems managing and tracking our debugging and testing.

Just interested to hear how you manage and effectively keep track of things.

Cheers!

John_Mc

Not that much to it really. Use a good Work Item management tool (Jira, Team Foundation Services etc) and then log bugs with a severity classification. Developers work through the Bug list in order of severity, most severe first.

dubbeat

Cheers.
Just curious, would your company have a separate person responsible for Q/A or would it be the developers responsibility to ensure that fixed bugs are actually fixed?

John_Mc

We'd have a Business Analyst who manages the requirements and functional testing. They starting doing "Bug Triage" sessions where they looked at the bugs logged and decided on the priorities for fixing them.

You need a separate person(s) to be doing the functional testing, logging the bugs and testing them once they are marked as fixed. Developers should never be the only people testing the new features.

jester77

What type of a development cycle do you have? Sounds like kanban or scrum might help, even with such a small team it would help. Get some proper sprints going, kanban board or scrum wall for visibility and accountability, with a backlog for what needs doing. We use JIRA with greenhopper but I think that would be too high a cost for a small team.

dubbeat

jester77 wrote: »

What type of a development cycle do you have?

Normally it's a weekly cycle. Build sent on Friday, bug's received on Monday, Build sent again on Friday.

John_Mc

jester77 wrote: »

What type of a development cycle do you have? Sounds like kanban or scrum might help, even with such a small team it would help. Get some proper sprints going, kanban board or scrum wall for visibility and accountability, with a backlog for what needs doing. We use JIRA with greenhopper but I think that would be too high a cost for a small team.

Yeah a methodology clearly defines everyones roles and responsibilities. I've seen scrum work well, but if it isn't followed with discipline, it's just an excuse for no requirements :pac:

srsly78

As mentioned in other threads....

Linux:
sudo apt-get install jenkins

Windows:
http://jenkins-ci.org/ Download and install.

All companies (big and small) should be using continuous integration software - this lets you setup automated unit and integration testing.

amen

Build sent on Friday

Never send a build on Friday! Its not clear are you sending directly to the clients Live ?

At a minimum I would expect
A: Developer tests and verify code works.
B: Developer runs unit tests
C: Developer checks in
Nightly build runs and assuming the code builds automated tests run.
E: Assuming all of the above work a release build is build which goes to your internal test server
F: Unit/regression tests are run on the test server
G: The new functionality is tested and signed off by your BA/QA etc
H: Once G is completed and there are no issues the build goes to the clients Test environment with an agreed got Live date ( at least 7 days from the release to clients test)
J: The build is tested and verified on the clients test environment.
H: Once Test and verified the build goes live on the agree date.

As for internal testing as the others said you need a bug tracking/features request application that lets you see open bugs/issue and assign based on severity/urgency. Just because a bug is severe doesn't mean it should be fixed first.

You could have a severe bug that kills an app for a user but the user only uses the app once a month while you have 100's using the app daily and they find it slow. In this case fixing the slowness would be better.

Trojan

This thread might help.

dubbeat

Trojan wrote: »

This thread might help.

The op from that post is describing my exact situation (near enough)

bpmurray

As srsly said, you need Jenkins. Here's a simple way to do it - create shell scripts (or batch files) to pull the code from the repository, build it and deploy the build to a test server. The integrate these steps into Jenkins. You now have a push-button end-to-end build. Next add your unit tests and coverage measurements. Over time, you can get these to the level they need to be, preferably 100% coverage. At this point you should be writing unit tests before code, allowing you to minimise the code you write and automatically verify your code's correctness. This means that your time after that is taken up by development, not fighting the build.

jester77

bpmurray wrote: »

As srsly said, you need Jenkins. Here's a simple way to do it - create shell scripts (or batch files) to pull the code from the repository, build it and deploy the build to a test server. The integrate these steps into Jenkins. You now have a push-button end-to-end build.

You can make this even easier by using hooks to trigger the build automatically in Jenkins any time code is pushed to the repo. Jenkins has lots of nice plugins that will automatically pull the code from the relevant repo and branch, and build and deploy it, and lots of other fancy stuff.

Feathers

John_Mc wrote: »

You need a separate person(s) to be doing the functional testing, logging the bugs and testing them once they are marked as fixed. Developers should never be the only people testing the new features.

Normally in Agile, you'd have someone in a 'Product Owner' role, be that a client or an internal business person who could say that they're happy with the fix.

But even if it's a small tech-only company, the main thing is just make sure that the work is getting reviewed. Just to add to John's point, you need a separate person testing to the person who made the fix, but both people's job title could be 'developer', so long as people aren't verifying their own work.

dubbeat wrote: »

Normally it's a weekly cycle. Build sent on Friday, bug's received on Monday, Build sent again on Friday.

A Wednesday build that runs over by a day is done Thursday, with everyone in the office on Friday if there are any issues.

A Friday build that runs over by a day is done… Saturday? The following Monday? If it is Saturday, how many of the team are around? What happens if you've a problem with someone else's code right before shipping. Even if you never get to Saturday, if people are rushing to make sure they don't have to work Saturday, you'll definitely get more bugs than if they can calmly come in Thursday morning & freshly make the changes needed.

Unless you've a great reason for doing this (e.g. the person raising bugs works Sat/Sun, for instance & you can gain time on UAT), I'd strongly suggest moving your build to mid-week.