Bugs

Bug

A programming error that causes a program to work poorly, produce incorrect results, or crash. (As an interesting aside, the term "bug" was coined when a real insect damaged one of the circuits of the first electronic digital computer, the ENIAC.)

Isolation

Think about the sequence of events that you just took the software through to eventually get to the problem. Ideally, you started testing by clicking one button, and then saw the problem immediately. More likely, though, you had been testing for a while, possibly for hours. Perhaps the last thing you did is the only thing required to reproduce the bug, or maybe you have to repeat hours of testing. Until you can prove that a simpler scenario is sufficient, you have to assume that every detail of your testing session is relevant. Your task is to rule out as many of those details as you can as not being relevant to the problem.

There are several different things that are subject to simplification. Consider:

Procedures. This is usually what testers focus on – shortening the step-by-step interaction with the system.

Inputs. This is all the data that you feed to the program, such as a command-line argument, a text field in a GUI interface, a file, or database. You want to also reduce this data to the smallest data set that still reproduces the problem.

Configuration. What options have you selected that are different from the default configuration? If you can't reproduce the problem the way the software is configured out of the box, find the few crucial settings that are necessary for the problem to show up.

Platforms. Can you reproduce the problem on all of the operating systems, operating system versions, and hardware combinations that are supported? If not, then you've found an important clue. Also, what about other software that is running, and their versions? Many bugs are not platform-specific, and testing on other platforms can sometimes be difficult, so this area often isn't thoroughly explored.

Other state information. The items above probably don't capture every possible relevant variable. Look for other things that might vary from one system to another and cause the bug to manifest on some systems but not others



Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Testing Documents

a. User Requirements Specification - URS

The User Requirements Specification is a document produced by, or on behalf of your organisation, which documents the purposes for which a system is required - its functional requirements - usually in order of priority / gradation.

Whilst the URS will not usually probe the technical specification, it will nevertheless outline the expectations and, where essential may provide further detail e.g. the User Interface, say Microsoft Windows®, and the expected hardware platform etc.

The URS is an essential document which outlines precisely what the User (or customer) is expecting from this system. The term User Requirement Specification can also incorporate the functional requirements of the system or may be in a separate document labelled the Functional Requirements Specification - the FRS.

b. Test Plan

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:

Title

Identification of software including version/release numbers
Revision history of document including authors, dates, approvals
Table of Contents
Purpose of document, intended audience
Objective of testing effort
Software product overview
Relevant related document list, such as requirements, design documents, other test plans, etc.
Relevant standards or legal requirements
Traceability requirements
Relevant naming conventions and identifier conventions
Overall software project organization and personnel/contact-info/responsibilties
Test organization and personnel/contact-info/responsibilities
Assumptions and dependencies
Project risk analysis
Testing priorities and focus
Scope and limitations of testing
Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
Outline of data input equivalence classes, boundary value analysis, error classes
Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
Test environment validity analysis - differences between the test and production systems and their impact on test validity.
Test environment setup and configuration issues
Software migration processes
Software CM processes
Test data setup requirements
Database setup requirements
Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
Test automation - justification and overview Test tools to be used, including versions, patches, etc.
Test script/test code maintenance processes and version control

c. Test Case

01. A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
02. Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible.

d. Test Script

A test script is basically a script of test cases linked together to walk the critical pathways through an application under test. These scripts are broken down into a series of user scenarios. Each scenario contains specific instructions for the tester to carry out, including the expected results along the way


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Some Testing Terms - part 2

6. SEI

'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.

7. CMM

'Capability Maturity Model', now called the CMMI ('Capability Maturity Model Integration'), developed by the SEI. It's a model of 5 levels of process 'maturity' that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMMI ratings by undergoing assessments by qualified auditors.

Level 1 - characterized by chaos, periodic panics, and heroic efforts required by individuals to successfully complete projects. Few if any processes in place; successes may not be repeatable.

Level 2 - software project tracking, requirements management, realistic planning, and configuration management processes are in place; successful practices can be repeated.

Level 3 - standard software development and maintenance processes are integrated throughout an organization; a Software Engineering Process Group is is in place to oversee software processes, and training programs are used to ensure understanding and compliance.

Level 4 - metrics are used to track productivity, processes, and products. Project performance is predictable, and quality is consistently high.

Level 5 - the focus is on continouous process improvement. The impact of new processes and technologies can be predicted and effectively implemented when required.

Perspective on CMM ratings: During 1997-2001, 1018 organizations were assessed. Of those, 27% were rated at Level 1, 39% at 2, 23% at 3, 6% at 4, and 5% at 5. (For ratings during the period 1992-96, 62% were at Level 1, 23% at 2, 13% at 3, 2% at 4, and 0.4% at 5.) The median size of organizations was 100 software engineering/maintenance personnel; 32% of organizations were U.S. federal contractors or agencies. For those rated at Level 1, the most problematical key process area was in Software Quality Assurance.

8. ISO

'International Organisation for Standardization' - The ISO 9001:2000 standard (which replaces the previous standard of 1994) concerns quality systems that are assessed by outside auditors, and it applies to many kinds of production and manufacturing organizations, not just software. It covers documentation, design, development, production, testing, installation, servicing, and other processes. The full set of standards consists of: (a)Q9001-2000 - Quality Management Systems: Requirements; (b)Q9000-2000 - Quality Management Systems: Fundamentals and Vocabulary; (c)Q9004-2000 - Quality Management Systems: Guidelines for Performance Improvements. To be ISO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete reassessment is required. Note that ISO certification does not necessarily indicate quality products - it indicates only that documented processes are followed. Also see http://www.iso.ch/ for the latest information. In the U.S. the standards can be purchased via the ASQ web site at http://e-standards.asq.org/

9. IEEE

'Institute of Electrical and Electronics Engineers' - among other things, creates standards such as 'IEEE Standard for Software Test Documentation' (IEEE/ANSI Standard 829), 'IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008), 'IEEE Standard for Software Quality Assurance Plans' (IEEE/ANSI Standard 730), and others.

10. ANSI

'American National Standards Institute', the primary industrial standards body in the U.S.; publishes some software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).

Other software development/IT management process assessment methods besides CMMI and ISO 9000 include SPICE, Trillium, TickIT, Bootstrap, ITIL, MOF, and CobiT.



Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Some Testing Terms - part 1

1. Validation:

The comparison between the actual characteristics of something (e.g. a product of a software project and the expected characteristics).Validation is checking that you have built the right system.

2. Verification:

The comparison between the actual characteristics of something (e.g. a product of a software project) and the specified characteristics.Verification is checking that we have built the system right.

3. Configuration Management

Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes.

4. When to stop testing

This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:

Deadlines (release deadlines, testing deadlines, etc.)
Test cases completed with certain percentage passed
Test budget depleted
Coverage of code/functionality/requirements reaches a specified point
Bug rate falls below a certain level
Beta or alpha testing period ends

5. Risk Analysis/ Identifying Test Cases

Use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include:

01 Which functionality is most important to the project's intended purpose?
02 Which functionality is most visible to the user?
03 Which functionality has the largest safety impact?
04 Which functionality has the largest financial impact on users?
05 Which aspects of the application are most important to the customer?
06 Which aspects of the application can be tested early in the development cycle?
07 Which parts of the code are most complex, and thus most subject to errors?
08 Which parts of the application were developed in rush or panic mode?
09 Which aspects of similar/related previous projects caused problems?
10 Which aspects of similar/related previous projects had large maintenance expenses?
11 Which parts of the requirements and design are unclear or poorly thought out?
12 What do the developers think are the highest-risk aspects of the application?
13 What kinds of problems would cause the worst publicity?
14 What kinds of problems would cause the most customer service complaints?
15 What kinds of tests could easily cover multiple functionalities?
16 Which tests will have the best high-risk-coverage to time-required ratio?


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Control Structure testing

