Glossary - M (part 1)

Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.


Monkey Testing: Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.



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

Glossary - L (part 1)

Load Testing: See Performance Testing.

Localization Testing: This term refers to making software specifically designed for a specific locality.


Loop Testing: A white box testing technique that exercises program loops.




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

Glossary - I (part 1)

Independent Test Group (ITG): A group of people whose primary responsibility is software testing,


Inspection: A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).


Integration Testing: Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.


Installation Testing: Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.




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

Glossary - H (part 1)

High Order Tests: Black-box tests conducted once the software has been integrated.




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

Glossary - G (part 1)

Glass Box Testing: A synonym for White Box Testing.


Gorilla Testing: Testing one particular module,functionality heavily.


Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.


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

Glossary - F (part 1)

Functional Decomposition: A technique used during planning, analysis and design; creates a functional hierarchy for the software.


Functional Specification: A document that describes in detail the characteristics of the product with regard to its intended features.



Functional Testing: See also Black Box Testing.

Testing the features and operational behavior of a product to ensure they correspond to its specifications.

Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.


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

Glossary - E (part 1)

Emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.


Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.


End-to-End testing: Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.


Equivalence Class: A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.


Equivalence Partitioning: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.


Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of the software under test.


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

Glossary - D (part 1)

Data Dictionary: A database that contains definitions of all data items defined during analysis.


Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.


Data Driven Testing: Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.


Debugging: The process of finding and removing the causes of software failures.


Defect: Nonconformance to requirements or functional / program specification


Dependency Testing: Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.


Depth Testing: A test that exercises a feature of a product in full detail.


Dynamic Testing: Testing software through executing it. See also Static 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

Glossary - C (part 1)

CAST: Computer Aided Software Testing.

Capture/Replay Tool: A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.

CMM: The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

Cause Effect Graph: A graphical representation of inputs and the associated outputs effects which can be used to design test cases.

Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.

Code Coverage: An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

Code Inspection: A formal testing technique where the programmer reviews source code with 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 Walkthrough: A formal testing technique where source code is traced 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.

Coding: The generation of source code.

Compatibility Testing: Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.

Component: A minimal software item for which a separate specification is available.
Component Testing: See Unit Testing.

Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.

Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.

Context Driven Testing: The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.

Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.

Cyclomatic Complexity: A measure of the logical complexity of an algorithm, used in white-box 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

Glossary - B (part 1)

B

Backus-Naur Form: A metalanguage used to formally describe the syntax of a language.

Basic Block: A sequence of one or more consecutive, executable statements containing no branches.

Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.

Basis Set: The set of tests derived using basis path testing.

Baseline: The point at which some deliverable produced during the software engineering process is put under formal change control.

Benchmark Testing: Tests that use representative sets of programs and data designed to evaluate the performance of computer hardware and software in a given configuration.

Beta Testing: Testing of a rerelease of a software product conducted by customers.

Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.

Black Box Testing: Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.

Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

Boundary Testing: Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

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

Boundary Value Analysis: BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.

Branch Testing: Testing in which all branches in the program source code are tested at least once.

Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.

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

Recommended Requirements Gathering Practices

The following is a list of recommended requirements gathering practices. They are based on the author's extensive review of industry literature combined with the practical experiences of requirements analysts who have supported dozens of projects.

Understand a project vision and scope document.

Initiate a project glossary that provides definitions of words that are acceptable to and used by customers/users and the developers, and a list of acronyms to facilitate effective communication.

Evolve the real requirements via a "joint" customer/user and developer effort. Focus on product benefits (necessary requirements), not features. Address the minimum and highest priority requirements needed to meet real customer and user needs.

Document the rationale for each requirement (why it is needed).

Establish a mechanism to control changes to requirements and new requirements.

Prioritize the real requirements to determine those that should be met in the first release or product and those that can be addressed subsequently.

When the requirements are volatile (and perhaps even when they are not), consider an incremental development approach. This acknowledges that some of the requirements are "unknowable" until customers and users start using the system.

Use peer reviews and inspections of all requirements work products.

Use an industry-strength automated requirements tool.

Assign attributes to each requirement.
Provide traceability.
Maintain the history of each requirement.

