1 Directory Structure project Directory Structure project IS Quality AssuranceIS Quality AssuranceWelcome 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 projectDirectory Structure project
2 QA Directory Structure OverviewProvide StandardizationMake access easier and more uniform for entire departmentCentralize filing system for more comprehensive coverageAs 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 HierarchyNetwork NeighborhoodChicago 34DataDepartmentsISQA CommonThe 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 HierarchyQA CommonSystem TestingIntegration TestingMethodologyMetricsCatchallUp 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 TestingAppName* (One folder for each application)AppVer* (One folder for each release)Test ApproachTest PlansTest CyclesTest ConditionsTest ScriptsTest ExecutionExecution ScheduleActual ResultsMetricsFor 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 TestingVersion* (One folder for each release)Test ApproachTest PlansTest CyclesTest ConditionsTest ScriptsTest ExecutionExecution ScheduleActual ResultsMetricsThe 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 MethodologyMethodologySystemIntegrationThe Methodology folder will contain all the process documentation. The folder will be broken into- System Test Methodology- Integration Test Methodologywith the main folder containing all other relevant information
8 QA Directory Structure MetricsGeneralSystemIntegrationThe Metrics folder will contain all the results documentation. The folder will be broken into- System Test Metrics- Integration Test Metricswith 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 CatchallDocumentationNotesQA FormsGeneral IssuesCatchall 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 SummaryImproved process flowMore comprehensive communication with other departmentsTighter integration with established standardsSo 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 projectDirectory Structure project