Showing posts with label Training material. Show all posts
Showing posts with label Training material. Show all posts

SDLC : Software Development Life Cycle

SDLC : Software Development Life Cycle

The following are the actives of the SDLC

1.       System engineering and modeling

2.       Software require analysis

3.       Systems analysis and design

4.       Code generation

5.       Testing

6.       Development and Maintenance

System Engineering and Modeling: In this process we have to identify the projects requirement and main features proposed in the application. Here the development team visits the customer and their system. They investigate the need for possible software automation in the given system. By the end of the investigation study. The team writes a document that holds the specifications for the customer system.

Software Requirement Analysis: In this software requirements analysis, firstly analysis the requirement for the proposed system. To understand the nature of the program to built, the system engineer must understand the information domain for the software, as well as required functions, performance and the interfacing. From the available information the system engineer develops a list of the actors use cases and system level requirement for the project. With the help of key user the list of use case and requirement is reviewed. Refined and updated in an iterative fashion until the user is satisfied that it represents the essence of the proposed system.

Systems analysis and design: The design is the process of designing exactly how the specifications are to be implemented. It defines specifically how the software is to be written including an object model with properties and method for each object, the client/server technology, the number of tiers needed for the package architecture and a detailed database design. Analysis and design are very important in the whole development cycle. Any glitch in the design could be very expensive to solve in the later stage of the software development.

Code generation: The design must be translated into a machine readable form. The code generation step performs this task. The development phase involves the actual coding of the entire application. If design is performed in a detailed manner. Code generation can be accomplished with out much complicated. Programming tools like compilers, interpreters like c, c++, and java are used for coding .with respect to the type of application. The right programming language is chosen.

Testing: After the coding. The program testing begins. There are different methods are there to detect the error in coding .different method are already available. Some companies are developed they own testing tools

Development and Maintenance: The development and maintenance is a staged roll out of the new application, this involves installation and initial training and may involve hardware and network upgrades. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could be happen because of some unexpected input values into the system. In addition, the changes in the system could be directly affecting the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

Usability Engineering - Usability Testing

Usability Engineering - Usability Testing

Usability Engineering, an empirical science has quite a simple definition. It studies the human interaction and cognitive behavior of an individual with respect to performing as task. It could be as simple as a driving a vehicle or using a product. Users interaction in performing a task should be in sync with the workflow of the product. Usability Engineering as a science helps in achieving this goal.

Usability for a Product

A Product should be usable. It means that people can use a product easily and efficiently to accomplish their own tasks. A product, which is usable, enables workers to concentrate on their tasks and to do real work, rather than on the tools they use to perform their tasks.

A usable product has the following characteristics:

• It’s easy to learn
• Efficient to use
• Provides quick recovery from errors
• Easy to remember
• Enjoyable to use
• Visually pleasing

Usability applies to every aspect of a product with which a person interacts (hardware, software, menus, icons, messages, documentation, training, and on-line help). Every design and development decision made throughout the product cycle has an impact on that product’s usability.

As customers depend more and more on software to get their jobs done and become more critical consumers, usability can be the critical factor that ensures that products will be used.

Usability Engineering Techniques

Usability engineering involves a variety of techniques that can provide important information about how customers work with your product. Different techniques are used at different stages of a product’s development.

For example, as processes are being engineered and requirements are being developed, observations and interviews may be the techniques of choice. Later in the development cycle, as the “look and feel” of a product is being designed, benchmarking, prototyping and participatory design may be useful techniques. Once a design has been determined, usability testing may be used more appropriately. Usability is an iterative process, just like software development. The usability process works best if it is done in partnership with product development.

Some usability techniques include

1. User and task observations – observing users at their jobs, identifying their typical work tasks and procedures, analyzing their work processes, and understanding people in the context of their work.

2. Interviews, focus groups and questionnaires – meeting with users, finding out about their preferences, experiences and needs.

3. Benchmarking and competitive analysis – evaluating the usability of similar products in the marketplace.

4. Participatory design - participating in design and bringing the user’s perspective to the early stages of development.

5. Paper prototyping – including users early in the development process through prototypes prepared on paper before coding begins.

6. Creation of guidelines - helping to assure consistency in design through development of standards and guidelines.

