Test Plan Template 02

Test Plan Template By www.guru99.
com
TEST PLAN FOR

<<PROJECT NAME>>
ChangeLog
Version Change Date By Description
version number Date of Name of person who Description of the changes

Change made changes made
1 INTRODUCTION.............................................................................................................2
1.1 SCOPE.......................................................................................................................2
Test Plan Template by www.guru99.com
1.1.1 In Scope...........................................................................................................2
1.1.2 Out of Scope....................................................................................................2
1.2 QUALITY OBJECTIVE.....................................................................................................2
1.3 ROLES AND RESPONSIBILITIES...................................................................................... 2
2 TEST METHODOLOGY...................................................................................................3
2.1 OVERVIEW.............................................................................................................. 3
2.2 TEST LEVELS............................................................................................................ 3
2.3 BUG TRIAGE............................................................................................................ 3
2.4 SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS................................................3
2.5 TEST COMPLETENESS................................................................................................ 4
3 TEST DELIVERABLES......................................................................................................4
4 RESOURCE & ENVIRONMENT NEEDS...........................................................................4

4.1 TESTING TOOLS........................................................................................................ 4
4.2 TEST ENVIRONMENT................................................................................................. 4
5 Terms/Acronyms...........................................................................................................5
1
1 Introduction
Brief introduction of the test strategies, process, workflow and methodologies used for the
project
1.1 Scope
1.1.1 In Scope
Scope defines the features, functional or non-functional requirements of the software that will
be tested
1.1.2 Out of Scope
Out Of Scope defines the features, functional or non-functional requirements of the software
that will NOT be tested
1.2 Quality Objective
Here make a mention of the overall objevtie that you plan to achive withou your testing
Some objectives of your testing project could be
 Ensure the Application Under Test conforms to functional and non-functional

requirements
 Ensure the AUT meets the quality specifications defined by the client
 Bugs/issues are identified and fixed before go live
1.3 Roles and Responsibilities

Detail description of the Roles and responsibilities of different team members like
 QA Analyst
 Test Manager
 Configuration Manager
 Developers
 Installation Team
2
Amongst others
2 Test Methodology
2.1 Overview
Mention the reason of adopting a particular test methodology for the project. The test
methodology selected for the project could be
 WaterFall
 Iterative
 Agile
 Extreme Programming
The methodology selected depends on multiple factors. You can read about Test Methodology
here
2.2 Test Levels
Test Levels define the Types of Testing to be executed on the Application Under Test (AUT).
The Testing Levels primarily depends on the scope of the project, time and budget constraints.
2.3 Bug Triage
The goal of the triage is to
 To define the type of resolution for each bug

 To prioritize bugs and determine a schedule for all “To Be Fixed Bugs’.
3
2.4 Suspension Criteria and Resumption Requirements
Suspension criteria define the criteria to be used to suspend all or part of the testing procedure
while Resumption criteria determine when testing can resume after it has been suspended
2.5 Test Completeness

Here you define the criterias that will deem your testing complete.
For instance, a few criteria to check Test Completeness would be
 100% test coverage
 All Manual & Automated Test cases executed
 All open bugs are fixed or will be fixed in next release
3 Test Deliverables
Here mention all the Test Artifacts that will be delivered during different phases of the testing
lifecycle.
Here are the sample deliverables

 Test Plan
 Test Cases
 Requirement Traceability Matrix
 Bug Reports
 Test Strategy
 Test Metrics
 Customer Sign Off
4 Resource & Environment Needs
4.1 Testing Tools
Make a list of Tools like

 Requirements Tracking Tool
 Bug Tracking Tool
 Automation Tools
4
Required to test the project
4.2 Test Environment

It mentions the minimum hardware requirements that will be used to test the Application.
Following software’s are required in addition to client-specific software.
 Windows 8 and above

 Office 2013 and above
 MS Exchange, etc.
5 Terms/Acronyms
Make a mention of any terms or acronyms used in the project
TERM/ACRONYM DEFINITION
API Application Program Interface
AUT Application Under Test
5
6
A properly designed database provides you with access to up-to-date, accurate

information. Because a correct design is essential to achieving your goals in working with
a database, investing the time required to learn the principles of good design makes
sense. In the end, you are much more likely to end up with a database that meets your
needs and can easily accommodate change.
This article provides guidelines for planning a desktop database. You will learn how to
decide what information you need, how to divide that information into the appropriate
tables and columns, and how those tables relate to each other. You should read this
article before you create your first desktop database.
Important: Access provides design experiences that let you create database applications
for the Web. Many design considerations are different when you design for the Web.
This article doesn't discuss Web database application design. For more information, see
the article Build a database to share on the Web.
5.1 In this article
Some database terms to know
7
What is good database design?
The design process
Determining the purpose of your database
Finding and organizing the required information
Dividing the information into tables
Turning information items into columns
Specifying primary keys
Creating the table relationships
Refining the design
Applying the normalization rules
5.2 Some database terms to know
Access organizes your information into tables: lists of rows and columns reminiscent of
an accountant’s pad or a spreadsheet. In a simple database, you might have only one
table. For most databases you will need more than one. For example, you might have a
table that stores information about products, another table that stores information about
orders, and another table with information about customers.
8
Each row is more correctly called a record, and each column, a field. A record is a
meaningful and consistent way to combine information about something. A field is a
single item of information — an item type that appears in every record. In the Products
table, for instance, each row or record would hold information about one product. Each
column or field holds some type of information about that product, such as its name or
price.
Top of Page
5.3 What is good database design?
Certain principles guide the database design process. The first principle is that duplicate
information (also called redundant data) is bad, because it wastes space and increases
the likelihood of errors and inconsistencies. The second principle is that the correctness
and completeness of information is important. If your database contains incorrect
information, any reports that pull information from the database will also contain
incorrect information. As a result, any decisions you make that are based on those
reports will then be misinformed.
A good database design is, therefore, one that:
 Divides your information into subject-based tables to reduce redundant data.
9
 Provides Access with the information it requires to join the information in the
tables together as needed.
 Helps support and ensure the accuracy and integrity of your information.
 Accommodates your data processing and reporting needs.
Top of Page
5.4 The design process
The design process consists of the following steps:
 Determine the purpose of your database
This helps prepare you for the remaining steps.
 Find and organize the information required
Gather all of the types of information you might want to record in the database, such as
product name and order number.
 Divide the information into tables
Divide your information items into major entities or subjects, such as Products or Orders.
Each subject then becomes a table.
 Turn information items into columns
Decide what information you want to store in each table. Each item becomes a field, and
is displayed as a column in the table. For example, an Employees table might include
fields such as Last Name and Hire Date.
 Specify primary keys
