Friday with Filip – Do you use a decent testing strategy?

Posted by Filip Ekberg on September 14 2012 6 Comments

Welcome to Friday with Filip!

Wow, am I excited or what! I was out on a “developer lunch” in Gothenburg with some very nice people and we started talking about blogging, teaching and other fun stuff like that. We started discussing how I usually have what we call “CodeStar” at work; each Friday I teach my co-workers about something exciting for an hour or two. I’m not Always the guy doing the presentations, but mostly.

Anyways, we college who was also with me on this lunch referred to it as “Friday with Filip” and this started to grow on me. So with some great input from my college , Iris and Anton, I decided to create a blog series called Friday with Filip!

The idea is pretty simple, I want to give my point of view on a subject and then hopefully teach you something and start a discussion around it. Feel free to leave a comment or drop me an e-mail on mail [at] filipekberg [dot] se! All feedback is welcome!

If you like the idea, please share it with your friends by clicking the share button below.

Do you use a decent testing strategy?

I’m currently working on some very large projects with my company and it’s all very interesting. What I’ve found most exciting about these larger projects is that the testing strategies are much more important when it comes to these larger systems. Personally I think that testing is Always important and should be prioritized.

If we look at it all from the customer perspective, how can they be ensured that things work accordingly if there is no documentation to back it up?

I don’t know about you, but I’ve heard the following excuse to why test reports are sometimes neglected:

We don’t need to do any advance testing, this system isn’t going to be that big.

Stop all these excuses! In my book I talk about how we can use unit testing to ensure that certain parts in a system work correctly, but this is just a fraction of everything that needs to be tested. Many things that we do, we test manually. If we wrote a couple of lines of text each time we did a test, it would surely take a couple of more minutes on each requirement, but it’s going to be worth it in the end!

You don’t really need to put so much effort into making a nice test document. Open up word and just add the information that you think would be valuable if you were looking on the system from the outside.

When you deliver your product, don’t you want to feel like you have a large pile of documents backing up your quality?

Here’s what I would want to have in a perfect programming world:

  • Write unit tests whenever it is suitable
  • Automate as many manual UI tests as possible
  • Document the tests and not leaving out anything even if it fails!

I recently set up a fairly simple test report document that just includes this:

  • Test name
  • A reference to the Use case / Requirement (of available)
  • Description of the test
  • Expected result
  • Actual result
  • Actions needed to mark the test as complete

When you assemble all these in a large document and give to your customer with a sprint delivery, you can surely feel better about yourself! Here is a word document that I put together for this, you can use it as you please. Let me know if you like it.

What is your testing strategy, if you have any? If you don’t, how would you like it to be?

Don’t forget to leave a comment or drop me an e-mail, thanks for reading the first Friday with Filip!

Vote on HN

6 Responses to Friday with Filip – Do you use a decent testing strategy?

  1. Anton SjöbergNo Gravatar says:

    “Write unit tests whenever it is suitable”

    My opinion regarding unit testining is that it is your duty as a system developer to design your code and use patterns that makes writing unit test is as normal as writing production code.

  2. Filip EkbergNo Gravatar says:

    I agree Anton, but the actual unit tests just cover a smaller fraction of what really needs to be tested. But it sure is a step in the right direction.

  3. Stuart McIntyreNo Gravatar says:

    “Write unit tests whenever it is suitable
    Automate as many manual UI tests as possible”

    UI tests typically have a long feedback cycle, whereas unit tests have a very fast feedback cycle. I would favour covering as much as possible at a unit level and just the critical workflows at a UI level.

  4. Pingback: Friday with Filip – Do you deliver high quality?

  5. SamualNo Gravatar says:

    I do agree with all the concepts you have offered in your post.

    They’re really convincing and will certainly work. Still, the posts are very brief for beginners. Could you please lengthen them a little from next time? Thanks for the post.

  6. Pingback: 2012 was an amazing year, here's a summary!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>