Involve customers and users throughout the development effort.

Perform requirements validation and verification activities in the requirements gathering process to ensure that each requirement is testable.



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

Quality testing dashboard

Quality testing dashboard
The tool would gather information as test cases were created, as problem reports were entered, and as test cases were executed. The data would automatically be gathered into a database and online up to the second, and reporting would be available at all times.

Because the test management system fosters a structured test process, it can provide several reports and processes that would otherwise require extensive manual data collection, organization, analysis, and reporting.

Throughout the lifecycle of a project, the test management system can provide relevant status reporting to facilitate planning, test execution, results tracking, and release decisions.

1. During test development, reports are available to determine what work has been completed and what tasks remain open.

2. During execution, the test management system tracks scripts that have been executed and those that have not, the result of the execution of each script, and the requirements coverage achieved and links to defects reported due to failed test cases, to provide a complete view of the release readiness.

Reports just based on defect tracking data show incomplete status; for example, a report that there are ten open defects does not tell much, unless we know how many test cases have been executed and how much requirements coverage is achieved by these test cases. We can use test management data to generate this missing information. Test case metrics complement defect reports metrics and give a better view of product quality.

Apart from this, other reports can be generated based on different attributes like type of test, modules, etc. Test management can provide objective, accurate, real-time information, which is just what is needed for deciding on the quality of a product. This is the most important benefit of having a structured testing process and tool. Based on test reports available, the product manager can make informed decisions about the quality of the application under development.



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

Preferred Requirements Gathering Techniques - Risk Analysis 5

Risk Assessment for Projects
At least 50% of all projects (if not much more) are not successful in the sense that they do not achieve their objectives, or do not deliver the promised results, or sacrifice the predefined quality, or are not completed in the given time schedule, or use much more resources than originally planned.

There is a multitude of reasons for projects to fail. Projects often come on top of the usual work load and members of the project team belong to different departments, i.e. they have their first accountability to their line manager which often brings them into conflict with the project work. Team members have to work overtime if they want to complete their project tasks. At the end, project work is often sacrificed, and time budgets are often not sufficient.

What is mostly neglected: the occurrence of problems in project implementation increases with the complexity and length of the project.Larger and more complex projects that run over more than a year have other reasons of failure. Often these projects have permanent staff who are released from other tasks and work full time on the project, and well established budgets. However, those projects depend on a large number of external assumptions which influence their outcomes. It is impossible to clearly predict the future and the impact of various influence factors that are uncertain. Many project plans are too rigid to flexibly respond to changing needs.

Common to most projects is the lack of appropriate and transparent communication. Team members (and other stakeholders) often do not share a common understanding of the project's goals and strategies. It is important to unveil these misunderstandings and hidden agendas from the very beginning. The following tool, if applied in a project planning session helps to uncover issues that otherwise might remain undiscussed.

Explanations:

Business Level: Does the project have a strategic importance for the organization?
Length: How long is the intended implementation time?
Complexity: Does the project cover various business areas / objectives?
Technology: Is the technology to be applied well-established or is it a technology which yet has to be developed?
Number of organizational units involved: cross functional / geographical areas, etc.
Costs: estimated costs of the project
Overall risk of failure: How would you personally rank the risk that the project cannot achieve the objectives with the intended resources?



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

Preferred Requirements Gathering Techniques - 5

Effort Estimation
Effort estimation consists in predict how many hours of work and how many workers are needed to develop a project. The effort invested in a software project is probably one of the most important and most analysed variables in recent years in the process of project management. The determination of the value of this variable when initiating software projects allows us to plan adequately any forthcoming activities. As far as estimation and prediction is concerned there is still a number of unsolved problems and errors. To obtain good results it is essential to take into consideration any previous projects. Estimating the effort with a high grade of reliability is a problem which has not yet been solved and even the project manager has to deal with it since the beginning.

Cost Estimation
It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organisation . This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organisation use to arrive at an estimate. An important aspect of software projects is to know the cost, The major contributing factor is effort.

Why SCE is difficult and error prone ?

