Custom Search

Sunday, February 22, 2009

How to Improve Tester Performance?

Many Companies don’t have resources or can’t afford to hire the required number of testers on the project. So what could be the solution in this case?

The answer is simple. Companies will prefer to have skilled testers instead of a army of testers!

So how can build skilled testers on any project?
You can improve testers performance by assigning him/her to the single project.
Due to this the tester will get the detail knowledge of the project domain, Can concentrate well on that project, can do the R&D work during the early development phase of the project.

This not only build his/her functional testing knowledge but also the project Domain knowledge.

Company can use following methods to Improve the Testers performance:
1) Assign one tester to one project for long duration or to the entire project. Doing this will build testers domain knowledge, He/She can write better test cases, Can cover most of the test cases, and eventually can find the problem faster.

2) Most of the testers can do the functional testing, BV analysis but they may not know how to measure test coverage,How to test a complete application, How to perform load testing. Company can provide the training to their employees in those areas.

3) Involve them in all the project meetings, discussions, project design so that they can understand the project well and can write the test cases well.

4) Encourage them to do the extra activities other than the regular testing activities. Such activities can include Inter team talk on their project experience, Different exploratory talks on project topics.

Most important is to give them freedom to think outside the box so that they can take better decision on Testing activities like test plan, test execution, test coverage.

If you have a better idea to boost the testers performance don’t forget to comment on!

Top Three Tips to Survive in this Recession

There are people who are happy of this recession - pink slips, reduction in IT recruitment, bleak prospects etc., makes them happy with the fact the IT industry is coming to ‘normalization’. This paper is not for those who are fuming at IT but for those unfortunates who are already into this fascinating world and wondering how to get stabilized here.

Gartner analysis till 2011 is not encouraging for all of us. But the world of outsourcing and off shoring is not going to be affected very much during the coming years. It gives us an opportunity to adjust ourselves to the new environment to survive.

Here are my top three tips to survive in this recession:

1) Upgrade Your Skills - Make a Strong Profile

When I was young my teachers used to emphasis on specialized skills. Yes even in our testing world, hitherto specialization was getting much attention and my organization was able to charge differential rates to the clients for a performance architect or automation developer. Oflate, my requirements are coming differently. Clients need a test automation architect, who is good in QTP, LoadRunner, Perl, Unix, SQL, Java etc., etc., but as things emerge, you should be a jack of all arts in all testing arena.

Unless you are multi skilled, it is going to be difficult for us to survive in the emerging context. When you are out of a project, take that as a boon period to upgrade your skills. Be in testing released certifications like ISTQB, CSTE, CSQA or tools related certifications like AIS, ASE or domain related certifications in Insurance, Banking or telecom is going to help you to improve your profile.

2) Learn to Manage Stress

One more critical skill, which we need to learn, is stress management. As we move on, we will get more work related pressure. I know already several of our colleagues never see the sun light during the project execution days and this will “improve” further due to the cost cutting and operating margin pressure on the IT companies.

All of us know that a young girl committed suicide recently due to the pressure from her managers. We need to learn to live with these pressures in life. A class on Yoga or meditation will help to stabilize your mind.

3) Be Always Ready to Face Challenges

Every other day, you can see news of IT firms downsizing employees. This is hard reality in countries like India where job security is associated with the work life. It is not the question of you being a performer or non-performer, but the question of available business and required resources.

One should not get de-motivated or depressed by these events in life. In western countries, job hoping is a regular feature in life cycle but in India we are yet to get accosted to this. If you happen to face this, take it bravely and face the challenges. Cross skill will help you during this time. One of my earlier delivery managers in insurance vertical is now CEO in a hospitality company. Life gives you enough opportunity if you are ready to take challenges and use every opportunity to upgrade your skills.

As we grow, not only our skills should grow with us, but also the certifications and membership which will give an enhanced look to your profile. Also, our confidence to face the challenges should also improve. Long back, I had a supervisor, who will become uneasy, if he did not have any problem to solve. We used to yell at him at that time and now I realize that he is my mentor in facing multi dimensional issues and problems in life.