a. Conditions Testing
Condition testing aims to exercise all logical conditions in a program module.

Errors in expressions can be due to:
1. Boolean operator error
2. Boolean variable error
3. Boolean parenthesis error
4. Relational operator error
5. Arithmetic expression error

Condition testing methods focus on testing each condition in the program. Strategies proposed include:

Branch testing - execute every branch at least once.

Domain Testing - uses three or four tests for every relational operator.

Branch and relational operator testing - uses condition constraints

Coverage of the constraint set guarantees detection of relational operator errors.



Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Why White box testing when black box testing

Why White box testing when black box testing is there to test conformance to requirements

Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.

May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.

Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

White Box Testing Techniques

White Box Testing Techniques

1. Basis Path Testing
a. Flow Graph Notation
b. Cyclomatic Complexity
c. Deriving Test Cases
d. Graph Matrices

2. Control Structure testing
a. Conditions Testing
b. Data Flow Testing
c. Loop Testing


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Usability Testing

Usability testing is a special form of testing that looks for bugs not in the functionality of the program, but in the layout and utility of the user interface. This step is often performed on a prototype before the actual system code is written, so it is easy to change if needed. For usability testing, you need to plan:

01. How you will choose the users for the test (what is a representative sample of your real user population?)

02. A set of tasks for the users to perform representing paths through your system showing key functionality

03. A method for getting feedback from the users - surveys, interviews, data collection in the system itself

04. How you will analyze the data you collected in order to make improvements to the user interface


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Types of Black Box Testing

Acceptance Testing / User Acceptance Testing - UAT Formal tests (often performed by a customer) to determine whether or not a system has satisfied predetermined acceptance criteria. These tests are often used to enable the customer (either internal or external) to determine whether or not to accept a system.

The test procedures that lead to formal 'acceptance' of new or changed systems. User Acceptance Testing is a critical phase of any 'systems' project and requires significant participation by the 'End Users'. To be of real use, an Acceptance Test Plan should be developed in order to plan precisely, and in detail, the means by which 'Acceptance' will be achieved. The final part of the UAT can also include a parallel run to prove the system against the current system.

The User Acceptance Test Plan will vary from system to system but, in general, the testing should be planned in order to provide a realistic and adequate exposure of the system to all reasonably expected events. The testing can be based upon the User Requirements Specification to which the system should conform.

As in any system though, problems will arise and it is important to have determined what will be the expected and required responses from the various parties concerned; including Users; Project Team; Vendors and possibly Consultants / Contractors.

In order to agree what such responses should be, the End Users and the Project Team need to develop and agree a range of 'Severity Levels'. These levels will range from (say) 1 to 6 and will represent the relative severity, in terms of business / commercial impact, of a problem with the system, found during testing. Here is an example which has been used successfully; '1' is the most severe; and '6' has the least impact :-

'Show Stopper' i.e. it is impossible to continue with the testing because of the severity of this error / bug

Critical Problem; testing can continue but we cannot go into production (live) with this problem

Major Problem; testing can continue but live this feature will cause severe disruption to business processes in live operation

Medium Problem; testing can continue and the system is likely to go live with only minimal departure from agreed business processes

Minor Problem ; both testing and live operations may progress. This problem should be corrected, but little or no changes to business processes are envisaged

'Cosmetic' Problem e.g. colours; fonts; pitch size However, if such features are key to the business requirements they will warrant a higher severity level.

The users of the system, in consultation with the executive sponsor of the project, must then agree upon the responsibilities and required actions for each category of problem. For example, you may demand that any problems in severity level 1, receive priority response and that all testing will cease until such level 1 problems are resolved.

Caution. Even where the severity levels and the responses to each have been agreed by all parties; the allocation of a problem into its appropriate severity level can be subjective and open to question. To avoid the risk of lengthy and protracted exchanges over the categorisation of problems; we strongly advised that a range of examples are agreed in advance to ensure that there are no fundamental areas of disagreement; or, or if there are, these will be known in advance and your organisation is forewarned.

Finally, it is crucial to agree the Criteria for Acceptance. Because no system is entirely fault free, it must be agreed between End User and vendor, the maximum number of acceptable 'outstandings' in any particular category. Again, prior consideration of this is advisable.

N.B. In some cases, users may agree to accept ('sign off') the system subject to a range of conditions. These conditions need to be analysed as they may, perhaps unintentionally, seek additional functionality which could be classified as scope creep. In any event, any and all fixes from the software developers, must be subjected to rigorous System Testing and, where appropriate Regression Testing.


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Test Data Categorization Techniques

1. Equivalence Partitioning

Divide the input domain into classes of data for which test cases can be generated.

Attempting to uncover classes of errors.

An equivalence class represents a set of valid or invalid states An input condition is either a specific numeric value, range of values, a set of related values, or a boolean condition.

Equivalence classes can be defined by:

If an input condition specifies a range or a specific value, one valid and two invalid equivalence classes defined.
If an input condition specifies a boolean or a member of a set, one valid and one invalid equivalence classes defined.

Test cases for each input domain data item developed and executed.


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Regression Testing

Testing conducted for the purpose of evaluating whether or not a change to the system (all CM items) has introduced a new failure. Regression testing is often accomplished through the construction, execution and analysis of product and system tests.

Regression testing is an expensive but necessary activity performed on modified software to provide confidence that changes are correct and do not adversely affect other system components. Four things can happen when a developer attempts to fix a bug. Three of these things are bad, and one is good:

Because of the high probability that one of the bad outcomes will result from a change to the system, it is necessary to do regression testing.

It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Most industrial testing is done via test suites; automated sets of procedures designed to exercise all parts of a program and to show defects. While the original suite could be used to test the modified software, this might be very time-consuming. A regression test selection technique chooses, from an existing test set, the tests that are deemed necessary to validate modified software.

There are three main groups of test selection approaches in use:

Minimization approaches seek to satisfy structural coverage criteria by identifying a minimal set of tests that must be rerun.

Coverage approaches are also based on coverage criteria, but do not require minimization of the test set. Instead, they seek to select all tests that exercise changed or affected program components.

Safe attempt instead to select every test that will cause the modified program to produce different output than original program.

An interesting approach to limiting test cases is based on whether we can confine testing to the "vicinity" of the change. (Ex. If I put a new radio in my car, do I have to do a complete road test to make sure the change was successful?) A new breed of regression test theory tries to identify, through program flows or reverse engineering, where boundaries can be placed around modules and subsystems. These graphs can determine which tests from the existing suite may exhibit changed behavior on the new version.

Regression testing has been receiving more attention as corporations focus on fixing the 'Year 2000 Bug'. The goal of most Y2K is to correct the date handling portions of their system without changing any other behavior. A new 'Y2K' version of the system is compared against a baseline original system. With the obvious exception of date formats, the performance of the two versions should be identical. This means not only do they do the same things correctly, they also do the same things incorrectly. A non-Y2K bug in the original software should not have been fixed by the Y2K work.

A frequently asked question about regression testing is 'The developer says this problem is fixed. Why do I need to re-test?’ to which the answer is 'The same person probably told you it worked in the first place'



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Performance Testing - Volume Testing

Volume Testing: Testing where the system is subjected to large volumes of data. As regards faults that should be found through volume testing are those, where the behaviour of the software deviates from that expected for a specified volume of data. Thus a bank system will be tested for faults at much larger volumes of data, than that of small retailer software. A fault which is only manifested on a table with a million records will be of no concern to the retail software, but will be picked up by the bank testers.

