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.

Deadlines and estimates

It has came to that time in work again when the questions start being asked. 

When is the testing likely to be complete?

How much testing is left to be done?

How is the testing going?

and many more questions. The reality is that you can only give a best guess especially since as testers we are relying on the rest of the development team to come up with the goods for us to test. For me today I took an educated guess that it should be finished just about on time.  I would say be clear with what you are aiming to complete and what you have already completed and then they can make a judgement call aswell on the likelyhood of something being completed. 

Most of all dont just allow something through that doesnt meet the expected!! 

Waiting...

3 days late testing and moving into day 4... I wont be starting the testing till tomorrow. In this case it is not my fault or that of the developers but some important things to consider are:-

* Smoke test the environment in advance to ensure that it is working correctly.
* Where possible smoke test the application/system in advance (even if it is an early build) to check that it is going to work.
* Regularly schedule your testing to fit in with your current testing progress.
* Regularly monitor your testing activities to keep all parties up to date with current progress.
* Keep contact with the developers and business analysts to pick up on any changes to the design and requirements. These can greatly impact the testing activites and you will need to know about this ASAP.