This is right time for all of us to introspect ourselves on the current skills and move forward. Nothing is impossible if you have the determination to WIN.

Saturday, February 21, 2009

Interview Tips

Interviews are a lot of work and require serious preparation. Review your recent performance and have examples of how you 1) solved a complex issue, 2) displayed leadership, 3) exhibited team spirit. Focus on accomplishments. Review in detail the requirements of this new post. Wear a nice suit
and be clean-shaved. Anticipate possible questions and have some well prepared responses. Be ready to ASK GOOD QUESTIONS.

Being nervous is natural, especially for an important experience you are about to go through. Some suggestions:

- Review the company, the division and the people you are going to work for. Learn as much about them, their products, their vision, their mission, etc...
Study online resources for this information, but also get on the phone, even seek meetings (informal ones) with others in the company, or with those
who know the company. This is considered a normal/natural part of your job seeking homework, by the way. Learn all you can, as it’s in your best

- Have one, or more, people who you know/trust to give you a series of mock interviews. What worked generally in this area (your mileage may vary!) was for anyone mock interviewer to set up a series of 3-5 interviews, each was to be a new/unique session and to put them through a variety of typical scenario's. Each session was treated like a full and FORMAL job interview, to include suit, demeanor and complete interview set of questions, answers and discussion. Afterward there was a blunt and candid review of what the objectives for that session were (from HIS perspective), what areas they did well on, where they did poorly/badly, identification of areas of opportunity where they missed out on something good (or bad) to capitalize on, and objective suggestions for improving body language,demeanor, language, and attitude. The reviews afterward were essential to improving my understanding of THEMSELVES and what they MUST improve in order to get
through the interview. For me, this proved to be a winning move.

- Go into the interview eager and ready to experience it. Relish and enjoy every moment of it. You will get to do it so infrequently, that this is a golden opportunity to experience to the fullest. You may think I'm kidding ---I'm not. By adjusting yourself so that this IS your mindset and approach, you'll find it not only enjoyable, but very rewarding as well.

- Try this approach on being calm---think about, and continuously remind yourself in productive, enriching and positive ways that you will calmly and rationally be successful in this interview. Mentally focus on what you WANT, vice what you don't want. It’s fine to honestly self-evaluate how you are
today. What is really important is HOW will you improve? What can you do better, and what are you doing about it now? Another approach is that being nervous is your minds way of telling you to be careful. You are in control of yourself. You decide what is important or worrisome. So, tell your mind what to think and how to act. Such an improvement can occur over time when you are persistent. Think about it. Side note: I've found in life, people who focus on what they don't want, or like, as the case may be, don't see how negative that is. They really believe that by telling themselves NOT to do something that somehow, magically, the RIGHT thing they are supposed to be doing will magically occur. It doesn't work that way. I've found when you positively and actively WANT something to occur, then make that accomplishment the focus of your attention --- it happens. I believe that occurs because you've DONE something, as opposed to the alternative of attempting to NOT do something. I believe the former is a positive builder in our lives. Be optimistic.

- Be honest regarding what you can do, and only volunteer what you are bad at, or cannot do when questioned about something specific that you can't do. Its reasonable to know your limitations, and that you can candidly explain the breadth of your abilities (and limits). If you find they focus on 'stuff'
you don't know, its ok. Expect such questions and take them in stride. Follow up with your speed/willingness to learn ..

The telephone interview or candidate screen allows the employer to determine if the candidate's qualifications, experience, workplace preferences and salary needs are congruent with the position and organization. The telephone interview saves managerial time and eliminates unlikely candidates. While I recommend developing a customized interview for each position, this generic interview will guide you.

You want to ask enough questions to determine if the person is a viable candidate. Remember, you have already screened many resumes and applications to come up with your short list of telephone screening candidates. These should be your best prospects at this point in your recruiting process.

