Agile

You know what really grinds my gears. Not people pointing out problems with Agile or even people deciding that it is not suitable for them. What grinds my gears is people creating problems with Agile without understanding what Agile really is and what is involved. For testing staff it could be a bad thing as many implementations see no place for professional testers but I would see this as an oportunity. By pair programming with one tester and one developer you get the best of both worlds with everything seen from two perspectives.

Last Minute Testing

Every time a release comes round it always ends up leading to last minute testing. For me this time it started with me coming back from holiday and having to test two systems that should already be in test. Had I done any data or test prep the clear answer is 'NO' was all the correct and accurate documentation provided the clear answer again is 'NO'. 

So how to approach this in a way that doesnt compromise my work. There are many ways but two that i will mention here.

1/ You could on the basis that it is in test and the correct documentation and requirements are not provided reject the application hand it back to development and remove it from the release.

2/ You could create a document that scopes what you will be testing and why based on the information that you do have and provide this information to the project and development leads. This will mean that you have provided clear details on what you will cover. Following this you should also produce a risk log of some description that is also provided to the project and development leads. This risk log should contain information of what was not provided to you and any areas that you fear might have been missed, it might even state testing was restricted due to the lack of time provided.

Some people would say that this sounds like covering your own back should anything go wrong. I would say that this is ensuring that you maintain your integrity and demonstrate you have done the best job that you can. Also listing the risks in this fashion brings them to the attention of project leaders so that they might be able to come up with some kind of mitigation.

This kind of information being produced and circulated means that should anyone question your competence or your coverage. You can provide all the documentation as to the process that you have followed and why. 

Planning time

Sorry I have not posted in a while but been looking after number one and enjoying my honeymoon.

Consequently this post came to me on holiday.

There are many things that should be considered when managing testing and one of the most important is the issue of resources. Even when you think you have it all done and everything scheduled into the correct deadlines there is always something that will change. It might be that someone goes off sick... it might be that you missed that someone was going on holiday or even some family berevement. The long and short of it is that your plans must be flexible and should even when tight deadlines are being worked to hold a measure of contingency. If you cannot have any contingency then your testing should be planned in a way that you know what all the high priority test cases are that absolutely must be covered.

This will mean that even for emergency changes you can have a good measure of assurance that the system will function as desired.