Latest Updates: Software Engineering RSS

  • The beauty of small tests

    Andrew Darnell 12:53 pm on 15th April, 2010 | 0 Permalink | Reply
    Tags: , , , Software Engineering, ,

    When tests are small, a test failure means just one thing – somewhere in these ten lines of code which are being tested, there is an error.  Ok, sometimes this can mean that there is an error in the test script, or a there is a failure, or change of expectation, but fundamentally, it pin-points the cause of the failure to a small target, which usually means that debugging becomes trivial.

    When an end to end acceptance test fails, the failure could be due to any one of a large number of source lines or expectations changes across a large body of code.  Debugging may be quick, but often isn’t.

    (More …)

     

  • Agile – Tests = Fragile

    Andrew Darnell 3:55 pm on 9th April, 2010 | 0 Permalink | Reply
    Tags: , , Software Engineering, , ,

    The nature of agile projects, with lots of small releases mean that there are a lot of test runs to execute if you want to have any confidence in the code and the product.

    Ignoring this testing just generates projects which will fail – not may fail – will fail, categorically will fail!

    There are two sets of tests that are critical here…

    Good unit test coverage and a TDD approach to development ensure that the rest of the organisation is supplied with product that works as developers expect it to.

    Component tests and functional acceptance tests ensure that the product does what the product owner expects it to.

    • Practically, the only way to do solid testing on new features is to have a stable product.
    • Practically, the only way to assure a stable product is to either have solid regression testing on each release or to not make any changes.
    • Practically, the only way to make sure that adequate regression testing is done is to automate the regression tests (unit, component, functional).

    Without these tests in place, iterating quickly places an impossible to meet burden of verification demand on the testers and product owners, which just gives you a fragile process not an agile one.

    Is your process Agile or Fragile?

     

  • Tech Talk - Behaviour Driven Development

    Ian Alderson 11:37 am on 18th March, 2010 | 0 Permalink | Reply
    Tags: Behaviour Driven Development, Software Engineering, Tech Talk,

    Last week several of my colleagues and I watched a Google Tech Talk on Beyond Test Driven Development: Behaviour Driven Development, presented by Dave Astels way back in March 2006.

    Although four years can seem like an eternity within software development, I found this video extremely pertinent to what I find myself doing today. I have been following the principles of Test Driven Development (TDD) for many years now, however this is the first time I have really delved into Behaviour Driven Development (BDD). I would thoroughly recommend watching the video if you have 45 minutes to spare, however, if not, I have summarised the notes I took whilst watching it below.

    (More …)

     

  • Caplin Tech Talk Series, by the self-elected programme chair ;-)

    Andrew Darnell 4:12 pm on 16th March, 2010 | 0 Permalink | Reply
    Tags: education, Productivity, Software Engineering, techtalk,

    As QA manager at Caplin, I manage a very busy team of test engineers.

    Previous to starting at Caplin, I was the European Test Engineering Manager at Google. While there I gained a few helpful tips to encourage ongoing learning, brainstorming, discussion and a bit of entertainment despite the typical time constraints of a busy testing environment.

    One of these ideas is regular tech talks. I find a short mental break from my usual week looking into something completely different can spur a number of interesting ideas and some excellent discussion amongst participants.

    The Caplin Tech Talk Series

    (More …)

     

  • Imprecise Accuracy is better than Precise Inaccuracy

    Ian Alderson 2:53 pm on 5th March, 2010 | 0 Permalink | Reply
    Tags: , Software Engineering

    Last week I blogged about how an estimate is not a guarantee. A small, but important, omission from that post was the distinction between an accurate estimate and a precise estimate.

    Frequently accuracy and precision seem to be considered the same thing. The critical difference was highlighted when I went on an agile course run by Mike Cohn. He demonstrated the difference by asking the question of when your birthday was?

    (More …)

     

  • An Estimate is not a Guarantee

    Ian Alderson 12:57 pm on 26th February, 2010 | 0 Permalink | Reply
    Tags: , , , Software Engineering

    The statement that an estimate is not a guarantee might sound obvious but it often feels anything but. Over the years I have frequently heard managers complain that something has taken longer than was anticipated and have been told to improve the estimates.

    Of course at times the estimates have been inaccurate, with features taking far more time to implement than was initially predicted. The question is how to learn from these experiences to help improve your estimates. This is especially pertinent for software engineers within financial services because this same conundrum is at the heart of pricing financial instruments.

    This article looks at how the Rational Expectations Theory can help you improve your estimates in software development. It starts by looking at estimating something much easier than a software enhancement, your journey time into work, and demonstrates when that estimate should be considered good or bad. It then looks how this can be applied to software development.

    (More …)

     

  • Testing APIs for Backwards Compatibility

    Ian Alderson 5:07 pm on 19th February, 2010 | 0 Permalink | Reply
    Tags: , Software Engineering,

    A couple of weeks ago, I wrote about Agile Framework Development and the various techniques that we have used here at Caplin to build our APIs in a way that is sympathetic to agile methodologies. One of the key problems with the iterative development of an API is how to ensure that it remains backwardly compatible. Although each new release of an API is focussed on providing more functionality, easier use, or increased robustness for its users, those same users want their existing code to continue working when they upgrade.

    This article addresses the issue of how to identify, with confidence, whether an API is backwardly compatible or not. As I mentioned previously there are times when an API is just too incorrect to be kept, however the decision for a breaking change must be a deliberate one – not an accidental one that is typically only discovered when the users of the API find that their existing code no longer works.

    (More …)

     

  • JavaScript Variable Naming Convention

    Ian Alderson 4:05 pm on 10th February, 2010 | 0 Permalink | Reply
    Tags: , Software Engineering

    When I joined Caplin 10 years ago I came from a company that used Hungarian notation to name its C++ and Visual Basic variables. For me, it seemed a natural progression to continue to use these naming conventions and adapt them to be suitable for the JavaScript code that I now writing.

    The evolution of software practices ebbs and flows over time, and it seems that Hungarian notation is currently out of favour. This is especially apparent with some of the new developers that have joined the team here at Caplin. One of the first questions they ask is often about the naming convention that we use.

    (More …)

     

  • Agile Framework Development

    Ian Alderson 12:58 pm on 2nd February, 2010 | 0 Permalink | Reply
    Tags: , , , Software Engineering,

    At times it seems that the philosophy of agile software development is at odds with that of framework development. Given the amount of print and web space dedicated to agile methodologies, it’s incredible how little is dedicated to this topic. It’s almost as if this conflict needs to be kept hidden away from view, not to be discussed in public.

    At Caplin we are living proof that framework development can be achieved following agile principles. We have been successfully building frameworks and APIs for the past 5 years using various agile methodologies from Scrum, to a mix of Scrum and XP, to Kanban.

    This article represents the approaches that we have undertaken to successfully build our frameworks.

    (More …)

     

  • Pitfalls of Exception expectations in JsUnit

    Ian Alderson 12:00 pm on 29th January, 2010 | 2 Permalink | Reply
    Tags: , JsCoverage, , Software Engineering, ,

    At Caplin we use the JsUnit framework to test our JavaScript code. Over time we have made minor modifications to it, integrating Mock4JS and JSCoverage, as well as adding a few of our own extensions that are sympathetic to our JavaScript coding style, however, by and large, our tests are written using plain old JsUnit assertions.

    One of the main reasons we were keen to adopt JsUnit five years ago was its similarity to JUnit 3. Back then our developers had been using JUnit for a few years, and familiarity of the JsUnit API meant that we could immediately start writing tests. Unfortunately the old adage “familiarity breeds contempt” reared its ugly head, and we discovered that our main issue with JsUnit were the occasional, very subtle, differences between it and JUnit. The logic for a test that works in JUnit might not work in JsUnit.
    (More …)

    Related Posts with Thumbnails
     

Older Posts →