For example, a window often used window object is populated with data, by calling a database object which runs a complex SQL query. Supposing the component is tested against tables with only 4-5 records. Of course it will return within seconds. Everything seems fine. It is then integrated with the window, and system tested. Again everything seems ok. It is only when the application is in User Acceptance (or even gone live) and it is tested against 100,000 records, is it discovered that, the SQL was not properly optimized and the tables not indexed. Thus it should have been tested at the component level.

Volume testing needs two things. Firstly clear expected outcomes of how the software is to behave for a given level of data. Secondly, data, and lots of it.

The expected behaviour at various levels, should be in the specification documentation. Ideally this will say something like "the customers details will be returned returned on the screen within 3 seconds, from a database with 1 million customer records." This gives the tester a benchmark to base a test case on.

The second requirement for data, needs either real life data, or simulated data. Usually, real life data will come in the form of a customer database, that has had private information, such as names and account numbers scrambled. Alternatively records can be created from scratch using automated tools or by adding rules directly on to the database, with SQL.

As with all testing, proper records must be kept showing the inputs, outputs other information, to aid potential debugging and audit purposes.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Performance Testing - Stress testing

Stress testing :is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). Bugs and failure modes discovered under stress testing may or may not be repaired depending on the application, the failure mode, consequences, etc. The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Performance Testing - Load testing

Load testing: is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term "load testing" by itself is too vague and imprecise to warrant use. For example, do you mean representative load," "overload," "high load," etc. In performance testing, load is varied from a minimum (zero) to the maximum level the systemcan sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Integration Testing

One of the most difficult aspects of software development is the integration and testing of large, untested sub-systems. The integrated system frequently fails in significant and mysterious ways, and it is difficult to fix it

Integration testing exercises several units that have been combined to form a module, subsystem, or system. Integration testing focuses on the interfaces between units, to make sure the units work together. The nature of this phase is certainly 'white box', as we must have a certain knowledge of the units to recognize if we have been successful in fusing them together in the module.

There are three main approaches to integration testing: top-down, bottom-up and 'big bang'. Top-down combines, tests, and debugs top-level routines that become the test 'harness' or 'scaffolding' for lower-level units. Bottom-up combines and tests low-level units into progressively larger modules and subsystems. 'Big bang' testing is, unfortunately, the prevalent integration test 'method'. This is waiting for all the module units to be complete before trying them out together.

Integration tests can rely heavily on stubs or drivers. Stubs stand-in for finished subroutines or sub-systems. A stub might consist of a function header with no body, or it may read and return test data from a file, return hard-coded values, or obtain data from the tester. Stub creation can be a time consuming piece of testing.

The cost of drivers and stubs in the top-down and bottom-up testing methods is what drives the use of 'big bang' testing. This approach waits for all the modules to be constructed and tested independently, and when they are finished, they are integrated all at once. While this approach is very quick, it frequently reveals more defects than the other methods. These errors have to be fixed and as we have seen, errors that are found 'later' take longer to fix. In addition, like bottom up, there is really nothing that can be demonstrated until later in the process.


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Functional testing

Functional testing: Application of test data derived from the specified functional requirements without regard to the final program structure. Also known as black-box testing.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Exploratory Testing

An interactive process of concurrent product exploration, test design, and test execution. The heart of exploratory testing can be stated simply: The outcome of this test influences the design of the next test.

The plainest definition of exploratory testing is test design and test execution at the same time. This is the opposite of scripted testing (predefined test procedures, whether manual or automated). Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan. This may sound like a straightforward distinction, but in practice it's murky. That's because "defined" is a spectrum. Even an otherwise elaborately defined test procedure will leave many interesting details (such as how quickly to type on the keyboard, or what kinds of behavior to recognize as a failure) to the discretion of the tester. Likewise, even a free-form exploratory test session will involve tacit constraints or mandates about what parts of the product to test, or what strategies to use. A good exploratory tester will write down test ideas and use them in later test cycles. Such notes sometimes look a lot like test scripts, even if they aren't. Exploratory testing is sometimes confused with "ad hoc" testing. Ad hoc testing normally refers to a process of improvised, impromptu bug searching. By definition, anyone can do ad hoc testing

What kinds of specifics affect ET? Here are some of them:

1. the mission of the test project
2. the mission of this particular test session
3. the role of the tester
4. the tester (skills, talents, and preferences)
5. available tools and facilities
6. available time
7. available test data and materials
8. available help from other people
9. accountability requirements
10. what the tester‘s clients care about
11. the current testing strategy
12. the status of other testing efforts on the same product
13. the product, itself- its user interface - its behavior - its present state of execution - its defects- its testability- its purpose
14. what the tester knows about the product- what just happened in the previous test - known problems with it- past problems with it - strengths and weaknesses - risk areas and magnitude of perceived risk - recent changes to it - direct observations of it- rumors about it - the nature of its users and user behavior - how it‘s supposed to work - how it‘s put together - how it‘s similar to or different from other products
15. what the tester would like to know about the product


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Boundary Value Analysis

Large number of errors tend to occur at boundaries of the input domain.

BVA leads to selection of test cases that exercise boundary values.

BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class.

Examples:

For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1).

If input conditions specify a number of values n, test with (n-1), n and (n+1) input values.

Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size).

If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

About Software Testing

Process of evaluation of Software application: To verify it satisfy the specified requirements With intent to find errors To Check if the system ?Fit for Purpose? Simulation of real time scenarios.

Testing is not a one-time activity—applications need to be tested throughout their lifecycle. Every version upgrade, module addition, or enhancement, as well as every implementation at a new site or increase in user load, needs to be put through comprehensive testing. The Program Doesn‘t Work Nobody would pay you to test if their program didn‘t have bugs. All programs have bugs. Any change to a program can cause new bugs, and any aspect of the program can be broken. You DON‘T ?verify that the program is working.? You FIND bugs. “If you set your mind to show that a program works correctly, you’ll be more likely to miss problems than if you want and expect the program to fail.” Complete Testing is Impossible:

1. There are a nearly infinite number of paths through any non-trivial program.
2. There are a virtually infinite set of combinations of data that you can feed the program.
You can’t test them all.
1. Therefore, your task is to find bugs --not to find all the bugs.
2. You want to find as many bugs as possible
3. Find the most serious bugs
4. Find bugs as early as possible
5. Your challenges will require judgment, trade-offs, and efficiency.

“Q: How many QA testers does it take to change a lightbulb?
A: QA testers don't change anything. They just report that it's dark.” Kerry Zallar?


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

HP LoadRunner Training Course

Overview
HP LoadRunner is a load testing product that determines application
scalability, behavior, and performance. It emulates thousands of virtual users, and identifies and isolates performance bottlenecks across and within each tier.

This course teaches students the fundamentals of performance testing using LoadRunner. By the completion of this course, students will be able to utilize LoadRunner’s features to automate performance / load tests.

Duration: 4 Days

Course Objectives
This course teaches you to:
• Discuss the value of load testing
• Plan for effective load testing
• Establish load test goals
• Run load test scenarios
• Load and overload when executing scenarios
• Analyze and interpret load test results


Prerequisites
• Knowledge of the Windows 2000 or Windows NT interface and environment
• High-level knowledge of the Web and or client/server environment


Intended Audience

Quality assurance engineers, performance engineers, and new users of LoadRunner who need to load test their applications and/or executives who be will involved in any part of load testing.


Course Outline

Introduction

• Define VuGen
• Identify the main components of the VuGen interface

Recording for the Web

• Create a VuGen script by recording user steps with VuGen in the web environment
• Describe the basics of HTML and URL recording levels

Replay

• Identify and configure the appropriate web runtime setting for replay
• Replay the script in VuGen to verify script functionality
• Recognize the debugging tools available in VuGen

