Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi all,
Vanilla are planning an update to the site on April 24th (next Wednesday). It is a major PHP8 update which is expected to boost performance across the site. The site will be down from 7pm and it is expected to take about an hour to complete. We appreciate your patience during the update.
Thanks all.

Debugging & Testing Regimes for Small companies

  • 26-11-2013 2:44pm
    #1
    dubbeat
    Registered Users Posts: 143 ✭✭


    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!
    Tagged:


Comments

  • #2
    John_Mc
    Registered Users Posts: 2,790 ✭✭✭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.


  • #3
    dubbeat
    Registered Users Posts: 143 ✭✭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?


  • #4
    John_Mc
    Registered Users Posts: 2,790 ✭✭✭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.


  • #5
    jester77
    Registered Users Posts: 11,262 ✭✭✭✭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.


  • #6
    dubbeat
    Registered Users Posts: 143 ✭✭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.


  • Advertisement
  • #7
    John_Mc
    Registered Users Posts: 2,790 ✭✭✭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:


  • #8
    srsly78
    Registered Users Posts: 7,157 ✭✭✭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.


  • #9
    amen
    Registered Users Posts: 2,781 ✭✭✭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
    D: 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.


  • #10
    Trojan
    Registered Users Posts: 16,402 ✭✭✭✭Trojan


    This thread might help.

    🎙️ The Recognized Authority Podcast



  • #11
    dubbeat
    Registered Users Posts: 143 ✭✭dubbeat


    Trojan wrote: »
    This thread might help.

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


  • Advertisement
  • #12
    bpmurray
    Registered Users Posts: 1,275 ✭✭✭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.


  • #13
    jester77
    Registered Users Posts: 11,262 ✭✭✭✭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.


  • #14
    Feathers
    Registered Users Posts: 1,082 ✭✭✭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.


Advertisement