Test Policy

I am quite interested in this testing artifact and how many people out there actually have one. This is a document that is very short maybe just a page and it highlights at the highest level what the business itself expects from testing.

I have worked in several places that dont have this and all of them seem to have the same issue testing seems to have a free reign and little focus. Within a company every member of the testing should have an awareness of this document. I am a firm believer that this should really be a bit like a cub scout promise.

I will amend this at a later date to add further information on what should be in a test policy and how to write it.

ISEB Intermediate Software Testing Exam

For those of you that think that this is just a piece of paper and proves nothing then I believe that you are wrong. Having just completed this exam I was pleasantly surprised to find how difficult this  actually was. All the info learnt and all the theory are for nothing in this if you cannot apply your knowledge to real situations.

It means that rather than just having a load of techniques, that you are not sure where to use, you can now identify what techniques to use in the planning stages of testing. For me it has given the insight to be able to greater understand a test analyst and test manager role. I also feel i have a best practice to aim for in my work.

One topic that I found especially usefull was the sections that covered risk. This will aid me on a day to day basis with scoping out the areas that I will be able to test.

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.

Out of the frying pan into the fire.

Have you ever thought that i would be good to say.

• We wont take things that arent unit tested.
• We will only be testing versus assessed risk.
• We will be reviewing all documents early and if not acceptable we will not allow development.
• If development is late then testing will be late and it wont go in the scheduled release.
• If its last minute then it better be a live issue.

Well the lion share of this is what the team I am part of are going to be doing soon. I fear that this is likely to start out being a rough ride as it is not what everyone is used to but it seems that it might well in the long run greatly improve things for everyone. Ultimately our team have little choice as currently we have little resources and alot of project and maintenance work to cover.

Testing danger!

I was sat in the waiting room at my local garage today and had some thoughts about testing and where we would be if people didnt take effort to ensure accurate testing. What would it be like if you had your MOT done then two hours later died in a crash cause by your brakes failing. In response the garage said "Well it all seemed to be passing so we just passed it only missed a few bits out." 

I think the main value in testing comes from doing the best job that you can to ensure quality and covering as many areas as you can in the time given. Then taking the results that you have and formulating a recommendation to proceed or not to proceed.