Requirement trade off

When testing against releases the process is ongoing stepping from the execution in one software release and into the planning and preparation for testing another release. With everyone working to tight deadlines and us working alongside the software developers often we find that many of the details and requirements are not available at the planning stages. I try to implement the following to ensure that by the time software is ready to test we have the required scripting completed and the requirements/design is available. Firstly i evaluate what should be in the release based on what has been approved and then i review the requirements. I then identify what i believe to be testable requirements and weak areas that will need further review and highlight these areas back to the business analysts. I will then produce test scenarios, scripts and cases to cover the testable areas and repeat this process up until the software is submitted for system testing. If the requirements still are not acceptable then a decision is taken to either reject the release or proceed with a risk. If proceeding with a risk then this should be formally noted against the project.

What definately should not happen is that the developer says to you we dont have the requirements but this is what it is supposed to do. If you take this information and then use it as a test basis then how do you know if that is the product that was requested initially. Ultimately what this will lead to is poorly defined requirements and a request that started out for a 'rope swing' and ended up being a 'crane'.

New testers starting out

My team have in recent times gained a couple new testers. This has highlighted to me some of the simple things that you forget as you become more experienced. Basic principles that are of use to someone completely new to testing.

1. KISS - Keep It Simple Stupid : if you are going to write test scripts keep them simple and write them so that anyone can follow them.


2. Review - When planning test scripts run the scenarios then at least have these peer reviewed i.e. get someone to look through what you are planning and comment on it. Once the scripts are complete i would recommend that for visability these are reviewed by business, technical and test representatives before script execution.


3. Dont debate it log it - When you find a defect then dont try and work out why or debate whether it is or not LOG IT. If you have found a difference between the actual and expected outcomes then the ideal person to resolve this issue is the developer and not the tester.


4. Picture says a thousand words - Where possible attach a screen shot of any issues, this gives more detail than just some text and might provide information to the developers that was not previously noticed. This also provides evidence that the issue was encountered as described.


5. Break it down - Break the scripting down into bite sized chunks in this way it will be much more reusable especially if you have a tool that will allow parameterisation.


6. Assume nothing - When you are testing an application it should not be based on what you think it should do. This information should have been clearly provided in advance in the documentation. If you dont have all of the requirements and design information required then this should be raised as an issue.

Unit test recording

I am in the process of working with some developers in ensuring that they produce an acceptable level of unit test evidence. This can cause issues as we dont wish to add a large overhead to the unit testing process by mandating the use of test scripts and formal test execution but at the same time require some record that the unit testing has been performed.

What is being trialled so far with some development acceptance is a simple document asking for information on the :
Introductory Information

• System - Software application that is being worked on.
• Project - Project Name and Code
• Change - What is being tested? could be the whole system or could be a small new feature.

Tabulated

• Tester - Person performing the unit testing (Ideally not the developer of the code.)
• Test ID - Identification for individual test
• Input - Quick summary of what action is required (e.g. click all close buttons)
• Expected Output - Quick summary of what is expected (e.g. application should close successfully with no exceptions or memory leaks)
• Test passed - Y/N
• Issues - Any issues outstanding.

This it is hoped will help prevent certain areas of unit testing being missed and greatly increase the overall quality of the end solutions.

Office Politics

Isn't it strange how when working within a company, everyone should be working together and separate teams should be effectively communicating, they just DON'T. I think a key issue here is office politics and this is within testing as much as any other area.

What relevance is this? you might be thinking.

My day began with fireworks over what team should be testing a piece of work and ended with finger pointing over who was responsible for the test environment when not enough resources have been scheduled for adequate resource.

To me it stresses that approach is everything when dealing with issues and that the power of talking to someone face to face should never be under estimated. If the communication initially had taken place sat around a table and been recorded then the responsibility in both cases would have been clearly laid out.

To deal with office politics and different team agendas
1/ Get everyone (especially those that have differing approaches) around the table in a meeting.
2/ Make it clear to all of the people attending what will be discussed and what is expected by the end of the meeting.
3/ Ensure that everyone agrees the way forward and that this approach is minuted and issued at the end to all attendes.

Once completed then by definition someone has assumed responsibility for this. Later in the process there should not then be any contention over resourcing etc. For these issues the documents production and agreement is essential as this ensures that everyone is clear of their responsibility.

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.