Choose each table’s primary key. The primary key is a column that is used to uniquely
identify each row. An example might be Product ID or Order ID.
 Set up the table relationships
Look at each table and decide how the data in one table is related to the data in other
tables. Add fields to tables or create new tables to clarify the relationships, as necessary.
 Refine your design
10
Analyze your design for errors. Create the tables and add a few records of sample data.
See if you can get the results you want from your tables. Make adjustments to the
design, as needed.
 Apply the normalization rules
Apply the data normalization rules to see if your tables are structured correctly. Make
adjustments to the tables, as needed.
Top of Page
5.5 Determining the purpose of your database
It is a good idea to write down the purpose of the database on paper — its purpose,
how you expect to use it, and who will use it. For a small database for a home based
business, for example, you might write something simple like "The customer database
keeps a list of customer information for the purpose of producing mailings and reports."
If the database is more complex or is used by many people, as often occurs in a
corporate setting, the purpose could easily be a paragraph or more and should include
when and how each person will use the database. The idea is to have a well developed
mission statement that can be referred to throughout the design process. Having such a
statement helps you focus on your goals when you make decisions.
Top of Page
5.6 Finding and organizing the required information
To find and organize the information required, start with your existing information. For
example, you might record purchase orders in a ledger or keep customer information on
paper forms in a file cabinet. Gather those documents and list each type of information
shown (for example, each box that you fill in on a form). If you don't have any existing
forms, imagine instead that you have to design a form to record the customer
information. What information would you put on the form? What fill-in boxes would you
create? Identify and list each of these items. For example, suppose you currently keep
the customer list on index cards. Examining these cards might show that each card holds
a customers name, address, city, state, postal code and telephone number. Each of these
items represents a potential column in a table.
11
As you prepare this list, don’t worry about getting it perfect at first. Instead, list each
item that comes to mind. If someone else will be using the database, ask for their ideas,
too. You can fine-tune the list later.
Next, consider the types of reports or mailings you might want to produce from the
database. For instance, you might want a product sales report to show sales by region, or
an inventory summary report that shows product inventory levels. You might also want
to generate form letters to send to customers that announces a sale event or offers a
premium. Design the report in your mind, and imagine what it would look like. What
information would you place on the report? List each item. Do the same for the form
letter and for any other report you anticipate creating.
Giving thought to the reports and mailings you might want to create helps you identify
items you will need in your database. For example, suppose you give customers the
opportunity to opt in to (or out of) periodic e-mail updates, and you want to print a
listing of those who have opted in. To record that information, you add a “Send e-mail”
column to the customer table. For each customer, you can set the field to Yes or No.
The requirement to send e-mail messages to customers suggests another item to record.
Once you know that a customer wants to receive e-mail messages, you will also need to
know the e-mail address to which to send them. Therefore you need to record an e-mail
address for each customer.
It makes good sense to construct a prototype of each report or output listing and
consider what items you will need to produce the report. For instance, when you
examine a form letter, a few things might come to mind. If you want to include a proper
salutation — for example, the "Mr.", "Mrs." or "Ms." string that starts a greeting, you will
have to create a salutation item. Also, you might typically start a letter with “Dear Mr.
12
Smith”, rather than “Dear. Mr. Sylvester Smith”. This suggests you would typically want to
store the last name separate from the first name.
A key point to remember is that you should break each piece of information into its
smallest useful parts. In the case of a name, to make the last name readily available, you
will break the name into two parts — First Name and Last Name. To sort a report by last
name, for example, it helps to have the customer's last name stored separately. In
general, if you want to sort, search, calculate, or report based on an item of information,
you should put that item in its own field.
Think about the questions you might want the database to answer. For instance, how
many sales of your featured product did you close last month? Where do your best
customers live? Who is the supplier for your best-selling product? Anticipating these
questions helps you zero in on additional items to record.
After gathering this information, you are ready for the next step.
Top of Page
5.7 Dividing the information into tables
To divide the information into tables, choose the major entities, or subjects. For example,
after finding and organizing information for a product sales database, the preliminary list
might look like this:
The major entities shown here are the products, the suppliers, the customers, and the
orders. Therefore, it makes sense to start out with these four tables: one for facts about
13
products, one for facts about suppliers, one for facts about customers, and one for facts
about orders. Although this doesn’t complete the list, it is a good starting point. You can
continue to refine this list until you have a design that works well.
When you first review the preliminary list of items, you might be tempted to place them
all in a single table, instead of the four shown in the preceding illustration. You will learn
here why that is a bad idea. Consider for a moment, the table shown here:
In this case, each row contains information about both the product and its supplier.
Because you can have many products from the same supplier, the supplier name and
address information has to be repeated many times. This wastes disk space. Recording
the supplier information only once in a separate Suppliers table, and then linking that
table to the Products table, is a much better solution.
A second problem with this design comes about when you need to modify information
about the supplier. For example, suppose you need to change a supplier's address.
Because it appears in many places, you might accidentally change the address in one
place but forget to change it in the others. Recording the supplier’s address in only one
place solves the problem.
When you design your database, always try to record each fact just once. If you find
yourself repeating the same information in more than one place, such as the address for
a particular supplier, place that information in a separate table.
Finally, suppose there is only one product supplied by Coho Winery, and you want to
delete the product, but retain the supplier name and address information. How would
you delete the product record without also losing the supplier information? You can't.
Because each record contains facts about a product, as well as facts about a supplier,
you cannot delete one without deleting the other. To keep these facts separate, you
must split the one table into two: one table for product information, and another table
for supplier information. Deleting a product record should delete only the facts about
the product, not the facts about the supplier.
Once you have chosen the subject that is represented by a table, columns in that table
should store facts only about the subject. For instance, the product table should store
14
facts only about products. Because the supplier address is a fact about the supplier, and
not a fact about the product, it belongs in the supplier table.
Top of Page
5.8 Turning information items into columns
To determine the columns in a table, decide what information you need to track about
the subject recorded in the table. For example, for the Customers table, Name, Address,
City-State-Zip, Send e-mail, Salutation and E-mail address comprise a good starting list
of columns. Each record in the table contains the same set of columns, so you can store
Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail address information
for each record. For example, the address column contains customers’ addresses. Each
record contains data about one customer, and the address field contains the address for
that customer.
Once you have determined the initial set of columns for each table, you can further
refine the columns. For example, it makes sense to store the customer name as two
separate columns: first name and last name, so that you can sort, search, and index on
just those columns. Similarly, the address actually consists of five separate components,
address, city, state, postal code, and country/region, and it also makes sense to store
them in separate columns. If you want to perform a search, filter or sort operation by
state, for example, you need the state information stored in a separate column.
You should also consider whether the database will hold information that is of domestic
origin only, or international, as well. For instance, if you plan to store international
addresses, it is better to have a Region column instead of State, because such a column
can accommodate both domestic states and the regions of other countries/regions.
Similarly, Postal Code makes more sense than Zip Code if you are going to store
international addresses.
The following list shows a few tips for determining your columns.
 Don’t include calculated data