7. Heuristic evaluations - evaluating software against accepted usability principles and making recommendations to enhance usability.

8. Usability testing - observing users performing real tasks with the application, recording what they do, analyzing the results and recommending appropriate changes.

Benefits of Usability: Usability engineering provides important benefits in terms of cost, product quality and customer satisfaction. It can improve development productivity through more efficient design and fewer code revisions. It can help to eliminate over-design by emphasizing the functionality required to meet the needs of real users. Design problems can be detected earlier in the development process, saving both time and money. It can provide further cost savings through reduced support costs, reduced training requirements and greater user productivity. A usable product means more satisfied customers and a better reputation for the product and for the organization that developed it.

Today many leading corporations are incorporating usability engineering into their product development cycles. For them, usability is becoming a competitive advantage.

Usability Test of Your Product

A usability test is a formal evaluation process that has as its goal improvement of the usability of the product being tested. It differs from a quality assurance or quality test, which has as its goal assessing whether the product works according to specifications. It differs from a customer assurance test, a pilot test and a beta test because the usability test ensures the collection of systematic, recorded, quantifiable data and observation of behaviors.

A usability test has these five characteristics:

• Each test has specific goals and concerns that are tested.

• The participants represent real users (6 to 12 participants are typical).

• The participants do real tasks.

• The participants are observed and recorded.

• The data is analyzed, problems diagnosed and recommendations made.

A usability test consists of these activities

• Planning the test, developing participant’s profiles, identifying participants from user pool, creating test materials, writing task scenarios and determining usability criteria and measures.

• Preparing the test location, pilot testing materials and procedures.

• Introducing the participant to the situation, the product and the procedure.

• Running of the task-based test, where participants are asked to complete a series of tasks that address the specific goals and concerns being tested.

• Participants are asked to “think aloud” (articulate their thoughts, feeling and actions). This data and the recorded video images, helps target areas that are confusing, unclear or misleading during the analysis stage.

• Debriefing the participant to get final thoughts, subjective feelings about the product and suggestions for improvement.

• Analyzing the data, making recommendations and documenting findings

Testing Your Project with end users that represent the end users of the final system. During the test, we can able to identify those areas of the system that will cause users to make errors, become less productive or be unable to complete a required activity.

The deliverable from a usability test is a report that details the problems encountered by the participants and recommendations for chance based on known human factors, cognitive and behavioral principles and recognized best practices.

Best Practices in Automated Testing

Best Practices in Automated Testing

The Case for Automated Testing

Today, rigorous application testing is a critical part of virtually all software development projects. As more organizations develop mission – critical systems to support their business activities, the need is greatly increased for testing methods that support business objectives. It is necessary to ensure that these systems are reliable, built according to specification and have the ability to support business processes. Many internal and external factors are forcing organizations to ensure a high level of software quality and reliability.

Why Automate the Testing Process?

In the past, most software tests were performed using manual methods. This required a large staff of test personnel to perform expensive and time-consuming manual test procedures. Owing to the size and complexity of today’s advanced software applications, manual testing is no longer a viable option for most testing situations.

Using Testing Effectively: By definition, testing is a repetitive activity. The methods that are employed to carry out testing (manual or automated) remain repetitious throughout the development life cycle. Automation of testing processes allows machines to complete the tedious, repetitive work while human personnel perform other tasks. Automation eliminates the required “think time” or “read time” necessary for the manual interpretation of when or where to click the mouse. An automated test executes the next operation in the test hierarchy at machine speed, allowing test to be completed many times faster than the fastest individual. Automated test also perform load/stress testing very effectively.

Reducing Testing Costs

The cost of performing manual testing is prohibitive when compared to automated methods. The reason is that computers can execute instructions many times faster and with fewer errors than individuals. Many automated testing tools can replicate the activity of a large number of users (and their associated transactions) using a single computer. Therefore, load/stress testing using automated methods requires only a fraction of the computer hardware that would be necessary to complete a manual test.

Replicating testing across different platforms

Automation allows the testing organization to perform consistent and repeatable test. When applications need to be deployed across different hardware or software platforms, standard or benchmark tests can be created and repeated on target platforms to ensure that new platforms operate consistently.

Greater Application Coverage

The productivity gains delivered by automated testing allow and encourage organization to test more often and more completely. Greater application test coverage also reduces the risk if exposing users to malfunctioning or non-compliant software.

