Presentation is loading. Please wait.

Presentation is loading. Please wait.

Directory Structure project Directory Structure project

Similar presentations


Presentation on theme: "Directory Structure project Directory Structure project"— Presentation transcript:

1 Directory Structure project Directory Structure project
IS Quality Assurance IS Quality Assurance Welcome to the rollout of our new Directory Structure Project. With all the changes that have been occurring in IS, we have been left with a legacy of various systems for keeping track of test data. Going forward, we are going to have one way to maintain our information so we can achieve more accountability. Directory Structure project Directory Structure project

2 QA Directory Structure
Overview Provide Standardization Make access easier and more uniform for entire department Centralize filing system for more comprehensive coverage As mentioned, - we all need to get on the ‘same page’ when it comes to documenting, tracking and saving information on the various projects we cover. - this standardization will enable upper management as well as members of other teams to know where to find information they may need. - also, by having one area in which to save testing methodology, use cases,scripts, and results we cut down on time someone might spend trying to locate that information.

3 QA Directory Structure
Main Hierarchy Network Neighborhood Chicago 34 Data Departments IS QA Common The Main Hierarchy is pretty straight forward and builds on an existing directory structure. - The Network Neighborhood everyone has rights to, - Chicago 34 is a server that everyone in IS has rights to, - As is the Data directory - And Departments. - IS, - And QA Common. This directory has the rights where anyone may view the information within.

4 QA Directory Structure
Resident Hierarchy QA Common System Testing Integration Testing Methodology Metrics Catchall Up to the QA Common directory are structures that already exist out on the network. Within the QA Common directory are a new set of directories that have been created for this project: - System Testing will be used extensively by the System Test team, and will be reviewed as needed by our department manager as well as upper management as needed. - Likewise, Integration testing will be used extensively by the Integration Team and reviewed by others as necessary. - Methodology will be a repository for departmental information as well as tracking and test script templates, and will most likely only be accessed periodically by most teams. - Similarly, with Metrics, it will only be accessed by team leads updating Test Cycle progress. - The Catchall will be just that: for any other information that doesn’t readily fall into any of the other categories.

5 QA Directory Structure
System Testing AppName* (One folder for each application) AppVer* (One folder for each release) Test Approach Test Plans Test Cycles Test Conditions Test Scripts Test Execution Execution Schedule Actual Results Metrics For the System Test Team we will have a set of nested directories for you to easily access and record your test results. We will need to break it down to this level of granularity to be able to isolate individual projects and their releases: - Application name at the highest level, - The Application version next, be it Beta, 1.0, 1.1, etc. - The Test Approach that needs to be completed before System Testing can begin - Test Plans generated from the Detail Design Documents out on the LAN - Test Cycles like Shakeout, Stress and Volume, etc. - Test Cases derived from user input and Test Use Cases from previous releases - Test Scripts where the testers will keep and maintain their scripts - Test execution schedule where the schedule will be kept and updated to track progress - Actual results where successes and failures in our application will be maintained - Metrics where we will keep information on bug report numbers and the like.

6 QA Directory Structure
Integration Testing Version* (One folder for each release) Test Approach Test Plans Test Cycles Test Conditions Test Scripts Test Execution Execution Schedule Actual Results Metrics The Integration test folder will be separate from the applications since they involve varios applications and will be referred to by release. - Verison will referr to release reference. Release references will be in a format that we all are familiar with like “3rd Quarter, 2001”. - The Test Approach that needs to be completed before Integration Testing can begin - Test Plans generated from the Detail Design Documents out on the LAN - Test Cycles like Shakeout, Stress and Volume, etc. - Test Cases derived from user input and Test Use Cases from previous releases - Test Scripts where the testers will keep and maintain their scripts - Test execution schedule where the schedule will be kept and updated to track progress - Actual results where successes and failures in our application will be maintained - Metrics where we will keep information on bug report numbers and the like.

7 QA Directory Structure
Methodology Methodology System Integration The Methodology folder will contain all the process documentation. The folder will be broken into - System Test Methodology - Integration Test Methodology with the main folder containing all other relevant information

8 QA Directory Structure
Metrics General System Integration The Metrics folder will contain all the results documentation. The folder will be broken into - System Test Metrics - Integration Test Metrics with the main folder containing all other relevant information. It is important that we document our results as much as possible. With the economy the way it is, it is important that we justify our ROI (return on investment) to upper management. If we do not demonstrate our value to others, we can not expect others to realize this on their own. Even in good times it makes good business sense to be able to demonstrate added value within an organization.

9 QA Directory Structure
Catchall Documentation Notes QA Forms General Issues Catchall is just that: documents that do not fit into any other category go here. Please refrain from keeping documents on your local hard drive. If you aren’t here one day, chances are that’s the day we’ll need to know something from you. Help the team out by keeping all test relevant documents in these publicly accessible folders.

10 QA Directory Structure
Summary Improved process flow More comprehensive communication with other departments Tighter integration with established standards So I believe that we’ve covered all the ‘Hows’ of what we are doing, but to drive the point home, - observing and using this uniform directory structure will improve the over all process flow of the many documents we handle while in the test phase - observing and using this uniform directory structure will improve our communication with other departments by enabling other teams to view our documents in one place. This instead of them having to chase someone down to see where something is. - we have talked a lot about methodology in the past months. By implementing this standardization project, we will be moving closer to doing the things we should be.

11 Finis Finis IS Quality Assurance IS Quality Assurance
That’s all folks. Thanks for coming and have a good day. Any one having questions, please feel free to contact me. Directory Structure project Directory Structure project


Download ppt "Directory Structure project Directory Structure project"

Similar presentations


Ads by Google