In most cases, you should not store the result of calculations in tables. Instead, you can
have Access perform the calculations when you want to see the result. For example,
suppose there is a Products On Order report that displays the subtotal of units on order
for each category of product in the database. However, there is no Units On Order
subtotal column in any table. Instead, the Products table includes a Units On Order
15
column that stores the units on order for each product. Using that data, Access
calculates the subtotal each time you print the report. The subtotal itself should not be
stored in a table.
 Store information in its smallest logical parts
You may be tempted to have a single field for full names, or for product names along
with product descriptions. If you combine more than one kind of information in a field, it
is difficult to retrieve individual facts later. Try to break down information into logical
parts; for example, create separate fields for first and last name, or for product name,
category, and description.
Once you have refined the data columns in each table, you are ready to choose each
table's primary key.
Top of Page
5.9 Specifying primary keys
Each table should include a column or set of columns that uniquely identifies each row
stored in the table. This is often a unique identification number, such as an employee ID
number or a serial number. In database terminology, this information is called
the primary key of the table. Access uses primary key fields to quickly associate data
from multiple tables and bring the data together for you.
16
If you already have a unique identifier for a table, such as a product number that
uniquely identifies each product in your catalog, you can use that identifier as the table’s
primary key — but only if the values in this column will always be different for each
record. You cannot have duplicate values in a primary key. For example, don’t use
people’s names as a primary key, because names are not unique. You could easily have
two people with the same name in the same table.
A primary key must always have a value. If a column's value can become unassigned or
unknown (a missing value) at some point, it can't be used as a component in a primary
key.
You should always choose a primary key whose value will not change. In a database that
uses more than one table, a table’s primary key can be used as a reference in other
tables. If the primary key changes, the change must also be applied everywhere the key
is referenced. Using a primary key that will not change reduces the chance that the
primary key might become out of sync with other tables that reference it.
Often, an arbitrary unique number is used as the primary key. For example, you might
assign each order a unique order number. The order number's only purpose is to identify
an order. Once assigned, it never changes.
If you don’t have in mind a column or set of columns that might make a good primary
key, consider using a column that has the AutoNumber data type. When you use the
AutoNumber data type, Access automatically assigns a value for you. Such an identifier is
factless; it contains no factual information describing the row that it represents. Factless
identifiers are ideal for use as a primary key because they do not change. A primary key
that contains facts about a row — a telephone number or a customer name, for
example — is more likely to change, because the factual information itself might change.
1. A column set to the AutoNumber data type often makes a good primary key. No two
product IDs are the same.
In some cases, you may want to use two or more fields that, together, provide the
primary key of a table. For example, an Order Details table that stores line items for
orders would use two columns in its primary key: Order ID and Product ID. When a
primary key employs more than one column, it is also called a composite key.
17
For the product sales database, you can create an AutoNumber column for each of the
tables to serve as primary key: ProductID for the Products table, OrderID for the Orders
table, CustomerID for the Customers table, and SupplierID for the Suppliers table.
Top of Page
5.10 Creating the table relationships
Now that you have divided your information into tables, you need a way to bring the
information together again in meaningful ways. For example, the following form includes
information from several tables.
18
1. Information in this form comes from the Customers table...
2. ...the Employees table...
3. ...the Orders table...
4. ...the Products table...
5. ...and the Order Details table.
Access is a relational database management system. In a relational database, you divide

your information into separate, subject-based tables. You then use table relationships to
bring the information together as needed.
Top of Page
5.10.1 Creating a one-to-many relationship
Consider this example: the Suppliers and Products tables in the product orders database.
A supplier can supply any number of products. It follows that for any supplier
represented in the Suppliers table, there can be many products represented in the
Products table. The relationship between the Suppliers table and the Products table is,
therefore, a one-to-many relationship.
19
To represent a one-to-many relationship in your database design, take the primary key
on the "one" side of the relationship and add it as an additional column or columns to
the table on the "many" side of the relationship. In this case, for example, you add the
Supplier ID column from the Suppliers table to the Products table. Access can then use
the supplier ID number in the Products table to locate the correct supplier for each
product.
The Supplier ID column in the Products table is called a foreign key. A foreign key is
another table’s primary key. The Supplier ID column in the Products table is a foreign key
because it is also the primary key in the Suppliers table.
20
You provide the basis for joining related tables by establishing pairings of primary keys
and foreign keys. If you are not sure which tables should share a common column,
identifying a one-to-many relationship ensures that the two tables involved will, indeed,
require a shared column.
Top of Page
5.10.2 Creating a many-to-many relationship
Consider the relationship between the Products table and Orders table.
A single order can include more than one product. On the other hand, a single product
can appear on many orders. Therefore, for each record in the Orders table, there can be
many records in the Products table. And for each record in the Products table, there can
be many records in the Orders table. This type of relationship is called a many-to-many
relationship because for any product, there can be many orders; and for any order, there
can be many products. Note that to detect many-to-many relationships between your
tables, it is important that you consider both sides of the relationship.
The subjects of the two tables — orders and products — have a many-to-many
relationship. This presents a problem. To understand the problem, imagine what would
happen if you tried to create the relationship between the two tables by adding the
Product ID field to the Orders table. To have more than one product per order, you need
more than one record in the Orders table per order. You would be repeating order
information for each row that relates to a single order — resulting in an inefficient
design that could lead to inaccurate data. You run into the same problem if you put the
Order ID field in the Products table — you would have more than one record in the
Products table for each product. How do you solve this problem?
The answer is to create a third table, often called a junction table, that breaks down the
many-to-many relationship into two one-to-many relationships. You insert the primary
key from each of the two tables into the third table. As a result, the third table records
each occurrence or instance of the relationship.
21
Each record in the Order Details table represents one line item on an order. The Order
Details table’s primary key consists of two fields — the foreign keys from the Orders and
the Products tables. Using the Order ID field alone doesn’t work as the primary key for
this table, because one order can have many line items. The Order ID is repeated for
each line item on an order, so the field doesn’t contain unique values. Using the Product
ID field alone doesn’t work either, because one product can appear on many different
orders. But together, the two fields always produce a unique value for each record.
In the product sales database, the Orders table and the Products table are not related to
each other directly. Instead, they are related indirectly through the Order Details table.
The many-to-many relationship between orders and products is represented in the
database by using two one-to-many relationships:
 The Orders table and Order Details table have a one-to-many relationship. Each
