Framework: An abstraction in which software providing generic functionality can be selectively changed by additional user written code, thus providing application specific software. A software framework is a universal, reusable software platform used to develop applications, products and solutions.
Harness: A collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. It has two main parts: the test execution engine and the test script repository.
Test harnesses allow for the automation of tests. They can call functions with supplied parameters and print out and compare the results to the desired value. The test harness is a hook to the developed code, which can be tested using an automation framework.
Keyword/action-based testing: A software testing methodology suitable for both manual and automated testing. This method separates the documentation of test cases -including the data to use- from the prescription of the way the test cases are executed. As a result it separates the test creation process into two distinct stages: a design and development stage, and an execution stage.
Test Module: In Action Based Testing a test module is a container for a well-defined flow of test cases. Test modules consist of test objectives and action lines. The test objectives outline the scope of the test module into individual verbal statements defining what is to be tested by the test cases contained in the module. The tests in the test module are defined by a series of “action lines”, often further organized in one or more test cases. Every action line consists of a keyword that defines the action, and arguments that define the data for the action, including input values and expected results.
Test Case: A set of conditions or variables under which a tester will determine whether an application or software system is working correctly. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.
Test Script: The instructions in a test program. It defines the actions and pass/fail criteria. For example, if the action is “to enter a valid account number,” the expected result is that the data are accepted. Entering an invalid number should yield a particular error message.
Load testing: The process of putting demand on a system or device and measuring its response. Load testing is performed to determine a system’s behavior under both normal and anticipated peak load conditions. It helps to identify the maximum operating capacity of an application as well as any bottlenecks and determine which element is causing degradation.
ROI: A performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. It is one way of considering profits in relation to capital invested. In software, this can measure the beneficial effects of QA, testing and other investments on the final product’s quality and sales.
Reusability: A segment of source code can be used again to add new functionalities with slight or no modification. Reusable modules and classes reduce implementation time, increase the likelihood that prior testing and use has eliminated bugs and localizes code modifications when a change in implementation is required.
Visibility: The ability to see what is truly happening to the entire or any part of the project at any point in time under any circumstance in any level of detail. Visibility is not only the collection and storage of metrics and indicators but a way to analyze, visualize and communicate them. The ability to monitor and assess the system is the key first part of managing or directing anything.
Maintainability: The ease with which a product can be maintained in order to: isolate defects or their cause, correct defects or their cause, meet new requirements make future maintenance easier, or cope with a changed environment.
Scalability: The ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources are added.
Sources: Wikipedia, PC Magazine
Code Current
The ability to install, implement, and successfully get the latest version of software to work.
Source: LogiGear
Continuous Delivery
The ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
Source: Continuous Delivery
DevOps
(Term derived from the words “Development” and “Operations”) A software development practice, grounded in agile philosophy, that emphasizes close collaboration between an organization’s software developers and other IT professionals, while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and organizational workflow in which building, testing, and releasing software happens rapidly, frequently, and more reliably.
Source: Wikipedia
Oracle Applications Testing
A comprehensive, integrated testing solution for Web applications, Web Services, packaged Oracle Applications and Oracle Databases.
Source: Wikipedia
Enterprise Resource Planning (ERP)
The core processes that are needed to run a company: finance, HR, manufacturing, supply chain, services, procurement, and others. ERP integrates these processes into a single system.
Source: SAP
Test Folders
The Tests node is the repository for your test modules. For purposes of organizing your tests, this folder can be further organized into subfolders to hold your test modules. This is helpful for projects with a multitude of test modules, and in which commonalities exist amongst groups of modules.
Source: TestArchitect
Test Modules
The test module is the work file in which you create tests. Its essence is to contain a group of test cases with a similar, and if possible narrowly-defined, scope. A TestArchitect project is typically comprised of multiple test modules, which are often grouped into folders and subfolders of the project. Test modules should be designed to run independently from each other, while the test cases within a test module can have dependencies among themselves. Within a test module, all actions, especially the family of check actions, should directly relate to the defined scope of the test module. This way it is easy to keep abreast of large tests, and functional changes to a system under test need only have a localized effect on the test suite – that is, only the relevant test modules are affected. The test module contains objectives and test cases. The objectives are an auxiliary device to further refine the scope of the test module. They allow a reader to understand why test cases are designed the way they are, and give an auditor a quick insight into the correctness and, more importantly, completeness of a test.
Source: TestArchitect
User-Defined Fields
In addition to its contents, every project item in TestArchitect has various metadata associated with it. Such fields as Name, Assigned user, Description and Creation date can be viewed by opening a given item and clicking on its Information tab. In addition to these predefined fields, TestArchitect allows you to create your own custom fields for project items, to use in accordance with your requirements. A user-defined field enables you to store additional information for project items. Furthermore, user-defined fields can be useful in integrating your project with external tools, such as HP Quality Center. You can often enhance the utility of an external tool with custom fields that allow more data to be exchanged between the tool and your project items.
Source:TestArchitect
