User story is one of the primary development artifact for the XP project teams. A user story contains just enough information so that development team can reasonably give estimate about completing, tester can discuss how it will validated and customer can see its value.

One of the common question that we hear most of the time is, how user stories are different from use cases. User stories are much simpler than use cases. User stories are very easy to create, discuss and develop. They also do not contain any technical details.

Typically good user stories are defined in the following format

As a I would like to do so that

While discussing User Stories, you should make sure that they are not very big. A big user story leaves the chances of ambiguity and absence of clarity in the mind of development team. Ideally, you should be able to break ...

This article will give you information on the guidelines we have followed in one of the automation projects. These guidelines were developed by our team. Benefits of any guidelines can only be realized if whole team agrees to follow them and work towards developing or improving them further. Hope you will find these helpful.

Structure Of Script

A script in general should have following structure

• Header
• Include Section - All include files are mentioned here.
• Declaration Section - Declare all the variables and functions here.
• Main Section - Section containing starting point for this script
• Supplementary functions - All the declared functions are implemented here.

Header Structure

Any script that you create for automation, should have header section in it. This section will have general information about the script, it's usage, author, revision history etc. You can follow template similar to this for header section -

File Name : Test_Case_001

Date : 02 Jul 2007

Author ...

Testing web application is certainly different than testing desktop or any other application. With in web applications, there are certain standards which are followed in almost all the applications. Having these standards makes life easier for use, because these standards can be converted into checklist and application can be tested easily against the checklist.

INTERFACE AND ERROR HANDLING

SERVER INTERFACE

• Verify that communication is done correctly, web server-application server, application server-database server and vice versa.
• Compatibility of server software, hardware, network connections

EXTERNAL INTERFACE

• Have all supported browsers been tested?
• Have all error conditions related to external interfaces been tested when external application is unavailable or server inaccessible?

INTERNAL INTERFACE

• If the site uses plug-ins, can the site still be used without them?
• Can all linked documents be supported/opened on all platforms (i.e. can Microsoft Word be opened on Solaris)?
• Are failures handled if there are errors in ...

Defect reports are probably primary work product for most of the software testers. Good bug report, which is informative and understandable earns you a good reputation. Weak report generate extra work for everyone. Most of the time, a weak bug report is returned with comments saying not clear, need more information etc. That makes you work again on the same defect and thus reduces efficiency of testers and developers both. Defect reports are not only used by programmers, but also by managers, executives, documentation team and support executives for various reasons.

Purpose of a defect report is multifold in any organization. Defect reports are used to

• Alert software programmers about the defect and gives them sufficient information to find root cause and fix the problem.
• Provide information to technical writers who are writing troubleshooting, known limitation etc.
• Provide starting point for the next release
• Add test cases in the regression ...

Testing web application is certainly different than testing desktop or any other application. With in web applications, there are certain standards which are followed in almost all the applications. Having these standards makes life easier for use, because these standards can be converted into checklist and application can be tested easily against the checklist.

LINKS

• Check that the link takes you to the page it said it would.
• Ensure to have no orphan pages (a page that has no links to it)
• Check all of your links to other websites
• Are all referenced web sites or email addresses hyperlinked?
• If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists.
• Check all mailto links and whether it reaches properly ...

Testing user interface for web application is slightly different from testing user interface of traditional applications. Irrespective of the web application there are certain things which should be tested for every web application. Following checklist will give some information on items that should be tested to ensure quality of the user interface of your web application.

COLORS

• Are hyperlink colors standard?
• Are the field backgrounds the correct color?
• Are the field prompts the correct color?
• Are the screen and field colors adjusted correctly for non-editable mode?
• Does the site use (approximately) standard link colors?
• Are all the buttons are in standard format and size?
• Is the general screen background the correct color?
• Is the page background (color) distraction free?

CONTENT

• All fonts to be the same
• Are all the screen prompts specified in the correct screen font?
• Does content remain if you need to go back to a previous page ...

Crating checklists for performance & security is extremely important. This checklist helps in better definition of performance and security requirement. In the absence of properly defined performance & security testing requirements, teams can spend great deal time in things which probably does not matter much.

LOAD

• Many users requesting a certain page at the same time or using the site simultaneously
• Increase the number of users and keep the data constant
• Does the home page load quickly? within 8 seconds
• Is load time appropriate to content, even on a slow dial-in connection?
• Can the site sustain long periods of usage by multiple users?
• Can the site sustain long periods of continuous usage by 1 user?
• Is page loading performance acceptable over modems of different speeds?
• Does the system meet its goals for response time, throughput, and availability?
• Have you defined standards for response time (i.e. all screens should paint within 10 ...

Purpose of this GUI Testing Checklist is to help you understand how your application can be tested according to the known and understood standards for GUI. This checklist can give some guidance to both development and QE teams. Development team can make sure that during the development they follow guidelines related to the compliance, aesthetics, navigation etc. but onus of testing GUI is on the QE team and as a tester it is your responsibility to validate your product against GUI standards followed by your organization.

This GUI test checklist can ensure that all the GUI components are thoroughly tested. In the first part of this checklist, we will cover Windows compliance standard and some test ideas for field specific tests.

Windows Compliance Standards

These compliance standards are followed by almost all the windows based application. Any variance from these standards can result into inconvenience to the user. This compliance ...

Test plan is probably one of the most significant document for software testing projects. Test plan may contain information related to scope, environment, schedule, risk, resources, execution, reporting, automation, completion criteria etc.

Test plan is usually created by Test Manager, Test Lead or senior testers in the team. Before start preparing Test Plan, information should be captured from various stakeholders of the project. Information captured from stakeholder is usually reflected in the Test Plan.

Typically, every Test Plan contain information about following activities. Information about these activities can be gathered from various stakeholders by asking questions that are required for your Test Plan.

Scope Management Before starting Test Planning activity, scope of the test activities should be known. You should have information on what features will be tested and what will not be tested. You should also have information on what areas your team is owning? Are you taking care ...