order can have more than one line item, but each line item is connected to only one
order.
 The Products table and Order Details table have a one-to-many relationship. Each
product can have many line items associated with it, but each line item refers to only one
product.
From the Order Details table, you can determine all of the products on a particular order.
You can also determine all of the orders for a particular product.
After incorporating the Order Details table, the list of tables and fields might look
something like this:
22
Top of Page
5.10.3 Creating a one-to-one relationship
Another type of relationship is the one-to-one relationship. For instance, suppose you
need to record some special supplementary product information that you will need
rarely or that only applies to a few products. Because you don't need the information
often, and because storing the information in the Products table would result in empty
space for every product to which it doesn’t apply, you place it in a separate table. Like
the Products table, you use the ProductID as the primary key. The relationship between
this supplemental table and the Product table is a one-to-one relationship. For each
record in the Product table, there exists a single matching record in the supplemental
table. When you do identify such a relationship, both tables must share a common field.
When you detect the need for a one-to-one relationship in your database, consider
whether you can put the information from the two tables together in one table. If you
don’t want to do that for some reason, perhaps because it would result in a lot of empty
space, the following list shows how you would represent the relationship in your design:
23
 If the two tables have the same subject, you can probably set up the relationship
by using the same primary key in both tables.
 If the two tables have different subjects with different primary keys, choose one of
the tables (either one) and insert its primary key in the other table as a foreign key.
Determining the relationships between tables helps you ensure that you have the right
tables and columns. When a one-to-one or one-to-many relationship exists, the tables
involved need to share a common column or columns. When a many-to-many
relationship exists, a third table is needed to represent the relationship.
Top of Page
5.11 Refining the design
Once you have the tables, fields, and relationships you need, you should create and
populate your tables with sample data and try working with the information: creating
queries, adding new records, and so on. Doing this helps highlight potential problems —
for example, you might need to add a column that you forgot to insert during your
design phase, or you may have a table that you should split into two tables to remove
duplication.
See if you can use the database to get the answers you want. Create rough drafts of your
forms and reports and see if they show the data you expect. Look for unnecessary
duplication of data and, when you find any, alter your design to eliminate it.
As you try out your initial database, you will probably discover room for improvement.
Here are a few things to check for:
 Did you forget any columns? If so, does the information belong in the existing
tables? If it is information about something else, you may need to create another table.
Create a column for every information item you need to track. If the information can’t be
calculated from other columns, it is likely that you will need a new column for it.
 Are any columns unnecessary because they can be calculated from existing fields?
If an information item can be calculated from other existing columns — a discounted
price calculated from the retail price, for example — it is usually better to do just that,
and avoid creating new column.
 Are you repeatedly entering duplicate information in one of your tables? If so, you
probably need to divide the table into two tables that have a one-to-many relationship.
24
 Do you have tables with many fields, a limited number of records, and many
empty fields in individual records? If so, think about redesigning the table so it has fewer
fields and more records.
 Has each information item been broken into its smallest useful parts? If you need
to report, sort, search, or calculate on an item of information, put that item in its own
column.
 Does each column contain a fact about the table's subject? If a column does not
contain information about the table's subject, it belongs in a different table.
 Are all relationships between tables represented, either by common fields or by a

third table? One-to-one and one-to- many relationships require common columns.
Many-to-many relationships require a third table.
5.11.1 Refining the Products table
Suppose that each product in the product sales database falls under a general category,
such as beverages, condiments, or seafood. The Products table could include a field that
shows the category of each product.
Suppose that after examining and refining the design of the database, you decide to
store a description of the category along with its name. If you add a Category
Description field to the Products table, you have to repeat each category description for
each product that falls under the category — this is not a good solution.
A better solution is to make Categories a new subject for the database to track, with its
own table and its own primary key. You can then add the primary key from the
Categories table to the Products table as a foreign key.
The Categories and Products tables have a one-to-many relationship: a category can
include more than one product, but a product can belong to only one category.
When you review your table structures, be on the lookout for repeating groups. For
example, consider a table containing the following columns:
 Product ID
 Name
 Product ID1
 Name1
25
 Product ID2
 Name2
 Product ID3
 Name3
Here, each product is a repeating group of columns that differs from the others only by
adding a number to the end of the column name. When you see columns numbered this
way, you should revisit your design.
Such a design has several flaws. For starters, it forces you to place an upper limit on the
number of products. As soon as you exceed that limit, you must add a new group of
columns to the table structure, which is a major administrative task.
Another problem is that those suppliers that have fewer than the maximum number of
products will waste some space, since the additional columns will be blank. The most
serious flaw with such a design is that it makes many tasks difficult to perform, such as
sorting or indexing the table by product ID or name.
Whenever you see repeating groups review the design closely with an eye on splitting
the table in two. In the above example it is better to use two tables, one for suppliers
and one for products, linked by supplier ID.
Top of Page
5.12 Applying the normalization rules
You can apply the data normalization rules (sometimes just called normalization rules) as
the next step in your design. You use these rules to see if your tables are structured
correctly. The process of applying the rules to your database design is called normalizing
the database, or just normalization.
Normalization is most useful after you have represented all of the information items and
have arrived at a preliminary design. The idea is to help you ensure that you have divided
your information items into the appropriate tables. What normalization cannot do is
ensure that you have all the correct data items to begin with.
You apply the rules in succession, at each step ensuring that your design arrives at one
of what is known as the "normal forms." Five normal forms are widely accepted — the
26
first normal form through the fifth normal form. This article expands on the first three,
because they are all that is required for the majority of database designs.
5.12.1 First normal form
First normal form states that at every row and column intersection in the table there,
exists a single value, and never a list of values. For example, you cannot have a field
named Price in which you place more than one Price. If you think of each intersection of
rows and columns as a cell, each cell can hold only one value.
5.12.2 Second normal form
Second normal form requires that each non-key column be fully dependent on the entire
primary key, not on just part of the key. This rule applies when you have a primary key
that consists of more than one column. For example, suppose you have a table
containing the following columns, where Order ID and Product ID form the primary key:
 Order ID (primary key)
 Product ID (primary key)
 Product Name
This design violates second normal form, because Product Name is dependent on
Product ID, but not on Order ID, so it is not dependent on the entire primary key. You
must remove Product Name from the table. It belongs in a different table (Products).
5.12.3 Third normal form
Third normal form requires that not only every non-key column be dependent on the
entire primary key, but that non-key columns be independent of each other.
Another way of saying this is that each non-key column must be dependent on the
primary key and nothing but the primary key. For example, suppose you have a table
containing the following columns:
 ProductID (primary key)