Transactions

• Explain the function of a transaction in a script
• Insert a transaction in a script during and after recording

Parameters

• Explain what parameters are and how they work
• Solve playback problems with parameterization
• Parameterize a script for load testing

Auto Correlation After Recording

• Define Correlation
• Correlate dynamic values found by using the Auto Correlation tool

Verification

• Recognize why and when to use verification
• Identify visual cues to check for during load testing
• Add Text Checkpoints during and after recording

Actions

• Create multiple Actions for a web script
• Configure Actions to achieve load testing goals

Introduction to Script View

• Identify when Script view is necessary
• Send customized output messages to the Replay Log
• Identify basic C code including statements, variables, and functions
• Apply basic debugging techniques in VuGen

Advanced Scripting Techniques

• Recognize general LoadRunner functions
• Recognize protocol specific functions

Manual Correlation

• Determine when manual correlation is required
• Correlate dynamic values using the create parameter option

Auto Correlation During Recording

• Create correlation rules to auto correlate during recording
• Import and export correlation rules

Introduction to Scenarios

• Explain elements that make a LoadRunner scenario
• Identify different types of scenarios
• How to choose the scenario
• Present the basic steps for creating a scenario

Scenario Execution

• Prepare for a scenario run
• Identify techniques to efficiently run a scenario

Scheduling Scenarios

• Scheduling by group and by scenario
• Prepare VuGen User (Vuser) initialization
• Configure duration scheduling
• Configure scenario ramp up and ramp down

Performance Monitors

• Value of Performance Monitors
• Select Performance Monitors
• Add measurements to Performance Monitors

Results Analysis

• Value of root cause analysis
• Diagnose errors with LoadRunner
• Meaningful interpretation of LoadRunner graphs



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Quality Center (QC) Certification Training Course

Overview
Mercury Quality Center is a web-based test management tool that provides the methodology, structure, organization, and documentation for all phases of the application testing process. It Serves as a central repository for all your testing assets and provides a clear foundation for the entire testing process. It establishes seamless integration and smooth information flow from one stage of the testing process to the next. It supports the analysis of test data and coverage statistics, to provide a clear picture of an application’s accuracy and quality at each point in its lifecycle. Because it is completely web-enabled, it supports communication and collaboration among distributed testing teams.

Duration: 2.5 Days (20 Hours)

Course Objectives
This course teaches you to:

Discuss the value of Test Management
Understanding the Architecture of QC
Understanding the Implementation of QC at different levels of Testing Life Cycle.


Prerequisites
Candidates should be well versed with the concepts of Manual Software Testing

Intended Audience
Quality assurance engineers, and new users of Quality Center who need to implement QC and/or executives who be will involved in any part of testing

Course Outline
Quality Center - Introduction

Need of Test-Management Tool
Module (TestDirector Project, Site Administration, Customization)]
Domain/Project Fundamentals
How to Get Started


Site Administration

Creating Domain/project
Adding users to project
Creating Groups


Customization

Release and Cycle creation

Test Requirements

Example of a test requirement
Importance of tracing and tracking requirements
Reviewing and building a
requirements structure
Entering requirements manually


Test Cases Creation and management

Review of an existing test case
Parameters
Building a test case structure
Creating manual test cases
Requirements coverage


Test Sets and Test Execution

Creating folders and test sets
Defining test execution flow
Setting test set properties
Manual test execution
Logging defects during manual testing
Automated test execution
Adding test hosts
Running a test set
Setting run times


Defect Tracking

Reporting defects
Searching for similar defects
Using grid filters
Deleting defects


Reporting and Analysis

Analysis menu graphs and reports
Creating editable reports with the advanced Reporting





Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

QTP Certification Training Course

Duration: 3 Days (24 Hours)

Course Objectives
This course teaches you: The concepts of functional automation. Getting abreast with the QTP and learning how to implement it to do effective test automation. Understanding the advanced level features of QTP along with doing hands on with them.

Prerequisites
Candidates should be well versed with the concepts of Manual Software Testing

Intended Audience
Quality assurance engineers, and new users of QTP who need to implement QTP and/or executives who will be involved in any part of testing.

Course Outline

Introduction to Automation
Architecture of Functional Automation Tools

Record and Play
Modes of Recording

Object Repository(Types)
Object Repository Manager(ORM) and Merging of OR
Object Identification

Actions
Parameterization

Checkpoints(Standard, Text, Bitmap, Database, XML from Resource)

Output Values(Standard, Text, Text Area, Bitmap, Database, XML from Resource)

Synchronization Points

Regular Expression

Recovery Scenarios

Function Libraries

Define VB Functions
VB subroutines
Accessing Data table at Runtime using VBScript

Concept of Descriptive programming.
Single physical description
Object of physical descriptions.


Framework
Types of Framework: 0,1,2,3.
Introduction to a Case Study.
Building Framework of a real life application.




Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Course Information

HP Win Runner
Course Content : Understanding Win Runner, Starting the Testing Process, Introducing the GUI Map, Recoding Tests, Understanding Scripts, Data Driving the Tests, Creating Checkpoints, Recovery Scenario

HP Load Runner
Course Content : Introducing Load Runner, Power of Load Runner, Building Scripts, Playing Back the Scripts, Understanding Record time settings, Understanding Run time settings, Creating a Load Testing Scenario, Running Load Test, Analyzing Results

HP Quick Test Professional
Course Content : Introduction to Automation,Architecture of Functional Automation Tools, Record & Play, Modes of Recording, Object Repository (Types), Object Repository Manager (ORM) & Merging of OR, Object Identification, Actions, Parameterization, Checkpoints, Output Values, Synchronization Points, Regular Expressions, Recovery Scenario, Function Libraries, QC & QTP connectivity.

HP Quality Center
Course Content : Quality Center Basics, Site Administration, Project Customization, Release Management using QC, Requirement Management using QC, Test Case Management using QC, Test Case Execution Control using QC, Defect Reporting using QC, Graphs and Reports.

Manual Testing
Course Content : Understanding Testing Basics, What is testing,Test Team Structure, Testing Envirnment, Attributes of Tester, Relevance of SDLC in Software Testing, SDLC Models, Different types of Testing done at different stages, Test Factors & their implementation, Designing Test Plan, Designing Test Case, How to Report Defects, Defect Lifecycle, Web Testing, Database Testing, Security Testing.

Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Public Training Overview

Looking to build software Testing skill set or becoming more specialized? Learn the skills and practices you need to meet the challenges of your job, and build the career you want.

CresTech offers the broadest range of Software Testing and Test Automation training courses available. Developed by top industry consultants, all courses are based on the latest industry practices and updated regularly to reflect current technologies, trends, and issues. Our Trainers are top Software Pros who can help you understand the finer points of software testing--An advantage that no one else can offer. You receive expert instruction, content tailored to students' needs, and group discussions to enhance your experience. In fact, over 98% of the Students for this course recommended CresTech's courses to their peers in the industry.

• Manual Testing

This module would serve as Stepping stone for students in the Testing. This will take participants through the understanding of job of a software tester and what awaits them when they work in company as Test Engineer. This is perhaps the Best "First" Course for Any Test Professional. This course initiates you into Software Testing taking you gently through different aspects of Software Testing. This course covers the essential theory and foundations of software quality as well as the practical skill building necessary to be an effective and active contributor to the software development process. It covers software testing and testing project management techniques that are applied daily by successful software development companies.

Course Outline

• An Overview of Product Development
• The Software Development Lifecycle
• An Overview of a Testing Organization
• Costs Associated with Testing and Quality
• Objectives of Testing
• Getting Started- Terminology, Test Types and Test Methods
• How to Report Software Bugs
• Analyzing Software Bugs
• Reproducing Software Bugs
• Introduction to Black, Gray and White Box Testing
• Black Box and White Box Test Case Design
• Essential Test Case Development methods
• Model-based Testing
• A Survey of Software Testing Tools
• Basics of Test Automation
• The Test Plan
• Automated Testing