Software cost estimation requires a significant amount of effort to perform it correctly.
SCE is often done hurriedly, without an appreciation for the effort required.
You need experience at developing estimates, especially for large projects.
Human bias i.e An Estimator is likely to consider how long a certain portion of the system would take, and then to merely extrapolate this estimate to the rest of the system, ignoring the non-linear aspects of software development.

The causes of poor and inaccurate estimation

imprecise and drifting requirements
new software projects are nearly always different form the last.
software practitioners don't collect enough information about past projects.
estimates are forced to match the resources available.



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

Preferred Requirements Gathering Techniques - 4

Effort Estimation
Effort estimation consists in predict how many hours of work and how many workers are needed to develop a project. The effort invested in a software project is probably one of the most important and most analysed variables in recent years in the process of project management. The determination of the value of this variable when initiating software projects allows us to plan adequately any forthcoming activities. As far as estimation and prediction is concerned there is still a number of unsolved problems and errors. To obtain good results it is essential to take into consideration any previous projects. Estimating the effort with a high grade of reliability is a problem which has not yet been solved and even the project manager has to deal with it since the beginning.

Cost Estimation
It is the responsibility of the project manager to make accurate estimations of effort and cost. This is particularly true for projects subject to competitive bidding where a bid too high compared with competitors would result in loosing the contract or a bid too low could result in a loss to the organisation . This does not mean that internal projects are unimportant. From a project leaders estimate the management often decide whether to proceed with the project. Industry has a need for accurate estimates of effort and size at a very early stage in a project. However, when software cost estimates are done early in the software development process the estimate can be based on wrong or incomplete requirements. A software cost estimate process is the set of techniques and procedures that an organisation use to arrive at an estimate. An important aspect of software projects is to know the cost, The major contributing factor is effort.

Why SCE is difficult and error prone ?

Software cost estimation requires a significant amount of effort to perform it correctly.
SCE is often done hurriedly, without an appreciation for the effort required.
You need experience at developing estimates, especially for large projects.
Human bias i.e An Estimator is likely to consider how long a certain portion of the system would take, and then to merely extrapolate this estimate to the rest of the system, ignoring the non-linear aspects of software development.

The causes of poor and inaccurate estimation

imprecise and drifting requirements
new software projects are nearly always different form the last.
software practitioners don't collect enough information about past projects.
estimates are forced to match the resources available.



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

Preferred Requirements Gathering Techniques - 3

Interfaces Analysis.
Missing or incorrect interfaces are often a major cause of cost overruns and product failures. Identifying external interfaces early clarifies product scope, aids risk assessment, reduces product development costs, and improves customer satisfaction. The steps of identifying, simplifying, controlling, documenting, communicating, and monitoring interfaces help to reduce the risk of problems related to interfaces.

Please see attached Requirement Analysis Template

b) The feasibility Study
The Feasibility Study uses technical information and cost data to determine the economic potential and practicality (i.e. feasibility) of a project. The Feasibility Study uses techniques that help evaluate a project and/or compare it with other projects. Factors such as interest rates, operating costs, and depreciation are generally considered. The following questions are answered during feasibility study

An abstract definition of problem
Formulation of different Solution strategy
Examination of alternative solution strategy (in terms of benefits, Resource requirement, costs etc)
Cost and benefit analysis to determine the best strategy

Who uses it?
Technical Architect, Business Analyst, Configuration Manager, Development Manager, Project Manager, IT Manager, System Administrator, Test Manager, Documentation Manager, Technical Writers, System Administrator.

When is it used?
The Feasibility Study analyses potential solutions against a set of requirements, evaluates their ability to meet these objectives, describe a recommended solution, and offer a justification for this selection.

c) Project Planning
When a project is estimated to be feasible, project planning is done. Project planning consist of the following steps

Effort, Cost, Resource and Project Duration planning
Risk Analysis and mitigation plan
Project Scheduling
Staffing organization and Staffing Plan



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

Preferred Requirements Gathering Techniques - 2

Prototyping.
Prototyping is a technique for building a quick and rough version of a desired system or parts of that system. The prototype illustrates the capabilities of the system to users and designers. It serves as a communications mechanism to allow reviewers to understand interactions with the system. Prototyping sometimes gives an impression that developers are further along than is actually the case, giving users an overly optimistic impression of completion possibilities. Prototypes can be combined effectively with other approaches such as JAD and models.