Here at, we want our candidates to reflect well on us, this means we have to not waste your time with inappropriate positions, but sometimes this in itself is not enough. The demand for candidates is high, but so is the competition for securing the most lucrative positions, in the most exciting projects.

We believe that effective interview preparation and technique, will help make a big difference whether you are trying to secure that next big career move or the SAP consultant’s three month contract worth circa £45,000 to you in income. If you look at the monetary value alone, your ability to perform well at interview, becomes very worthwhile and is a part of your skillset that you should not neglect.


Preparing for interviews helps you to:

Anticipate questions and prepare answers such that you present yourself in a clear and concise manner. It also improves the accuracy and completeness of the answer. Customise your answers in line with the job requirements, organisation culture/norms and industry facts. This helps you to relate past experience to current job requirements and to provide convincing examples/experiences in relation to the organisation/ industry/project deliverables.


While preparation covers all aspects, you may like to concentrate on three core areas. This does not mean preparation excludes areas such as knowledge of company, job and industry. These are also important as knowledge of these aspects show the interviewee's interest.

Technical Preparation

Key areas to pay attention to pre-interview are:
Does the role require technical skillsets that I already have or need to acquire?
What are my key examples of work in this specific technical discipline?
What are my areas of strength, relevant to this role?
What do I anticipate are the most important technical skillsets for the client?
How can I best demonstrate my ability in those key skillsets?
What technical questions can I ask that will demonstrate an appreciation of the interviewers typical technical issues/problems? (Especially useful if you know the key project objectives in advance).

Operational Preparation
Preparation in this area concentrates on the use of technical knowledge in a project or work environment.
This shifts from being able to demonstrate technical knowledge, to demonstrating the role that you have performed and can perform in a work environment or project lifecycle. The interviewees experience during usage of technical knowledge. This could vary for different roles. For example; Programmers would need to know about debuggers, profilers, tool or utilities etc.

Analyst /Designer Would need to know methodology (SSAD, OOM), standards (IEEE, ANSI, CUA), environment (utilities) etc. Project Managers Would need to know have technology awareness (versions, new releases), available techniques ( tools, standards ), quality assurance (measurements, test management), configuration management (version control, change management) project management (planning, organizing reporting), user requirements and contractual obligations. The depth would be an over-view of all levels for technical knowledge.

Personal Preparation
This area would include presentation of positive traits and habits. In addition to this it is important to concentrate on developing appropriate communication skills, again, how you say something can count for a great deal. This is hard to prepare for, they are registered by the interviewer through your use of language, demeanour, mannerisms and delivery of your responses to their questions. If you maintain a professional, positive and focussed outlook in the interview, you should be fine. Typical criteria that are being looked at by the interviewer will include:

Presentation skill.
Confidence level
Comprehension Brevity
Logical & concise responses.
Command of language
Power of expression
Closing an Interview.
Keep it simple, brief and professional.
Ask if the interviewer has any further questions or would like further information (references, certificates, technical assessments).
Confirm that you have enjoyed the meeting, you are very interested in the role and company, would readily attend another interview or can start on (date) if offered.
Is there another stage, when is a decision to be made?

Thank the interviewer for their time and that you look forward to hearing from them soon.

Post interview.
Don't be too discouraged if no definite next stage is mentioned, they may have to discuss with colleagues. Keep positive. If you get the impression that the interview is not going well, don't let that show as you may have misread the situation.

Wednesday, February 18, 2009

Localization Testing of the UI

Also keep an eye on the behavior of applications that run processes in a system-such as operating-system services-rather than in a user's context. When a system process queries its user default UI language settings, it might get a result different from what a user's process running at the same time will get. This can cause localization problems, inconsistency in the UI that the user sees (if parts of it are generated by the system services), or even problems in functionality. In order to avoid those problems, always check an application's behavior with different default user and system UI languages. The settings for UI languages should also be different from those used in the development environment.