Results Reporting

Full-featured automated testing systems also produce convenient test reporting and analysis. These reports provide a standardized measure of test status and results, thus allowing more accurate interpretation of testing outcomes. Manual methods require the user to self-document test procedures and test results

Understanding the Testing Process

The introduction of automated testing into the business environment involves far more than buying and installing an automated testing tool.

Typical Testing Steps: Most software testing projects can be divided into general steps

Test Planning: This step determines like ‘which’ and ‘when’.
Test Design: This step determines how the tests should be built the level of quality.
Test Environment Preparation: Technical environment is established during this step.
Test Construction: At this step, test scripts are generated and test cases are developed.
Test Execution: This step is where the test scripts are executed according to the test plans.
Test evaluation: After the test is executed, the test results are compared to the expected results and evaluations can be made about the quality of an application.

Identifying Tests Requiring Automation

Most, but not all, types of tests can be automated. Certain types of tests like user comprehension tests test that run only once and tests that require constant human intervention are usually not worth the investment incurred to automate. The following are examples of criteria that can be used to identify tests that are prime candidates for automation.

High path frequency – Automated testing can be used to verify the performance of application paths that are used with a high degree of frequency when the software is running in full production. Examples include: creating customer records.

Critical Business Processes – Mission-critical processes are prime candidates for automated testing. Examples include: financial month-end closings, production planning, sales order entry and other core activities. Any application with a high –degree of risk associated with a failure is a good candidate for test automation.

Repetitive Testing – If a testing procedure can be reused many times, it is also a prime candidate for automation

Applications with a Long Life Span – If an application is planned to be in production for a long period of time, the greater the benefits are from automation.

Task Automation and Test Set-Up

In performing software testing, there are many tasks that need to be performed before or after the actual test. For example, if a test needs to be executed to create sales orders against current inventory, goods need to be in inventory. The tasks associated with placing items in inventory can be automated so that the test can run repeatedly. Additionally, highly repetitive tasks not associated with testing can be automated utilizing the same approach.

Who Should Be Testing?

There is no clear consensus in the testing community about which group within an organization should be responsible for performing the testing function. It depends on the situation prevailing in the organization.

Life Cycle of Testing Process


Life Cycle of Testing Process

Once the project is confirmed to start, the phases of the development of project can be divided into the following phases:

·         Software requirements phase.

·         Software Design

·         Implementation

·         Testing

·         Maintenance

In the whole development process, testing consumes highest amount of time. But most of the developers oversee that and testing phase is generally neglected. As a consequence, erroneous software is released. The testing team should be involved right from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle are:

1. Requirements stage
2. Test Plan
3. Test Design.
4. Design Reviews
5. Code Reviews
6. Test Cases preparation.
7. Test Execution
8. Test Reports.
9. Bugs Reporting
10. Reworking on patches.
11. Release to production.

Requirements Stage

Normally in many companies, developers itself take part in the requirements stage. Especially for product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements should be documented properly for further use and this document is called “Software Requirements Specifications”.

Test Plan

Without a good plan, no work is a success. A successful work always contains a good plan. The testing process of software should also require good plan. Test plan document is the most important document that brings in a process – oriented approach. A test plan document should be prepared after the requirements of the project are confirmed. The test plan document must consist of the following information:

• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design

Test Design is done based on the requirements of the project. Test has to be designed based on whether manual or automated testing is done. For automation testing, the different paths for testing are to be identified first. An end to end checklist has to be prepared covering all the features of the project.

The test design is represented pictographically. The test design involves various stages. These stages can be summarized as follows:

• The different modules of the software are identified first.
• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So the test design assesses the quality of testing process.

Test Cases Preparation

Test cases should be prepared based on the following scenarios:

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

Design Reviews

The software design is done in systematical manner or using the UML language. The tester can do the reviews over the design and can suggest the ideas and the modifications needed.

Code Reviews

Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a tester may find out.

Test Execution and Bugs Reporting

Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures occur, the bugs should be reported to the developer immediately to get the required workaround.

The test reports should be documented properly and the bugs have to be reported to the developer after the testing is completed.

Release to Production: Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done.
The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.

Automated Testing Advantages, Disadvantages and Guidelines