Use Cases.
A use case is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques. Use cases should always be supplemented with quality attributes and other information such as interface characteristics. Many developers believe that use cases and scenarios (descriptions of sequences of events) facilitate team communication. They provide a context for the requirements by expressing sequences of events and a common language for end users and the technical team.

Be cautioned that use cases alone do not provide enough information to enable development activities. Other requirements elicitation techniques should also be used in conjunction with use cases. Use operational concepts as a simple, cost-effective way to build a consensus among stakeholders and to address two large classes of requirements errors: omitted requirements and conflicting requirements. Operational concepts identify user interface issues early, provide opportunities for early validation, and form a foundation for testing scenarios in product verification.



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

Preferred Requirements Gathering Techniques - 1

Preferred Requirements Gathering Techniques

Following are a set of recommended requirements elicitation techniques. These techniques can be used in combination. Their advantages are that they are effective in emerging the real requirements for planned development efforts.

Interviews
Interviews are used to gather information. However, the predisposition, experience, understanding, and bias of the person being interviewed influence the information obtained. The use of context-free questions by the interviewer helps avoid prejudicing the response . A context-free question is a question that does not suggest a particular response. For example, who is the client for this system? What is the real reason for wanting to solve this problem? What environment is this product likely to encounter? What kind of product precision is required?

Document Analysis
All effective requirements elicitation involves some level of document analysis such as business plans, market studies, contracts, requests for proposals, statements of work, existing guidelines, analyses of existing systems, and procedures. Improved requirements coverage results from identifying and consulting all likely sources of requirements.

Brainstorming
Brainstorming involves both idea generation and idea reduction. The goal of the former is to identify as many ideas as possible, while the latter ranks the ideas into those considered most useful by the group. Brainstorming is a powerful technique because the most creative or effective ideas often result from combining seemingly unrelated ideas. Also, this technique encourages original thinking and unusual ideas.

Requirements Workshops.
Requirements workshops are a powerful technique for eliciting requirements because they can be designed to encourage consensus concerning the requirements of a particular capability. They are best facilitated by an outside expert and are typically short (one or a few days). Other advantages are often achieved -- participant commitment to the work products and project success, teamwork, resolution of political issues, and reaching consensus on a host of topics. Benefits of requirements workshops include the following:

Workshop costs are often lower than are those for multiple interviews.
They help to give structure to the requirements capture and analysis process.
They are dynamic, interactive, and cooperative.
They involve users and cut across organizational boundaries.
They help to identify and prioritize needs and resolve contentious issues.
When properly run, they help to manage user's expectations and attitude toward change

A special category of requirements workshop is a Joint Application Development (JAD) workshop. JAD is a method for developing requirements through which customers, user representatives, and developers work together with a facilitator to produce a requirements specification that both sides support.



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

Glossary - A (part 1)

A
Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.
Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).
Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.
Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.
Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.
Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.
Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality.
Automated Testing:
Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing. The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.
Software Testing Training
Software testing institute
corporate training software testing

For More Visit Site Crestech Software
For discussion FORUM Crestech Forum

SRS Document Template - Introduction

SRS Document Template - Introduction

1.1 Purpose of this document Describes the purpose of the document, and the intended audience.

1.2 Scope of this document Describes the scope of this requirements definition effort. Introduces the requirements elicitation team, including users, customers, system engineers, and developers.

This section also details any constraints that were placed upon the requirements elicitation process, such as schedules, costs, or the software engineering environment used to develop requirements.

1.3 Overview Provides a brief overview of the product defined as a result of the requirements elicitation process.

1.4 Business Context Provides an overview of the business organization sponsoring the development of this product. This overview should include the business's mission statement and its organizational objectives or goals.





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

Corporate Trainings » Crestech Curricullum » Compatibility Testing

Compatibility Testing Course Code :CTQCT 105 Source : CresTech Course Length : 2 days

