Software Testing Methodology

AlexQin

AlexQin

AlexQin

Desktop application development and Test automation
The software was written to provide a friendly interface for information workers: Spreadsheet jockeys, business people needing written reports, and game players. The full spectrum of desktop software could pretty well be categorized into spreadsheet, wordprocessor, database, and entertainment categories since desktop computers were rarely networked to other information resources. Desktop applications used the keyboard, and then later a mouse, to navigate through windows and a drop-down menu. Inside a desktop application software package one would find an event-driven framework surrounding individual procedural functions. The automation focused on improving the time it took to test a desktop application for functionality. The test utilities link into desktop applications and try each command as though a user were accessing the menu and window commands. Most QA technicians testing a desktop application compare the function of all the menus and windows to a written functional specification document. The variation from the document to the performance shows the relative health of a desktop application.

AlexQin

Clicent/Server Development and Test automation
The original intent for client/server applications was to separete presentation logic from business logic. In an ideal system design, the client was reponsible for presenting the user interface, command elements (drop-down menus, buttons, controls), displayed results information in a set of windows, charts, and dials. The client connected to a server to process functions and the server responded with data.
In a client/server environment the protocols are cleanly defined so that all the clients use the same protocols to communicate with the server.
The client-side frameworks to provide the same functionality of desktop application frameworks plus most of the needed communication code to issue commands to the server and the code needed to automatically update a client with new functions received from the server.The server-side frameworks provide code needed to received and handle requests from multiple clients, and code to connect to database for data persistence and remote information providers. Additionally, these framworks need to handle stateful transations and intermittent network connections. Stateful transactions require multiple steps to accomplish a task.
Client/server applications are normally transactional in nature and usually several interactions with the user are needed to finish a single request. For example, in a stock trading application the user begins a transaction by identifying themselves to the server, looking up an order code, and then submitting a request to the server, and receives and presents the results to the user. The client-side application normally knows something about the transaction - for example, the client-side application will normally store the user identification and a session code such as cookie value across the user's interaction with the server-based application. Users like it better when the client-side application knows about the transaction because each step in a request can be optimized in the client application. For example. in the stock trading example the client application could calculate a stock trade commission locally without having to communication with server.
Client/server application test automation provides the functionality of desktop application test automation plus these:

• Client/server applications operate in a network environment. The tests need to not only check for the function of an application, they need to test how the application handles slow or intermittent network performance.
• Automated test are ideal to determine the number of client applications a server is able to efficiently handle at any given time.
• The server is usually a middle tier between the client application and several data sources. Automated tests need to check the server for correct functionality while it communicates with the data source.
  

AlexQin

Black-Box testing on Window-based Application
Editable Fields Checking and Validation:

• Valid/invalid characters/strings data in all editable fields
• Valid minimum/maximum/mid range values in fields
• Null strings (or no data ) in required fields
• Record length (character limit)in text/memo fields
• Cut/copy/paste into/from fields when possible
  

Not Editable Fields Checking:

• Check for all test/spelling in warnings and error messages/dialogs
• Invoke/check all menu items and their options
  

Application Usability:

• Appearance an outlook (Placement an alignment of objects on screen)
• User Interface Test (open all menus, check all items)
• Basic functionality checking (File+Open+Save, etc..)
• Right mouse clicking sensitivity
• Resize/min/max/restore app, windows (check min app size)
• Scrollability when applicable (scrollbars, keyboard, autoscrolling)
• Keyboard and mouse navigation, highlighting, dragging, drag/drop
• Print in landscape an portrait modes
• Check F1, What's This , Help menu
• Short-cut and Accelerator keys
• Tab Key order and Navigation in all dialog boxes and menus
  

AlexQin

Web-Enabled Development and Test automation
Web-Enabled application go further in these areas:

• Web-enabled application are meant to be stateless. HTTP was designed to be stateless. Each request from a Web-enabled application is meant to be atomic and not rely on any previouse requests. This has huge advantages for system architecture and datacenter provisioning. When requests are stateless, then any sserver can respond to the request and any request handler on any server may service the request.
• Web-enabled application are platform independent. The client application may be written for Windows, Macintosh, Linux, and any other platform that is capable of implementing the command protocol and network connection to the server.
• Web-enabled application expect the client application to provide presentation rendering and simple scripting capabilities. The client application is usually a browser, however, it may also be a dedication client application such as a retail cash register, a Windows-based data analysis tool, ot an electronic address book in your mobile phone.
  

