Test oracle

ISTQB Glossary definition In Simple English, Field Notes For Test oracle
ISTQB Glossary definition

"A source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark), other software, a user manual, or an individual’s specialized knowledge, but should not be the code."  

[After Adrion]

In Simple English,

In short, Where you get your 'expected results' defined form is what a test oracle is.

QA Practitioner's Field Notes

• Please note here that the test oracle is only a source for the expected result and not the process of getting it.
• More often even experienced test analyst and QA practitioners confuse the test oracle with other similar systems and roles.
• AS IS system is another way to talk about the test oracle and AS IS system is still not the test oracle
• In terms of roles, An SME, BA, user champion or Single point of contact, functional lead all are roles that could help you with figuring out what the expected result is, still they are not the explicit test oracle though they may play that role for some time. The problem is that invariably and quite beyond their control when these roles try to be the test oracle they deviate from expected result based on what their role calls for as their interests in the project.
• The test oracle is ideally a role that is independent of the other roles.
• This independence helps them be very objective and just present what the expected result functionally would be independent of the system it is implemented in.
• When technology re platforming, modernizing and upgrade projects are taken up, the need for a separate test oracle arises as most of the functional outcome is clearly defined. In fact the objective of most of these projects is to provide at the very least the same functional response as the previous system.
• Interaction with the test oracle is better done at the early stages of the project and particularly the test execution phase.

For Example:

Example 1:

Say a company is upgrading it's leave management system from a 7 year old standalone web based software that they were using to the latest version of the same brand of software. This being a off the shelf product would have evolved and grown in the 7 years to do a lot more that the earlier version. It may even not do some of the functional scenarios that the older version did.

In this situation the upgrade team has 2 options, to document every functional transaction that was handled by the old system and establish the same in the new system or they can take these functional transactions from old system and redesign these to use the new features of the latest software and work with the limitations of the new system.

Only in the first case would a test oracle make sense. in the second case the test oracle would not be of much need or use.

So, what do you think?

Was the explanation clear enough?

Did you understand?

Did you get what you were searching for?

If you have any more questions, comments or compliments please let me know as your comments below.

Test strategy

ISTQB Glossary  definition 

"A high-level document defining the test levels to be performed and the testing within those levels for a programme (one or more projects)."

In Simple English,

It is a published agreement to keep all parties involved informed about the strategy defined to test a project. This involves documenting the level of testing targeted, the kinds of testing agreed on as needed and the approach agreed upon.

Field Notes 

1. This document is often confused with test plan document.

2. Depending on the way on organization defines it, test strategy sometimes will involve several items that are generally considered as part of a formal test plan.

3. Some companies altogether combine both the test strategy and test plan documents and have a single artifact. They call it Master test document or test strategy or test plan.
remember, as rose by any other name is still a rose.

4.This however is different from test policy. While Test Policy is defined and maintained at the organization level, test strategy is at a project or program level. (Program here does not mean a piece of code. It means a very big Project which in turn has several projects under it)

Test suite

ISTQB Glossary definition In Simple English, flield notes for "Test suite"

ISTQB Glossary definition

A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.

In Simple English,

it's a group of related test cases that makes sense to be tested together to achive a test objective at hand.

QA Practitioner’s notes for ream work experience in this field

• Test suites are often dynamically created to match the the task at hand.
• Most times test suites are used as work allocation mechanism within a huge team. 
• Though it's easy to use it to manage work allocation its not the best way to achive test objectives. 
• Though by definition each steps' result should feed to the next step as input it is not a hard requirement. 
• Most often test suites are created based on the release being tested.   

Now, Let’s see one or more example cases to understand this even better:

Say you are asked to test an web application like gmail. One way to form the test suites would be to have one per function like, send mail, receive mail and manage drafts.

Feedback
So, what do you think?
Was the explanation clear enough?
Did you understand?
Did you get what you were searching for?

If you have any more questions, comments or compliments please let me know as your comments below.

TQM

See Total Quality Management

transcendent-based quality

A view of quality, wherein quality cannot be precisely defined, but we know it when we see it, or are aware of its absence when it is missing. Quality depends on the perception and affective feelings of an individual or group of individuals towards a product. [After Garvin] See also manufacturing-based quality, product-based quality, user-based quality, value-based quality.

transactional analysis

The analysis of transactions between people and within people’s minds; a transaction is defined as a stimulus plus a response. Transactions take place between people and between the ego states (personality segments) within one person’s mind.

traceability

The ability to identify related items in documentation and software, such as requirements with associated tests. See also horizontal traceability, vertical traceability.

TPG

See Test Process Group.

TPI Next

A continuous business-driven framework for test process improvement that describes the key elements of an effective and efficient test process.

Total Quality Management

An organization-wide management approach centered on quality, based on the participation of all members of the organization and aiming at long- term success through customer satisfaction, and benefits to all members of the organization and to society. Total Quality Management consists of planning, organizing, directing, control, and assurance. [After ISO 8402]

top-down testing

An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested. See also integration testing.

TMMi

See Test Maturity Model integration.

time behavior

See performance .

three point estimation

A test estimation method using estimated values for the “best case”, “worst case”, and “most likely case” of the m er being estimated, to define the degree of certainty associated with the resultant estimate.

thread testing

An approach to 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.

testware

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, d bases, environment, and any additional software or utilities used in testing. [After Fewster and Graham]

testing

The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

tester

A skilled professional who is involved in the testing of a component or system.

testable requirement

A requirements that is stated in terms that permit establishment of test designs (and subsequently test cases) and execution of tests to determine whether the requirement has been met. [After IEEE 610]

test type

A group of test activities aimed at testing a component or system focused on a specific test objective, i.e. functional test, usability test, regression test etc. A test type may take place on one or more test levels or test phases. [After TMap]