Testing the Waterhouse

So I recently had a discussion at work to define how my role works and the responsibilities and what it entails. I thought it would be good to open that up to the wider audience here, as I often hear that there is no need for a Test Manager/Test Lead in an Agile environment. Whilst there is no need for what we would see as an old school test manager, being one that manages test resources and allocates testers to projects, there is still a need for a test manager/test lead, and I'll explain my thinking here. In the past my role has been around fighting fires and helping teams out when testing resource is needed, which don't get me wrong I have enjoyed as it's meant getting my hands dirty and improving things from the ground level. However, I wanted my role to be clearly defined as we have gone through structural changes since it was last defined, and some of the responsibilities aren't necessarily valid still. Drive testing within teams  Directly or by working c...

I'm currently working with a new team who haven't really worked in an Agile way before, nor do they have much experience of what types of testing you can do on an application, so in preparation I tried to come up with simple definitions on the above types of tests. I thought it would make a good blog post, as it's somethign that I would undoubtedly find useful at a future point... So here goes: To define a Unit Test it's a simple test that tests a single piece of code/logic. When it fails it will tell you what piece of code is broken. An Integration Test is a test that tests the combination of different pieces of an application, when it fails it will tell you that your system(s) are not working together as you thought they would. An Acceptance Test is a test that tests the software does what is expected by the customer/user of the software. When it fails it tells you that your application is not doing what the customer/user thought it would do or even what it sh...

It's important when writing automated tests to remember that the code you write should be up to production standards, meaning any conventions that you have in place should be adhered to and that it should follow good design patterns. Too many people often say why does it have to be as good as production code, it's "Only" a test, so long as it passes then that's fine... To answer this we need to look at why we want our tests to be written in such a structured and efficient manner: - Maintainability - by making the test code structured and efficient, it becomes far easier to maintain and in doing so changes in the future can happen quickly as the test isn't linked to anything that it shouldn't be and it's easy to understand for a new set of eyes. - Durability - Again by making the tests structured they should be resistant to changes, if you change a variable name for instance then it shouldn't effect the unit test unless it absolutely has to....