Not every software testing project can or should be automated. Before your department accepts a new test automation project, you should establish a process by which projects are reviewed and either accepted or rejected. This can be done with a simple Test Automation Acceptance Checklist.

Repeatable Test Cases with Static Data

The true cost benefit of test automation is achieved only when the same scripts are executed multiple times. The first execution is very expensive because it includes the one-time cost of the automation tools and 100% of the Test Automation engineer’s time. When the scripts are executed again, the cost of test automation declines sharply. The tool has already been purchased and the scripts have already been coded. If there have been changes in the application, the scripts may require maintenance before being executed. Maintenance on minor software updates should be minimal.

Because test automation is only successful when the scripts can be executed multiple times, only application which require the same test cases to be executed with the same data are good candidates for automation. For example, a mortgage application that needs to be regression tested on a weekly basis could be a good candidate for test automation. Script maintenance is minimal and the scripts can enter a mortgage application using the same group of test data in a fraction of the time it would take a manual tester to test the same functionality.

On the other hand, a mortgage origination system, which cannot use the same test data for each iteration would not be a good automation candidate. Due to the nature of mortgage systems, data could be staged in various states of approval or rejection, based on the current data and the departments who have already processed their part of the mortgage application. If the script cannot easily figure out what data to enter in the software, it is not a good automation candidate.

Another problem with automating this type of complex system is that the test environment often contains a sampling of production data that is refreshed on a periodic basis. Sometimes this can be overcome by rebuilding the test data when the test environment is refreshed. The feasibility of rebuilding test data on a regular basis depends on the complexity of the application. You will have to make that decision on a case-by-case basis.

Application or Environmental Stability

Environmental stability is crucial to a successfully automating a software testing project. Scripts cannot be coded in a timely manner if the application environment is unavailable, experiences frequent down-times, or excessive defects and errors.

Little or No Application or Environment Downtime

It takes longer to write scripts than it does to manually test the same functionality. Most automation tools are watered down version of C or Visual Basic, which means that writing automated scripts is essentially programming and takes adequate time and specialized skills. Unlike manual test cases, which can sometimes be written based off requirements and mock-ups, automated tools require the actual application. When a test environment is unavailable, automation engineers cannot create scripts, which prolongs the project and ends up costing more.

Excessive downtime can consist of any of the following:

• Unstable Environment
• Lack of Infrastructure Support
• Frequent Application Updates
• Buggy Code
• Effects of Environment Instability on Script Development and Execution

When an application or environment is unstable, scripting progress is dramatically slowed or stopped altogether. In some cases, it’s possible to continue scripting, but this may causes more work at a later date. For example, if you are scripting in buggy code, you may have to script around error messages and the scripts will have to be revised at a later date. Or, you may only be able to create scripts to a certain point and finish them at a later date. To help avoid and decrease environment instability, read the chapter on Service Level Agreements.

Timely Defect Fixes

Application defects do not have to be detrimental to an automated software testing project. When defects are fixed in a timely manner, scripting can continue without significant downtime. When estimating an automated testing project, it’s always best to add some buffer time that will accommodate for defect reporting and revisions.

When defect fixes take an excessive amount of time to resolve and are causing the automated software testing project to be delayed, it’s time to pull together a meeting. Invite all the major players and discuss the root of the problem and what everyone can to improve the situation. Maybe development is spending too much time trying to reproduce the problem and having your automation team enter better description would help them turn the defect fixes around faster. Maybe you can work together to classify defects and establish reasonable fix times for each classification. For example, a Critical defect needs to be fixed that day while a High defect needs to be fixed with in 24 hours.

Be first to comment this article | Add as favourites (20) | Quote this article on your site | Views: 254 | Read more...

Quality Assurance, which is generally known as “QA” is the process of providing confirmation facts which is required to build assurance amidst all concerns to ensure, that the quality related activities are being made effectively. The systematic process will be handled to enrich the confidence, that the product or service has met all the needs and requirements of the said objectives.

QA is an effective methodology specifically made to evaluate the quality of the products. QA generally includes different steps and procedures like problem finding, curative process to amend and rectify any deficits. Quality assurance involves quite essential precaution measures, so that it could be found out that the complete output of a product or service is within the specifications under a wide condition of operation. To make it worthwhile, it entails that the process is being monitored with the support of indicators.

Quality Assurance insures all activities such as design, production, development, installation, servicing to documentation. Generally, QA involves quality control that includes the quality assurance process connected to the physical distinctiveness of a structure, material, system or its component that caters a mode to curb the quality to the preset requirements and objectives. Therefore, Quality Assurance is illustrated as the complete process to ensure the feature and quality of the product.