The missing context in a Web-enabled application test automation means that software developers and QA technicians must manually script tests for each Web-enalbled application. Plus, they need to maintain the test scriots as the application changes. Web-enabled application test automation tools focus on making the scriot writing and maintenance tasks easier. The test automation tool offer these features:

• A friendly, graphical user interface to integrate the record, edit, and run-time script functions.
• A recorder that watches how an application is used and writes a test script for you.
• A playback utility that drives a Web-enalbed application by processing the test script and logging. The playback utility also provides the facility to play back several concurrently running copies of the same script to check the system for scalability and load testing.
• A report utility to show how the playback differed from the original recording. The differences may be slower or faster performance times, errors, and incomplete transactions.
  

AlexQin

Testing Web Sites Applications
Many developers and testers are making the transition from testing traditional client/server, PC, and/or mainframe systems, to testing rapidly changing Web applications.
Web test: This testing forcuses on how well all parts of the web site hold together, whether inside and outside the website are working and whether all parts of the website are connected.
Web sites Server consist of three back-end layer:

• Web server
• Application server
• Data layers
  

AlexQin

AlexQin

AlexQin

Black Box testing for web-based application: (1)

1. Browser functionality:

• Is the browser compatible with the application design?
• There are many different types of browsers available.
• GUI design components
• Are the scroll bars, buttons, and frames compatible with the browser and functional?
• To check the functionality of the scroll bars on the interface of the Web page to make sure the the user can scroll through items and make the correct selection from a list of items.
• The button on the interface need to be functional and the correct hyperlink should go to the correct page.
• If frames are used on the interface, they should be checked for the correct size and whether all of the components fit within the viewing screen of the monitor.
  

2. User Interface
One of the reasons the web browser is being used as the front end to applications is the ease of use. Users who have been on the web before will probably know how to navigate a well-built web site. While you are concentrating on this portion of testing it is important to verify that the application is easy to use. Many will believe that this is the least important area to test, but if you want to be successful, the site better be easy to use.
3.Instructions
You want to make sure there are instructions. Even if you think the web site is simple, there will always be someone who needs some clarification. Additionally, you need to test the documentation to verify that the instructions are correct. If you follow each instruction does the expected result occur?

4. Site map or navigational bar
Does the site have a map? Sometimes power users know exactly where they want to go and don't want to wade through lengthy introductions. Or new users get lost easily. Either way a site map and/or an ever-present navigational bar can help guide the user. You need to verify that the site map is correct. Does each link on the map actually exist? Are there links on the site that are not represented on the map? Is the navigational bar present on every screen? Is it consistent? Does each link work on each page? Is it organized in an intuitive manner?

5. Content
To a developer, functionality comes before wording. Anyone can slap together some fancy mission statement later, but while they are developing, they just need some filler to verify alignment and layout. Unfortunately, text produced like this may sneak through the cracks. It is important to check with the public relations department on the exact wording of the content.
You also want to make sure the site looks professional. Overuse of bold text, big fonts and blinking (ugh) can turn away a customer quickly. It might be a good idea to consult a graphic designer to look over the site during User Acceptance Testing. You wouldn't slap together a brochure with bold text everywhere, so you want to handle the web site with the same level of professionalism.
Finally, you want to make sure that any time a web reference is given that it is hyperlinked. Plenty of sites ask you to email them at a specific address or to download a browser from an address. But if the user can't click on it, they are going to be annoyed.

6. Colors/backgrounds
Ever since the web became popular, everyone thinks they are graphic designers. Unfortunately, some developers are more interested in their new backgrounds, than ease of use. Sites will have yellow text on a purple picture of a fractal pattern. (If you've never seen this, try most sites at GeoCities or AOL.) This may seem "pretty neat", but it's not easy to use.
Usually, the best idea is to use little or no background. If you have a background, it might be a single color on the left side of the page, containing the navigational bar. But, patterns and pictures distract the user.