For example, assume you have a machine with MUI installed and a user whose default UI language is different from that of the system. Suppose a fax service waiting for incoming calls is running continuously and that, when a fax arrives, the service displays a notification message to the currently logged user (if there is one). You must ensure that the message be in the user's language, which might not necessarily be the same as the one returned to the fax service when it queries its default UI language.

In particular, localization testing of the UI and linguistics should cover items such as:

  • Validation of all application resources.

  • Verification of linguistic accuracy and resource attributes.

  • Checking for typographical errors.

  • Checking that printed documentation, online Help, messages, interface resources, and command-key sequences are consistent with each other. If you have shipped localized versions of your product before, make sure that the translation is consistent with the earlier released versions.

  • Confirmation of adherence to system, input, and display environment standards.

  • Checking usability of the UI.

  • Assessment of cultural appropriateness.

  • Checking for politically sensitive content.

  • Making sure the market-specific information about your company, such as contact information or local product-support phone numbers, is updated.

Platform in Localization Testing

Any language version of Windows XP or Windows 2000 can be selected as a platform for the test if the product is properly globalized. Of course, in the case of localization testing, the localized version of the operating system can be a wise choice, since that's the most likely environment for your application in the real world. However, a globalized and localizable application, even after it undergoes localization, must be able to run on any language version of the operating system and with MUI installed.

You should run the application with MUI installed when your application implements an MUI behavior, through pluggable UI, satellite dynamic-link libraries (DLLs), or some other technique that adjusts the UI language to the user's preferences. MUI allows the user to switch the UI language of the operating system and thus you must make sure your application matches the operating-system settings. You should verify the behavior of the application when the user's default language of the UI differs from the other locale settings. By doing so, you'll immediately see any problems in the way resources are loaded and processed.

General Areas of Focus in Localization Testing

Localization testing should focus on several general areas. The first involves things that are often altered during localization, such as the UI and content files. The second consists of culture-specific, language-specific, and country-specific areas. Examples include configurable components-such as region defaults and the default language-as well as language-specific and region-specific functionality-such as default spelling checkers, speech engines, and so on. You should also test the availability of drivers for local hardware and look for the encryption algorithms incorporated into the application. The rules and regulations for distribution of cryptographic software differ from country to country.

Pay specific attention to the customization that could not be automated through the globalization services infrastructure (Win32 NLS APIs and the .NET Framework). For example, check that formatting of mailing addresses is locale-specific and that parts of the user's name are ordered correctly. (The order in which surname and first name appear varies according to country. For instance, some Muslim countries and certain regions in India use a different name order than that used in the English language.) Functionality of this kind is often implemented by an application-testing must verify its correctness.

Other areas of localization testing should include basic functionality tests; setup, upgrade, and uninstall tests that are run in the localized environment; and, finally, application and hardware compatibility tests that are planned according to the product's target market.

Purpose of Localization Testing

Products that are localized to international markets often face domestic competition, which makes it critical for the localized product to blend seamlessly into the native language and cultural landscape. The cost of a localization effort can be significant. Once you have the strings translated and the GUI updated, localization testing should be used to help ensure that the product is successfully migrated to the target market.

In addition to verifying successful translation, basic functional testing should be performed. Functional issues often arise as a result of localizing software. Don't risk the time and effort spent localizing by not performing adequate Quality Assurance.

Localization Testing Features

  • Object based Recording: Does not record based on coordinates and hence Localization testing is not affected by position change due to shorter or longer localized strings.

  • Centralized Object Repository: Localization testing will not be affected by textual changes as only logical name are placed in the scripts.

  • Unicode Support: Full Unicode support allows you to record in any language.

  • Automatic Resource Generator: Extracts all the string, literals and stores them in a resource file.

  • I18N Editor: Allows you to assign localized terms for the contents of the resource.

  • Powerful Library: Provides powerful libraries to get and set locales at runtime. Allows you to change the date format to suite the locale to be tested.