27
 Name
 SRP
 Discount
Assume that Discount depends on the suggested retail price (SRP). This table violates
third normal form because a non-key column, Discount, depends on another non-key
column, SRP. Column independence means that you should be able to change any non-
key column without affecting any other column. If you change a value in the SRP field,
the Discount would change accordingly, thus violating that rule. In this case Discount
should be moved to another table that is keyed on SRP.
6 Design considerations for updating data
Access for Office 365 Access 2019 Access 2016 Access 2013 Access 2010 Access 2007
28
A well-designed database not only helps ensure data integrity, but is easier to maintain
and update. An Access database is not a file in the same sense as a Microsoft Word
document or a Microsoft PowerPoint slide deck. Instead, it's a collection of objects —
tables, forms, reports, queries, and so on — that must work together to function
properly.
Users enter data primarily through controls. What you do with a given control depends
on the data type set for the underlying table field, any properties set for that field, and
properties set for the control. Finally, consider using additional database techniques such
as validation, default values, lists and lookups, and cascading updates.
For more information on updating data from a user point-of-view, see Ways to add, edit,
and delete records.
6.1 In this article
 How database design affects data entry
 Set a default value for a field or control
 Using validation rules to limit data
 Working with value lists and Lookup fields
 Deleting the data from a list or Lookup fields
 How data types affect the way you enter data
 How table field properties affect the way you enter data
 Use cascading updates to change primary and foreign key values
 Why ID numbers sometimes seem to skip a number
 Bulk updating data by using queries
6.2 How database design affects data entry
The information that you keep in a database is stored in tables, which contain data about
a particular subject, such as assets or contacts. Each record in a table contains
29
information about one item, such as a particular contact. A record is made up of fields,
such as name, address, and telephone number. A record is commonly called a row, and a
field is commonly called a column. These objects must adhere to a set of design
principles or the database will either work poorly or fail altogether. In turn, those design
principles affect how you enter data. Consider the following:
 Tables Access stores all data in one or more tables. The number of tables you
use depends on the design and complexity of the database. Although you may view data
in a form, a report, or in the results returned by a query, Access stores the data only in
tables and the other objects in the database are built on top of those tables. Each table
should be based on one subject. For example, a table of business contact information
should not contain sales information. If it does, finding and editing the correct
information can become difficult, if not impossible.
 Data types Typically, each of the fields in a table accepts only one type of data.
For example, you cannot store notes in a field set to accept numbers. If you try to enter
text in such a field, Access displays an error message. However, that is not a hard and
fast rule. For example, you can store numbers (such as postal codes) in a field set to the
Short Text data type, but you cannot perform calculations on that data because Access
considers it a piece of text.
With some exceptions, the fields in a record should accept only one value. For example,
you can not enter more than one address in an address field. This is in contrast to
Microsoft Excel, which lets you to enter any number of names or addresses or images in
a single cell unless you set that cell to accept limited types of data.
 Multivalued fields Access provides a feature called the multivalued field to

attach multiple pieces of data to a single record, and to create lists that accept multiple
values. You can always identify a multivalued list because Access displays a check box
next to each list item. For example, you can attach a Microsoft PowerPoint slide deck and
any number of images to a record in your database. You can also create a list of names
and select as many of those names as needed. The use of multivalued fields may seem
to break the rules of database design because you can store more than one record per
table field. But Access enforces the rules "behind the scenes," by storing the data in
special, hidden tables.
 Using forms You typically create forms when you want to make a database
easier to use, and to help ensure that users enter data accurately. How you use a form to
edit data depends on the design of the form. Forms can contain any number of controls,
such as lists, text boxes, buttons, and even datasheets. In turn, each of the controls on
the form either reads data from or writes data to an underlying table field.
30
For more information, see Database design basics and Create a table and add fields.
Top of Page
6.3 Set a default value for a field or control
If a large number of records share the same value for a given field, such as a city or
country/region, you can save time by setting a default value for the control bound to
that field or the field itself. When you open the form or table to create a new record,
your default value appears in that control or field.
In a Table
1. Open the table in Design View.
2. At the top of the view, select the field.
3. At the bottom of the view, select the General tab.
4. Set the Default Value property to the value you want.
In a Form
1. Open the form in Layout or Design View.
2. Right-click the control you want to work with and then click Properties.
3. On the Data tab, set the Default Value property to the value you want.
Top of Page
6.4 Using validation rules to limit data
You can validate data in Access desktop databases as you enter it by using validation
rules. Validation rules can be set in either table design or table datasheet view. There are
three types of validation rules in Access:
 Field Validation Rule You can use a field validation rule to specify a criterion
that all valid field values must meet. You should not have to specify the current field as a
part of the rule unless you are using the field in a function. Restrictions on types of
31
characters to be entered in a field may be easier to do with an Input Mask. For example,
a date field might have a validation rule that disallows values in the past.
 Record Validation Rule You can use a record validation rule to specify a
condition that all valid records must satisfy. You can compare values across different
fields using a record validation rule. For example, a record with two date fields might
require that values of one field always precede values of the other field (for example,
StartDate is before EndDate).
 Validation on a form You can use the Validation Rule property of a control on
a form to specify a criterion that all values input to that control must meet. The
Validation Rule control property works like a field validation rule. Typically, you use a
form validation rule instead of a field validation rule if the rule was specific only to that
form and not to the table no matter where it was used.
For more information, see Restrict data input by using validation rules.
Top of Page
6.5 Working with value lists and Lookup fields
There are two types of list data in Access:
 Value lists These contain a hard-coded set of values that you enter manually.
The values reside in the Row Source property of the field.
 Lookup fields These use a query to retrieve values from another table.

The Row Source property of the field contains a query instead of a hard-coded list of
values. The query retrieves values from one or more tables in a database. By default, the
lookup field presents those values to you in the form of a list. Depending on how you set
the lookup field, you can select one or more items from that list.
Note Lookup fields can confuse new Access users because a list of items appears in
one location (the list that Access creates from the data in the lookup field), but the data
can reside in another location (the table that contains the data).
By default, Access displays list data in a combo box control, although you can specify a
list box control. A combo box opens to present the list, and then closes once you make a
selection. A list box, by contrast, remains open at all times.
32
To edit lists, you can also run the Edit List Items command or you can edit the data
directly in the Row Source property of the source table. When you update the data in a
lookup field, you update the source table.
If the Row Source Type property of your list box or combo box is set to Value List, you
can edit the list of values while the form is open in Form view — avoiding the need of
switching to Design view or Layout view, opening the property sheet, and editing
the Row Source property for the control each time you need to make a change to the
list. To edit the list of values, the Allow Value List Edits property for the list box or
combo box must be set to Yes.
For more information, see Create a list of choices by using a list box or combo box.
6.5.1 Prevent the editing of the value list in Form view
1. Right-click the form in the Navigation Pane and click Design view or Layout