QA professionals have the industry expertise to implement a comprehensive suite of compatibility / interoperability tests for your product. We will test your software, hardware, Web site, or internal application according to industry standards with special focus on your target market. Compatibility testing is performed on your software or hardware product in our quality test lab, provisioned for an environment specific to your customers. Our QA Lab has a vast array of desktop systems, servers, laptops, operating systems, browsers and plug-ins. Our lab provisioning methods allow test matrixies to be quickly configured to maximize the range of possible testing configurations to meet your needs. In addition we have expanded the compatibility matrix to include the most popular virtualization environments. So if you are developing a virtual appliance or virtual application stack we can test it in all supported environments. Also with the increased popularity of VISTA x32 and VISTA x64 there are additional potential compatibility issues especially on the 64bit architecture. SWAT Lab form the necessary tests to ensure your product is compatible with all versions of VISTA Some typical compatibility tests include: Testing a Web site, or Web-delivered application for compatibility with a range of the leading browsers and desktop hardware platforms. Testing a peripheral with a wide range of PCs. Testing a server with different add-in cards, applications, and operating systems. Testing an application on a range of different operating systems and in combination with other applications. Verifying the compatibility and interoperability of a set of enterprise-class applications in a complex hardware and software environment designed to meet your specific business needs. In addition to the comprehensive compatibility testing provided by SWAT Lab, we also provide online access to the testing through our web-enabled portal. This enables your developers to view the results of the testing in real time and respond immediately to any discrepancies that are uncovered. SWAT Lab becomes your local QA center, helping you to meet your critical project deadlines. Why utilize Crestech for compatibility testing? We can test compatibility for both software and hardware, and we can set up almost any test environment you need, from a simple selection of a dozen browsers on the leading desktop systems to a complex enterprise server farm. We can test your website, CD, or application quickly and inexpensively. Our testing lab offers all the hardware and software needed for such testing. We are experts at testing products for compatibility with hardware and software environments. If testing every possibility strains your budget, we'll help you narrow the field to the most likely areas, so that you can maximize the return on your testing investment. We offer web-enabled reporting that ensures you always know the status of your product's testing. You will receive objective feedback you can use to insure a stable release of your product. Our testing process includes: Expert consultation on defining the compatibility issues that are significant for your product and a cost-effective matrix of platforms it should be tested against. Development of a Compatibility Test Plan specifying exactly what tests will be executed. Test execution by our staff of experienced test engineers. Using our online portal, you will have complete, real-time access to the development and execution of your tests. This allows you to view and supervise the work being done on your project during every phase from start to finish. 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

Corporate Trainings » Crestech Curricullum » Test Management

Test Management Course Code : CTQTM 104 Source : CresTech Course Length : 3 days

This Three-day course focuses on Training on Test management Concepts, Testing Specialization, testing phases and plans, test Bed Automation, test metrices like Web, Security and Database Testing , Automation Management, process and Framework Design. Intended Audience: This training is being designed to meet the requirements of Team leads, Test Managers, Project Managers and all other senior management staff who are all in the designation of Project Managers and above. Also, the experienced software testers, test/QA engineers, test/QA managers and project managers who will be planning, managing, and executing the testing of Software Applications. Course outline : Introduction to Testing Test Strategies Requirements Management and Test UML and Testing Testing Types/Phases Creating & Maintaining a Test Bed Code Testing Testing in Distributed Environments Web Testing Test Automation Test Metrics The Master Test Plan Test Completion Review Testing and Lifecycles Introducing a Test Culture Further Information References Information on where to research on 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

Corporate Trainings » Borland Segue » Performance Concepts

Performance Concepts Course Code : CTQPC 103 Source : CresTech Course Length : 2 days

Course outline : Overview of Performance Testing Performance Testing Life Cycle Types of Performance Testing Performance Goals Effort Estimation for Performance Testing Simulating Realistic scenarios for Load Testing Web Sites Client Side emulations while conducting load tests Administering Load Tests Performance Monitoring and Tuning Locating Performance Bottlenecks Performance Testing Tools Sample Performance Test Plan Sample Performance Report 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

Corporate Trainings » Crestech Curricullum » XML Testing

XML Testing Course Code : CTQXT 102 Source : CresTech Course Length : 2 days