Things to be consider in Localization Testing

What we need to consider in Localization Testing ?

  • Things that are often altered during localization, such as the UserInterface and content files.

  • Operating System

  • Keyboards

  • Text Filters

  • Hot keys

  • Spelling Rules

  • Sorting Rules

  • Upper and Lower case conversions
  • Printers

  • Size of Papers

  • Mouse

  • Date formats

  • Rulers and Measurements

  • Memory Availability

  • Voice User Interface language/accent

  • Video Content

Definition of Localization Testing

Localization is the process of adapting a globalized application to a particular culture/locale. Localizing an application requires a basic understanding of the character sets typically used in modern software development and an understanding of the issues associated with them. Localization includes the translation of the application user interface and adapting graphics for a specific culture/locale. The localization process can also include translating any help content associated with the application.

Localization of business solutions requires that you implement the correct business processes and practices for a culture/locale. Differences in how cultures/locales conduct business are heavily shaped by governmental and regulatory requirements. Therefore, localization of business logic can be a massive task.

Localization testing checks how well the build has been translated into a particular target language. This test is based on the results of globalized testing where the functional support for that particular locale has already been verified. If the product is not globalized enough to support a given language, you probably will not try to localize it into that language in the first place!

Overview of Localization Testing

Although localization and, by extension, localization testing are not strictly a part of the development of world-ready software, localization becomes possible once you have developed world-ready software. If you do decide to localize, you should be familiar with the scope and purpose of localization testing. Localizers translate the product UI and sometimes change some initial settings to adapt the product to a particular local market.

This definitely reduces the "world-readiness" of the application. That is, a globalized application whose UI and documentation are translated into a language spoken in one country will retain its functionality. However, the application will become less usable in the countries where that language is not spoken.

Localization testing checks how well the build has been translated into a particular target language. This test is based on the results of globalized testing where the functional support for that particular locale has already been verified. If the product is not globalized enough to support a given language, you probably will not try to localize it into that language in the first place!

You should be aware that pseudo-localization, which was discussed earlier, does not completely eliminate the need for functionality testing of a localized application. When you test for localizability before you localize, the chances of having serious functional problems due to localization are slim. However, you still have to check that the application you're shipping to a particular market really works. Now you can do it in less time and with fewer resources.

Localization Testing


Localization (L10N) is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. This process involves translating all native language strings to the target language and customizing the GUI so that it is appropriate for the target market. Depending on the size and complexity of the software, localization can range from a simple process involving a small team of translators, linguists, desktop publishers and engineers to a complex process requiring a Localization Project Manager directing a team of a hundred specialists. Localization is usually done using some combination of in-house resources, independent contractors and full-scope services of a localization company.

Tuesday, February 17, 2009

Learning Basics of Rational Robot - IBM Test automation tool

Learning Basics of Rational Robot (7.0)

1. Features of Rational Robot
Rational Robot is an automated functional, regression testing tool for automating Windows, Java, IE and ERP applications under windows platform. Rational Robot provides test cases for common objects such as menus, lists, bitmaps and specialized test cases for objects specific to the development environment. It integrates with tools like Rational Test Manager, Rational Clearquest and Requisite Pro in the Rational Unified Processor for Defect Tracking, Change Management and Requirement Traceability. It also supports UI technologies like Java, the Web, all VS.NET controls, Oracle Forms, Borland Delphi and Sybase Power Builder applications.

2. Rational Administrator
It is a tool for managing associations between Rational artifacts such as Test Datastores, Requisite Pro projects and Rose models.

  • Rational Projects are created using Rational Administrator
  • Users and Groups can be maintained
  • Project assets can be upgraded

3. Recording Options
Using Object oriented technology, Robot identifies an object by its name property not by its location coordinates. There are two different options

  • GUI - Functional Testing
  • VU - Performance Testing

