EI's - The Experts

Greenwich park visit at London 16.5.10

2010-05-19T03:31:00.001+05:30

I went alone and discovered a new dimension of my lovable life. This visit made me realise that i am a lover of nature. I just kept walking all around.

That was a vast garden with inclined surfaces all the way which i loved most while climbing up and down.

Along side of the gardens were crowd of people, most of them were seen as a group and some people (Essentially Couples) drew themselves away from the crowd looking for having fun. Almost all of them came either with crowd or with a partner. i was the only one singling out myself.

It was an exoting fun for me to see the places and to lie down on the green grass to look at the sky. I felt as if i were at the zenith of a mountain.

In the centre of garden was a pool surrounded by trees and flowers which was a dream place to be with. I saw many elderly people being independent and walking here and there in the garden. I was terribly astonished to see them going around without anybody's nurturing.

In the middle of the garden had many children playing with themselves or with their parents. Children had been having lots of fun playing cricket, foot ball, throw ball and many more games. Even some of the children had been rolling down the slant portion of the hill-like garden.

Those two hours were promisingly unforgettable and I always want to keep going to that garden.

Compatability Testing

2008-09-26T10:26:00.001+05:30

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

Breadth Testing

2008-09-26T10:24:00.003+05:30

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

Parallel Testing

2008-09-26T10:24:00.001+05:30

In general, parallel testing involves testing multiple products or subcomponents simultaneously. A parallel test station typically shares a set of test equipment across multiple test sockets, but, in some cases, it may have a separate set of hardware for each unit under test (UUT).

Control Testing

2008-09-26T10:23:00.003+05:30

Usage: Control is a management tool to ensure that processing is performed in accordance with what management desires or intends.

Objective:
Accurate and complete data.
Authorized transactions.
Maintenance of adequate audit trail of information.
Efficient, effective and economical process.
Process meeting the needs of the user.

Test Summary Report

2008-09-26T10:23:00.001+05:30

A test summary report is a testing work product that formally summarizes the results of all testing on an endeavor.

The typical objectives of a test summary report are to:

v Summarize all of the testing that was performed since the previous test summary report.
v Enable project management and the customer to know the status of project testing.

Error handling Testing

2008-09-26T10:22:00.002+05:30

Error handling refers to the anticipation, detection, and resolution of programming, application, and communications errors. Specialized programs, called error handlers, are available for some applications. The best programs of this type forestall errors if possible, recover from them when they occur without terminating the application,

Locale

2008-09-26T10:22:00.001+05:30

Locale is a set of parameters that defines the user's language, country and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier.

Pseudolocalization

2008-09-17T09:48:00.001+05:30

Pseudolocalization is a software testing method to test internationalization aspects of software. Specifically, it brings to light potential difficulties with localization by replacing localizable text (particularly in a graphical user interface) with text that imitates the most problematic characteristics of text from a wide variety of languages.

Internationalization and localization

2008-09-17T09:47:00.000+05:30

Internationalization and localization are means of adapting computer software to different languages and regional differences. Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text.

Parser

2008-09-15T15:56:00.004+05:30

A parser is one of the components in an interpreter or compiler, which checks for correct syntax and builds a data structure (often some kind of parse tree, abstract syntax tree or other hierarchical structure) implicit in the input tokens. The parser often uses a separate lexical analyser to create tokens from the sequence of input characters. Parsers may be programmed by hand or may be semi-automatically generated (in some programming language) by a tool (such as Yacc)

Fault Injection

2008-09-15T15:56:00.003+05:30

Fault injection is a technique for improving the coverage of a test by introducing faults in order to test code paths, in particular error handling code paths, that might otherwise rarely be followed. It is often used with stress testing and is widely considered to be an important part of developing robust software

Software brittleness

2008-09-15T15:56:00.001+05:30

The term software brittleness refers to the increased difficulty in fixing older software that may appear reliable, but fails badly when presented with unusual data or altered in a seemingly minor way.

Types of prototyping

2008-09-15T15:52:00.003+05:30

Throw Away Prototyping:
Also called close ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Evolutionary prototyping:
Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built

Incremental prototyping:
The final product is built as separate prototypes At the end the separate prototypes are being merged in an overall design

Extreme prototyping:
Extreme Prototyping as a development process is used for developing especially web applications. Basically, it breaks down web development into three phases, each one based on the preceding one

