QA Terms

Difference between Primary and Unique Keys

For example, in a list of American Citizens, the column with social security numbers would be a primary key whereas the first and last name columns combined with phone number would be a unique key.

Automation Challenges

- Exploitation of automation tool - Frequency of use of test case - Reusability of Automation script - Adaptability of test case for automation

How validation activities should be conducted

- Hire third party independent verification and validation - Assign internal staff members that are not involved in validation and verification activities - Independent evaluation

QA documents requirements

- List the number of defects detected as per severity level - Explain each requirement or business function in detail - Inspection reports - Configurations - Test plans and test cases - Bug reports - User manuals - Prepare separate reports for managers and users

Steps for Bug Cycle

- Once the bug is identified by the tester, it is assigned to the development manager in open status. - If the bug is a valid defect the development team will fix it and if it is not a valid defect, the defect will be ignored and marked as rejected. - The next step will be to check whether it is in scope, if it is, the bug is not part of the current release and the defects are postponed. - If the defect or bug is found earlier then the tester will assign a DUPLICATE status. - When bug is assigned to a developer to fix, it will be given a IN-PROGRESS status. - Once the defect is repaired, the status will changed to FIXED. The tester will give it a CLOSED status if it passes the final test.

QA documents

- Requirement Document - Test Metrics - Test cases and Test plan - Task distribution flow chart - Transaction Mix - User profiles - Test log - User profiles - Test incident report - Test summary report

Software Quality practices through SDLC

- Review the requirements before starting the development phase - Code Review - Write comprehensive test cases - Session based testing - Risk based testing - Prioritize bug based on usage - Form a dedicated security and performance testing team - Run a regression cycle - Perform sanity tests on production - Simulate customer accounts on production - Include software QA Test Reports

Tools used by a tester while testing

- Selenium - Firebug - OpenSTA - WinSCP - YSlow for FireBug - Web Developer toolbar for firebox

Contents in test plans and test cases

- Testing objectives - Testing scope - Testing the frame - The environment - Reason for testing - The criteria for entrance and exit - Deliverables - Risk factors

Functional testing

- Testing the features and operational behavior of a product to ensure they correspond to its specifications. - Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. AKA Black Box Testing

Automation Test Plan Strategy

- The strategy for Automation Test Plan - Preparation of Automation Test Plan - Recording the scenario - Error handler incorporation - Script enhancement by inserting check points and looping constructs - Debugging the script and fixing the issues - Rerunning the script - Reporting the result

Test Metrics

- Total test - Test run - Test passed - Test failed - Tests deferred - Test passed the first time

Quality Assurance engineer tasks

- Writing source code - Software design - Control of source code - Reviewing code - Change management - Configuration management - Integration of software - Program testing - Release management process

Application Programming Interface (API)

A programming language that allows different applications to communicate with one another. Companies often release this so that other organizations can build products that are based off of this original software. An example of an this would be Java's JDBC (Java DataBase Connectivity)

Smoke testing

A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire. Similar to Sanity Testing

Test Plan

A document that describes a project's testing plans. It includes everything from the testing scope, to approach and resources, as well as the schedule.

Cause effect graph

A graphical representation of inputs and the associated outputs effects that can be used to design test cases.

Configuration management

A process to control and document any changes made during the life of a project. Release control, Change control and Revision control are the important aspects of this.

Bug triage

A process to: - Ensure bug report completeness - Assign and analyze the bug - Assigning bug to proper bug owner - Adjust bug severity properly - Set appropriate bug priority

Testware

A subset of software, which helps in performing the testing of application. It is a term given to the combination of software application and utilities which is required for testing a software package.

Verification

All the key aspects of software developments are taken in concern like code, specifications, requirements and document plans. This is done on the basis of four things: list of issues, checklist, walkthroughs and inspection meetings.

Modification Requests (MR)

Also referred as Defect report, it is written for reporting errors/problems/suggestions in the software.

Data Driven Testing

An automation testing part, which tests the output or input values. These values are read directly from the data files. The data files may include csv files, excel files, data pools and many more. It is performed when the values are changing by the time.

Sanity Testing

Brief test of major functional elements of a piece of software to determine if its basically operational.

Test stub

Called from the software component to be tested, it is used in top down approach. It is required when we need to test the interface between modules X and Y and we have developed only module X. So we cannot just test module X but if there is any dummy module we can use that dummy module to test module X.

Test driver

Calls a component to be tested, it is used in bottom up approach. Example: Module B cannot receive or send data from module A directly, so in these case we have to transmit data from one module to another module by some external features. This external feature is referred as this term.

Software Development Life Cycle (SDLC)

Describes the process through which software is developed. There are slight differences in what different organizations call these specific steps, but they all start with development and end with application maintenance. The most popularly accepted steps are: requirement phase, the design phase, the coding phase, the testing phase, release, and maintenance.

Validation

Follows verification. Involves actual testing, and all the verification aspects are checked thoroughly in this phase.

Beta testing

Testing of a rerelease of a software product conducted by customers.

When there is not enough time for thorough testing