Intended Audience
The course is best suited to guys who are planning to take up Testing as Career and want to get a head start into the testing world. This is also ideal for students who are yet to come out of the college but want to equip themselves with the skills that can fetch them a job when they come in Market.

Duration

One Month


• Automated Testing

Use of various tools is becoming more common and automated test execution seems obligatory in the different forms or rapid, incremental and iterative development, due to larger amounts of regression testing. The course provides an introduction to testing tools and test automation adopting a Practical Orientated Approach to take you through Different realms of Software Testing & Automation. The course gives the knowledge that is necessary to avoid pitfalls of test automation.

Automated Testing Tools
• Mercury Tools
» Win Runner
» Load Runner
» QTP
» Test Director/Quality Center
Duration (8 Weeks)

• IBM-Rational
» Test Manager
» Rational Robot
» Rational Performance Tester
» Rational Functional Tester
Duration (8 Weeks)

• Open Source Tools
» Bugzilla
» OSTA
» J-Meter
» Water
Duration (8 Weeks)

Course Outline
• Testing and Test Automation: Trends
• Areas of Test Automation
• Organizational Aspects of Test Automation
• Automation Framework Architecture
• Automation Testing Tools

Intended Audience
This tools are best suited for people who have a sound understanding of Manual Testing principals and now want to improve upon their skill set to Test automation.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

CresTech is market leader in Outsourced Software Testing Services providing Consulting, Resourcing, Training and Products to the corporate houses that help them in improving their Testing Processes and Quality. We implement Quality and Testing Solutions for the Organizations in order to meet their timelines, budget and quality goals.

Our software testing services span across enterprise such as Banking and Finance, Insurance, Media & Entertainment, Telecom, ERP and Travel and Tourism. Nurturing Innovation and Specializing the Automation, we have High-end Framework in COTS tools and Open Source Tools, which increments the productivity by over 300% and provide Cost and Test effective solutions to the customers.

Company started with a Vision to bring Quality to Software Quality, CresTech provides and partners with Corporates to provide customized, unique, cost-effective Testing Solutions with globally Renowned Experts and a Team of highly Passionate and certified testers.

We offer our clients a complete range of Software Testing Services addressing all of their testing needs including:

Test Planning
Strategy and Management
Providing skilled resources and specialized training
Managed test teams
Specialist test automation engineers.
Consulting


We make sure you have access to best industry practices, resources and ensure these are deployed in a well managed efficient way.

Solutions
Let us implement and deploy a complete testing framework for your organization that makes your processes more matured and increases the effectivity of your resources.

Trainings
Our trainers are top notch software professionals working in top MNCs as software quality engineers. You will not only learn what is testing but also an industry perspective of Software testing best practices.

Products
TestBest: Our flagship product to take care of all your testing related needs in one go. Now manage your testing with an ease you have never experienced before.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Corporate Trainings Overview

CresTech offers advantage of the cost-effective convenience of on-site training and you can get your team the training they need without requiring them to sacrifice project schedules. CresTech has a proven team of experienced industry consultants to help client ramp up their testing team in no time.

Training Models

Training Models


Implants
Mentoring
Consulting


Three tier Training Structure


Beginners
Experienced
Advanced (Preparing for certification)


Multiple tier of trainers for different trainings



Trainings

Manual Testing


Mercury Tools


Win Runner
Load Runner
QTP
Test Director/Quality Center
QC/BPT Training
SiteScope


IBM-Rational


Test Manager
Rational Robot
Rational Performance Tester
Rational Functional Tester



Open Source Tools


Bugzilla
OSTA
J-Meter
Water
Sahi



Borland

SilkTest
RedStonesoftware
Eggplant



Performance Testing

Security Testing

Customized Trainings

- Training can be conducted keeping in view customer’s framework and domain.
- Can conduct project based training
- Approach to each engagement resulting in customer satisfaction.
- Customer centric approach



Course Material

- Copyrighted Course Contents
- Prepared by Renowned Testing Experts
- Course Contents consist of Hands – on session integrated tightly with the classroom session
- Lab exercises prepared keeping Real Life scenarios in mind – To help Attendees appreciate the Implementation rather than Tool
- Course completion certificate for participant.



Trainers

- ISTQB Certified Trainers
- Trained and certified directly by Mercury Interactive and IBM Rational on their cutting edge Tools
- Seasoned Test professionals having rich working experience on various Functional testing projects for corporate
- Have used the Tools extensively to automate complex applications that required heavy customization of automation tool itself.




Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Skill Sets of Software Testing Professional

Software testing is not an easy task, a software tester should requires at least complete knowledge of software testing tools, logical and analytical ability along with quality approach to the software testing processes. A talented tester requires few more skill sets to become successful software testing professional. Unfortunately, we don't see quality software tester in many software development and testing organizations. Majority of the people in the software community consider software testing a mediocre job suitable for people who have lesser analytical and problem-solving skills. The essential skills a software tester should have are not properly assessed when recruiting for a software testing assignment. Below is the list of essential skill sets required in a software tester:

Logical and Analytical Thinking
Any problem and task can be very well completed if the approach is right to solve the problem. For a right and directional approach one should have good logical sense to analyze the problem. The high-end thought process is the key quality in a software tester.
The role of a software tester is to find the logical as well as functional errors in a software application. To find logical errors a software tester should be able to do complete visualization and mapping of the all possible scenarios.
Thus to develop a strategy and to test the software application requires strong and fundamental logical and analytical approach towards software testing.

Time management and Planning
On time delivery of the project is the dream and of course duty as well as commitment of every software organization. Development of the application, testing of the application, bug-fixing of the application and release of the application versions are all the steps which are independent on each step. Any delay in above processes will extend the schedule and in turn will become more money and time consuming process. Every client wants the timely delivery of the application.
Software testing plays major role in the software development life cycle, so proper planning of the software testing plans and timely execution of the plan is the commendable quality of a software tester. A Software tester should define all the testing criteria, approach, assumptions and schedule in time bound schedule and with proper planning.

Effective communication skills
A software tester requires to report for its work, to give presentation on the progress, to communicate and coordinate with the team. All these things require proper, clear and effective communication skills in a budding software tester.
For experienced software tester the client interaction and management interaction increases where the good communication skills helps to grow in the organization.
Along with communication skills, a software tester should emphasize on his presentation skills like body language and appearance. Apart from good communication skill a software tester should be patience to listen others and should not shy or fear to put their strong points and facts in a discussion.


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Software Testing Tools Overview

IeUnit - IeUnit is an open-source simple framework to test logical behaviors of web pages, released under IBM's Common Public License. It helps users to create, organize and execute functional unit tests. Includes a test runner with GUI interface. Implemented in JavaScript for the Windows XP platform with Internet Explorer.

QEngine Web Test Studio - Web functional test tool from AdventNet. Scripting uses Jython; records using page elements controls symbolically rather than with raw screen coordinate. Secure recording on password fields; data-driven Test wizard to fetch script data from external source; provision to add GUI, Database and File checkpoints and verify database tables, files, page titles and HTML element properties. Supports keyword-driven testing, built-in exception handling and reporting facility. Works with a variety of browsers and OS's. Free and professional versions available.

AppPerfect DevSuite - Suite of testing, tuning, and monitoring products from AppPefect Corp. that includes a web functional testing module. Records browser interaction by element instead of screen co-ordinates. Supports handling dynamic content created by JavaScript; supports ASP, JSP, HTML, cookies, SSL. For Windows and MSIE; integrates with a variety of IDE's.