Advantages of prototyping:
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers.
Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications

Software prototyping

2008-09-15T15:52:00.001+05:30

A possible activity during software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed. A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.

Proof-of-Principle Prototype (Model)

2008-09-15T15:50:00.000+05:30

This type of prototype is used to test some aspect of the intended design without attempting to exactly simulate the visual appearance, choice of materials or intended manufacturing process. Such prototypes can be used to “prove” out a potential design approach such as range of motion, mechanics, sensors, architecture, etc. These types of models are often used to identify which design options will not work, or where further development and testing is necessary..

Proof of Concept

2008-08-25T10:17:00.002+05:30

A proof of concept can refer to a partial solution that involves a relatively small number of users acting in business roles to establish whether the system satisfies some aspect of the requirements

Concept Testing

2008-08-25T10:07:00.000+05:30

Concept testing is the process of using quantitative methods and qualitative methods to evaluate consumer response to a product idea prior to the introduction of a product to the market. It can also be used to generate communication designed to alter consumer attitudes toward existing products..

Data flow analysis

2008-08-19T15:30:00.002+05:30

It is a process for collecting run-time information about data in programs without actually executing them.

Hazard Analysis

2008-08-19T15:30:00.001+05:30

A technique used to characterize the elements of risk. The result of a hazard analysis will drive the methods used for development and testing of a system.

Control flow analysis

2008-08-19T15:29:00.005+05:30

A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.

Control flow analysis

2008-08-19T15:29:00.004+05:30

A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.

Dynamic analysis

2008-08-19T15:29:00.003+05:30

The process of evaluating behavior, e.g. memory performance, CPU usage, of a system or component during execution.

Test Point Analysis (TPA)

2008-08-19T15:29:00.001+05:30

A formula based test estimation method based on function point analysis.

Status accounting

2008-08-19T15:28:00.003+05:30

An element of configuration management, consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of the approved changes.

Function Point Analysis (FPA)

2008-08-19T15:28:00.001+05:30

A method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources, and project control.

Mutation testing

2008-08-19T15:27:00.003+05:30

Mutation testing (sometimes also called mutation analysis) is a method of software testing, which involves modifying program's source code in small ways. These, so-called mutations, are based on well-defined mutation operators that either mimic typical user mistakes (such as using the wrong operator or variable name) or force the creation of valuable tests (such as driving each expression to zero).

Monkey test

2008-08-19T15:27:00.001+05:30

A monkey test is a unit test that runs with no specific test in mind. The monkey in this case is the producer of any input. For example, a monkey test can enter random strings into text boxes to ensure handling of all possible user input or provide garbage files to check for loading routines that have blind faith in their data

Stub

2008-08-19T15:26:00.003+05:30

A routine that doesn't actually do anything other than declare itself and the parameters it accepts. Stubs are used commonly as placeholders for routines that still need to be developed. The stub contains just enough code to allow it to be compiled and linked with the rest of the program.

Heuristic evaluation

2008-08-19T15:26:00.001+05:30

A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called “heuristics”).

Testware

2008-08-19T15:25:00.001+05:30

Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing.

Orthogonal array

2008-08-19T15:24:00.002+05:30

A 2-dimensional array constructed with special mathematical properties, such that choosing any two columns in the array provides every pair combination of each number in the array.

Thread Testing

2008-08-19T15:24:00.001+05:30

A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy

Wide Band Delphi

2008-08-19T15:23:00.002+05:30

An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members

Security testing

2008-08-19T15:23:00.001+05:30

The process to determine that an IS (Information System) protects data and maintains functionality as intended. The six basic security concepts that need to be covered by security testing are: confidentiality, integrity, authentication, authorisation, availability and non-repudiation.

Fault Tree Analysis

2008-08-19T15:22:00.001+05:30

A technique used to analyze the causes of faults (defects). The technique visually models how logical relationships between failures, human errors, and external events can combine to cause specific faults to disclose.

Status Accounting

2008-08-19T15:21:00.000+05:30

Difference Between Smoke and Sanity Tests

2008-07-22T17:17:00.007+05:30