Automated Testing Advantages, Disadvantages and Guidelines

Advantages of Automated Testing

Introduction:” Automated Testing" is automating the manual testing process currently in use. This requires that a formalized "manual testing process", currently exists in the company or organization.

Automation is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks.

Minimally, such a process includes:

Detailed test cases, including predictable "expected results", which have been developed from Business Functional Specifications and Design documentation

A standalone Test Environment, including a Test Database that is restorable to a known constant, such that the test cases are able to be repeated each time there are modifications made to the application.

The following types of testing can be automated

Functional - testing that operations perform as expected.

Regression - testing that the behavior of the system has not changed.

Exception or Negative - forcing error conditions in the system.

Stress - determining the absolute capacities of the application and operational infrastructure.

Performance - providing assurance that the performance of the system will be adequate for both batch runs and online transactions in relation to business projections and requirements.

Load - determining the points at which the capacity and performance of the system become degraded to the situation that hardware or software upgrades would be required.

Benefits of Automated Testing

Reliable: Tests perform precisely the same operations each time they are run, thereby eliminating human error

Repeatable: You can test how the software reacts under repeated execution of the same operations.
Programmable: You can program sophisticated tests that bring out hidden information from the application.

Comprehensive: You can build a suite of tests that covers every feature in your application.

Reusable: You can reuse tests on different versions of an application, even if the user interface changes.

Better Quality Software: Because you can run more tests in less time with fewer resources

Fast: Automated Tools run tests significantly faster than human users.

Cost Reduction: As the number of resources for regression test are reduced.

Choosing the right tools for the job and targeting the right areas of the organization to deploy them can only realize these benefits. The right areas where the automation fit must be chosen.

The following areas must be automated first

1. Highly redundant tasks or scenarios
2. Repetitive tasks that are boring or tend to cause human error
3. Well-developed and well-understood use cases or scenarios first
4. Relatively stable areas of the application over volatile ones must be automated.

Automated testers must follow the following guidelines to get the benefits of automation:

·         • Concise: As simple as possible and no simpler.

·         • Self-Checking: Test reports its own results; needs no human interpretation.

·         • Repeatable: Test can be run many times in a row without human intervention.

·         • Robust: Test produces same result now and forever. Tests are not affected by changes in the external environment.

·         • Sufficient: Tests verify all the requirements of the software being tested.

·         • Necessary: Everything in each test contributes to the specification of desired behavior.

·         • Clear: Every statement is easy to understand.

·         • Efficient: Tests run in a reasonable amount of time.

·         • Specific: Each test failure points to a specific piece of broken functionality; unit test failures provide "defect triangulation".

·         • Independent: Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.

·         • Maintainable: Tests should be easy to understand and modify and extend.

·         • Traceable: To and from the code it tests and to and from the requirements.

Disadvantages of Automation Testing

Though the automation testing has many advantages, it has its own disadvantages too. Some of the disadvantages are:

• Proficiency is required to write the automation test scripts.
• Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences.
• Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be rerecorded or replaced by a new test script.
• Maintenance of test data files is difficult, if the test script tests more screens.

Some of the above disadvantages often cause damage to the benefit gained from the automated scripts. Though the automation testing has pros and corns, it is adapted widely all over the world.

Introduction to CMM

Introduction to CMM

Quality software should reasonably be bug-free, delivered on time and within budget. It should meet the given requirements and/or expectations, and should be maintainable.

In order to produce error free and high quality software certain standards need to be followed.

Quality Standards

ISO 9001: 2000 is Quality Management System Certification. To achieve this, an organization must satisfy ISO 9001: 2000 clauses (clauses 1 - 8).

Six Sigma is a process improvement methodology focused on reduction in variation of the processes around the mean. Its objective is to make the process defect free.

SEI CMM is a defacto standard for assessing and improving processes related to software development, developed by the software community in 1986 with leadership from SEI. It’s a software specific process maturity model. It provides guidance for measuring software process maturity and helps process improvement programs.

SEI CMM is organized into 5 maturity levels:

·         Initial

·         Repeatable 

·         Defined 

·         Manageable 

·         Optimizing

1)Initial

The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.

2) Repeatable:

Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

3) Defined:

The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

4) Managed:

Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

5) Optimizing:

Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Comparison of CMM and ISO

Features

 