This course is designed to provide software testing and quality assurance professionals with the knowledge necessary to plan, design and execute tests for applications that involve XML technologies. It covers the basics of XML, its implementation to support application programming interfaces and specifically web services, ways to validate the format and the contents of XML messages and methods to test XML-based applications. Prerequisites: The principal vocabulary of XML technologies Fundamentals of XML files, Document Type model and XML schema Definition and applications of Web Services Basics of the Web Services Description Language (WSDL) XML validation: the meaning of Well-formed and Valid XML Common tools for XML validation Methods of testing XML-based applications Where to look for additional resources What the course is about : Scope: what do we cover in depth, what do we glance over, what we do not cover Goals: what will we learn Administrative items XML Basics Markup languages XML vs HTML XML elements and attributes Document Type model XML schema Web Services Web services as a ubiquitous form of the application programming Interface Offering and consuming web services Web Services Definition language (WSDL) Testing XML Validating XML Well-formed XML Valid XML XML validators Testing XML-based applications Accessing applications through XML web services Analyzing results Where the defects lurk, or where XML break 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

Corporate Trainings » Crestech Curricullum » Security Testing

Security Testing Course Code : CTQST 101 Source : CresTech Course Length : 2 days

Introduction : Over recent times there have been a number of highly public attacks on well-known corporations via their web applications. While many companies focus intensely on security of their networks, through facilities such as firewalls and encryption technology, they often leave their deployed web application quite vulnerable to attack through their choice of architecture, design and implementation. Frequently web applications are prone to simple exploits which could be easily prevented through better input validation Course Prerequisites : This course assumes an understanding of Web applications vulnerabilities. SANS SEC519/SEC419 course (Web Application Security Workshop) or equivalent is highly recommended. Intended Audience : This course is appropriate for testing, QA, and software development practitioners who are responsible for developing and executing test strategies and plans for functional and non-functional security requirements. This course requires an ability to understand security risk patterns used by attackers. Participants should be comfortable reviewing code as part of their testing activities. Course Objectives : After taking course u should be able to : This course provides an overview of testing concerns relating to security of web applications. The course covers a number of facets of web security, including : Planning security testing Risk avoidance and containment Network and system security Server-side application vulnerabilities and test techniques Client-side application vulnerabilities and test techniques Course outline : Introduction What is computer Security? Test types and their effect on application security Computer Security Concepts Test strategy and planning Test design for application security testing A survey of testing tools (IBM Watch-fire and HP App-Scan) and resources 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

Corporate Trainings » Crestech Curricullum » Application Web Testing

Application Web Testing Course Code : CTQWT 100 Source : CresTech Course Length : 2 days

Introduction : This training course provides a comprehensive overview of methods, techniques and tools that can be applied to testing of e-business systems. In addition the course will focus on management and team skills that ensure that testing is conducted effectively and efficiently. The course is focused on practical approaches to testing, based on the experience of the presenters? skills in consulting and test outsourcing, as well as adopting leading trends and ideas emerging from Europe and the USA . During the course extensive case-studies and real-world experiences will be presented. Intended Audience : This course addresses e-business issues of concern to project, development and testing managers as well as testing practitioners. Managers will learn new approaches for identifying and managing risks, preparing test strategies and identify test activities, and for planning and monitoring the testing process. Test practitioners will learn new techniques and tools for conducting e-business tests. Course Objectives : By the end of this course participants will be able to: Develop a strategy and plans for testing e-business applications Define comprehensive and cost-effective tests to dig out bugs in your systems Identify bugs and ensure that bugs are being resolved appropriately Utilise automated test tools to reduce costs involved in testing Manage your testing activities and test team Course outline Web Application Testing Foundation How Web Application Testing is Different from Traditional Testing INTERNET/Networking Basics for Testers Basic Types of Tests and What to Look For Browser Basics and How to test within the browser Discuss installation testing Discuss configuration and compatibility testing Discuss what to look for in functionality and UI 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

Corporate Trainings

CresTech has emerged among the top Software Quality Management Training Centers in the country.

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. Our superlative selection of courses has been specifically designed to help industry professionals’ work with today's best-of-breed automation tools. Students receive individualized mentoring from our first-class, certified trainers to fully maximize the benefits of each course.