Software sanity tests are commonly conflated with smoke tests. A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable. A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive (for example, the responsiveness of a web page or an input button). If the smoke test fails, it is impossible to conduct a sanity test. In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct (for example, an interest rate calculation for a financial application). If the sanity test fails, it is not reasonable to attempt more rigorous testing. Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests on a weekly build as part of their development process.

Build Verification test

2008-07-10T17:07:00.001+05:30

What is BVT?
Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly. Typically BVT process is automated. If BVT fails that build is again get assigned to developer for fix.
BVT is also called smoke testing or build acceptance testing (BAT)

Use Case

2008-07-10T12:00:00.001+05:30

A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system's declared responsibilities, showing how the primary actor's goal might be delivered or might fail.
Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal; each step in a scenario is a sub (or mini) goal of the use case. As such, each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.

State diagrams

2008-07-10T11:59:00.001+05:30

It shows the dynamic behaviour of a system. The diagram shows the various states that an object can get into and the transitions that occur between the states.
State:
The state object is a snapshot of an object at a particular point in its life. A state may have an activity describing the function being performed.
Initial State:
The initial state is the starting state of the object with reference to the behaviour that the diagram explains. Each state diagram should have only one initial state.
Final State:
Each final state is the ending state of the object with reference to the behaviour that the diagram explains. There may be multiple final states for an object.
Transition:
The transition link represents the relationship between different states of an object. The transition guard is a condition which limits the cases in which a transition can occur. The transition action is performed during the transition and cannot be interrupted.

Scripting language

2008-07-10T11:58:00.003+05:30

A scripting language, script language or extension language is a programming language that controls a software application. "Scripts" are often treated as distinct from "programs", which execute independently from any other application. At the same time they are distinct from the core code of the application, which is usually written in a different language, and by being accessible to the end user they enable the behavior of the application to be adapted to the user's needs.

Robustness testing

2008-07-10T11:58:00.001+05:30

It is defined as the degree to which a system operates correctly in the presence of exceptional inputs or stressful environmental conditions. The goal of robustness testing is to develop test cases and test environments where a system's robustness can be assessed. Many research projects worked on this topic, the two major approaches are:
Robustness testing approaches
Our robustness testing experiments of HA middleware

Scribe

2008-07-10T11:57:00.003+05:30

The person who records each defect mentioned and any suggestions for process improvement during a review meeting, on a logging form. The scribe has to ensure that the logging form is readable and understandable.

Configuration management

2008-07-10T11:57:00.001+05:30

A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

Testing Process

2008-07-10T11:56:00.004+05:30

The process for testing application blocks is outlined below. The steps listed should be performed regardless of the testing methodology that is used for the blocks.
Input
The following input is required to test an application block:
· Functional specifications
· Requirements
· Performance objectives
· Deployment scenarios
Steps
Figure shows the steps in the testing process for application blocks.
1. Create test plans. Create test plan documentation with a prioritized list of test cases and execution details.
2. Review the design. Review the design to ensure that it addresses all the deployment scenarios and the requirements. Also, ensure adherence to guidelines for performance, security, globalization, maintainability, and so on.
3. Review the implementation. Review the code to ensure that various best practices are followed.
4. Perform black box testing. Test the code from an end-user perspective by executing all the end-user scenarios.
5. Perform white box testing. Analyze the code for failure scenarios and simulate them by passing invalid data using custom test harnesses.

Database Integrity Testing

2008-07-10T11:56:00.003+05:30

Testing the methods and processes used to access and manage the data (base), to ensure access methods, processes and data rules function as expected and that during access to the database, data is not corrupted or unexpectedly deleted, updated or created.

Incremental development model

2008-07-10T11:55:00.003+05:30

A development life cycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this life cycle model, each subproject follows a ‘mini V-model’ with its own design, coding and testing phases.

Usability Testing

2008-07-10T11:55:00.001+05:30

It is defined as: "In System Testing, testing which attempts to find any human-factor problems". A better description is "testing the software from a user’s point of view". Essentially it means testing software to prove/ensure that it is 'user-friendly', as distinct from testing the functionality of the software. In practical terms it includes ergonomic considerations, screen design, standardisation etc.

Bug Life Cycle

2008-07-09T19:22:00.007+05:30

Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software.
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle.
The life cycle of the bug can be shown diagrammatically as follows:

Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.

Recovery testing

2008-07-03T16:04:00.001+05:30