view.
2. Click the control to select it, and then press F4 to display the property sheet.
3. On the Data tab of the property sheet, set the Allow Value List Edits property

to No.
4. Click File and then click Save, or press Ctrl+S .
6.5.2 Specify a different form for editing the value list
By default, Access provides a built-in form for the purpose of editing the value list. If you
have another form that you would prefer to use for this purpose, you can enter the name
of the form in the List Items Edit Form property, as follows:
1. Right-click the form in the Navigation Pane, and then click Design

view or Layout view on the shortcut menu.
2. Click the control to select it, and then press F4 to display the property sheet.
3. On the Data tab of the property sheet, click the drop-down arrow in the List

Items Edit Form property box.
4. Click the form you want to use for editing the value list.
33
5. Click the File and then click Save, or press Ctrl+S .
6.5.3 Examine a lookup field in a form
1. Open the form in Layout or Design View.
2. Right-click the list box or combo box control and click Properties.
3. In the property sheet, click the All tab and locate the Row Source Type and Row
Source properties. The Row Source Type property should contain either Value
List or Table/Query, and the Row Source property should contain either a list of items
separated by semicolons or a query. For more space, right-click the property, and
select Zoom or press Shift+F2.
Typically, value lists use this basic syntax: "item";"item";"item"
In this case, the list is a set of items surrounded by double quotation marks and
separated by semicolons.
Select queries use this basic syntax: SELECT [table_or_query_name].[field_name] FROM

[table_or_query_name].
In this case, the query contains two clauses (SELECT and FROM). The first clause refers to
a table or query and a field in that table or query. The second clause refers only to the
table or query. Here is a key point to remember: SELECT clauses don't have to contain
the name of a table or query, although it is recommended, and they must contain the
name of at least one field. However, all FROM clauses must refer to a table or query. So,
you can always find the source table or source query for a lookup field by reading the
FROM clause.
4. Do one of the following.
o If you are using a value list, edit the items in the list. Make sure you
surround each item with double quotation marks, and separate each item with a
semicolon.
o If the query in the lookup list references another query, open that second
query in Design View (right-click the query in the Navigation Pane and click Design
View). Note the name of the table that appears in the upper section of the query
designer, and then go to the next step.
34
Otherwise, if the query in the Lookup field references a table, note the name of the table,
and go to the next step.
5. Open the table in Datasheet View, and then edit the list items as needed.
6.5.4 Examine a lookup field in a table
2. In the upper section of the query design grid, in the Data Type column, click or
otherwise place the focus on any Text, Number, or Yes/No field.
3. In the lower section of the table design grid, click the Lookup tab, and then look
at the Row Source Type and Row Source properties.
The Row Source Type property must read Value List or Table/Query. The Row

Source property must contain either a value list or a query.
Value lists use this basic syntax: "item";"item";"item"
In this case, the list is a set of items surrounded by double quotation marks and
separated by semicolons.
Typically, select queries use this basic syntax: SELECT [table_or_query_name].

[field_name] FROM [table_or_query_name].
a table or query and a field in that table or query. The second clause refers only to the
table or query. Here is a key point to remember: SELECT clauses don't have to contain
the name of a table or query, although it is recommended, and they must contain the
name of at least one field. However, all FROM clauses must refer to a table or query. So,
you can always find the source table or source query for a lookup field by reading the
FROM clause.
4. Do one of the following.
o If you are using a value list, edit the items in the list. Make sure you
surround each item with double quotation marks, and separate each item with a
semicolon.
o If the query in the Lookup field references another query, in the Navigation
Pane, open that second query in Design view (right-click the query and click Design
35
View). Note the name of the table that appears in the upper section of the query
designer, and then go to the next step.
Otherwise, if the query in the Lookup field references a table, note the name of the table,
and go to the next step.
5. Open the table in Datasheet View, and then edit the list items as needed.
Top of Page
6.6 Deleting the data from a values list or Lookup field
The items in a value list reside in the same table as the other values in a record. By
contrast, the data in a lookup field resides in one or more other tables. To remove data
from a value list, open the table and edit the items.
Removing data from a lookup list requires additional steps, and those steps vary
depending on whether the query for the lookup lists takes its data from a table or
another query. If the query for the lookup list is based on a table, you identify that table
and the field that contains the data that appear in the list. You then open the source
table and edit the data in that field. If the query for the lookup list is based on another
query, you must open that second query, find the source table and field from which the
second query takes its data, and change the values in that table.
6.6.1 Remove data from a value list
2. In the upper section of the design grid, select the table field that contains the
value list.
3. In the lower section of the grid, click the Lookup tab, and then locate the Row
Source property.
By default, double quotation marks surround the items in a value list, and semicolons
separate each item: "Excellent";"Fair";"Average";"Poor"
4. As needed, remove the items from the list. Remember to delete the quotation
marks that surround each deleted item. Also, do not leave a leading semicolon, do not
36
leave pairs of semicolons together (;;), and if you remove the last item in the list, delete
the final semicolon.
Important If you delete an item from a value list, and records in the table already use
that deleted item, the deleted item remains part of the record until you change it. For
example, suppose your company has a warehouse in City A, but then sells that building.
If you remove "City A" from the list of warehouses, you will see "City A" in your table
until you change those values.
6.6.2 Remove data from a lookup field
2. In the upper section of the design grid, select the lookup field.
3. In the lower section of the design grid, click the Lookup tab and locate the Row
Source Type and Row Source properties.
The Row Source Type property should display Table/Query, and the Row

Source property must contain a query that references a table or another query. Queries
for lookup fields always begin with the word SELECT.
Typically (but not always), a select query uses this basic syntax: SELECT
[table_or_query_name].[field_name] FROM [table_or_query_name].
a table and to a field in that table; conversely, the second clause refers only to the table.
A point to remember: The FROM clause will always tell you the name of the source table
or query. SELECT clauses might not always contain the name of a table or a query,
although they always contain the name of at least one field. However, all FROM clauses
must refer to a table or query.
4. Do one of the following:
o If the query in the Lookup field references another query, click

