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'.