For Pass standard , learners will explain the characteristics (types, applications and
output) of different testing methodologies used during two different software
development projects. They will also explain the effect that the choice of development
methodology has on the software product, testing methodologies, user requirements
and team members. For example, a large software development project may use an
Agile methodology, as the requirements of the project can be changed based on user
requirements, which means that the test scripts can also be adapted. Also, performance
testing is likely to be important to determine the reliability of the product in a safety
critical application.
Overall, the evidence will be logically structured and it may be basic in parts. It may also
contain minor technical inaccuracies relating to software testing terminology.
Learning aim B Please note that if this unit is to be delivered alongside another BTEC programming unit,
then the best delivery approach is to use the Agile software development methodology
for learning aims B and C. If this unit is to be delivered after another BTEC programming
unit, then the best delivery approach is to use the waterfall software development
methodology. The alternative is to provide a software program and documentation to be
tested.
For Distinction standard , learners will perform a comprehensive and appropriate
range of self-planned and created tests systematically and meticulously against a
software product, showing appropriate detail and accuracy. For example, an appropriate
range of tests will focus on the vast majority of aspects, from using a software product
and performing simple tasks, to fully detailed processes in the software product, finding
potential faults and predicting errors. Learners will develop an effective test plan based
on user requirements (initial specification of the product), and the continuous testing of
the product and accurate recording of the test results will be used to build up a bank of
issues, such as user errors or system faults (meticulously).
Overall, the evidence, such as a portfolio, will be easy to read and understand by a third
party who may be an apprentice software tester. It will be logically structured, using
technical engineering and software development terms and consistent reference of
information sources.