the Build button (On the Data tab of the property sheet, click next) to open the
query in Design view. Make note of the name of the table that appears in the upper
section of the query designer, and then continue to step 5.
o If the query in the Lookup field references a table, make note of the name
of the table, and then continue to step 5.
37
5. Open the source table in Datasheet View.
6. Locate the field that contains the data used in the lookup list, and then edit that
data as needed.
Top of Page
6.7 How data types affect the way you enter data
When you design a database table, you select a data type for each field in that table, a
process that helps ensure more accurate data entry.
6.7.1 View data types
Do one of the following:
Use Datasheet View
1. Open the table in Datasheet View.
2. On the Fields tab, in the Formatting group, look at the value in the Data Type

list. The value changes as you place the cursor in the various fields in your table:
Use Design View
2. Look at the design grid. The upper section of the grid shows the name and data
type of each table field.
38
6.7.2 How data types affect data entry
The data type that you set for each table field provides the first level of control over
what type of data is permitted into a field. In some cases, such as a Long Text field, you
can enter any data that you want. In other cases, such as an AutoNumber field, the data
type setting for the field prevents you from entering any information at all. The following
table lists the data types that Access provides, and describes how they affect data entry.
For more information, see Data types for Access desktop databases and Modify or

change the data type setting for a field.
Data type Effect on data entry
Short Text Short Text fields accept either text or numeric characters, including delimit
lists of items. A text field accepts a smaller number of characters than does
Note, beginning in Access
Long Text field — from 0 to 255 characters. In some cases, you can use
2013, Text data types have
conversion functions to perform calculations on the data in a Short Text fie
been renamed to Short
Text.
Long Text You can enter large amounts of text and numeric data in this type of field u
64,000 characters. Also, you set the field to support rich text formatting, yo
Note, beginning in Access
can apply the types of formatting that you normally find in word processin
2013, Memo data types
programs, such as Word. For example, you can apply different fonts and fo
39
have been renamed sizes to specific characters in your text, and make them bold or italic, and s
to Long Text. on. You can also add Hypertext Markup Language (HTML) tags to the data
more information, see Insert or add a rich text field.
In addition, Long Text fields have a property called Append Only. When yo

enable that property, you can append new data to a Long Text field, but yo
cannot change existing data. The feature is intended for use in applications
such as issue tracking databases, where you may need to keep a permanen
record that remains unchangeable. When you place the cursor in a Long Te
field with the Append Only property enabled, by default, the text in the fie
disappears. You cannot apply any formatting or other changes to the text.
Like Short Text fields, you can also run conversion functions against the da
a Long Text field.
Number You can enter only numbers in this type of field, and you can perform
calculations on the values in a Number field.
Large Number You can enter only numbers in this type of field, and you can perform
calculations on the values in a Large Number field.
Note, Large Number data
types are available only in For more information, see Using the Large Number data type.
the Office 365 subscription
version of Access.
Date/Time You can enter only dates and times in this type of field.
You can set an input mask for the field (a series of literal and placeholder
characters that appear when you select the field), you must enter data in th
spaces and the format that the mask provides. For example, if you see a m
such as MMM_DD_YYYY, you must type Oct 11 2017 in the spaces provide
You cannot enter a full month name, or a two-digit year value. For more
information, see Control data entry formats with input masks.
If you don't create an input mask, you can enter the value using any valid d
or time format. For example, you can type 11 Oct. 2017, 10/11/17, October
2017, and so on.
You can also apply a display format to the field. In that case, if no input ma
40
present, you can enter a value in almost any format, but Access displays th
dates in accordance with the display format. For example, you can enter
10/11/2017, but the display format might be set so that it displays the valu
11-Oct-2017.
For more information, see Insert today’s date.
Currency You can enter only currency values in this type of field. Also, you don't hav
manually enter a currency symbol. By default, Access applies the currency
symbol ( ¥, £, $, and so on) specified in your Windows regional settings. Yo
can change this currency symbol to reflect a different currency, if needed.
AutoNumber You can't enter or change the data in this type of field at any time. Access
increments the values in an AutoNumber field whenever you add a new rec
to a table.
Calculated You can't enter or change the data in this type of field at any time. The resu
of this field are determined by an expression you define. Access updates th
values in a Calculated field whenever you add or edit a new record to a tab
Yes/No When you click a field that is set to this data type, Access displays either a
check box or a drop-down list, depending on how you format the field. If y
format the field to show a list, you can select either Yes or No, True or Fal
or On or Off from the list, again depending on the format applied to the fi
You cannot enter values in the list or change the values in the list directly f
a form or table.
OLE Object You use this type of field when you want to display data from a file created
with another program. For example, you can display a text file, an Excel cha
or a PowerPoint slide deck in an OLE Object field.
Attachments provide a faster, easier, and more flexible way to view data fro
other programs.
Hyperlink You can enter any data in this type of field, and Access wraps it in a Web
address. For example, if you type a value in the field, Access surrounds you
text with http://www.your_text.com. If you enter a valid Web address, you
link will work. Otherwise, your link will result in an error message.
41
Also, editing existing hyperlinks can be difficult because clicking a hyperlin

field with your mouse starts your browser and takes you to the site specifie
the link. To edit a hyperlink field, you select an adjacent field, use the TAB o
arrow keys to move the focus to the hyperlink field, and then press F2 to
enable editing.
Attachment You can attach data from other programs to this type of field, but you cann
type or otherwise enter text or numeric data.
For more information, see Attach files and graphics to the records in your
database.
Lookup Wizard The Lookup Wizard is not a data type. Instead, you use the wizard to create
two types of drop-down lists: value lists and lookup fields. A value list uses
delimited list of items that you enter manually when you use the Lookup
Wizard. Those values can be independent of any other data or object in yo
database.
By contrast, a lookup field uses a query to retrieve data from one or more o
the other tables in a database. The lookup field then displays the data in a
drop-down list. By default, the Lookup Wizard sets the table field to the
Number data type.
You can work with lookup fields directly in tables, and also in forms and
reports. By default, the values in a lookup field appear in a type of list cont
called a combo box — a list that has a drop-down arrow:
You can also use a list box which displays several items with a scroll bar to
more items:
Depending on how you set the lookup field and the combo box, you can e
the items in the list and add items to the list by turning off the Limit To
List property of the lookup field.
42
If you cannot directly edit the values in a list, you have to add or change th
data in your predefined list of values, or in the table that serves as the sour
for the lookup field.
Finally, when you create a lookup field, you can optionally set it to support
multiple values. When you do so, the resulting list displays a check box nex
each list item, and you can select or clear as many of the items as needed.
figure illustrates a typical multi-valued list:
For information about creating multivalued lookup fields and using the
resulting lists, see Create or delete a multivalued field.
Top of Page
6.8 How table field properties affect the way you enter data
In addition to the design principles that control the structure of a database and the data
types that control what you can enter in a given field, several field properties can also
affect how you enter data into an Access database.
6.8.1 View properties for a table field
Access provides two ways to view the properties for a table field.
In Datasheet view
1. Open the table in Datasheet View.
2. Click the Fields tab and use the controls in the Formatting group to view the