CMM

 

ISO 9000

 

Assess process maturity

 

Yes

 

No

 

Emphasizes continuous improvement

 

Yes

 

No

 

Provides self-assessments

 

Yes

 

Yes

 

Applicable to projects

 

Software only

 

No

 

Applicable to programs

 

Software only

 

Yes

 

Applicable to organizations (operations)

 

Software only

 

Yes

 

Requires a quality management system

 

Yes

 

Yes

 

Conclusion:

CMM ensures that the process followed for developing a product produces error free product. A company which is process driven is more successful than the company which is people driven. Hence a company needs to have a good process for software development for it to be successful.

 

 

 

 

 

 

 

 

 

 

 

 

 

Software Testing Best Practices

Software Testing Best Practices
"We need to adopt the best practices in the industry." While it appears as an obvious conclusion, the most glaring lack of it's presence continues to astound the study team. 
The best practices can be classified into the following types: 

a) Basic Best Practices 
b) Foundational Best Practices 
c) Incremental Best Practices 
Basic Best Practices
They are the training wheels you need to get started and when you take them off, it is evident that you know how to ride. But remember, that you take them off does not mean you forget how to ride. This is an important difference, which all too often is forgotten in software. "Yeah, we used to write functional specification but we don't do that anymore" means you forget to ride, not that you didn't need to do that step anymore. The Basic practices have been around for a long time.
Functional Specifications 
The testers use this to write down test cases from a black box testing perspective. The advantage of having a functional specification is that the test generation activity could happen in parallel with the development of the code. This is ideal from several dimensions. It gains parallelism in execution, removing a serious serialization bottleneck in the development process. 
Reviews and Inspection
It is argued that software inspection can easily provide a ten times gain in the process of debugging software. Not much needs to be said about this, since it is a fairly well known and understood practice. 
Formal Entry and Exit Criteria
The idea is that every process step, be it inspection, functional test, or software design, has a precise entry and precise exit criteria. These are defined by the development process and are watched by management to gate the movement from one stage to another. 
Functional Test – Variations
Most functional tests are written as black box tests working off a functional specification. The number of test cases that are generated usually are variations on the input space coupled with visiting the output conditions. 
Multi-platform Testing
When code is ported from one platform to another, modifications are sometimes done for performance purposes. The net result is that testing on multiple platforms has become a necessity for most products. Therefore techniques to do this better, both in development and testing, are essential.
Internal Betas
Techniques to best conduct such an internal Beta test are essential for us to obtain good coverage and efficiently use internal resources. This best practice has everything to do with Beta programs though on a smaller scale to best leverage it and reduce cost and expense of an external Beta. 
Automated Test Execution
The goal of automated test execution is that we minimize the amount of manual work involved in test execution and gain higher coverage with a larger number of test cases. The automated test execution has a significant impact on both the tools sets for test execution and also the way tests are designed.
Nightly’ Builds
The concept of a nightly build has been in vogue for a long time. While every build is not necessarily done every day, the concept captures frequent builds from changes that are being promoted into the change control system. 
Foundational Best Practices
The Foundational practices are the rock in the soil that protects your efforts against harshness of nature, be it a redesign of your architecture or enhancements to sustain unforeseen growth. They need to be put down thoughtfully and will make the difference in the long haul, whether you build a ranch or a skyscraper. Their value added is significant and established by a few leaders in the industry. Unlike the Basics, they are probably not as well known and therefore need implementation help. While there may be no textbooks on them yet, there is plenty of documentation to dig up.
User Scenarios
One of the viable methods of testing is to develop user scenarios that exercise the functionality of the applications. This best practice should capture methods of recording user scenarios and developing test cases based on them. In addition it could discuss potential diagnosis methods when a specific failure scenario occurs. 
Usability Testing
Usability testing needs to not only assess how usable a product is but also provide feedback on methods to improve the user experience and thereby gain a positive quality image. The best practice for usability testing should also have knowledge about advances in the area of Human Computer Interface. 
In-Process ODC Feedback Loops
Orthogonal defect classification is a measurement method that uses the defect stream to provide precise measurability into the product and the process. Given the measurement, a variety of analysis techniques have been developed to assist management and decision-making on a range of software engineering activities.
Multi-Release ODC/Butterfly
The technology of multi-release ODC/Butterfly analysis allows a product manager to make strategic development decisions so as to optimize development costs, time to market, and quality issues by recognizing customer trends, usage patterns, and product performance.
“Requirements” for Test Planning
One of the roles of software testing is to ensure that the product meets the requirements of the clientele. Capturing the requirements therefore becomes an essential part not only to help develop but to create test plans that can be used to gauge if the developed product is likely to meet customer needs.
Automated Test Generation
Almost 30% of the testing task can be the writing of test cases. To first order of approximation, this is a completely manual exercise and a prime candidate for savings through automation. 
Incremental Best Practices
The Incremental practices provide specific advantages in special conditions. While they may not provide broad gains across the board of testing, they are more specialized. These are the right angle drills -- when you need it, there's nothing else that can get between narrow studs and drill a hole perfectly square. At the same time, if there was just one drill you were going to buy, it may not be your first choice. Not all practices are widely known or greatly documented. But they all possess the strength that are powerful when judiciously applied.

