Monday, June 30, 2008
Glossary - M (part 1)
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)
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)
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)
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)
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)
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.
href="http://www.crestechsoftware.com/public_traini
ng.php/">Software Testing Training
Software testing
institute
href="http://www.crestechsoftware.com/corporate_tra
ining.php">corporate training software testing
For More Visit Site
href="http://www.crestechsoftware.com/">http://www.
crestechsoftware.com/
For discussion FORUM
href="http://www.crestechsoftware.com/forum">http:/
/www.crestechsoftware.com/forum
Glossary - E (part 1)
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 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)
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)
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
Thursday, June 26, 2008
SOFTWARE PROJECT MANAGEMENT
Software Project Management is all about managing Planning, Monitoring and Execution of Project Management In general there are four successive processes that bring a system into being
Requirement Gathering
Feasibility Study
Project Planning
Project Execution
a) Requirement Gathering
The requirements process is a full system life cycle set of activities that includes:
Understanding the customers' needs and expectations
Identifying and analyzing the requirements
Defining the requirements
Clarifying and restating the requirements
Prioritizing requirements
Partitioning requirements
Tracking requirements
Managing requirements
Testing and verifying requirements
Validating requirements
Requirements analysis and management needs additional attention as a key factor in the success of systems and software development projects.
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
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
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
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 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.
href="http://www.crestechsoftware.com/public_traini
ng.php/">Software Testing Training
Software testing
institute
href="http://www.crestechsoftware.com/corporate_tra
ining.php">corporate training software testing
For More Visit Site
href="http://www.crestechsoftware.com/">http://www.
crestechsoftware.com/
For discussion FORUM
href="http://www.crestechsoftware.com/forum">http:/
/www.crestechsoftware.com/forum
Preferred Requirements Gathering Techniques - 4
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
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 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
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)
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
Friday, June 20, 2008
Corporate Trainings
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
Corporate Trainings » Crestech Curricullum » Application Web Testing
| ||||||||||
| Introduction : Intended Audience : Course Objectives : By the end of this course participants will be able to:
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
| ||||||||||
| Introduction : 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 : 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 :
Course outline :
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
| ||||||||||
| 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.
What the course is about :
| ||||||||||
Corporate Trainings » Borland Segue » Performance Concepts
| ||||||||||
| Course outline :
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
| ||||||||||
| 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:
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
| ||||||||||
| 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:
Why utilize Crestech for compatibility 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 | ||||||||||
Thursday, June 19, 2008
ISTQB Foundation Certification
- 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
- General V Model Component testing Integration Testing System Testing Acceptance Test Generic type of testing
- 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
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
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
ISTQB Advanced Certification
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
- Test Management: A Software Testing Perspective
- Test Process Fundamentals
- Test and Development Process
- Classification Of development Process
- Test Process Fundamentals
- Test Planning and Control
- Test Analysis and Design
- Test Tools
- Audit and Review Process
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
- 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
- Incident handling
- Standardized Classification for Software Anomalies According to IEEE 1044
- Risk Identification
- Risk Analysis and Evaluation
- Risk Control and Treatment
- Risk Monitoring
- Risk Oriented Test Plan Creation and Test Prioritization
- Individual Skill
- Functional Team Roles
- Social Team Roles
- Test Execution Report
- Client Sign-Off Report
- Managing Execution Report
- Metrics Definition and Selection
- Presenting Measurement Values
- Types Of Test Metrics
- Residual Defect Estimation and Reliability
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
CSTE Certification
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
- 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
- Test Management
- Giving Information
- Receiving Information
- Personal Effectiveness
- Continuing Professional Education
- Leadership
- Recognition
- Networking
- Code of Ethics
- 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
- Pre-Planning Activities
- Test Planning
- Post Planning Activities
KNOWLEDGE OF : EXECUTING THE TEST PLAN
Knowledge Domain 7 : Test Design
- Design Preparation
- Design Execution
- Execute Tests
- Compare Actual versus Expected Results
- Test Log
- Record Discrepancies
- Defect Tracking
- Testing Defect Correction
- 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
- 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
HP Quality Center (QC) Certification
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
- Creating Domain/project
- Adding users to project
- Creating Groups
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
- Review of an existing test case
- Parameters
- Building a test case structure
- Creating manual test cases
- Requirements coverage
- 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
- Reporting defects
- Searching for similar defects
- Using grid filters
- Deleting defects
- 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
HP Quick Test Professional (QTP) Certification
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
Wednesday, June 18, 2008
About Software Testing

Process of evaluation of Software application: To verify it satisfy the specified requirements With intent to find errors To Check if the system ?Fit for Purpose? Simulation of real time scenarios.
Testing is not a one-time activity—applications need to be tested throughout their lifecycle. Every version upgrade, module addition, or enhancement, as well as every implementation at a new site or increase in user load, needs to be put through comprehensive testing. The Program Doesn‘t Work Nobody would pay you to test if their program didn‘t have bugs. All programs have bugs. Any change to a program can cause new bugs, and any aspect of the program can be broken. You DON‘T ?verify that the program is working.? You FIND bugs. “If you set your mind to show that a program works correctly, you’ll be more likely to miss problems than if you want and expect the program to fail.” Complete Testing is Impossible:
1. There are a nearly infinite number of paths through any non-trivial program.
2. There are a virtually infinite set of combinations of data that you can feed the program.
You can’t test them all.
1. Therefore, your task is to find bugs --not to find all the bugs.
2. You want to find as many bugs as possible
3. Find the most serious bugs
4. Find bugs as early as possible
5. Your challenges will require judgment, trade-offs, and efficiency.
“Q: How many QA testers does it take to change a lightbulb?
A: QA testers don't change anything. They just report that it's dark.” Kerry Zallar?
Software Testing Training
Software testing institute
corporate training software testing
For More Visit Site
http://www.crestechsoftware.com/
For discussion FORUM
http://www.crestechsoftware.com/forum
Boundary Value Analysis

Large number of errors tend to occur at boundaries of the input domain.
BVA leads to selection of test cases that exercise boundary values.
BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class.
Examples:
For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1).
If input conditions specify a number of values n, test with (n-1), n and (n+1) input values.
Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size).
If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries.
Software Testing Training
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
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
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
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
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 - 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