properties for each table field.
In Design View
43
2. In the lower part of the grid, click the General tab, if it isn't already selected.
3. To see the properties for a lookup field, click the Lookup tab.
6.8.2 How properties impact data entry
The following table lists the properties that have the greatest impact on data entry and explains
how they affect data entry.
Property Location in Possible values Behavior when you try to enter data
table design
grid
Field Size General tab 0-255 The character limit applies only to fields set
to the Text data type. If you try to enter
more than the specified number of
characters, the field cuts them off.
Required General tab Yes/No When turned on, this property forces you to
enter a value in a field, and Access will not
let you save any new data until you
complete a required field. When turned off,
the field will accept null values, meaning the
field can remain blank.
A null value is not the same thing as a zero

value. Zero is a digit, and "null" is a missing,
undefined, or unknown value.
Allow General tab Yes/No When turned on, you can enter zero-length
zero strings — strings that contain no characters.
length To create a zero-length string, you enter a
strings pair of double quotation marks in the field
("").
Indexed General tab Yes/No When you index a table field, Access

prevents you from adding duplicate values.
You can also create an index from more
44
table design
grid
than one field. If you do this, you can

duplicate the values in one field, but not in
both fields.
Input General tab Predefined or An input mask forces you to enter data in a

Mask custom sets of predefined format. The masks appear when
literal and you select a field in a table or a control on a
placeholder form. For example, suppose you click a Date
characters field and see this set of characters: MMM-
DD-YYYY. That is an input mask. It forces
you to enter month values as three-letter
abbreviations, such as OCT, and the year
value as four digits — for example, OCT-15-
2017.
Input masks only control how you enter

data, not how Access stores or displays that
data.
For more information see Control data entry

formats with input masks and Format a date
and time field.
Limit to Lookup tab Yes/No Enables or disables changes to the items in

List a lookup field. Users sometimes try to
change the items in a lookup field manually.
When Access prevents you from changing
the items in a field, this property is set
to Yes. If this property is enabled and you
need to change the items in a list, you must
open the list (if you want to edit a value list)
or the table that contains the source data
for the list (if you want to edit a lookup
field) and change the values there.
Allow Lookup tab Yes/No Enables or disables the Edit List
45
table design
grid
Value List Items command for value lists, but not for

Edits lookup fields. To enable that command for
lookup fields, enter a valid form name in
the List Items Edit Form property. The
Allow Value List Edits command appears on
a shortcut menu that you open by right-
clicking a list box or combo box control.
When you run the command, the Edit List
Items dialog box appears. Alternately, if you
specify the name of a form in the List Items
Edit Form property, Access starts that form
instead of displaying the dialog box.
You can run the Edit List Items command

from list box and combo box controls
located on forms, and from combo box
controls located in tables and query result
sets. Forms must be open in either Design
view or Browse view; tables and query result
sets must be open in Datasheet view.
List Items Lookup tab Name of a data If you enter the name of a data entry form
Edit Form entry form as the value in this table property, that form
opens when a user runs the Edit List
Items command. Otherwise, the Edit List
Items dialog box appears when users run
the command.
46
7 System Requirements
7.1 Windows
 Windows Vista/Windows Server 2008 or higher.
 .NET Framework 2.0 or higher.
 500 MB RAM required. 1+ GB recommended.
 Adequate free disk space for transmission logging and writing received files.
47
Windows XP SP3, Windows Server

2003 SP2, Windows Server 2003
Office 2010 Professional,
Access R2, Windows Vista SP1, Windows
14.0 July 15, 2010 14 Professional Academic
2010 Server 2008, Windows 7, Windows
and Professional Plus
Server 2008 R2, Windows Server
2012, Windows 8[55]
Windows 7, Windows Server 2008
Access January 29, Office 2013 Professional
15.0 15 R2, Windows Server 2012, Windows
2013 2013 and Professional Plus
8, Windows 10[56]
Access September Windows 7, Windows 8, Windows Office 2016 Professional
16.0 16
2016 22, 2015 8.1, Windows 10[57] and Professional Plus
Access September Office 2019 Professional
16.0 16 Windows 10[58]
2019 24, 2018 and Professional Plus
48

Test Plan Template 02

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Test Plan Template 02

Загружено:

Авторское право:

Доступные форматы

Test Plan Template By www.guru99.

TEST PLAN FOR

Version Change Date By Description

version number Date of Name of person who Description of the changes

4 RESOURCE & ENVIRONMENT NEEDS...........................................................................4

1.1.2 Out of Scope

1.2 Quality Objective

Some objectives of your testing project could be

 Ensure the Application Under Test conforms to functional and non-functional

1.3 Roles and Responsibilities

2.2 Test Levels

2.3 Bug Triage

The goal of the triage is to

 To define the type of resolution for each bug

2.4 Suspension Criteria and Resumption Requirements

2.5 Test Completeness

Here are the sample deliverables

4 Resource & Environment Needs

4.1 Testing Tools

Make a list of Tools like

Required to test the project

4.2 Test Environment

Following software’s are required in addition to client-specific software.

 Windows 8 and above

A properly designed database provides you with access to up-to-date, accurate

5.1 In this article

Some database terms to know

What is good database design?

The design process

Determining the purpose of your database

Finding and organizing the required information

Dividing the information into tables

Turning information items into columns

Specifying primary keys

Creating the table relationships

Refining the design

Applying the normalization rules

5.2 Some database terms to know

5.3 What is good database design?

A good database design is, therefore, one that:

 Divides your information into subject-based tables to reduce redundant data.

 Accommodates your data processing and reporting needs.

5.4 The design process

The design process consists of the following steps:

 Determine the purpose of your database

This helps prepare you for the remaining steps.

 Find and organize the information required

 Divide the information into tables

 Turn information items into columns

 Specify primary keys

 Set up the table relationships

 Refine your design

 Apply the normalization rules

5.5 Determining the purpose of your database

5.6 Finding and organizing the required information

5.7 Dividing the information into tables

5.8 Turning information items into columns

 Don’t include calculated data

 Store information in its smallest logical parts

5.9 Specifying primary keys

5.10 Creating the table relationships

1. Information in this form comes from the Customers table...

2. ...the Employees table...