Automated Testing Best Practices

Automated Testing Best Practices
Why Automate the Testing Process?
In the past, most software tests were performed using manual methods. This required a large staff of test personnel to perform expensive and time-consuming manual test procedures. Owing to the size and complexity of today’s advanced software applications, manual testing is no longer a viable option for most testing situations. 
Using Testing Effectively
By definition, testing is a repetitive activity. The methods that are employed to carry out testing (manual or automated) remain repetitious throughout the development life cycle. Automation of testing processes allows machines to complete the tedious, repetitive work while human personnel perform other tasks. Automation eliminates the required “think time” or “read time” necessary for the manual interpretation of when or where to click the mouse. An automated test executes the next operation in the test hierarchy at machine speed, allowing test to be completed many times faster than the fastest individual. Automated test also perform load/stress testing very effectively.
Reducing Testing Costs
The cost of performing manual testing is prohibitive when compared to automated methods. The reason is that computers can execute instructions many times faster and with fewer errors than individuals. Many automated testing tools can replicate the activity of a large number of users (and their associated transactions) using a single computer. Therefore, load/stress testing using automated methods requires only a fraction of the computer hardware that would be necessary to complete a manual test. 
Replicating testing across different platforms
Automation allows the testing organization to perform consistent and repeatable test. When applications need to be deployed across different hardware or software platforms, standard or benchmark tests can be created and repeated on target platforms to ensure that new platforms operate consistently. 
Greater Application Coverage
The productivity gains delivered by automated testing allow and encourage organization to test more often and more completely. Greater application test coverage also reduces the risk if exposing users to malfunctioning or non-compliant software. 
Results Reporting
Full-featured automated testing systems also produce convenient test reporting and analysis. These reports provide a standardized measure of test status and results, thus allowing more accurate interpretation of testing outcomes. Manual methods require the user to self-document test procedures and test results.


Understanding the Testing Process
The introduction of automated testing into the business environment involves far more than buying and installing an automated testing tool. 

Typical Testing Steps: Most software testing projects can be divided into general steps 

Test Planning: This step determines like ‘which’ and ‘when’. 
Test Design: This step determines how the tests should be built the level of quality. 
Test Environment Preparation: Technical environment is established during this step. 
Test Construction: At this step, test scripts are generated and test cases are developed. 
Test Execution: This step is where the test scripts are executed according to the test plans. 
Test evaluation: After the test is executed, the test results are compared to the expected results and evaluations can be made about the quality of an application. 
Identifying Tests Requiring Automation
Most, but not all, types of tests can be automated. Certain types of tests like user comprehension tests test that run only once and tests that require constant human intervention are usually not worth the investment incurred to automate. The following are examples of criteria that can be used to identify tests that are prime candidates for automation. 

High path frequency – Automated testing can be used to verify the performance of application paths that are used with a high degree of frequency when the software is running in full production. Examples include: creating customer records. 

Critical Business Processes – Mission-critical processes are prime candidates for automated testing. Examples include: financial month-end closings, production planning, sales order entry and other core activities. Any application with a high –degree of risk associated with a failure is a good candidate for test automation. 

Repetitive Testing – If a testing procedure can be reused many times, it is also a prime candidate for automation. 