JStudio SiteWalker - Test tool from Jarsch Software Studio allows capture/replay recording; fail definitions can be specified for each step of the automated workflow via JavaScript. JavaScript's Document Object Model enables full access to all document elements. Test data from any database or Excel spreadsheet can be mapped to enter values automatically into HTML form controls. HTML-based test result reports can be generated. Shareware for Windows/MSIE.

Test Complete Enterprise - Automated test tool from AutomatedQA Corp. includes web functional testing capabilities. Works with Internet Explorer. QEngine - Test tool from AdventNet enables functional testing of Web sites and Web-based applications. Record and playback capability; automatic recording of any Web browser events and translates into an Python editable scripts. Includes Script Editor, Application Map Editor to view and edit the map object properties. Supports multiple OS's and browsers.

actiWate - Java-based Web application testing environment from Actimind Inc. Advanced framework for writing test scripts in Java (similar to open-source frameworks like HttpUnit, HtmlUnit etc. but with extended API), and Test Writing Assistant - Web browser plug-in module to assist the test writing process. Freeware.

KUMO Editor - Toolset from Softmorning LTD for creation and editing of web macros and automated web tests. Includes syntax-coloring editor with intellisense, autocomplete, run-time debugging features. Macro recorder transforms any click to a C# directive. Page objects navigator allows browsing of hierarchy of web objects in a page. Enables creation of scenarios from spreadsheets; and loop, retry on error, robust handling of page modifications. Can export created .DLL and .EXE files to enable running web macros on demand and integration into other software frameworks. Multilingual for Asian, eastern and western European languages.

WebInject - Open source tool in PERL for automated testing of web applications and services. Can be used to unit test any individual component with an HTTP interface (JSP, ASP, CGI, PHP, servlets, HTML forms, etc.) or it can be used to create a suite of HTTP level functional or regression tests.

Site Test Center - Functional and performance test tool from Alliance Software Engineering. Has an XML-based scripting capability to enable modifying captured scripts or creating new scripts. Utilizes a distributed testing model and consists of three parts: STC Administrator, STC Master and STC Master Service.

jWebUnit - Open source Java framework that facilitates creation of acceptance tests for web applications. Provides a high-level API for navigating a web application combined with a set of assertions to verify the application's correctness including navigation via links, form entry and submission, validation of table contents, and other typical business web application features. Utilizes HttpUnit behind the scenes. The simple navigation methods and ready-to-use assertions allow for more rapid test creation than using only JUnit and HttpUnit.

SimpleTest - Open source unit testing framework which aims to be a complete PHP developer test solution. Includes all of the typical functions that would be expected from JUnit and the PHPUnit ports, but also adds mock objects; has some JWebUnit functionality as well. This includes web page navigation, cookie testing and form submission.

WinTask - Macro recorder from TaskWare, automates repetitive tasks for Web site testing (and standard Windows applications), with its HTML objects recognition. Includes capability to expand scope of macros by editing and adding loops, branching statements, etc. (300+ commands); ensure robustness of scripts with Synchronization commands. Includes a WinTask Scheduler.

TestCaseMaker/Runner - Test case document driven functional test tool for web applications from Agile Web Development. Maker creates test case documents, and Runner executes the test case document; test case documents are always synchronized with the application. Free including source code.

Canoo WebTest - Free Java Open Source tool for automatic functional testing of web applications. XML-based test script code is editable with user's preferred XML editor; until recording capabilities are added, scripts have to be developed manually. Can group tests into a testsuite that again can be part of a bigger testsuite. Test results are reported in either plain text or XML format for later presentation via XSLT. Standard reporting XSLT stylesheets included, and can be adapted to any reporting style or requirements.

TestSmith - Functional/Regression test tool from Quality Forge. Includes an Intelligent, HTML/DOM-Aware and Object Mode Recording Engine, and a Data-Driven, Adaptable and Multi-Threaded Playback Engine. Handles Applets, Flash, Active-X controls, animated bitmaps, etc. Controls are recorded as individual objects independent of screen positions or resolution; playback window/size can be different than in capture. Special validation points, such as bitmap or text matching, can be inserted during a recording, but all recorded items are validated and logged 'on the fly'. Fuzzy matching capabilities. Editable scripts can be recorded in SmithSript language or in Java, C++ or C++/MFC. 90-day evaluation copy available.

TestAgent - Capture/playback tool for user acceptance testing from Strenuus, LLC. Key features besides capture/playback include automatically detecting and capturing standard and custom content errors. Reports information needed to troubleshoot problems. Enables 'Persistent Acceptance Testing' that activates tests each time a web application is used.

MITS.GUI - Unique test automation tool from Omsphere LLC; has an intelligent state machine engine that makes real-time decisions for navigating through the GUI portion of an application. It can test thousands of test scenarios without use of any scripts. Allows creation of completely new test scenarios without ever having performed that test before, all without changing tool, testware architecture (object names, screen names, etc), or logic associated with the engine. Testers enter test data into a spreadsheet used to populate objects that appear for the particular test scenario defined.

Badboy - Tool from Bradley Software to aid in building and testing dynamic web based applications. Combines sophisticated capture/replay ability with performance testing and regression features. Free for most uses; source code avalable.

SAMIE - Free tool designed for QA engineers - 'Simple Automated Module For Internet Explorer'. Perl module that allows a user to automate use of IE via Perl scripts; Written in ActivePerl, allowing inheritance of all Perl functionality including regular expressions, Perl dbi database access, many Perl cpan library functions. Uses IE's built in COM object which provides a reference to the DOM for each browser window or frame. Easy development and maintenance - no need to keep track of GUI maps for each window. For Windows.

PAMIE - Free open-source 'Python Automated Module For Internet Explorer' Allows control of an instance of MSIE and access to it's methods though OLE automation . Utilizes Collections, Methods, Events and Properties exposed by the DHTML Object Model.

PureTest - Free tool from Minq Software AB, includes an HTTP Recorder and Web Crawler. Create scenarios using the point and click interface. Includes a scenario debugger including single step, break points and response introspection. Supports HTTPS/SSL, dynamic Web applications, data driven scenarios, and parsing of response codes or parsing page content for expected or unexpected strings. Includes a Task API for building custom test tasks. The Web Crawler is useful for verifying consistency of a static web structure, reporting various metrics, broken links and the structure of the crawled web. Multi-platform - written in Java.

Solex - Web application testing tool built as a plug-in for the Eclipse IDE (an open, extensible IDE). Records HTTP messages by acting as a Web proxy; recorded sessions can be saved as XML and reopened later. HTTP requests and responses are fully displayed in order to inspect and customize their content. Allows the attachment of extraction or replacement rules to any HTTP message content, and assertions to responses in order to validate a scenario during its playback.

QA Wizard - Automated functional web test tool from Seapine Software. Advanced object binding reduces script changes when Web-based apps change. Next-generation scripting language eliminates problems created by syntax or other language errors. Includes capability for automated scripting, allowing creation of more scripts in less time. Supports unlimited set of ODBC-compatible data sources as well as MS Excel, tab/comma delimited file formats, and more. Free Demo and Test Script available. For Windows platforms.

HTTP-WebTest - A Perl module which runs tests on remote URLs or local Web files containing Perl/JSP/HTML/JavaScript/etc., and generates a detailed test report. This module can be used "as-is" or its functionality can be extended using plugins. Plugins can define test types and provide additional report capabilities. This module comes with a set of default plugins, but can be easily extended with third-party plugins. Open-source project maintained by Ilya Martynov.

