Team BLT
CS 4500
February 22, 2008
version: 1.0
Verification & Validation Plan
1.0 Introduction and overview- 1.1 Purpose of this Document Delivering a quality software product is our number one objective. This document outlines the procedures and processes that will be followed to ensure that this objective is met. It will provide guidelines to ensure quality of each individual component. It also defines what a quality product is and how we will ensure our product is quality. The method we will use for tracking, delegating, and fixing bugs. This is our quality assurance plan.
- 1.2 Scope of the Development Project Currently, DAZ Studio is a professional quality product. Though it is great to have a high quality product it can make it difficult for an new user to get accustomed to it and be able to use it to its full potential. Many users have already acheived this and enjoy using DAZ Studio. However, there is a large community of people that want an application that they can download and within 15 minutes they can be manipulating their own models for use in online virtual communities, video games, and other applications that allow users to utilize their own models. DAZ 3D would like to make another application that will target these users. We are going to work in cooperation with DAZ 3D to acheive this goal. DAZ 3D has provided us with suggested enhancements for the application. We also bring a fresh perspective to the table and have many great ideas that will enhance the application as well. We will have the responsibility of implementing changes that will help achieve the end goal. We will also simplify many of the tools and make the user experience a more pleasant one in less time.
- 1.3 Definitions, Acronyms, and Abbreviations
- 3D - three-dimensional
- DAZ Studio - a 3D posing application for 3D models.
- QT - framework that makes it possible for Daz Studio to be cross-platform.
- Sprint - development process in which a certain number of tasks are scheduled to be accomplished within a given time period. At the end of the time period progress is evaluated, new tasks are assigned, and a new time period is established.
- UI - user interface.
- 1.4 References www.daz3d.com
- 1.5 Overview of Document This document describes the testing plans, procedures, and requirements of the project.
Software Requirements Specification
Software Design Specification
-
An outline of each of the following documents is provided. Each team member takes ownership of an equal number of documents. That team member is responsible for the completion of the document. All team members participate in the preparation and review of the content for each document prior to delivery. Changes are discussed and the document is revised as necessary.
| Project Item | Review Date | Due Date |
|---|---|---|
| Project Plan | January 30, 2008 | January 31, 2008 |
| SRS V1 | February 3, 2008 | February 5, 2008 |
| SDS V1 | February 7, 2008 | February 8, 2008 |
| SDS V2 | February 13, 2008 | February 15, 2008 |
| VVP | February 18, 2008>/td> | February 19, 2008 |
| VVR | March 2, 2008 | March 4, 2008 |
| Stage 1 Release | March 3-5, 2008 | March 6, 2008 |
| VVR | March 24, 2008 | March 25, 2008 |
| Stage 2 Release | March 24-26, 2008 | March 27, 2008 |
| VVR | April 7, 2008 | April 8, 2008 |
| Stage 3 Release | April 7-9, 2008 | April 10, 2008 |
- 3.1 Component test strategy overview
- Testing Process: process by which the software will be tested.
- Test frequency: how often test is required.
- Components tested: detailed description components being tested.
- Test recording procedures: description of testing records that will be maintained.
- 3.2 ViewPort
- Testing Process: verify that component is refreshing properly and not flickering. Tools that manipulate component all function as designed.
- Test frequency: at the completion of each sprint (milestone) even no enhancements were made to the component.
- Components tested: all subcomponents of ViewPort
- Test recording procedures: document any outstanding/undocumented bugs. Add any relevant comments to existing bugs.
- 3.3 DockAreaColumn
- Testing Process: column resizes and contents refreshes while resizing. Tabs exist only where appropriate. Columns are collapsable only when other columns exist in the same docked area.
- Test frequency: at the completion of each sprint (milestone) even no enhancements were made to the component.
- Components tested: all subcomponents of DockAreaColumn
- Test recording procedures: document any outstanding/undocumented bugs. Add any relevant comments to existing bugs.
- 3.4 Pane
- Testing Process: All panes are dockable/undockable. Panes are draggable. Preview image of pane exists while docking/undocking/dragging.
- Test frequency: at the completion of each sprint (milestone) even no enhancements were made to the component.
- Components tested: all subcomponents of Pane
- Test recording procedures: document any outstanding/undocumented bugs. Add any relevant comments to existing bugs.
- 3.5 Menu
- Testing Process: all tools within menus are functional. Unwanted tools are removed. Added tools are found in the menu. Menu is organized and intuitive.
- Test frequency: at the completion of each sprint (milestone) even no enhancements were made to the component.
- Components tested: all subcomponents of Menu
- Test recording procedures: document any outstanding/undocumented bugs. Add any relevant comments to existing bugs.
- 4.1 System test strategy overview
- Testing Process: process by which the software will be tested.
- Test frequency: how often test is required.
- Components tested: detailed description components being tested.
- Test recording procedures: description of testing records that will be maintained.
- 4.2 System test description
- Testing Process: all elements of the UI will be tested for functionality. This will expose newly introduced bugs and provide a means for tracking progress (remaining items).
- Test frequency: at the conclusion of each sprint (milestone).
- Components tested: ViewPort, DockAreaColumn, Pane, Menu.
- Test recording procedures: encountered bugs will be recorded for review/fix later.
-
Team BLT will use a spreadsheet for bug tracking. Each bug will contain a priority, a status, a description, and additional comments.
Priority will range from P1 (blocker - program fails), P2 (medium - nuasances that do not affect functionality), and P3 (enhancements).
The status can be under review (logged but not yet discussed by the team), in progress (delegated to a team member who is working on it), fixed (team member has resolved the issue), or closed (fix has been verified by a team member other than he who fixed it).
The description will provide information about what the problem is and how to duplicate the issue. Additional comments will provide an area to add any information that is deemed beneficial to resolving the issue.
| Requirement | SDS Reference |
|---|---|
| Remove unnecessary tools | Section 2.3 |
| Add beneficial tools | Section 2.3 |
| Improve overall appearance | Section 2.3 |
| Enhance Functionality | Section 2.3 |
-
The nature of our project is somewhat subjective because each person has a different opinion regarding what is a "user-friendly" and functional UI. Some of our test acceptance is based on our personal opinion and the opinion of our sponsor. When possible test acceptance will be based on functional vs. non-functional.
| Identifier | Description | Test Means | Acceptance | System Functionality |
|---|---|---|---|---|
| Remove unnecessary tools | Any tool that causes confusion or is complex enough that it requires description must be removed. | Black Box | Are all tools present needed? | Avoid distracting user with tools that are not for the beginner. |
| Add beneficial tools | Any tools that will make the application easier to use should be added. | Black Box | Are any other tools needed? | Supply the user with all necessary tools. |
| Improve overall appearance | The appearance must flow and have no flaws that distract the user from using the application in the intented way. | Black Box | Does the eye flow? | A clean UI will provide an intuitive application that is easily learned and utilized. |
| Enhance Functionality | Enhance the functionality of UI elements (resizing, moving, dragging, refreshing, etc) | Black Box | Do all elements work smoothly? | Provide an overall improved user experience. |
- 8.1 Procedure by which the software product will be acceptance tested
- Software will be thorougly tested by our team. Daz 3D will also be testing our software. After the software has been deemed acceptable to us and the Daz 3D engineering team the software will be looked at by our collegues and other internal Daz employees outside of engineering for approval. Feedback will be provided and we will review and implement feedback as deemed necessary.
- 8.2 Specific acceptance criteria
- As much as possible, the software will be objectively verified. All columns must be resizeable and the contents should update while resizing. No unnecessary tabs will be present within the columns. Columns will not be collapsable unless other tool palettes exist behind the current palette. All panes must be dockable and undockable. A preview of the pane must be present at all times when docking, undocking, and dragging. The viewport must refresh sufficiently to avoid artifact renderings while avoiding flickering. All provided tools function as designed.
- Many of our enhancements are, however, subjective. The UI is pleasing to the eye. There are no distracting elements. All tools provided are necessary and no necessary tools are omitted.
- 8.3 Scenario by which the software product will be installed
- Daz 3D provides a downloadable version free of charge for both Mac and PC. The installer and build environment is provided by Daz 3D. Any one who desires can download and install Daz Studio Easy on their home computer.
| Date | Version | Description |
|---|---|---|
| February 22, 2008 | 1.0 | Create VVP |