Recovery testing is a system test that focuses the software to fall in a variety of ways and verifies that recovery is properly performed. If it is automatic recovery then re-initialization, check pointing mechanisms, data recovery and restart should be evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits.

Stubs and Drivers

2008-07-03T15:58:00.002+05:30

A software application is made up of a number of ‘Units’, where output of one ‘Unit’ goes as an ‘Input’ of another Unit. e.g. A ‘Sales Order Printing’ program takes a ‘Sales Order’ as an input, which is actually an output of ‘Sales Order Creation’ program.
Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use ‘Stub’ and ‘Driver.
A ‘Driver’ is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit.
A Unit may reference another Unit in its logic. A ‘Stub’ takes place of such subordinate unit during the Unit Testing. A ‘Stub’ is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a ‘Stand-in’ for the subordinate unit and provides the minimum required behavior for that unit.
Programmer needs to create such ‘Drivers’ and ‘Stubs’ for carrying out Unit Testing.
Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question.
Example - For Unit Testing of ‘Sales Order Printing’ program, a ‘Driver’ program will have the code which will create Sales Order records using hard coded data and then call ‘Sales Order Printing’ program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a ‘Stub’, which will simply return fix discount data.

Test strategy

2008-06-30T17:44:00.000+05:30

A test strategy must address the risks and present a process that can reduce those risks. The two components of Test strategy are:
Test Factor: The risk of issue that needs to be addressed as a part of the test strategy. Factors that are to be addressed in testing a specific application system will form the test factor.
Test phase: The phase of the systems development life cycle in which testing will occur.

Severity

2008-06-27T10:54:00.001+05:30

It is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior. The ’severity’ of a problem is defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool.

Priority

2008-06-27T10:53:00.000+05:30

It is associated with scheduling, and “severity” is associated with standards. “Priority” means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency).

Quality

2008-06-27T10:51:00.004+05:30

It measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions.

Audit

2008-06-27T10:51:00.003+05:30

An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify:
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]

Error Seeding

2008-06-27T10:51:00.001+05:30

The process of adding known faults wantedly in a program for monitoring the rate of detection & removal and also to estimate the total number of faults remaining in the program.

Levels of the CMM

2008-06-27T10:50:00.000+05:30

Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Projects establish their defined processes by applying the organization’s set of standard processes, tailored, if necessary, within similarly standardized guidelines.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimized
It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.

Structure of CMM

2008-06-27T10:49:00.000+05:30

Maturity Levels: A number of level continuums culminating in the discipline needed to engage in continuous process improvement and optimization.
Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.

Capability Maturity Model Integration (CMMI)

2008-06-27T10:48:00.004+05:30

It is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

LCSAJ

2008-06-27T10:48:00.003+05:30

A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements, the end of the linear sequence, and the target line to which control flow is transferred at the end of the linear sequence.

Traceability matrix

2008-06-27T10:48:00.001+05:30