HttpUnit - Open source Java program for accessing web sites without a browser, from SourceForge.net/Open Source Development Network, designed and implemented by Russell Gold. Ideally suited for automated unit testing of web sites when combined with a Java unit test framework such as JUnit. Emulates the relevant portions of browser behavior, including form submission, basic http authentication, cookies and automatic page redirection, and allows Java test code to examine returned pages as text, an XML DOM, or containers of forms, tables, and links. Includes ServletUnit to test servlets without a servlet container.

iOpus Internet Macros - Macro recorder utility from iOpus Inc. automates repetitious aspects of web site testing. Records any combination of browsing, form filling, clicking, script testing and information gathering; assists user during the recording with visual feedback. Power users can manually edit a recorded macro. A command line interface allows for easy integration with other test software. Works by remote controlling the browser, thus automatically supports advanced features such as SSL, HTTP-Redirects and cookies. Can handle data input from text files, databases, or XML. Can extract web data and save as CSV file or process the data via a script. For Windows and MSIE.

MaxQ - Free open-source web functional testing tool from Tigris.org, written in Java. Works as a proxy server; includes an HTTP proxy recorder to automate test script generation, and a mechanism for playing tests back from the GUI and command line. Jython is used as the scripting language, and JUnit is used as the testing library.

TestWeb - Test tool from Original Software Group Ltd. utilizes a new approach to recording/playback of web browser scripts. It analyses the underlying intentions of the script and executes it by direct communication with web page elements. IntelliScripting logic removes the reliance on specific browser window sizes, component location and mouse movements for accurate replay, for easier script maintenance; supports hyperlinks targeted at new instances of browser. Playback can run in background while other tasks are performed on the same machine.

Compuware TestPartner - Automated software testing tool from Compuware designed specifically to validate Windows, Java, and web-based applications. The 'TestPartner Visual Navigator' can create visual-based tests, or MS VBA can be used for customized scripting.

WebKing - Web site functional, load, and static analysis test suite from ParaSoft. Maps and tests all possible paths through a dynamic site; can enforce over 200 HTML, CSS, JavaScript, 508 compliance, WML and XHTML coding standards or customized standards. Allows creation of rules for automatic monitoring of dynamic page content. Can run load tests based on the tool's analysis of web server log files. For Windows, Linux, Solaris.

eValid - Web test tool from Software Research, Inc that uses a 'Test Enabled Web Browser' test engine that provides browser-based client side quality checking, dynamic testing, content validation, page performance tuning, and webserver load and capacity analysis. Utilizes multiple validation methods.

Rational Functional Tester - IBM's (formerly Rational's) automated tool for testing of Java, .NET, and web-based applications. Enables data-driven testing, choice of scripting languages and editors. For Windows and Linux.

e-Test Suite - Integrated functional/regression test tool from Empirix for web applications and services and .NET and J2EE applications; includes site monitoring and load testing capabilities, and record/playback, scripting language, test process management capabilities. Includes full VBA script development environment and options such as javascript, C++, etc. DOM-based testing and validation; 'Data Bank Wizard' simplifies creation of data-driven tests. Evaluation version available.

QuickTest Pro - Functional/regression test tool from Mercury; includes support for testing Web, Java, ERP, etc.

Winrunner - Functional/regression test tool from Mercury; includes support for testing Web, Java, ERP, etc.

Compuware's QARun - QARun for functional/regression testing of web, Java, and other applications. Handles ActiveX, HTML, DHTML, XML, Java beans, and more.

SilkTest - Functional test tool from Segue for Web, Java or traditional client/server-based applications. Features include: test creation and customization, test planning and management, direct database access and validation, recovery system for unattended testing, and IDE for developing, editing, compiling, running, and debugging scripts, test plans, etc.

Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Software Testing Processes: An approach for Software Quality

Software testing is one of the inevitable processes in software development life cycle. For software testing process there are few sets of test are defined: making test plan, test cases design, defect documentation or bug logging and status report file.

All these steps are taken together by software testing teams to make a complete software testing cycle. This software testing cycle helps organization to achieve high quality software products and applications. To process high quality software testing the software development requirement documents and design document play major role in planning and designing the software testing deliverables.

There are various open source testing tools present and available freely to make the testing easy and simplified for beginners as well. Expert software testing professionals has right mix of following:
- logical and reasoning aptitude,
- software testing experience and
- good knowledge of frameworks and practice on testing tools.

Let’s discuss few processes of software testing:

Making Test Plan: Test plan describes the following –
- the objective of software testing,
- scope of the software testing,
- approach and assumptions in testing,
- dependencies and risks measurement and
- schedule and steps for the test phases

Many testing organizations and companies defines test plan as to describe software testing phases, testing procedures, technical analysis and other general standard testing practice. Objective of Test Plan defines “why testing is required”, whereas scope of Test Plan defines “what are the requirements in testing”.

Test Cases Design: Test cases designs are prepared to give the complete direction and flow in the testing procedure. Test cases are designed by keeping the operational flow of the software in mind. To design high quality test cases, the proper documentation of current test cycle is required to make it extendible in future test cycle. Test cases in common define the author, description, steps, and expected result of the testing.

Defect Documentation/Bug Logging: Software Testing is done to find the malfunctioning and defects in the software. Defect finding is the most critical role in the software testing cycle. Making proper documentation of defects stating how to reproduce the bug is required and expected from the software tester. Defect documentation commonly states the tester name, reproduction steps, severity and status of the defects.

Status report file: Status of the software testing is prepared in weekly, bi-monthly, monthly basis. Status report helps in meeting timelines and forecasting the staging of the software for production. Quality status reports always focus the goal of testing and software testing deliverables.


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Software Development Lifecycle (SDLC)

In planning a test project it is important to get a bigger understanding of the software development process being used. The lifecycle used can often have a big effect on the test effort. A software lifecycle model is a definition of the process which is used to develop software.
The lifecycle model defines the phases of the development process, the order they occur in, the degree to which they may overlap, and the entry and exit criteria for each phase.