Our Training Centers across INDIA

Training at CresTech takes place at our expanded training facilities in Noida, Gurgaon and Jaipur (shortly coming up with more in other regions of INDIA) that have been professionally designed to provide students with an unsurpassed learning experience. Our classrooms are fully equipped with the latest state-of-the-art equipment, such as high-speed workstations, flat panel monitors, high-speed Internet connections, in addition to ergonomic seating and high-resolution LCD projectors.

Advance Level Courses

CresTech has developed advanced level courses to complement the basic courses authored by IBM Rational, HP Mercury, Borland Segue and Compuware. We provide the complete insight to these Tools along with the industry experience to the participants equipping them with the expertise to handle the critical stages in the projects.

Open Source Power

CresTech stands distinct among the QA community with its initiative towards introducing the Open Source training programs across automation and performance testing spheres. We have set up the line of trainers who are the industry experts and hold the credit of delivering the best solutions through the non-commercial testing tools.

Onsite Training

Additionally, CresTech will conduct any of our training courses at your site, reducing travel expenses for your employees and they shall be able to get the training at ease and saving their time.

Training Space Rental

When you are looking for highly professional and technologically outfitted training facilities, take a look at CresTech state-of-the-art training rooms. Our training facility is available for rental as a low-cost, long-term leasing solution for your training needs.

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

HP Quick Test Professional (QTP) Certification

Overview

QTP

Duration: 3 Days (24 Hours)

Course Objectives

This course teaches you to:
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.



Crestech Software Systems

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

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

HP Quality Center (QC) Certification

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

Crestech Software Systems

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

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

CSTE Certification

KNOWLEDGE OF: THE TEST ENVIRONMENT

Knowledge Domain 1 : Test Principles and Concepts

• Definition of Test Specifications
• Testing Techniques
• Testing Methods
• Independent Testing
• Commercial off the self Software
• Testing Code Development Under Outside Contract
• Test Quality
• Testing Life Cycle
• Vocabulary

Knowledge Domain 2 : The Tester’s Role in Software Development and Acquisition

• The Development and Acquisition Process
  • Process Knowledge
  • Roles/Responsibilities
• Quality Principles
• V Testing Concepts
• Testing During and After Development Acquisition
  • Verification
  • Validation
  • Test Approaches
• Quality Attributes

Knowledge Domain 3 : Test Management

• Test Management
• Giving Information
• Receiving Information
• Personal Effectiveness
• Continuing Professional Education
• Leadership
• Recognition
• Networking
• Code of Ethics

Knowledge Domain 4 : Build the Test Environment

• Test Standard
• Test Environment Components
• Test Tools
• Quality Assurance/Quality Control
• Building the Test Environment Work Processes
• Adapting the Test Environment to Different Technologies

KNOWLEDGE OF : TEST PLANNING

Knowledge Domain 5 : Risk Analysis

• Risk Identification
• Managing Risks

Knowledge Domain 6 : Test Planning Process

• Pre-Planning Activities
• Test Planning
• Post Planning Activities

KNOWLEDGE OF : EXECUTING THE TEST PLAN

Knowledge Domain 7 : Test Design

• Design Preparation
• Design Execution

Knowledge Domain 8 : Performing Tests

• Execute Tests
• Compare Actual versus Expected Results
• Test Log
• Record Discrepancies

Knowledge Domain 9 : Defect Tracking and Correction

• Defect Tracking
• Testing Defect Correction

Knowledge Domain 10 : Acceptance Testing

• Concepts of Accepting Testing
• Roles and Responsibilities
• Acceptance Test Process

KNOWLEDGE OF : TEST ANALYSIS AND REPORTING

Knowledge Domain 11 : Status of Testing

• Test Completion Criteria
• Test Metrics
• Management by Fact

Knowledge Domain 12 : Test Reporting

• Reporting Tools
• Test Report Standards
• Statistical Analysis

Crestech Software Systems

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

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

ISTQB Advanced Certification

Overview

