Automated regression testing refers to the process by which computer software is regression tested in an automated manner by using testing scripts. These scripts are run against software code for validating the changes that has been made to the code.
Test scripts are the instructions which include the requirements for inputs and outputs of a test case. Each test case is entered into a test script to create a full test harness of an application. Test scripts can be automated by writing code that will execute the instructions within a test case. The simplest way to set up automated regression testing is to construct a suite of test cases, each of which consists of a test input file and a "correct answer" output file.
Automated regression testing is important because :
- It provides portability when the code is moved to another machine.
- A confidence is achieved that changing the program has not introduced any bug.
- Automating regression testing allows users to manage the ever increasing number of test cases and suites, while ensuring both reliability and afford ability.
- Testing efforts are reduced to a greater extent.
- It could be tested in parallel with product development.
- Test coverage is increased.
Wednesday, September 8, 2010
Automated Regression Testing and its features
Posted by
Sunflower
at
9/08/2010 12:35:00 PM
0
comments
Labels: Advantages, Automated Regression testing, Automated Testing, efficient, Importance, Portability, Process, Regression, Regression Testing, Software, Test cases, Test Scripts
|
| Subscribe by Email |
|
Tuesday, September 7, 2010
Selecting a test strategy for regression testing
Regression testing is selective retesting of the system; executed with an objective to ensure the bug fixes work and those bug fixes have not caused any un-intended effects in the system.
The selection of test cases for regression testing depends on:
- Requires knowledge on the bug fixes and how it affect the system.
- Includes the area of frequent defects.
- Includes the area which has undergone many/recent code changes.
- Includes the area which is highly visible to the users.
- Includes the core features of the product which are mandatory requirements of the customer.
Selection of test cases for regression testing depends more on the criticality of bug fixes than the criticality of the defect itself.
Do not focus on the test cases that are bound to fail and those test cases which has no or less relevance to the bug fixes. Select more positive test cases than negative test cases for final regression test cycle as this may create some confusion and unexpected heat. It is also recommended that the regular test cycles before regression testing should have right mix of both positive and negative test cases. Negative test cases are those test cases which are introduced newly with intent to break the system.
Good approach is to plan and act for regression testing from the beginning of project before the test cycles. One of the ideas is to classify the test cases into various Priorities based on importance and customer usage.
For an Effective Regression Testing :
- Create a regression test plan identifying focus areas, strategy, test entry and exit criteria. It can also outline Testing Prerequisites, Responsibilities, etc.
- Create test cases.
- Defect tracking.
Posted by
Sunflower
at
9/07/2010 07:39:00 PM
0
comments
Labels: Bugs, Defects, Errors, Product, Regression, Regression Testing, Selection of test case, Software, Strategy, Test Strategy, Testing Strategy, Tests
|
| Subscribe by Email |
|
Monday, September 6, 2010
Overview of Regression Testing and its objectives.
Regression testing is an important part of the software development life cycle. regression means going back. If any kind of modification is done in software, testing needs to be done to ensure that it works as specified and that it has not negatively impacted any functionality that it offered previously.
Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged.
The objectives of regression testing are :
- To identify uncovered and unexpected defects.
- To ensure that changes or additions in the code are safe & are not liable to break the existing functionality of the application.
- To ensure and track the quality of its output.
- The changes to the software application have not introduced any new bugs.
Regression testing is necessary when there is a change made to an existing tested software. Each change implies more regression testing needs to be done to ensure that the system meets the project goals.
Regression testing can become cost effective if the test cases are automated the test cases may be executed using scripts after each change is introduced in the system. Also, teams do not execute all the test cases during the regression testing. They test only what they decide is relevant.
In short, regression testing means rerunning tests of things that used to work to make sure that a change didn't break something else. The set of tests used is called the Regression Test Set. It's enormously helpful when you change an application, change the environment, and during integration of pieces.
Regression testing is a simple concept, but it needs to be done just right to work in the real world.
Posted by
Sunflower
at
9/06/2010 02:57:00 PM
0
comments
Labels: Bugs, Change, Cost Effective, Defects, Errors, Necessary, Objectives, Regression, Regression Testing, SDLC, Software
|
| Subscribe by Email |
|
Sunday, September 5, 2010
Software Localization - some details in terms of how the process work - Part 1
What is software localization ? Localization means releasing software that works in different countries the same way. For a person who is not experienced at this, they would wonder as to how the same software can work in different countries almost identically ? After all, if you look at the test that shows up in a software, the text is different in different languages, and it must be a lot of effort to get this done. Well, it is a lot of effort to get a software that works properly in different countries, but not as high as you might expect. Consider a website that showcases news or has articles (which means the site is almost entirely text based). Such sites would need re-writing the entire content into different languages, and the effort can be considerable, and for sites that depend on getting news out quickly, the amount of time involved can be considerable.
However, if you consider a software, there are 2 main elements. One element is the text that a user views (whether it be text on dialogs, or error messages) - this needs to be different in different languages. On the other hand, a huge amount of the internals of a software is the code, and this code does not need to be translated (which is a huge amount of effort savings), since this code is not visible to the users.
In this post, I will give a very high level summary of how the localization of software can be done, and then break this up in future posts. Inside the software, in any part of the code where there is an output of text that the user can see, there is a special section of code that identifies this is as a UI content. When this is done all over the software, all the text, error messages, information given to users, etc, all of this has a small identifier that marks that this section of code is different.
Next, a script is run that gathers all these sections of code that has an identifier, and presto, you get a large set of phrases. These are then sent off for translation into different languages, and when translated, are put back language by language into the software. So, when a user launches German version of the software, the code pulls out all the German translations, and shows those to the users instead of the English originals. Thus, you find that your software has become localized.
This is a simplified version of the entire process, and I will add more details in future posts.
Posted by
Ashish Agarwal
at
9/05/2010 11:27:00 PM
0
comments
Labels: Internationalization, Languages, Localization, Localization Engineering, Software
|
| Subscribe by Email |
|
Friday, September 3, 2010
Mutation Testing : how it is performed, benefits, operators and tools.
Mutation Testing is a powerful method for finding errors in software programs. Mutation testing involves deliberately altering a program’s code, then re-running a suite of valid unit tests against the mutated program. A good unit test will detect the change in the program and fail accordingly. Mutation testing is expensive to run, especially on very large applications. Mutation Testing is complicated and time-consuming to perform without an automated tool.
How Mutation testing is performed?
- Create a mutant software which is different from the original software by one mutation.
- Each of the mutant software has one fault.
- Test cases are applied to the original software and the mutant software.
- Results are evaluated. The test case that is applied is wrong if the mutant software as well as the original software produces the same result. The test case is right if the test case detects fault in the software.
Benefits of Mutation Testing
- Introduces a new level of error detection.
- Uncover errors in code that were previously thought impossible to detect automatically.
- The customer will receive a more reliable and bug free software.
On what factors Mutation testing depends ?
- It depends heavily on the types of faults that the mutation operators are designed to represent.
- Mutation operators means certain aspects of the programming techniques, the slightest change in which may cause the program to function incorrectly.
Mutation Operators and Tools
Some mutation operators for languages like Java, C++ etc. are :
- Changing the access modifiers, like public to private etc.
- Static modifier change.
- Argument order change.
- Super keyword deletion.
- Essay writing services
Tools like Jester, Pester, Nester and Insure++ are some of the tools that are available for mutation testing.
Posted by
Sunflower
at
9/03/2010 07:20:00 PM
0
comments
Labels: Advantages, Benefits, Error Detection, Errors, Factors, Mutant, Mutation testing, Mutators, Operators, Performance, Software, Testing tools
|
| Subscribe by Email |
|
Thursday, September 2, 2010
Overview of Ad hoc testing and what are its features.
Ad hoc testing is an expression largely used in information technology industry. This is a kind of quality control testing that works on randomization and it is not a fixed technique. This allow for maximum customization and it can deliver more reliable results, and that is why the term is so popular.
In ad-hoc testing, tests are carried out without planning and prior documentation. There is no formal test plan. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing.
This testing is a part of exploratory testing. Ad-hoc testing helps in deciding the scope and duration of the various other testing. the best part of this testing is discovery. Another use for ad hoc testing is to determine the priorities for your other testing activities. In this aspect, ad hoc testing has been criticised because it isn't structured, but this can also be a strength: important defects can be found rapidly.
Ad-hoc testing can be done throughout the software development life cycle.The relationships between the subsystems can be exposed as ad hoc testing can find holes in your test strategy.In this way, it serves as a tool for checking the completeness of your testing. Finding new tests in this way can also be a sign that you should perform root cause analysis.
Posted by
Sunflower
at
9/02/2010 09:21:00 PM
0
comments
Labels: Ad hoc testing, Ad-hoc, Documentation, Features, Planning, Scope, SDLC, Software Development Life Cycle, Techniques, Testers, Tests
|
| Subscribe by Email |
|
Wednesday, September 1, 2010
What is Recovery Testing and what are its features.
Recovery testing tells how well an application is able to recover from a crash, hardware failure. Recovery testing should not be confused with reliability testing, which tries to discover the specific point at which failure occurs.
- Recovery is ability to restart the operation after integrity of application is lost.
- The time taken to recover depends upon the number of restart points, volume of application, training and skill of people conducting recovery activities and the
tools available for recovery.
- Recovery testing ensures that the operations can be continued after a disaster.
- Recovery testing verifies recovery process and effectiveness of recovery process.
- In recovery testing, adequate back up data is preserved and kept in secure location.
- Recovery procedures are documented.
- Recovery personnel have been assigned and trained.
- Recovery tools have been developed and are available.
To use recovery testing, procedures, methods, tools and techniques are assessed to evaluate the adequacy. Recovery testing can be done by introducing a failure in the system and check whether the system is able to recover. A simulated disaster is usually performed on one aspect of application system. Recovery testing should be carried for one segment and then on the other segment when there are many failures.
Recovery testing is used when the continuity of the system is needed inorder for system to perform or function properly.User estimates the losses, time span to carry out recovery testing. Recovery testing is done by system analysts, testing professionals and management personnel.
Posted by
Sunflower
at
9/01/2010 07:23:00 PM
0
comments
Labels: Applications, Black box testing, Crash, Features, Objectives, Recover, Recovery, Recovery Testing, System, Usage
|
| Subscribe by Email |
|