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'.
Wednesday 21 January 2009
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Friday 16 January 2009
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
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.
- 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.
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.
Subscribe to:
Posts (Atom)