Objective of the training would be train the participants on Test-Management Skills. It involves knowledge Testing Process, Test Policy and Handbook, Test Plan and Test Control, Test Deviation Management, Risk based Test Management, Test Metrics and Test Staff qualification skills. This course is also in-line with ISTQB Advance Level Test manager Certification helping you prepare for certification exam

Duration: 2 Days Intended Audience

• Software Tester having basic Testing skills
• Test-Lead who need to Lead Testing Teams Technically
• Test Manager, who need to manage QA processes and Test-Teams

Software Test Management an Introduction

• Test Management: A Software Testing Perspective
• Test Process Fundamentals
• Test and Development Process
• Classification Of development Process

Test Process

• Test Process Fundamentals
• Test Planning and Control
• Test Analysis and Design
• Test Tools
• Audit and Review Process

Testing in Software Life-Cycle

Test and Development Process
The General V model
W-Model
Extreme Programming
Rapid Application Development

TestPolicy and Handbook

Quality Policy and Test Policy
Test Policy and Handbook

Test Plan

• General Test Plan Structure
• The Level Test Plan
• IEEE 829 , Standard for Test documentation
• Definition Of Test Strategy
• Test Effort Estimation
• Organization Of Test Team and Test Levels
• Test Planning as an Iterative Process Accompanying Development

Test Control

• Initiating the Test Tasks
• Monitoring the Test Progress
• Reacting to Test Result
• Reacting to Changed Circumstances
• Evaluating Test Completion
• General Techniques and Approaches
• Improving the Software Development Process
• Evaluating the Test Processes
• Audit and Assessments

Test Deviation Management

• Incident handling
• Standardized Classification for Software Anomalies According to IEEE 1044

Risk Based Test Management

• Risk Identification
• Risk Analysis and Evaluation
• Risk Control and Treatment
• Risk Monitoring
• Risk Oriented Test Plan Creation and Test Prioritization

Staff Qualification Skill

• Individual Skill
• Functional Team Roles
• Social Team Roles

Test Reporting

• Test Execution Report
• Client Sign-Off Report
• Managing Execution Report

Test Metrics

• Metrics Definition and Selection
• Presenting Measurement Values
• Types Of Test Metrics
• Residual Defect Estimation and Reliability

QA Best Practices

Testing Process Practices
Test Strategy Definition
Team Handling
Effective Estimation
Effective Metrics UtilizationTest Reports


Crestech Software Systems

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

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

ISTQB Foundation Certification

Session 1:

• The Basics of Software Testing: Error and bug terminology Testing terms The Psychology of testing General Principal of testing Test Planning and Control Test Analysis and design Test Implementation and execution Evaluation of Test Exit criterion Test closure activities

Session 2:

• General V Model Component testing Integration Testing System Testing Acceptance Test Generic type of testing

Session 3:

• Static Testing Examination of Test groups Roles and Responsibilities in a Test Group Reviews and Type of Reviews Static Analysis: Basics Static Analysis: Data Flow analysis Static Analysis: Control Flow analysis

Session 4:
Dynamic Analysis

• Black Box Testing Techniques Equivalence Class Partitioning Boundary value analysis State Transition testing Cause Effect graphing Use Case Testing
• White Box Analysis Statement coverage Branch Coverage Test of condition Path Coverage

Session 5:
Test Tool

• Type of test tools
• Tools for test management and control
• Tools for test specifications
• Tools for static and dynamic testing
• Tools for Non Functional tests
• Selection and Introduction of test tools
  Session 6:
  Test Management
  
  • Test Organization
  • Test Planning
  • Cost and Economy Aspect
  • Definition of Test Strategy
  • Test Activity Management
  • Incident Management
  • Requirements for Configuration management
• 
  
• 
  
• 
  
• Crestech Software Systems
  
  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

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


Software testing institute


corporate training software testing



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

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

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


Software testing institute


corporate training software testing



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

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

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


Software testing institute


corporate training software testing



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

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

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


Software testing institute


corporate training software testing



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

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

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


Software testing institute


corporate training software testing



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

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

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


Software testing institute


corporate training software testing



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

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

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


Software testing institute


corporate training software testing



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

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