4. SQABasic language
SQABasic is similar to Microsoft Visual Basic. All the scripts will be in scriptname.rec format. When you playback the script, Robot automatically compiles and runs the script, which repeats your actions and executes the verification points.

5. Shell Scripts
It is a master script that calls other automated scripts and plays them back in sequence. “callscript test1” is a command to call script named test1. Combined into a single shell script, scripts can run in unattended mode and perform comprehensive test coverage. It centralizes test results into one test log.

6. Low level Recording
Turn “Low Level Recording On” in Robot during recording, mouse and keyboard actions are automatically stored in an external file.

7. Verification Points
Verification points verify that a certain action has taken place, or verify the state of an object. There are 11 Verification points in Robot

  • Alpha-numeric : Verifies alphanumeric data. Used for edit boxes, pushbuttons, labels, text fields, etc.,
  • Object Properties: Tests object attributes such as color, font and position.
  • Menu: Verifies the menu values and optionally their state (enabled or disabled) of a window
  • Clip Board: Verifies the contents of the windows clipboard
  • Window Existence: Tests to see if a particular window does or does not exist on the screen.
  • Region Image: Graphically compares an area of the screen you specify
  • Window Image: Graphically compares an entire window such as a window box.
  • Object Data: Test data contents of objects(eg. Dropdown)
  • File Comparison: Compares the contents of the two files (size and the contents)
  • File Existence: Checks for the existence of a specified file
  • Module Existence: Used to verify whether a specified module is loaded into a specified context, or loaded anywhere in memory.

When you are creating verification points, there will be two options – Wait State and expected Results.
Wait states are useful when AUT requires an unknown amount of time to complete a task. Using a wait state keeps the verification point form failing if the task is not completed immediately or if the data is not accessible immediately.
Expected Results – Click Pass or Fail in the Verification Point Name dialog box.

8. Variable Window
During debugging, if you want to examine variable and constant values, you can variables window. View->Variables.

9. Object Mapping
If AUT contains a custom object or any object that Robot does not recognize, you
can create a custom object mapping before start recording. By adding the object’s
class to the list of classes that Robot recognizes, and then associating the class to a
standard object type. Robot saves this custom class/object type mapping in the
project and uses it to identify the custom object during playback.

10. Debug Tools

Animate(F11) – Animation mode allows you to see each line of script as it executes.
Step Over(F10) – Use to execute a single command line within a script
Step Into(F8) – Use to being single step execution
Step Out(F7) – Use to step out of the called script and return to the calling script.
Go Until Cursor(F6) – Use to play back the active GUI script, stopping at the text cursor location.

11. Library Files and Header Files
Header files have .sbh extensions and contain the procedure declarations and global variables referred to in your script files. There are two types of library files. Those with .sbl extensions can’t have verification points. Those with .rec extensions are stored in the project and can have verification points. Both Header and library are in \SQABAS32 in the project directory.

12. Image Masks used for dynamic objects
Image masks are used to hide an area of the screen. When you play back a script that contains an Image VP and a mask, Robot ignores the masked area when comparing actual results to the recorded baseline.

13. Data Pool
A Datapool is a test dataset that supplies data variables in a test script during playback. Using datapools allows you to run multiple iterations of a script using different data each time. It can be created and managed using Test Manager for data driven tests.

14. Important Web Site for Rational Robot trial version download and Rational Robot tutorial:

Monday, February 16, 2009

Plan on Testing Success

A good test plan is the cornerstone of a successful testing implementation. While every testing effort may be unique, most test plans include a common content framework. This article presents the components that make up this framework, and serves as a guide to writing your own test plan.


