FIT2043 Lecture Notes - Lecture 19: Requirements Traceability
L19 - Documentation for QA and Testing
QA Plans
● Typically written at the start of the project
● Describes what will be tested, how, when, and by whom
● Does not have to detail every single test that you will run
● Who read this?
○ People inside the company
○ People responsible for designing reviews and test
○ People responsible for carrying out reviews/tests and analysing results
● How to write them:
○ Internal document so can use a reasonable amount of technical vocabulary
○ Needs to specific so that the QA staff can do their job properly
○ Can refer to other internal documentation if needed
● What gets QA-ed?
○ Everythang
● Methods
○ Walkthroughs
■ Go through the code or software and looking at code artefacts to
evaluate their quality
○ Technical Reviews
■ Done in a meeting, by a panel
■ A small part of the software is reviewed
■ If it find any problems, schedule a follow-up review to ensure the
problems have been fixed
Test Plans
● Has policies for testing and QA
● Say how will the system be tested
● Say who responsible for what
Test Cases
● A set of input data or actions that is used to test system functionality
● Can be used for automated testing or manual testing
● Who reads this?
○ Manual testers
○ can’t assume that the reader is familiar with the code base when writing test
cases
● Writing good test cases: each test case needs:
○ Unique ID
○ Input data and actions that the tester should take to perform the test
○ Expected output that the tester can tell whether the test passed or failed
○ Setup is what the tester has to do before the test can begin
○ Procedure is what the tester has to do as part of the test
Traceability between Testing and Requirements (Traceability Matrix)
Document Summary
Typically written at the start of the project. Describes what will be tested, how, when, and by whom. Does not have to detail every single test that you will run. People responsible for designing reviews and test. People responsible for carrying out reviews/tests and analysing results. Internal document so can use a reasonable amount of technical vocabulary. Needs to specific so that the qa staff can do their job properly. Can refer to other internal documentation if needed. Go through the code or software and looking at code artefacts to evaluate their quality. Done in a meeting, by a panel. A small part of the software is reviewed. If it find any problems, schedule a follow-up review to ensure the problems have been fixed. Say how will the system be tested. A set of input data or actions that is used to test system functionality. Can be used for automated testing or manual testing.