Actually what is Quality? Well, this is the important point that needs to be discussed. Quality could be explained as the statement of the characteristic features of a product that abides and have met the implied needs. Generally, quality must never be perplexed with the status of the product. Almost all businesses will have a well-built QA system which will be engrossed over a time period and will be examined and evaluated every time.

Quality Assurance is a proactive operation which puts an end to all the flaws and defects happening in the process. QA gives a good and ace support to deliver an error free output right in the from the beginning. This process engages the team to discover the area of distress. This will help to make out the corrective actions by identifying the problems.

To ensure the quality and effectiveness of the product or service, the QA team will undergo and implement the cutting edge technologies to present it flawless. Let us discuss about the techniques that will be used to ensure the correct functionality of the product.

Black-box Testing

The major functionality testing that is handled in QA is said to be known as Black-box Testing. Handling this method of testing offers quite number of advantages and they are:

• Test is balanced as the developer and the tester are self-reliant from each other.
• Test is handled as per the user perspective not with the vision of the developer.
• Test cases could be intended once the descriptions are complete.

White-box testing

This entails the code familiarity and the cognition of the program. This testing could be handled by cognitive and trained testers as the data must be chosen carefully.

Performance Testing

The typical testing methodology would be the Performance testing. This testing will greatly help to find the systems performance as well as the effectiveness of the code, which plays the lead game to give a prompt turnout.

Be first to comment this article | Add as favourites (26) | Quote this article on your site | Views: 303 | Read more...

Enter automated software testing. While nothing can replace good human testers, broad test coverage requires some degree of software automation for it to be economically feasible. Automated testing tools can provide a huge workforce multiplier and do a very good job complimenting human testers. Every change to your website no matter how small requires thorough testing to ensure that nothing else was affected. This becomes very time consuming very quickly due to the large number of possible cases to test. A strategy whereby tests are automated using software becomes an economic necessity.

There are two classes of automated testing tools. The first kind, functional and regression testing tools, helps to make sure that the website behaves as it should: for example if a customer clicks on button X, page Y is displayed without errors. Functional and regression testing tools are able to automate a large number of scenarios to ensure that your website works as intended. The second type, load testing tools gauge how well your website performs when subjected to a large stress, such as a large number of simultaneous users. I will be discussing load testing in a separate article.

I will now give you an overview of the basic characteristics of functional testing. Before you can begin any kind of functional test automation you will need to identify the test scenarios you wish to automate. Once this is done, you will need to generate test scripts that cover these scenarios.

A functional testing tool will typically record user interactions with a website. As you perform various operations on your website or application, the tool records every step. When you finish recording, it generates an automated script from your interactions with your website. Alternatively you could use the tool to construct the script by hand. Typically testers tend to do a combination of the two. They will use the recorder to generate the basic framework of their scripts and then tweak the scripts by hand to incorporate special cases.

Scripts can be graphical and/or text based in nature. A good functional testing tool does not require users to have a programming background. Users not proficient in programming will work predominantly with graphical scripts. In most tools graphical scripts will typically show all interactions in a tree structure and users can edit any node of the tree to modify the script. Some users however, who have programming backgrounds may wish to program their scripts. These users will typically work with a text script written in a standard language such as JavaScript or VBScript.

Once you have generated your script you will need to insert checks in your scripts to test if your website is functioning correctly. Such checks are usually called checkpoints. A checkpoint verifies that values of a property obtained when testing the website match expected values. Checkpoints enable you to set the criteria for comparing expected values with obtained values. The expected value of a property is derived from recording interactions with the web site. It is viewed and modified from checkpoints. The current value is retrieved during replay (i.e. during the execution of the test case).

There are many different kinds of checkpoints. A page checkpoint verifies the source of a page or frame as well as its statistical properties. You can check for broken links, verify link URLs, image sources, the hierarchy of HTML tags or even the entire HTML source of the Web page or frame. You can also set thresholds for the loading time of a page. A text checkpoint verifies that a given text is displayed or is not displayed in a specified area on a web page. A web object checkpoint verifies the properties of a web object e.g. the value of an HTML INPUT field. A database checkpoint verifies the contents of a database used by your website.

When you replay a test script, the testing tool will open the recorded application and perform the recorded steps in the same sequence they were specified in the script. As it replays the script it will also run through all the checkpoints you have inserted into the script. In addition, you can test your application’s behavior with varying data inputs. For example you can try to submit a page after entering different values in the edit box of a web page. At the end of the replay a detailed report is typically be generated.

Be first to comment this article | Add as favourites (47) | Quote this article on your site | Views: 561 | Read more...