This section establishes the scope and purpose of the test plan. This is where to describe the Fundamental aspects of the testing effort.

  • Purpose - Describe why the test plan was developed--what the objectives are. This may include documenting test requirements, defining testing strategies, identifying resources, estimating schedules and project deliverables.
  • Background - Explain any events that caused the test plan to be developed. This can include implementing improved processes, or the addition of new environments or functionality.
  • Technical Architecture - diagram the components that make up the system under test. Include data storage and transfer connections and describe the purpose each component serves including how it is updated. Document the layers such as presentation/interface, database, report writer, etc. A higher level diagram showing how the system under test fits into a larger automation picture also can be included if available.
  • Specifications - list all required hardware and software including vendors and versions.
  • Scope - briefly describe the resources that the plan requires, areas of responsibility, stages and potential risks.
  • Project Information - identify all the information that is available in relation to this project. User documentation, project plan, product specifications, training materials and executive overview materials are examples of project information.


This section of the test plan lists all requirements to be tested. Any requirement not listed is outside of the scope of the test plan. (The day you’re held accountable for a released bug in an untested area, you’ll be glad you had a written, signed document that shows what was in and out of scope when the testing effort was carried out!)

  • Functional Test Requirements - all functions to be tested, such as creating, editing and deleting records, are listed. This can be a fairly comprehensive listing for a full system test, or it may refer to another document.
  • Design Requirements - testing the user interface, menu structures or other forms of design elements also should be listed.
  • Integration Requirements - the requirements for testing the flow of data from one component to the other may be included if it will be part of the test plan.

Test Strategy

Use this section to describe how the test objectives will be met for each type of testing that may be part of the test plan: unit, function, integration, system, volume, stress, performance, configuration and/or installation testing. For each subset, detail the following:

  • Objective - the overall objective this strategy is designed to meet. For a complete system test, this may be a statement that all functional requirements must behave as expected or as documented.
  • Technique - document how test cases were developed, the tool(s) used to store them and where they can be found, how they will be executed, and the data to be used. Make notes here if tests are to be performed in cycles, or in concert with other testing efforts.
  • Special Considerations - unique or necessary system setup, data or other test dependencies; environment conditions or other aspects that are required to establish a known state for testing.
  • Test Cases - list or refer to the actual test cases that will be carried out to implement the plan. (See Anatomy of a Test Case on page 7 of this issue.)
  • Completion Criteria - record the criteria that will be used to determine pass/fail of tests and the action that is to be taken based on test results.
  • Assumptions - describe any outside projects or issues that may impact the effectiveness or timeliness of the test effort.
  • Tools - document the tools that will be employed for testing. Cite the vendor, version and the help desk number to call for support.


Identify the resource roles and responsibilities that will be required for test plan execution.

  • Project Plan - develop a project plan showing the phases, tasks, and resources. Update the project plan as needed to reflect such events as changes in deadlines or available resources.


Document the schedule in which the application under test is to be made available for testing, and the estimated time for executing test cases. Specify if frequent builds will be provided on a regular basis during the test cycle, or when system components are expected to be ready for testing.


List all the deliverables that are associated with the testing effort, and where copies of these deliverables or documents may be located. This includes the test plan itself, test scripts, test cases and project plan.

Defect Tracking and Reporting

Document the tool and process used to record and track defects. List any reports to be produced and include recipients, frequencies, delivery mechanisms and examples. Identify team resources involved in the defect tracking process.

Describe any ratings, categories or classifications used to identify or prioritize defects. Following are sample categories for prioritizing defects:

  • Critical - denotes an unusable function that causes an abend or general protection fault, or when a change in one area of the application causes a problem elsewhere.
  • Severe - a function does not perform as required or designed, or an interface object does not work as presented.
  • Annoyance - function works but not as quickly as expected, or does not conform to standards and conventions.
  • Cosmetic - not critical to system performance: misspelled words, incorrect formatting, vague or confusing error messages or warnings.


The test plan should be reviewed by all parties responsible for its execution, and approved by the test team, product and development managers. Provide for approval signatures at the bottom of the test plan. A walkthrough meeting with all parties in attendance is the most effective method of obtaining test plan approval.


When the test effort is complete, document the results. Identify any discrepancies between the plan and the actual implementation, and document how those discrepancies were handled. Get ready for your next succesful test plan.