It is a table that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (sometimes known as marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.

Defect

2008-06-27T10:47:00.002+05:30

A flaw in a component or system that can cause the component or system perform its required function, e.g. an incorrect statement or data definition. A defect, encountered during execution, may cause a failure of the component or system.

Concurrency testing

2008-06-27T10:47:00.001+05:30

Testing to determine how the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or system.

Business process-based testing

2008-06-27T10:45:00.003+05:30

The testing of the full business process, from the start of a transaction through to the completion. Its testing the full business process ensures that the system is really going to work.

Agile testing

2008-06-27T10:45:00.001+05:30

It is practice for a project using agile methodologies, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm.

Accessibility testing

2008-06-27T10:41:00.000+05:30

Accessibility testing for web sites is a service that can provide much more than the standard point-by-point testing techniques of most automated services

State transition testing

2008-06-27T10:40:00.002+05:30

It focuses on the testing of transitions from one state (e.g., open, closed) of an object (e.g., an account) to another state.

Structured basis testing

2008-06-27T10:40:00.001+05:30

A test case design technique in which test cases are derived from the code logic to achieve 100% branch coverage.

Test script

2008-06-27T10:39:00.002+05:30

A test script in Software Testing is a set of instructions that will be performed on the System under Test to test that the system functions as expected. These steps can be executed manually or automatically.

Scenario testing

2008-06-27T10:39:00.001+05:30

It is a software testing activity that uses scenario tests, or simply scenarios, which are based on a hypothetical story to help a person think through a complex problem or system. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario has four key characteristics. It is a story that is motivating, credible, complex, and easy to evaluate.

Test plan

2008-06-26T18:15:00.001+05:30

A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.

Error Guessing

2008-06-26T18:14:00.002+05:30

It is a software testing design technique based on the ability of the tester to draw on his past experience, knowledge and intuition to predict where bugs will be found in the software under test. Some areas to guess are: empty or null strings, zero instances, occurrences, blank or null characters in strings, Negative numbers

Entity Life Cycle Testing

2008-06-26T18:14:00.001+05:30

It is employed during System Testing where validation is done for an entity which undergone several processes’ before it reaches the current Scenario under focus. How this differs from Business Scenario Testing is that a Scenario Test Case talks about the end to end of particular cycle of the Entity, whereas Entity Life Cycle Testing talks about the entire Scenarios’ the entity Traveled/Undergone during its life, before it reaches the current Scenario.

Decision Testing

2008-06-26T18:13:00.003+05:30

Decision tables offer a simple, visual aid, and they can be applied in knowledge-based systems to perform verification processes efficiently. In software development, decision tables help test teams manage complex logic in software applications

Boundary value analysis

2008-06-26T18:13:00.001+05:30

It is a selection technique where test data are chosen to lie along "boundaries" of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters. This technique is often called stress testing.

Equivalence partitioning

2008-06-26T18:12:00.000+05:30

It is a technique with the goal:
To reduce the number of test cases to a necessary minimum.
To select the right test cases to cover all possible scenarios.
Although in rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the specification of the component's behaviour.

Black Box Design Techniques

2008-06-26T18:11:00.000+05:30

Equivalence Partitioning
Boundary Value Analysis
Algorithm Test
Decision Table Test
Syntactic Test
Semantic Test
Elementary Comparison Test
Data Cycle Test / Entity Life Cycle Test
Process Cycle Test
Program Interface Test
Real-Life Test
Error Guessing
Random Test
Idiot Proofing

White box test design techniques

2008-06-26T18:08:00.003+05:30

Line coverage
Statement coverage
Decision coverage
Condition coverage
Decision condition coverage
Multiple condition coverage
Determination condition coverage

White box test design techniques

2008-06-26T18:08:00.002+05:30

Line Coverage:
Line coverage is the weakest coverage criteria. It requires execution of every line of code at least once.

Statement Coverage:
It requires the execution of all program statements. However, all the statements in a program could be executed without revealing errors even if the program as a whole may be riddles with errors.

Decision Coverage:
For decision coverage, the programmer can use case a. and any of the other three. For decision coverage, the programmer must test once when the condition (we must take the THEN and ELSE parts) is true and once when it is false. It should cover all lines as well as all branches of the program.

Condition Coverage:
It checks each of the ways the condition can be made True or False.

Decision/Condition Coverage:
In this type of coverage both decision as well as condition coverage must be satisfied.

Prototyping

2008-06-26T18:08:00.001+05:30

Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost.

Software Development Lifecycle Models

2008-06-26T17:51:00.002+05:30

1. SEQUENTIAL MODELS
a. Pure Waterfall
b. The “V” Model

2. INCREMENTAL MODELS
a. The Staged Delivery Model
b. The Parallel Development Model

3. EVOLUTIONARY MODELS
a. The Spiral Model

4. RELATED ASPECTS OF SOFTWARE ENGINEERING
a. Component-Based Software Engineering
b. Architecture Tradeoff Analysis
c. The Iterative Development Method

Software life cycle model

2008-06-26T17:51:00.001+05:30

A software life cycle model (SLCM) is a representation of the major components of software development work and their interrelationships in a graphical framework that can be easily understood and communicated.

Recovery Testing

2008-06-26T17:50:00.002+05:30

Recovery testing is the activity of testing how well the software is able to recover from crashes, hardware failures and other similar problems. Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.
Examples of recovery testing:
While the application running, suddenly restart the computer and after that check the validness of application's data integrity;
While application receives data from the network, unplug and then in some time plug-in the cable, and analyze the application ability to continue receiving of data from that point, when network connection disappeared;
To restart the system while the browser will have definite number of sessions and after rebooting check, that it is able to recover all of them.

Negative Test and Positive Test

2008-06-26T17:50:00.001+05:30

Terms like "negative test" and "positive test" are more of a concept than a strict activity. In both instances you are dealing with an input, an action, and an output. The action acts upon the input to derive a certain output. So a test case (and thus a good test) is just one that deals with those three things. Both test cases can produce errors and, in fact, some say that the success of a test case is based upon the probability of it finding new errors in an application.

Fuzz testing

2008-06-26T17:49:00.000+05:30

Fuzz testing or fuzzing is a software testing technique used to discover coding errors and security loopholes in software, operating systems or networks by inputting massive amounts of random data, called fuzz, to the system in an attempt to make it crash. If vulnerability is found, a tool called a fuzz tester (or fuzzer), indicates potential causes. Fuzz testing was originally developed by Barton Miller at the University of Wisconsin in 1989.

Test suite

2008-06-26T17:48:00.001+05:30

A test suite, also known as a validation suite, is a collection of test cases that are intended to be used as input to a software program to show that it has some specified set of behaviors. Test suites are used to group similar test cases together. A system might e.g. have a smoke test suite that consists only of smoke tests or a test suite for some specific functionality in the system. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests

Dynamic Testing

2008-06-26T17:47:00.000+05:30

Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.

Static Testing

2008-06-26T17:45:00.004+05:30

The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Reviews, Inspections and Walkthrough are static testing Methodologies

Bug

2008-06-26T17:45:00.003+05:30

A software bug (or just "bug") is an error, flaw, mistake, "undocumented feature", failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy.

Test Scenario

2008-06-26T17:45:00.001+05:30

A set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one. The terms "test scenario" and "test case" are often used synonymously.

Test Case Format

2008-06-26T17:44:00.000+05:30

Requirement Traceability:
A cross reference to the numbers of the requirements (in the system specification) which are being verified in this test.
Purpose:
Describe the features of the software to be tested, and the particular behavior being verified by this test.
Procedure:
Describe how to carry out the test (Sometimes this will be as simple as "Enter the data in the table below at the keyboard.") Where appropriate, you may omit redundant explanations by referring to procedures you described in previous portions of the document.
Test Data:
Write the actual input data to be provided and the expected output for your actual working product. You must provide the actual input data values, not just a description. For example, "Enter a new wholesale price" is wrong. "Enter a wholesale price of $23.50" is correct. For the expected results you must provide the actual values not just a description. For example, "The updated retail price is displayed" is wrong. "The retail price of $49.99 is displayed" is correct. Be sure to include any manual calculations necessary to determine the expected outputs. (For example, if the program converts Fahrenheit temperature to Celsius, show the hand computations you did using the conversion formulas to arrive at the expected results).
Often the test data can be shown in tabular form, with a column of input items and the corresponding column of expected outputs. If the test input is contained in an external data file, you can provide the file name and have the file contents listed on a separate page.

Test Case

2008-06-26T17:43:00.003+05:30

A test case in software engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied.

Automation Testing

2008-06-26T17:43:00.001+05:30

Automation is defined as developing and executing tests that can run unattended, comparing the actual to expected results and logging status. In simple words, it is automating the manual testing process currently in use.

Ad Hoc Testing

2008-06-26T17:42:00.000+05:30

Ad hoc testing is a commonly used term for software testing performed without planning and documentation. The tests are intended to be run only once, unless a defect is discovered. Ad hoc testing is a part of exploratory testing, being the least formal of test methods. In this view, ad hoc testing has been criticized because it isn't structured, but this can also be strength: important things can be found quickly.

Smoke Testing

2008-06-26T17:41:00.001+05:30

A smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection. Next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software; some even believe that it is the most effective of all.

Functional Testing

2008-06-26T17:40:00.004+05:30

Functional Testing is testing software based on its functional requirements. It ensures that the program physically works the way it was intended and all required menu options are present. It also ensures that the program conforms to the industry standards relevant to that environment; for example, in a Windows program, pressing F1 brings up help.

Performance Testing

2008-06-26T17:40:00.003+05:30

Performance testing is performed, to determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance testing is a subset of Performance engineering, an emerging computer science practice which strives to build performance into the design and architecture of a system, prior to the onset of actual coding effort.

Beta

2008-06-26T17:40:00.001+05:30

A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.