In order to understand where to focus testing efforts during a time crunch, the project team must perform risk analysis and speak with stakeholders. Primary considerations include, but are not limited to, understanding important functionality, especially those apparent to the end user, and making sure that the software is capable of meeting it's initial specifications.

Build

It is a number given to Installable software that is given to testing team by the development team.

Release

It is a number given to Installable software that is handed over to customer by the tester or developer.

Ad Hoc testing

It is a testing phase where the tester tries to break the system by randomly trying the system's functionality. It can include negative testing as well.

Test Case

More specific than a test plan. It describes, step-by-step, how to test the application. This document includes test steps, prerequisites, outputs, and test environment.

Alpha testing

Testing of an application when development is about to complete and released to public. Minor design changes can still be made as a result of this testing.

Retesting

Only carried out to check the defects fixes.

Regression testing

Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.

Boundary testing

Test which focus on the limit conditions of the software being tested. (Some of these tests are stress tests)

Negative testing

Testing an application with incorrect data, ensuring that errors don't occur with unexpected user behavior. For example, you would put both numbers and letters into the password field when the field only allows numbers. If an error message occurs, you know that your program has passed this particular test; it didn't let you into the system when there was unexpected behavior. Testing aimed at showing software does not work. Also known as "test to fail".

Positive Testing

Testing an application with the correct data, ensuring that everything works as it should with expected user behavior. For example, if a password only allows numbers, you would only put numbers into this field. If everything works as it should, your program has passed this particular test. Testing aimed at showing software works. Also known as "test to pass".

White box testing

Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing. Contrast with Black Box Testing.

Black box testing

Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component

Stress testing

Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how.

Branch testing

Testing in which all branches in the program source code are tested at least once.

Path testing

Testing in which all paths in the program source code are tested at least once.

Integration testing

Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

Unit testing

Testing of individual software component. AKA Component Testing

System testing

Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.

Difference between Negative and Positive Testing

Testing type 1 ensures that everything works when there is unexpected user behavior, Testing type 2 ensures that everything works when the end user does what the program expects. In other words, Testing type 1 makes sure that things that shouldn't work, don't, while Testing type 2 makes sure that things that should work, do.

Volume testing

Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.

USE case

The document that describes, the user action and system response for a particular functionality. It includes revision history, table of contents, flow of events, cover page, special requirements, pre-conditions and post-conditions.

Requirements

The features, functions, and goals of the proposed software system as defined by the client. For example, a company may want their software to "Store shopping cart data for at least 30 days." This would be an example of this term.

Quality Assurance (QA)

The role of this is to monitor the quality of the process to produce a quality of a product.

Quality Audit

The systematic and independent examination for determining the quality of activities. It allows the cross check for the planned arrangements, whether they are properly implemented or not.

Test strategy includes (similar to test plan)

This includes introduction, resource, scope and schedule for test activities, test tools, test priorities, test planning and the types of test that has to be performed.

Unique key

This is a column or group of columns that together hold unique values. A table can have more than one of these.

Primary key

This is column in a database where each row has a unique value. Each table has only one of these. No NULL values are allowed.

Software testing

This is the process of ensuring the final product and to check the functionality of the final product and to see whether the final product meets the user's requirement.

Test case sequence

This should have these four things: 1. Name 2. Description 3. Steps, description of the actions that need to be performed 4. Expected Results, describe expected outcomes so as to compare results

Specifications

This term explains how these features, functions, and goals are to be met. For example, "A user's session information will be persisted into the operational datastore upon logout or session timeout and maintained for 30 days."

Performance testing

This testing allows you to see what is happening from an architecture perspective. This testing is concerned with an application's efficiency not user load.

When do we perform functional testing?

This testing tests the code from end-to-end, making sure that all parts of the application are working -- even the parts that occur during failures. This testing should start early. Planning can be initiated during the analysis phase, and this testing should start well before development is complete. It is common to start running these tests within the QA department once a Minimum Viable Product is released.

Agile testing

This type of software testing involves the testing of the software from the customer point of view. The importance of this testing is that, unlike normal testing process, this testing does not wait for a development team to complete the coding first and then move onto testing. The coding and testing both goes simultaneously. It requires continuous customer interaction. It works on SDLC ( Systems Development Life Cycle) methodologies, it means that the task is divided into different segments and compiled at the end of the task.

CRUD testing

This type of testing is another name for Black Box testing. Stands for Create, Read, Update, and Delete

Test Driven Development

To prepare test cases before writing the actual code. Which means you will be writing code for the tests before you write code for the application.

Thread testing

Top-down testing, where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.

Traceability matrix

Used to verify the test scripts per specified requirements of test cases.

Bug release

When software or an application is handed over to the testing team knowing that the defect is present in a release. During this the priority and severity of bug is low, as bug can be removed before the final handover.

Bug leakage

When the bug is discovered by the end users or customer, and missed by the testing team to detect, while testing the software.

Load testing

When you want to see what happens to your system with a certain user load, you are doing this testing. With this form of testing, you have a better understanding of what is happening from the users' perspective. Here, the load refers to the large volume of users, messages, requests, data, etc.