Severity

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

Test script

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

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

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

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

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

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

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

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

• 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

1. Line coverage
2. Statement coverage
3. Decision coverage
4. Condition coverage
5. Decision condition coverage
6. Multiple condition coverage
7. Determination condition coverage

White box test design techniques

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Alpha

The alpha build of the software is the build delivered to the software testers, which is persons different from the software engineers, but usually internal to the organization or community that develops the software. In a rush to market, more and more companies are engaging external customers or value-chain partners in their alpha testing phase. This allows more extensive usability testing during the alpha phase.
In the first phase of testing, developers generally test the software using white box techniques. Additional validation is then performed using black box or grey box techniques, by another dedicated testing team, sometimes concurrently. Moving to black box testing inside the organization is known as alpha release

Pre-alpha

Sometimes a build known as pre-alpha is issued, before the release of an alpha or beta. In contrast to alpha and beta versions, the pre-alpha is not "feature complete". When it is used, it refers to all activities performed during the software project prior to software testing. These activities can include requirements analysis, software design, software development and unit testing.

Regression testing

Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists. Test department coders develop code test scenarios and exercises that will test new units of code after they have been written.

Integration testing

Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.

Unit testing

Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing is often automated but it can also be done manually. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits. This testing mode is a component of Extreme Programming (XP), a pragmatic method of software development that takes a meticulous approach to building a product by means of continual testing and revision.

User Acceptance Testing or System Validation

In this type of testing, the developed product is handed over to the user/paid testers in order to test it in real time scenario. The product is validated to find out if it works according to the system specifications and satisfies all the user requirements. As the user/paid testers use the software, it may happen that bugs that are yet undiscovered, come up, which are communicated to the developers to be fixed. This helps in improvement of the final product.

Functional Validation/Testing

This type of testing is carried out in order to find if the system meets the functional requirements. In this type of testing, the system is validated for its functional behavior. Functional testing does not deal with internal coding of the project, in stead, it checks if the system behaves as per the expectations.

Integration Validation/Testing

Integration testing is carried out in order to find out if different (two or more) units/modules co-ordinate properly. This test helps in finding out if there is any defect in the interface between different modules.

Buddy Checks

This is the simplest type of review activity used to find out bugs in a work product during the verification. In buddy check, one person goes through the documents prepared by another person in order to find out if that person has made mistake(s) i.e. to find out bugs which the author couldn’t find previously. The activities involved in Verification process are: Requirement Specification verification, Functional design verification, internal/system design verification and code verification (these phases can also subdivided further). Each activity makes it sure that the product is developed right way and every requirement; every specification, design code etc. is verified!

Code Validation/Testing

Developers as well as testers do the code validation. Unit Code Validation or Unit Testing is a type of testing, which the developers conduct in order to find out any bug in the code unit/module developed by them. Code testing other than Unit Testing can be done by testers or developers

Walkthrough

Walkthrough can be considered same as inspection without formal preparation (of any presentation or documentations). During the walkthrough meeting, the presenter/author introduces the material to all the participants in order to make them familiar with it. Even when the walkthroughs can help in finding potential bugs, they are used for knowledge sharing or communication purpose.

Inspection

Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents and work product during various phases of the product development life cycle. The work product and related documents are presented in front of the inspection team, the member of which carry different interpretations of the presentation. The bugs that are detected during the inspection are communicated to the next level in order to take care of them

Validation

Validation is a process of finding out if the product being built is right? i.e. whatever the software product is being developed; it should do what the user expects it to do. The software product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is done during or at the end of the development process in order to determine whether the product satisfies specified requirements.

Verification

The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e. Verification is a process that makes it sure that the software product is developed the right way. The software should confirm to its predefined specifications, as the product development goes through different stages, an analysis is done to ensure that all required specifications are met.

Black Box and White Box Testing

Black Box Testing is testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs.

Glass Box Testing is a technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs.

Testing Tips

Black Box Testing is testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs.

Glass Box Testing is a technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs.