|
First, you need a testplan. Define your test strategy, test environment, test tools, test team. Read (in some cases, write) the functional and technical specifications. Make a list of what features constitute "feature complete" and make sure the specifications clearly describe expected functionality. Add quality features such as reliability, stability, ease of use. Lastly, detail the platforms the software must be compatible with. Then take 2-3 days and write your test cases. Look at each feature in three ways -- median, this is the positive test case, bound, this is the boundary condition, and error, this is an error the software developers should expect the user to encounter -- it should be handled appropriately.
For embedded systems, you will want to look closely at stability and memory usage on the hardware. If you are working with wireless PocketPCs & video streaming as we are, you will want to look at memory usage on the device, intermittent network connectivity, and concurrency against the server.
Take these steps and do not expect to master your new role the first time around -- get feedback on your planning from developers and project managers. Add or subtract test cases based on developers' feedback. Add or subtract from your qa team definition based on your project managers' feedback. OK, you have your plan, as the system is developed, build out your test enviornment - and don't get caught up evaluating testing tools until your manual test effort is working well.
Lastly, don't try to go through a test cycle without a good bug tracking syste |
|