Applications with a Long Life Span – If an application is planned to be in production for a long period of time, the greater the benefits are from automation. 
Task Automation and Test Set-Up
In performing software testing, there are many tasks that need to be performed before or after the actual test. For example, if a test needs to be executed to create sales orders against current inventory, goods need to be in inventory. The tasks associated with placing items in inventory can be automated so that the test can run repeatedly. Additionally, highly repetitive tasks not associated with testing can be automated utilizing the same approach.
Who Should Be Testing?
There is no clear consensus in the testing community about which group within an organization should be responsible for performing the testing function. It depends on the situation prevailing in the organization



Technical Terms Used in Testing World

Audit: An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. 

Acceptance testing: Testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. 

Alpha Testing: Acceptance testing performed by the customer in a controlled environment at the developer's site. The software is used by the customer in a setting approximating the target environment with the developer observing and recording errors and usage problems. 

Assertion Testing: A dynamic analysis technique which inserts assertions about the relationship between program variables into the program code. The truth of the assertions is determined as the program executes. 

Boundary Value: (1) A data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component. (2) A value which lies at, or just inside or just outside a specified range of valid input and output values. 

Boundary Value Analysis: A selection technique in which test data are chosen to lie along "boundaries" of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters. 

Branch Coverage: A test coverage criteria which requires that for each decision point each possible branch be executed at least once. 

Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. 

Beta Testing: Acceptance testing performed by the customer in a live application of the software, at one or more end user sites, in an environment not controlled by the developer. 

Boundary Value Testing: A testing technique using input values at, just below, and just above, the defined limits of an input domain; and with input values causing outputs to be at, just below, and just above, the defined limits of an output domain. 

Branch Testing: Testing technique to satisfy coverage criteria which require that for each decision point, each possible branch [outcome] is executed at least once. Contrast with testing, path; testing, statement. See: branch coverage. 

Compatibility Testing: The process of determining the ability of two or more systems to exchange information. In a situation where the developed software replaces an already working program, an investigation should be conducted to assess possible comparability problems between the new software and other programs or systems. 

Cause Effect Graph: A Boolean graph linking causes and effects. The graph is actually a digital-logic circuit (a combinatorial logic network) using a simpler notation than standard electronics notation. 

Cause Effect Graphing: This is a Test data selection technique. The input and output domains are partitioned into classes and analysis is performed to determine which input classes cause which effect. A minimal set of inputs is chosen which will cover the entire effect set. It is a systematic method of generating test cases representing combinations of conditions. 

Code Inspection: A manual [formal] testing [error detection] technique where the programmer reads source code, statement by statement, to a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards. 

Code Review: A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. 

Code Walkthrough: A manual testing [error detection] technique where program [source code] logic [structure] is traced manually [mentally] by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions. 

Coverage Analysis: Determining and assessing measures associated with the invocation of program structural elements to determine the adequacy of a test run. Coverage analysis is useful when attempting to execute each statement, branch, path, or iterative structure in a program. 

Crash: The sudden and complete failure of a computer system or component. 

Criticality: The degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system. 

Cyclomatic Complexity: The number of independent paths through a program. The cyclomatic complexity of a program is equivalent to the number of decision statements plus 1. 

Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. 

Error Guessing: This is a Test data selection technique. The selection criterion is to pick values that seem likely to cause errors. 

Error Seeding: The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. Contrast with mutation analysis. 

Exception: An event that causes suspension of normal program execution. Types include addressing exception, data exception, operation exception, overflow exception, protection exception, and underflow exception. 

Exhaustive Testing: Executing the program with all possible combinations of values for program variables. This type of testing is feasible only for small, simple programs. 

Failure: The inability of a system or component to perform its required functions within specified performance requirements. 

Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. 

Functional Testing: Testing that ignores the internal mechanism or structure of a system or component and focuses on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements and corresponding predicted results. 

Integration Testing: An orderly progression of testing in which software elements, hardware elements, or both are combined and tested, to evaluate their interactions, until the entire system has been integrated. 

Usability Testing: Tests designed to evaluate the machine/user interface. 

Validation: Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. 

Validation, Verification and Testing: Used as an entity to define a procedure of review, analysis, and testing throughout the software life cycle to discover errors, determine functionality, and ensure the production of quality software. 

