7 Chapter Seven Development of a Framework
7.1 Evolved quality assurance framework
During the course of the evaluation of the process additional documents and modifications to the process were developed. Some enhancements to the process are listed below:
1. The adoption of use cases to document and explain typical customer scenarios. 2. Application prototypes for proof of concept were introduced to facilitate
getting sign off of previous documents. A prototype is not a completed software solution but a portion of the solution that indicates the direction that the solution is taking.
3. A template repository for project documentation was also developed to assist with the discovery and retrieval of present and previous project documentation. The repository would be version controlled to assist with configuration management.
4. The addition of a resource plan and schedule for the project so that all team participants regardless of the project stage would have visibility on their inclusion on the project. This facilitated their attendance at review meetings. It also provided a cause and effect indicator if resources were not available to complete certain items of project material. The impact to other departments was more obvious.
5. A separate traceability matrix was created which allowed for the mapping of each user requirement and functional point through analysis, design, coding and test. This matrix was used to supplement the project schedule.
6. A Quality policy that outlines the roles and responsibilities for the project participants in terms of acceptable standards, guidelines and quality criteria for deliverables.
7. A more detailed company technical architecture plan that facilitated discussion at review meetings.
8. Enhancements to the existing URD, SDS, test strategy, test plan documents to cover issues that arose over previous projects.
9. The inclusion of stage meetings (Go – No – Go meeting), as review meetings were not attended by all project participants. It gave an opportunity for a
dependent department to hold the project up pending items to be completed. The benefit was to facilitate outstanding items that were „lost‟ during the project to be aired and to have relevant stake holders present to make decisions on the continuation of the project.
10. The inclusion of change control practices to ensure that change requests to the project are recorded and that their impact to the project and participants is assessed before the changes are made. The dissemination of information pertaining to the change requests is handled effectively to reduce the impact on the project.
11. The identification and inclusion into the test process all artefacts of the project lifecycle including those from development for visibility to all project participants.
12. The identification and inclusion of all software and test tools for the project into the process for greater team understanding of deliverables and responsibilities from all team participants. Checklists would be created to ensure that all deliverables were complete before the project would move from one stage to another.
13. The inclusion of a post project review meeting to discuss issues that arose during the project and to address these issues. This review ensures that continuous process improvement is adhered to by making changes as appropriate to the relevant artefacts and processes.
For the purpose of explanation the tools and deliverables that have not been mentioned earlier are listed below.
Defect repository / tool
This is a data store where the details of software defects are recorded. The repository would allow for the status of defects to be identified and for the production of metrics in relation to the defect. E.g. length of time the defect was open and what build it was fixed in.
Reports
This is a report that records information relevant for presentation to management with regards the status of the project for a particular team or stage.
Development tools
This item relates to the software tools that the developers require to fulfil their role on the project. It is included to highlight the responsibility of the developers to ensure that they have the correct tools for the tasks assigned to them. E.g. Code editor and compiler
Development environment
This item relates to the software environment that is necessary for the developer to fulfil their role on the project. It is included to highlight the responsibility of the developers to ensure that they have the correct environment for the tasks assigned to them
Code repository
This is a data store where the software source code is maintained. The repository would allow for the source code to be checked out to individual developers to maintain control over builds.
Test data
This item relates to the generation and maintenance of data that is used during the test process. The data would be versioned and maintained for repeated use. The data would be created to meet with test coverage expectations to ensure as much of the functionality is tested as possible.
Test case repository
This is a data store where the test cases are stored. It is also used to record what the status of the test cases are to report on what tests have been executed, what tests have passed and failed etc. The repository would allow for the status of the software to be assessed at defined intervals, e.g. weekly. The metrics from the test case repository and defect repository should give a good indicator as to what the status of the project software is.
QA environment
This item relates to the software environment that is necessary for the tester to fulfil their role on the project. It is included to highlight the responsibility of the testers to ensure that they have the correct environment for the tasks assigned to them
Build
The build is a version of software that has been released from the code repository. The build may come from development to QA for testing or from QA to customer. The version of the build should be unique so that the contents can be verified with supporting documentation. E.g. handover documents, defect fix reports.
The QA framework is depicted on the next two pages in figures 7.4 and 7.5 respectively. Figure 7.4 depicts the Analysis and design phases and figure 7.5 depicts the Implementation phases.