I. Water-Fall Model
The Waterfall life cycle model was introduced by Winston Royce in 1970 and is currently the most commonly used model for software development. It emphasizes that software is developed in sequential phases (e.g., analysis, design, code, etc.) with established milestones, documents, and reviews at the end of each phase. There is no overlap of each phases (i.e., design can't begin until analysis is completed) and the entire scope of the project is addressed at each phase. The waterfall lifecycle is often criticized as being a "one way street, with no turning back" where once analysis is complete, design can begin, but once design has begun, analysis cannot be re-entered - the requirements are frozen.
"One phase starts when the previous phase completes for all modules/units. Since the previous phase's end determine the start of the next phase, a small delay in one phase may propagate till the end. Such small delay in each phase may cause bigger delay or time-over-runs on the project"

Waterfall Model Assumption
The requirements are knowable in advance of implementation.
The requirements have no unresolved, high-risk implications. e.g., risks due to COTS choices, cost, schedule, performance, safety, security, and user interface organizational impacts.
The nature of the requirements is compatible with all the key system stakeholders‘ expectations. e.g. users, customer, developers, maintainers, investors
The right architecture for implementing the requirements is well understood.
There is enough calendar time to proceed sequentially.


Advantages of Waterfall Model
Conversion of existing projects in to new projects.
For proven platforms and technologies, it works fine.
Suitable for short duration projects.
The waterfall model is effective when there is no change in the requirements, and the requirements are fully known.
If there is no Rework, this model builds a high quality product.
The stages are clear cut
All R&D done before coding starts, implies better quality program design


Disadvantages of Waterfall Model
Testing is postponed to later stage till coding completes.
Not suitable for large projects
It assumes uniform and orderly sequence of steps.
Risk in certain project where technology itself is a risk.
Correction at the end of phase need correction to the previous phase, so rework is more.
Real projects rarely flow in a sequential process.
It is difficult to define all requirements at the beginning of a project.
The model has problems adapting to change.
A working version of the system is not seen until late in the project's life.
Errors are discovering later (repairing problem further along the lifecycle becomes progressively more expensive).
Maintenance cost can be as much as 70% of system costs.


II. V Model
The main messages of the V-model are: “Start testing as early as possible to find defects as early as possible."
Already during the early development stages, it is possible to start your testing activities, because the sooner an error is corrected, the cheaper it is. If an error is transferred to a next stage, the cost to solve it rises exponentially. To avoid this, we must verify (test) each step taken in the development process of the application.
E.g. based on user requirements, set-up in the beginning of the development stage, the test team can immediately derive the test requirements (The test team has to be independent from the development team to avoid making the same thinking mistake again!). Then these test requirements can be used to verify whether or not the user requirements contain any errors. (Mostly logical errors: gaps in the user requirements, or wrong assumptions...) A programmer can do a perfect job in programming, but if the analysis he received contains an error, all his work may become useless. So it is very important that an error is not transferred to the next stage.

III. Spiral Model
The spiral lifecycle is similar to the Incremental approach but takes risk analysis into account. Each phase of the project is broken into planning, risk analysis, development, and evaluation steps. As each component or phase is begun risk or alternative analysis is carried out to determine the best way to deal with the current phase. In this way each phase is developed in a way that makes the risk acceptable (assuming the risk analysis is valid) to the team.
As with the incremental approach the broader picture must be understood before the development of each phase can be begun; there is no use trying to hit an ill-defined target.
The spiral life cycle requires that risk analysis be done. Other than in a broad way (i.e. should we even begin this project) I have rarely seen risk analysis used in project development. The use of this approach would require the greatest organizational change of all of the lifecycle processes. If the organization could be made to see the benefits of this approach it could be adopted. As with any change however the inclusion of new and locally unproven approaches can be viewed as a risk in itself and difficult to introduce.

IV. Rapid Application Development (RAD)
RAD refers to a development life cycle designed to give much faster development and higher quality systems than the traditional life cycle. It is designed to take advantage of powerful development software like CASE tools, prototyping tools and code generators. The key objectives of RAD are: High Speed, High Quality and Low Cost. RAD is a people-centered and incremental development approach.
Active user involvement, as well as collaboration and co-operation between all stakeholders are imperative. Testing is integrated throughout the development life cycle so that the system is tested and reviewed by both developers and users incrementally.

Advantages of RAD
With conventional methods, there is a long delay before the customer gets to see any results. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.


Why use RAD?
Bad Reasons for Using RAD
To prevent cost overruns (RAD needs a team already disciplined in cost management) To prevent runaway schedules (RAD needs a team already disciplined in time management).
Good Reasons for using RAD
To converge early toward a design acceptable to the customer and feasible for the developers To limit a project's exposure to the forces of change To save development time, possibly at the expense of economy or product quality.





Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Prototyping Model : A Systems Development Method (SDM)

The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users.

There are several steps in the Prototyping Model:

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.





Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Extreme Programming : A Software Development Approach

Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable requirements. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained'. Testing ('extreme testing') is a core aspect of Extreme Programming. Programmers are expected to write unit and functional test code first - before the application is developed. Test code is under source control along with the rest of the code. Customers are expected to be an integral part of the project team and to help develop scenarios for acceptance/black box testing. Acceptance tests are preferably automated, and are modified and rerun for each of the frequent development iterations. QA and test personnel are also required to be an integral part of the project team. Detailed requirements documentation is not used, and frequent re-scheduling, re-estimating, and re-prioritizing is expected.

XP begins with four values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen practices which XP projects should follow. Many of these practices are old, tried and tested techniques, yet often forgotten by many, including most planned processes. As well as resurrecting these techniques, XP weaves them into a synergistic whole where each one is reinforced by the others.

One of the most striking, as well as initially appealing, is its strong emphasis on testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.

On this platform XP builds an evolutionary design process that relies on re-factoring a simple base system with every iteration. All design is centered on the current iteration with no design done for anticipated future needs. The result is a design process that is disciplined, yet startling, combining discipline with adaptivity in a way that arguably makes it the most well developed of all the adaptive methodologies.



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Gray Box Testing

Test designed based on the knowledge of algorithm, internal states, architectures, or other high -level descriptions of the program behavior.

Gray box testing combines white box techniques with black box input testing. Gray box approaches usually require using several tools together. A good example of a simple gray box analysis is running a target program within a debugger and then supplying particular sets of inputs to the program. In this way, the program is exercised while the debugger is used to detect any failures or faulty behavior. Rational's Purify is a commercial tool that can provide detailed runtime analysis focused on memory use and consumption. This is particularly important for C and C++ programs (in which memory problems are rampant).


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

White Box Testing

White Box testing is done with the code perspective. The emphasis is to ensure that each line of the code is executed atleast once.

Unit Testing: Testing performed to isolate and expose faults and failures as soon as the source code is available, regardless of the external interfaces that may be required. Often times, the detailed design and requirements documents are used as a basis to compare how and what the unit is able to perform. White and black-box testing methods are combined during unit testing.

Can derive test cases to ensure:

1. all independent paths are exercised at least once.
2. all logical decisions are exercised for both true and false paths.
3. all loops are executed at their boundaries and within operational bounds.
4. all internal data structures are exercised to ensure validity.


Why White box testing when black box testing is there to test conformance to requirements
- Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.
- May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.
- Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.

"Bugs lurk in corners and congregate at boundaries"

White Box Testing Techniques

1. Basis Path Testing
a. Flow Graph Notation
b. Cyclomatic Complexity
c. Deriving Test Cases
d. Graph Matrices
2. Control Structure testing
a. Conditions Testing
b. Data Flow Testing
c. Loop Testing



Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Black Box Testing

Testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs. It is because of this that black box testing can be considered testing with respect to the specifications, no other knowledge of the program is necessary

The advantages of this type of testing include:

1. The test is unbiased because the designer and the tester are independent of each other.
2. The tester does not need knowledge of any specific programming languages.
3. The test is done from the point of view of the user, not the designer.
4. Test cases can be designed as soon as the specifications are complete.


The disadvantages of this type of testing include:

1. The test can be redundant if the software designer has already run a test case.
2. The test cases are difficult to design.
3. Testing every possible input stream is unrealistic because it would take a inordinate amount of time; therefore, many program paths will go untested.


Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php

Types of Software Testing

A. Black Box Acceptance Testing Exploratory Testing Functional Testing Integration Testing Performance Testing Load Testing Stress Testing Volume Testing Regression Testing Smoke Testing Usability Testing Sanity Testing Installation Testing System Testing UI B. White Box i. Unit Testing ii. Coverage Testing iii. Basis Path Testing 1. Flow Graph Notation 2. Cyclomatic Complexity 3. Deriving Test Cases iv. Control Structure testing. 1. Conditions Testing 2. Data Flow Testing 3. Loop Testing Software Testing Training Our Software Testing Partner Software testing institute For More Visit Site http://www.qacampus.com For discussion FORUM http://www.qacampus.com/forum/index.php

Incremental Model : The way in Software is Built

This model derives its name from the way in which the software is built. More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished. A build consists of pieces of code from various modules that interact together to provide a specific function. At each stage of the IM a new build is coded and then integrated into the structure, which is tested as a whole. Note that the product is only defined as finished when it satisfies all of its requirements. “A clever person solves a problem. A wise person avoids it. – Einstein”

Software Testing Training

Our Software Testing Partner
Software testing institute

For More Visit Site
http://www.qacampus.com

For discussion FORUM
http://www.qacampus.com/forum/index.php