Volume Testing: Testing designed to challenge a system's ability to manage the maximum amount of data over a period of time. This type of testing also evaluates a system's ability to handle overload situations in an orderly fashion


Risk Analysis

Risk Analysis 
Risk Analysis is one of the important concepts in Software Product/Project Life Cycle. Risk analysis is broadly defined to include risk assessment, risk characterization, risk communication, risk management, and policy relating to risk. Risk Assessment is also called as Security risk analysis. 
Technical Definitions: 
Risk Analysis: A risk analysis involves identifying the most probable threats to an organization and analyzing the related vulnerabilities of the organization to these threats. 
Risk Assessment: A risk assessment involves evaluating existing physical and environmental security and controls, and assessing their adequacy relative to the potential threats of the organization. 
Business Impact Analysis: A business impact analysis involves identifying the critical business functions within the organization and determining the impact of not performing the business function beyond the maximum acceptable outage. Types of criteria that can be used to evaluate the impact include: customer service, internal operations, legal/statutory and financial. 
Risks for a software product can be categorized into various types. Some of them are: 
Product Size Risks: 
The following risk item issues identify some generic risks associated with product size: 
1. Estimated size of the product and confidence in estimated size?  
2. Estimated size of product?  
3. Size of database created or used by the product?  
4. Number of users of the product?  
5. Number of projected changes to the requirements for the product? 
Risk will be high, when a large deviation occurs between expected values and the previous experience. All the expected information must be compared to previous experience for analysis of risk. 
Business Impact Risks: 
The following risk item issues identify some generic risks associated with business impact: 
1. Affect of this product on company revenue?  
2. Reasonableness of delivery deadline?  
3. Number of customers who will use this product and the consistency of their needs relative to the product?  
4. Number of other products/systems with which this product must be interoperable?  
5. Amount and quality of product documentation that must be produced and delivered to the customer?  
6. Costs associated with late delivery or a defective product? 

Customer-Related Risks: 
Different Customers have different needs. Customers have different personalities. Some customers accept what is delivered and some others complain about the quality of the product. In some other cases, customers may have very good association with the product and the producer and some other customers may not know. A bad customer represents a significant threat to the project plan and a substantial risk for the project manager. 
The following risk item checklist identifies generic risks associated with different customers: 
1. Have you worked with the customer in the past?  
2. Does the customer have a solid idea of what is required?  
3. Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?  
4. Is the customer willing to participate in reviews?  
5. Is the customer technically sophisticated in the product area?  
6. Does the customer understand the software engineering process? 
Process Risks: 
If the software engineering process is ill-defined or if analysis, design and testing are not conducted in a planned fashion, then risks are high for the product. 
1. Has your organization developed a written description of the software process to be used on this project?  
2. Are the team members following the software process as it is documented?  
3. Are the third party coders following a specific software process and is there any procedure for tracking the performance of them?  
4. Are formal technical reviews are done regularly at both development and testing teams?  
5. Are the results of each formal technical review documented, including defects found and resources used?  
6. Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases?  
7. Is a mechanism used for controlling changes to customer requirements that impact the software? 
Technical Issues: 
1. Are specific methods used for software analysis?  
2. Are specific conventions for code documentation defined and used?  
3. Are any specific methods used for test case design?  
4. Are software tools used to support planning and tracking activities?  
5. Are configuration management software tools used to control and track change activity throughout the software process?  
6. Are tools used to create software prototypes?  
7. Are software tools used to support the testing process?  
8. Are software tools used to support the production and management of documentation?  
9. Are quality metrics collected for all software projects?  
10. Are productivity metrics collected for all software projects? 
Technology Risk: 
1. Is the technology to be built new to your organization?  
2. Does the software interface with new hardware configurations?  
3. Does the software to be built interface with a database system whose function and performance have not been proven in this application area?  
4. Is a specialized user interface demanded by product requirements?  
5. Do requirements demand the use of new analysis, design or testing methods?  
6. Do requirements put excessive performance constraints on the product
Development Environment Risks: 
1. Is a software project and process management tool available?  
2. Are tools for analysis and design available?  
3. Do analysis and design tools deliver methods that are appropriate for the product to be built?  
4. Are compilers or code generators available and appropriate for the product to be built?  
5. Are testing tools available and appropriate for the product to be built?  
6. Are software configuration