Home Library Translate
A A A
Share »
Follow us on Facebook Follow us on Twitter Follow us on LinkedIn
Connect »

Blog: Business Communications

Menu

  • This Blog's Home
  • Guest Writer Submissions
  • Policies
  • To Subscribe to a Blog
  • About
  • Feedback

Creating Test Plans

By Theresa Pojuner on February 6, 2012

Once the application/product has been created and before it goes live, a detailed quality check will be conducted. To perform this check and to ensure that all functionality/features/ attributes/ facets of the product perform as intended, a Test Plan is created and used to perform a detailed check on the application/product.  A test plan can be created for prototypes, system and data migrations, system designs etc, but what will be posted here is a sample test plan for a simple field within a product. No matter what type of test plan is created, the logic and organization of the test plan created will be similar to what is noted.

To clarify the definition, Test Plans are needed to help the Quality Assurance (QA) tester conduct a series of tests in order to validate an application via functionality, task oriented or even mathematical or data tests.

To present the Test Plan, use an outline format so that a task can be noted and insert sub-tasks to further define the test. This format seems to be the easiest to follow, as Test plans are usually extremely detailed. As a simple example, if a numerical field is to be tested within an entry form, list this as a task. Then below it, list sub-items that need to be checked.

For example:

  • does the field accept the maximum length of numbers,
  • If more than the maximum length of characters is input:
    • does the field accept it,
    • does an error message occur; if yes, note in bug list
    • does it accept alpha or extraneous characters; if yes, note in bug list
    • does it accept decimals.
  • is the data saved when you go to the next screen and return (check previous screen as well)
  • check the database
    • is the data saved as entered.

All this may seem tedious, but those are the typse of scenarios that need to be tested. Every situation listed has to be tested step-by-step and verified. Every action that a user might perform has to be noted and checked. Along with verification, the test plan should also check to see if the application is logical or if the flow makes sense. The creator of the test plan needs to have placed them self in the mindset of the user and include different actions that a user might perform.

The beginning of the Test Plan, along with pertinent instructions, should include:

  • System requirements denoting the platform under which the program would and/or would not work, who can access the program, and what results should be expected. This precedent should also be verified.
  • A set of detailed systematic instructions as to how the application should work and what steps the tester can undertake to validate the authenticity of the program or to invalidate it. In other words, the tester needs to see if the program can be broken or fail or has faults in it; to invalidate it.

Test plans are lengthy, detailed, and have to be part of the team’s project plan. Test plans must consist of a series of test cases or scenarios which will aid in retracing steps whenever problems occur as well as for regression testing.

When problems are encountered, different resolutions should be tried and then listed. If no resolutions are listed, note them as irregularities or anomalies within a Bug List.

We will talk about a Bug List in the next post.

« Previous Next »

Search Our Site

Meet This Blog’s Host

Gail Zack Anderson, President of Applause, Inc., has nearly 20 years experience in training and coaching. She provides individual presentation coaching, and leads effective presentation workshops and effective trainer workshops. [Read more ...]


Theresa Pojuner is a Documentation Specialist with over 20 years of writing experience and is skilled in many areas of documentation, for example, Style Guides, Training Manuals and Test Cases, wth a specialty n Technical Writing and Procedures. [Read more ...]

Recent Blog Posts
Alternate Recent Posts Widget

  • Becoming A Technical Writer-Communicator Review
  • Creating A Knowledge Community
  • Tips for Handling Technical Writer Stress
  • Likeminded Communication
  • A Technical Writer Is Different From Other Writers
  • Involve and Engage Your Audience 20 Ways
  • Tips On Documenting Processes
  • Communicating Technical Writing Review
  • Communicating Via Visual Designs
  • Special Tips for Laptop Presentations

Related Library Topics

  • Body Language
  • Netiquette

Categories of Posts

  • Basics and Overviews
  • Body Language
  • Communicating Change
  • Communication Best Practices
  • Feedback (Sharing)
  • Humor in speaking
  • images
  • Listening
  • Netiquette
  • Presenting
  • slide shows
  • Speaking Skills
  • Team Presentations
  • technical writing
  • Telephone Skills
  • Uncategorized
  • Visual Aids
  • Voice and Vocal Habits
  • Writing

Library's Blogs

  • Boards of Directors
  • Building a Business
  • Business Communications
  • Business Ethics, Culture and Performance
  • Business Planning
  • Career Management
  • Coaching and Action Learning
  • Consulting and Organizational Development
  • Crisis Management
  • Customer Service
  • Facilitation
  • Free Management Library Blogs
  • Fundraising for Nonprofits
  • Human Resources
  • Leadership
  • Marketing and Social Media
  • Nonprofit Capacity Building
  • Project Management
  • Quality Management
  • Social Enterprise
  • Spirituality
  • Strategic Planning
  • Supervision
  • Team Building and Performance
  • Training and Development
About Feedback Legal Privacy Policy Contact Us
Free Management Library, © Copyright Authenticity Consulting, LLC ®; All rights reserved.
  • Graphics by Wylde Hare LLC
  • Website maintained by Caitlin Cahill

By continuing to use this site, you agree to our Privacy Policy.X