These SQL interview questions are very simple and mainly were used for interviewing software testers who is involved (or going to involve) in database SQL testing or grey box testing.
Q. How do you select all records from the table?
Select * from table_name;
Q. What is a join?
Join is a process of retrieve pieces of data from different sets (tables) and returns them to the user or program as one “joined” collection of data.
Q. How do you add record to a table?
A. INSERT into table_name VALUES (‘ALEX’, 33 , ‘M’);
Q. How do you add a column to a table?
ALTER TABLE Department ADD (AGE, NUMBER);
Q. How do you change value of the field?
A. UPDATE EMP_table set number = 200 where item_munber = ‘CD’;
update name_table set status = 'enable' where phone = '4161112222';
update SERVICE_table set REQUEST_DATE = to_date ('2006-03-04 09:29', 'yyyy-mm-dd hh24:MM') where phone = '4161112222';
Q. What does COMMIT do?
A. Saving all changes made by DML statements
Q. What is a primary key?
A. The column (columns) that has completely unique data throughout the table is known as the primary key field.
Q. What are foreign keys?
A. Foreign key field is a field that links one table to another table’s primary or foreign key.
Q. What is the main role of a primary key in a table?
A. The main role of a primary key in a data table is to maintain the internal integrity of a data table.
Q. Can a table have more than one foreign key defined?
A table can have any number of foreign keys defined. It can have only one primary key defined.
Q. List all the possible values that can be stored in a BOOLEAN data field.
There are only two values that can be stored in a BOOLEAN data field: -1(true) and 0(false).
Q. What is the highest value that can be stored in a BYTE data field?
A. The highest value that can be stored in a BYTE field is 255. or from -128 to 127. Byte is a set of Bits that represent a single character. Usually there are 8 Bits in a Byte, sometimes more, depending on how the measurement is being made. Each Char requires one byte of memory and can have a value from 0 to 255 (or 0 to 11111111 in binary).
Q. Describe how NULLs work in SQL?
The NULL is how SQL handles missing values. Arithmetic operation with NULL in SQL will return a NULL.
Q. What is Normalization?
A. The process of table design is called normalization.
Q. What is Trigger?
A. Trigger will execute a block of procedural code against the database when a table event occurs. A2. A trigger defines a set of actions that are performed in response to an insert, update, or delete operation on a specified table. When such an SQL operation is executed, in this case the trigger has been activated.
Q. Can one select a random collection of rows from a table?
Yes. Using SAMPLE clause. Example:
SELECT * FROM EMPLOYEES SAMPLE(10);
10% of rows selected randomly will be returned.
Q. You issue the following query:
SELECT FirstName FROM StaffListWHERE FirstName LIKE '_A%‘
Which names would be returned by this query? Choose all that apply.
Allen
CLARK
JACKSON
David
Q. Write a SQL SELECT query that only returns each city only once from Students table? Do you need to order this list with an ORDER BY clause?
A. SELECT DISTINCT City FROM Students;
Q. What is DML and DDL?
DML and DDL are subsets of SQL. DML stands for Data Manipulation Language and DDL – Data Definition Language.
DML consist of INSERT, UPDATE and DELETE
DDL commands
CREATE TABLE, ALTER TABLE, DROP TABLE, RENAME TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX.
CREATE/ALTER/DROP VIEW
Q. Write SQL SELECT query that returns the first and last name of each instructor, the Salary, and gives each of them a number.
A. SELECT FirstName, LastName, Salary, ROWNUM FROM Instructors;
Q. Is the WHERE clause must appear always before the GROUP BY clause in SQL SELECT ?
A. Yes. The proper order for SQL SELECT clauses is: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY. Only the SELECT and FROM clause are mandatory.
Q. Which of the following statements are Data Manipulation Language commands?
INSERT
UPDATE
GRANT
TRUNCATE
CREATE
Ans. A and B. The INSERT and UPDATE statements are Data Manipulation Language (DML) commands. GRANT is a Data Control Language (DCL) command. TRUNCATE and CREATE are Data Definition Language (DDL) commands
Question: Describe SQL comments.
A. SQL comments are introduced by two consecutive hyphens (--) and ended by the end of the line.
Q. Difference between TRUNCATE, DELETE and DROP commands?
A. The DELETE command is used to remove 'some or all rows from a table.
TRUNCATE removes ALL rows from a table. The operation cannot be rolled back
The DROP command removes a table from the database. All the tables' rows, indexes and privileges will also be removed.
Sunday, September 19, 2010
Wednesday, September 15, 2010
User Acceptance Testing
What is User Acceptance Testing?
User Acceptance Testing is often the final step before rolling out the application.Usually the end users who will be using the applications test the application before ‘accepting’ the application.
This type of testing gives the end users the confidence that the application being delivered to them meets their requirements.
This testing also helps nail bugs related to usability of the application.
User Acceptance Testing – Prerequisites:
Before the User Acceptance testing can be done the application is fully developed.Various levels of testing (Unit, Integration and System) are already completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT.
User Acceptance Testing – What to Test?
To ensure an effective User Acceptance Testing Test cases are created.These Test cases can be created using various use cases identified during the Requirements definition stage.
The Test cases ensure proper coverage of all the scenarios during testing.
During this type of testing the specific focus is the exact real world usage of the application. The Testing is done in an environment that simulates the production environment.
The Test cases are written using real world scenarios for the application
User Acceptance Testing – How to Test?
The user acceptance testing is usually a black box type of testing. In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing.However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment.
The steps taken for User Acceptance Testing typically involve one or more of the following:
.......1) User Acceptance Test (UAT) Planning
.......2) Designing UA Test Cases
.......3) Selecting a Team that would execute the (UAT) Test Cases
.......4) Executing Test Cases
.......5) Documenting the Defects found during UAT
.......6) Resolving the issues/Bug Fixing
.......7) Sign Off
User Acceptance Test (UAT) Planning:
As always the Planning Process is the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria.
Designing UA Test Cases:
The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios.
The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating.
Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something.
The Business Analysts and the Project Team review the User Acceptance Test Cases.
Selecting a Team that would execute the (UAT) Test Cases:
Selecting a Team that would execute the UAT Test Cases is an important step.
The UAT Team is generally a good representation of the real world end users.
The Team thus comprises of the actual end users who will be using the application.
Executing Test Cases:
The Testing Team executes the Test Cases and may additional perform random Tests relevant to them
Documenting the Defects found during UAT:
The Team logs their comments and any defects or issues found during testing.
Resolving the issues/Bug Fixing:
The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users.
Sign Off:
Upon successful completion of the User Acceptance Testing and resolution of the issues the team generally indicates the acceptance of the application. This step is important in commercial software sales. Once the User “Accept” the Software delivered they indicate that the software meets theirrequirements.
The users now confident of the software solution delivered and the vendor can be paid for the same.
What are the key deliverable of User Acceptance Testing?
In the Traditional Software Development Life cycle successful completion of User Acceptance Testing is a significant milestone.The Key Deliverables typically of User Acceptance Testing Phase are:
1) The Test Plan- This outlines the Testing Strategy
2) The UAT Test cases – The Test cases help the team to effectively test the application
3) The Test Log – This is a log of all the test cases executed and the actual results.
4) User Sign Off – This indicates that the customer finds the product delivered to their satisfaction
Capability Maturity Model
The Capability Maturity Model defines various levels of Organization based on the processes that they follow.
Level 0
The following is true for “Level 0” Organizations -
There are no Processes, tracking mechanisms, no plans. It is left to the developer or any person responsible for Quality to ensure that the product meets expectations.
Level 1 – Performed Informally
The following is true for “Level 1” Organizations -
In Such Organizations, Typically the teams work extra hard to achieve the results. There are no tracking mechanisms, standards defined. The work is done but is informal and not well documented.
Level 2 – Planned and Tracked
The following is true for “Level 2” Organizations -
There are processes within a team and the team can repeat them or follow the processes for all projects that it handles. However the process is not standardized throughout the Organization. All the teams within the organization do not follow the same standard.
Level 3 – Well-Defined
In “Level 3” Organizations the processes are well defined and followed throughout the organization.
Level 4 – Quantitatively Controlled
In “Level 4” Organizations -
“Level 5” Organizations have well defined processes, which are measured and the organization has a good understanding of IT projects affect the Organizational goals.
The Organization is able to continuously improve its processes based on this understanding.
Level 0
The following is true for “Level 0” Organizations -
There are no Processes, tracking mechanisms, no plans. It is left to the developer or any person responsible for Quality to ensure that the product meets expectations.
Level 1 – Performed Informally
The following is true for “Level 1” Organizations -
In Such Organizations, Typically the teams work extra hard to achieve the results. There are no tracking mechanisms, standards defined. The work is done but is informal and not well documented.
Level 2 – Planned and Tracked
The following is true for “Level 2” Organizations -
There are processes within a team and the team can repeat them or follow the processes for all projects that it handles. However the process is not standardized throughout the Organization. All the teams within the organization do not follow the same standard.
Level 3 – Well-Defined
In “Level 3” Organizations the processes are well defined and followed throughout the organization.
Level 4 – Quantitatively Controlled
In “Level 4” Organizations -
- The processes are well defined and followed throughout the organizationLevel 5 – Continuously Improving
- The Goals are defined and the actual output is measured
- Metrics are collected and future performance can predicted
“Level 5” Organizations have well defined processes, which are measured and the organization has a good understanding of IT projects affect the Organizational goals.
The Organization is able to continuously improve its processes based on this understanding.
Thursday, September 9, 2010
Auditing Software Testing Process
Introduction:
To ensure transparency and reliability of the IT systems it may be necessary to audit the Software Development Processes including the most important aspect – Software Testing Process.
Auditing is an important activity in organizations. In the context of testing it helps us ensure that the Testing processes are followed as defined.
Types of Testing Process Audits
There can be various reasons to conduct Audits. The Audits may serve aim to achieve certain definite goals. Based on that we can classify them as follows:
Audit to verify compliance: In this type of auditing the prime motivation is to judge if the process complies with a standards. In these scenarios, the actual testing process is compared with the documented process. For example ISO Standards require us to define our Software testing process. The audit will try to verify if we actually conducted the testing as documented
Audit for process improvement/problem solving:
In this type of audit the motivation is to audit and trace the various steps in the process and try to weed out process problems. For instance it is observed that too many software defects escaped detection even though the testing process was apparently followed. So the audit is done as a preliminary step to collect facts and analyze them.
Audit for Root Cause Analysis
In this type of audit the motivation is to audit the testing process is to find a Root Cause of a specific problem. For example the customers discovered a huge problem with the software. So we retrace our testing steps to find out what went wrong in this specific case.
Internal Audits
Typically the internal audits are initiated from within the organizations
External Audits
External Audits are done by and initiated by external agencies
Why Audit Software Testing Process?
Auditing Test Process helps the management understand if the process is being followed as specified. Typically Testing audit may be done for one or more of the following factors:
• To ensure continued reliability and integrity of the process
• To verify compliance of standards (ISO, CMM, etc)
• To solve process related problems
• To find the root cause of a specific problem
• To detect or prevent Fraud
• To improve the Testing process
Auditing of the Testing process may also be done if the Software Product is a mission critical one such as used for Medical Life Support Systems
This is done to prevent any loop holes or bugs in the system
How to Audit
Typically the Audit of the Testing Process will include the following steps:
• reviewing the Testing process as documented in the Quality Manual
This helps the auditor understand the process as defined.
• Reviewing the deliverable documents at each step
• Document reviewed include
............... Test Strategy
............... Test Plans
............... Test Cases
............... Test Logs
............... Defects Tracked
............... Test Coverage Matrix
............... any other relevant records
Each of the above document provides a certain level of traceability that the process was followed and the necessary steps were taken
• Interviewing the Project Team at various levels – PM, Coordinator, Tester
Interviewing the Project Team members gives an understanding of the thought process prevalent in those conducting the Testing Process.
This can provide valuable insights over an above what was actually documented
ISACA – ww.isaca.org provides guidelines and standards for Auditing Information Systems & Software Development Lifecycle
CISA stands for Certified Information Systems Auditor
Similarly independent agencies may verify the Test Processes and SDLC for ensuring compliance with FDA ( Food and Drug Administration)
What can be audited?
Whether the test process deliverable exist as specified
The only thing that can be really verified in an audit is that the process deliverables exist. The process deliverables are taken as a proof that the necessary steps were taken to do the testing. For example if Test Logs exist, we assume that testing was done and the Test Logs were created as a result of actual tests executed.
A separate exercise may be initiated to verify the authenticity of the Test Logs or other test deliverables
Whether test cases created covered all requirements/use cases
This analysis reveals if the test coverage was sufficient. It indicates that whether the testing team did the best to provide adequate amount of testing
Whether all Defects were fixed
The Status of all the Defects logged is checked to verify if all were fixed and verified
Whether there are any known bugs in the software released
Sometimes all the defects may not be fixed, the software may be released with known problems. Test Logs would indicate the actual results and evidence of any bugs being present.
Whether the levels of testing was effective enough
If Defects pass through the various levels of testing undetected, it may reflect poorly on the effectiveness of the testing process
- What were the number of defects (Defect Leaks) that went by undetected in each phase
- Number of iterations of testing in each level
- Time taken to test each module/component
- This data may be used for process improvement
- Versions of source code actually tested
What is Regression Testing?
Regression Testing attempts to verify:
- That the application works as specified even after the changes/additions/modification were made to it
- The original functionality continues to work as specified even after changes/additions/modification to the software application
- The changes/additions/modification to the software application have not introduced any new bugs
When is Regression Testing necessary?
Regression Testing plays an important role in any Scenario where a change has been made to a previously tested software code. Regression Testing is hence an important aspect in various Software Methodologies where software changes enhancements occur frequently.Any Software Development Project is invariably faced with requests for changing Design, code, features or all of them.
Some Development Methodologies embrace change.
For example ‘Extreme Programming’ Methodology advocates applying small incremental changes to the system based on the end user feedback.
Each change implies more Regression Testing needs to be done to ensure that the System meets the Project Goals.
Why is Regression Testing important?
Any Software change can cause existing functionality to break.Changes to a Software component could impact dependent Components.
It is commonly observed that a Software fix could cause other bugs.
All this affects the quality and reliability of the system. Hence Regression Testing, since it aims to verify all this, is very important.
Making Regression Testing Cost Effective:
Every time a change occurs one or more of the following scenarios may occur:- More Functionality may be added to the system
- More complexity may be added to the system
- New bugs may be introduced
- New vulnerabilities may be introduced in the system
- System may tend to become more and more fragile with each change
After the change the new functionality may have to be tested along with all the original functionality.
With each change Regression Testing could become more and more costly.
To make the Regression Testing Cost Effective and yet ensure good coverage one or more of the following techniques may be applied:
- Test Automation: If the Test cases are automated the test cases may be executed using scripts after each change is introduced in the system. The execution of test cases in this way helps eliminate oversight, human errors,. It may also result in faster and cheaper execution of Test cases. However there is cost involved in building the scripts.
- Selective Testing: Some Teams choose execute the test cases selectively. They do not execute all the Test Cases during the Regression Testing. They test only what they decide is relevant. This helps reduce the Testing Time and Effort.
Regression Testing – What to Test?
Since Regression Testing tends to verify the software application after a change has been made everything that may be impacted by the change should be tested during Regression Testing. Generally the following areas are covered during Regression Testing:- Any functionality that was addressed by the change
- Original Functionality of the system
- Performance of the System after the change was introduced
Technical Terms Used in Testing World
Audit: An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria.
Acceptance testing: Testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
Alpha Testing: Acceptance testing performed by the customer in a controlled environment at the developer's site. The software is used by the customer in a setting approximating the target environment with the developer observing and recording errors and usage problems.
Assertion Testing: A dynamic analysis technique which inserts assertions about the relationship between program variables into the program code. The truth of the assertions is determined as the program executes.
Boundary Value: (1) A data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component. (2) A value which lies at, or just inside or just outside a specified range of valid input and output values.
Boundary Value Analysis: A selection technique in which 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.
Branch Coverage: A test coverage criteria which requires that for each decision point each possible branch be executed at least once.
Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner.
Beta Testing: Acceptance testing performed by the customer in a live application of the software, at one or more end user sites, in an environment not controlled by the developer.
Boundary Value Testing: A testing technique using input values at, just below, and just above, the defined limits of an input domain; and with input values causing outputs to be at, just below, and just above, the defined limits of an output domain.
Branch Testing: Testing technique to satisfy coverage criteria which require that for each decision point, each possible branch [outcome] be executed at least once. Contrast with testing, path; testing, statement. See: branch coverage.
Compatibility Testing: The process of determining the ability of two or more systems to exchange information. In a situation where the developed software replaces an already working program, an investigation should be conducted to assess possible comparability problems between the new software and other programs or systems.
Cause Effect Graph: A Boolean graph linking causes and effects. The graph is actually a digital-logic circuit (a combinatorial logic network) using a simpler notation than standard electronics notation.
Cause Effect Graphing: This is a Test data selection technique. The input and output domains are partitioned into classes and analysis is performed to determine which input classes cause which effect. A minimal set of inputs is chosen which will cover the entire effect set. It is a systematic method of generating test cases representing combination of conditions.
Code Inspection: A manual [formal] testing [error detection] technique where the programmer reads source code, statement by statement, to a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.
Code Review: A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.
Code Walkthrough: A manual testing [error detection] technique where program [source code] logic [structure] is traced manually [mentally] by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.
Coverage Analysis: Determining and assessing measures associated with the invocation of program structural elements to determine the adequacy of a test run. Coverage analysis is useful when attempting to execute each statement, branch, path, or iterative structure in a program.
Crash: The sudden and complete failure of a computer system or component.
Critical: The degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system.
Cyclomatic Complexity: The number of independent paths through a program. The cyclomatic complexity of a program is equivalent to the number of decision statements plus 1.
Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.
Error Guessing: This is a Test data selection technique. The selection criterion is to pick values that seem likely to cause errors.
Error Seeding: The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. Contrast with mutation analysis.
Exception: An event that causes suspension of normal program execution. Types include addressing exception, data exception, operation exception, overflow exception, protection exception, and underflow exception.
Exhaustive Testing: Executing the program with all possible combinations of values for program variables. This type of testing is feasible only for small, simple programs.
Failure: The inability of a system or component to perform its required functions within specified performance requirements.
Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner.
Functional Testing: Testing that ignores the internal mechanism or structure of a system or component and focuses on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements and corresponding predicted results.
Integration Testing: An orderly progression of testing in which software elements, hardware elements, or both are combined and tested, to evaluate their interactions, until the entire system has been integrated.
Interface Testing: Testing conducted to evaluate whether systems or components pass data and control correctly to one another.
Mutation Testing: A testing methodology in which two or more program mutations are executed using the same test cases to evaluate the ability of the test cases to detect differences in the mutations.
Operational Testing: Testing conducted to evaluate a system or component in its operational environment.
Parallel Testing: Testing a new or an altered data processing system with the same source data that is used in another system. The other system is considered as the standard of comparison.
Path Testing: Testing to satisfy coverage criteria that each logical path through the program be tested. Often paths through the program are grouped into a finite set of classes. One path from each class is then tested.
Performance Testing: Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements.
Qualification Testing: Formal testing, usually conducted by the developer for the consumer, to demonstrate that the software meets its specified requirements.
Quality Assurance: (1) The planned systematic activities necessary to ensure that a component, module, or system conforms to established technical requirements. (2) All actions that are taken to ensure that a development organization delivers products that meet performance requirements and adhere to standards and procedures. (3) The policy, procedures, and systematic actions established in an enterprise for the purpose of providing and maintaining some degree of confidence in data integrity and accuracy throughout the life cycle of the data, which includes input, update, manipulation, and output. (4) The actions, planned and performed, to provide confidence that all systems and components that influence the quality of the product are working as expected individually and collectively.
Quality Control: The operational techniques and procedures used to achieve quality requirements.
Regression Testing: Rerunning test cases which a program has previously executed correctly in order to detect errors spawned by changes or corrections made during software development and maintenance.
Review: A process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review.
Risk: A measure of the probability and severity of undesired effects.
Risk Assessment: A comprehensive evaluation of the risk and its associated impact.
Software Review: An evaluation of software elements to ascertain discrepancies from planned results and to recommend improvement. This evaluation follows a formal process. Syn: software audit. See: code audit, code inspection, code review, code walkthrough, design review, specification analysis, static analysis
Static Analysis: Analysis of a program that is performed without executing the program. The process of evaluating a system or component based on its form, structure, content, documentation is also called as Static Analysis.
Statement Testing: Testing to satisfy the criterion that each statement in a program be executed at least once during program testing.
Storage Testing: This is a determination of whether or not certain processing conditions use more storage [memory] than estimated.
Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.
Structural Testing: Testing that takes into account the internal mechanism [structure] of a system or component. Types include branch testing, path testing, statement testing. (2) Testing to insure each program statement is made to execute during testing and that each program statement performs its intended function.
System Testing: The process of testing an integrated hardware and software system to verify that the system meets its specified requirements. Such testing may be conducted in both the development environment and the target environment.
Test: An activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component.
Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.
Testcase: Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.
Testcase Generator: A software tool that accepts as input source code, test criteria, specifications, or data structure definitions; uses these inputs to generate test input data; and, sometimes, determines expected results.
Test Design: Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.
Test Documentation: Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report.
Test Driver: A software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results.
Test Incident Report: A document reporting on any event that occurs during testing that requires further investigation.
Test Item: A software item which is the object of testing.
Test Log: A chronological record of all relevant details about the execution of a test.
Test Phase: The period of time in the software life cycle in which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied.
Test Plan: Documentation specifying the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, responsibilities, required, resources, and any risks requiring contingency planning. See: test design, validation protocol.
Test Procedure: A formal document developed from a test plan that presents detailed instructions for the setup, operation, and evaluation of the results for each defined test.
Test Report: A document describing the conduct and results of the testing carried out for a system or system component.
Test Result Analyzer: A software tool used to test output data reduction, formatting, and printing.
Testing: (1) The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. (2) The process of analyzing a software item to detect the differences between existing and required conditions, i.e. bugs, and to evaluate the features of the software items.
Traceability Matrix: A matrix that records the relationship between two or more products; e.g., a matrix that records the relationship between the requirements and the design of a given software component. See: traceability, traceability analysis.
Unit Testing: Testing of a module for typographic, syntactic, and logical errors, for correct implementation of its design, and for satisfaction of its requirements (or) Testing conducted to verify the implementation of the design for one software element; e.g., a unit or module; or a collection of software elements.
Usability: The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component.
Acceptance testing: Testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
Alpha Testing: Acceptance testing performed by the customer in a controlled environment at the developer's site. The software is used by the customer in a setting approximating the target environment with the developer observing and recording errors and usage problems.
Assertion Testing: A dynamic analysis technique which inserts assertions about the relationship between program variables into the program code. The truth of the assertions is determined as the program executes.
Boundary Value: (1) A data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component. (2) A value which lies at, or just inside or just outside a specified range of valid input and output values.
Boundary Value Analysis: A selection technique in which 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.
Branch Coverage: A test coverage criteria which requires that for each decision point each possible branch be executed at least once.
Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner.
Beta Testing: Acceptance testing performed by the customer in a live application of the software, at one or more end user sites, in an environment not controlled by the developer.
Boundary Value Testing: A testing technique using input values at, just below, and just above, the defined limits of an input domain; and with input values causing outputs to be at, just below, and just above, the defined limits of an output domain.
Branch Testing: Testing technique to satisfy coverage criteria which require that for each decision point, each possible branch [outcome] be executed at least once. Contrast with testing, path; testing, statement. See: branch coverage.
Compatibility Testing: The process of determining the ability of two or more systems to exchange information. In a situation where the developed software replaces an already working program, an investigation should be conducted to assess possible comparability problems between the new software and other programs or systems.
Cause Effect Graph: A Boolean graph linking causes and effects. The graph is actually a digital-logic circuit (a combinatorial logic network) using a simpler notation than standard electronics notation.
Cause Effect Graphing: This is a Test data selection technique. The input and output domains are partitioned into classes and analysis is performed to determine which input classes cause which effect. A minimal set of inputs is chosen which will cover the entire effect set. It is a systematic method of generating test cases representing combination of conditions.
Code Inspection: A manual [formal] testing [error detection] technique where the programmer reads source code, statement by statement, to a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.
Code Review: A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.
Code Walkthrough: A manual testing [error detection] technique where program [source code] logic [structure] is traced manually [mentally] by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.
Coverage Analysis: Determining and assessing measures associated with the invocation of program structural elements to determine the adequacy of a test run. Coverage analysis is useful when attempting to execute each statement, branch, path, or iterative structure in a program.
Crash: The sudden and complete failure of a computer system or component.
Critical: The degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system.
Cyclomatic Complexity: The number of independent paths through a program. The cyclomatic complexity of a program is equivalent to the number of decision statements plus 1.
Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.
Error Guessing: This is a Test data selection technique. The selection criterion is to pick values that seem likely to cause errors.
Error Seeding: The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program. Contrast with mutation analysis.
Exception: An event that causes suspension of normal program execution. Types include addressing exception, data exception, operation exception, overflow exception, protection exception, and underflow exception.
Exhaustive Testing: Executing the program with all possible combinations of values for program variables. This type of testing is feasible only for small, simple programs.
Failure: The inability of a system or component to perform its required functions within specified performance requirements.
Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner.
Functional Testing: Testing that ignores the internal mechanism or structure of a system or component and focuses on the outputs generated in response to selected inputs and execution conditions. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements and corresponding predicted results.
Integration Testing: An orderly progression of testing in which software elements, hardware elements, or both are combined and tested, to evaluate their interactions, until the entire system has been integrated.
Interface Testing: Testing conducted to evaluate whether systems or components pass data and control correctly to one another.
Mutation Testing: A testing methodology in which two or more program mutations are executed using the same test cases to evaluate the ability of the test cases to detect differences in the mutations.
Operational Testing: Testing conducted to evaluate a system or component in its operational environment.
Parallel Testing: Testing a new or an altered data processing system with the same source data that is used in another system. The other system is considered as the standard of comparison.
Path Testing: Testing to satisfy coverage criteria that each logical path through the program be tested. Often paths through the program are grouped into a finite set of classes. One path from each class is then tested.
Performance Testing: Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements.
Qualification Testing: Formal testing, usually conducted by the developer for the consumer, to demonstrate that the software meets its specified requirements.
Quality Assurance: (1) The planned systematic activities necessary to ensure that a component, module, or system conforms to established technical requirements. (2) All actions that are taken to ensure that a development organization delivers products that meet performance requirements and adhere to standards and procedures. (3) The policy, procedures, and systematic actions established in an enterprise for the purpose of providing and maintaining some degree of confidence in data integrity and accuracy throughout the life cycle of the data, which includes input, update, manipulation, and output. (4) The actions, planned and performed, to provide confidence that all systems and components that influence the quality of the product are working as expected individually and collectively.
Quality Control: The operational techniques and procedures used to achieve quality requirements.
Regression Testing: Rerunning test cases which a program has previously executed correctly in order to detect errors spawned by changes or corrections made during software development and maintenance.
Review: A process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review.
Risk: A measure of the probability and severity of undesired effects.
Risk Assessment: A comprehensive evaluation of the risk and its associated impact.
Software Review: An evaluation of software elements to ascertain discrepancies from planned results and to recommend improvement. This evaluation follows a formal process. Syn: software audit. See: code audit, code inspection, code review, code walkthrough, design review, specification analysis, static analysis
Static Analysis: Analysis of a program that is performed without executing the program. The process of evaluating a system or component based on its form, structure, content, documentation is also called as Static Analysis.
Statement Testing: Testing to satisfy the criterion that each statement in a program be executed at least once during program testing.
Storage Testing: This is a determination of whether or not certain processing conditions use more storage [memory] than estimated.
Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.
Structural Testing: Testing that takes into account the internal mechanism [structure] of a system or component. Types include branch testing, path testing, statement testing. (2) Testing to insure each program statement is made to execute during testing and that each program statement performs its intended function.
System Testing: The process of testing an integrated hardware and software system to verify that the system meets its specified requirements. Such testing may be conducted in both the development environment and the target environment.
Test: An activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component.
Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.
Testcase: Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.
Testcase Generator: A software tool that accepts as input source code, test criteria, specifications, or data structure definitions; uses these inputs to generate test input data; and, sometimes, determines expected results.
Test Design: Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.
Test Documentation: Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report.
Test Driver: A software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results.
Test Incident Report: A document reporting on any event that occurs during testing that requires further investigation.
Test Item: A software item which is the object of testing.
Test Log: A chronological record of all relevant details about the execution of a test.
Test Phase: The period of time in the software life cycle in which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied.
Test Plan: Documentation specifying the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, responsibilities, required, resources, and any risks requiring contingency planning. See: test design, validation protocol.
Test Procedure: A formal document developed from a test plan that presents detailed instructions for the setup, operation, and evaluation of the results for each defined test.
Test Report: A document describing the conduct and results of the testing carried out for a system or system component.
Test Result Analyzer: A software tool used to test output data reduction, formatting, and printing.
Testing: (1) The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. (2) The process of analyzing a software item to detect the differences between existing and required conditions, i.e. bugs, and to evaluate the features of the software items.
Traceability Matrix: A matrix that records the relationship between two or more products; e.g., a matrix that records the relationship between the requirements and the design of a given software component. See: traceability, traceability analysis.
Unit Testing: Testing of a module for typographic, syntactic, and logical errors, for correct implementation of its design, and for satisfaction of its requirements (or) Testing conducted to verify the implementation of the design for one software element; e.g., a unit or module; or a collection of software elements.
Usability: The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component.
Software Testing Myths
“Software implementation is a cozy bonfire, warm, bright, a bustle of comforting concrete activity. But beyond the flames is an immense zone of darkness.Testing is the exploration of this darkness.” - extracted from the 1992 Software Maintenance Technology Reference Guide
Testing is often considered as a thankless job.
While developers say with pride: "Wow!! My code is running in production", testers usually don’t say "Wow!! The code that I tested is running in production"!!! This attitude can also be justified if we consider some examples of the usual talk that goes on among colleagues/peers/friends in the IT circle, like:
Mr. A: Which project are you working on?
Mr. B (Tester): Currently. I'm in a Testing project.
Mr. A: Oh...Umm...OK...
Mr. A: Mr. C, how about you?
Mr. C (Programmer/Developer): A Development & Maintenance project
Mr. A: Oohh?? What technology? Which platform? What’s the project all about?? … And so on
Even though there's no denying the fact that Construction/Coding is a very significant phase in the life cycle of any software product, the role of Testing as an activity should be given its due importance, because of the main reason, among others, that its the phase of SDLC just before asoftware product goes to production; i.e.; when your software product/application actually starts functioning in real world.
Therefore, it’s the only phase where you can ensure & gain a reasonable level of confidence that that you are delivering quality products to the customer.
This does not mean that quality assurance starts in the Testing phase. Ensuring & Maintaining quality is a continuous process which should be practiced right from Day 1 of the SDLC cycle.
In other words, during testing phase, you can "bang" your product in different ways, by which I refer to different kinds of testing like functional testing, stress testing, performance testing & so on, and validate whether the software product works fine.
Needless to say, delivering quality software delights customers & helps in getting more business. That said about the importance of Testing, we will now proceed to look into some perceptions or “myths” about software testing which prevails, in general, among the IT community
Testing is done to demonstrate that there are no errors/bugs/defects in the software product being developed
No. Not at all!! Though this is one way of conveying the meaning, it takes us away from
the main objective of testing
Testing is the process of uncovering defects... The objective of any tester should be to
try his best to crack the code. This should not be seen as a destructive activity which points fingers at or find faults with the developers. In fact,testing should be considered as a healthy feedback mechanism to the developer community so that they can make maximum use of the defects found during testing, analyze them, find the root cause & devise appropriate preventive mechanisms. Actually, the defects found during testing helps improving the quality of the code!
A tester should never work under the assumption that the system works!! The software product should be tested with the intent of finding errors. The test, which when executed reveals a defect in the software, is a success. Though Testing, by itself, does not improve the quality of the software product, it is an indicator of the quality. Rather that considering Testing
as a separate phase in the SDLC, it should be an activity which is integrated into each & every phase. The intent should be to Analyze & Test, Design & Test, Develop & Test, Fix Defects & Test more...!!
Testing is done to ensure that the software/application does what it is supposed to do
True enough!! But it’s not just that...The software should also not do what it is not supposed to do. Good test cases are the only way to establish a reasonable level of confidence on thesoftware product. The Tester should think of all possible scenarios based upon the test requirements or test plan. Though there are various methods to prepare a large number of test cases like Equivalence Partioning, Boundary Value Analysis and so on, a lot depends on one's own intuition to come up with some good cases which reveals defects in thesoftware
Testing is easy...!!!
Sometime back, I conducted a short class on Software Testing to a group of new recruits. While we were discussing about different type of projects, one participant said that he is very interested in atesting career. When asked the reason for his interest, prompt came the answer: “Testing is very easy, that’s why!!” This holds good only in some situations.
Though it’s simple to prepare straightforward test cases, at times testing can be a real challenging task.
Any production issues will, in many cases, backfire first to the testing teams. Why was this scenario not covered in the test plan??
Therefore, a Tester should develop the capability to look or think beyond the requirements mentioned in the test plan or specifications.
This is very important in case of System Testers who are responsible for ensuring that the software product works appropriately from "end-to-end ".
Testing does not offer any opportunities for career growth.
There are a wide range of roles that one can take up, if opting for a Testing career.
Pursuing a testing career offers more scope for improving Business/Domain knowledge.
It enables one to adopt a holistic approach of the entire software system instead of concentrating on just a unit or module.
A good number of testing certifications are offered by reputed institutes, which helps you attain a strong foundation in this career path.
This does not mean that you don’t have all these opportunities at all if you are a Developer.
It can be said that a Testing career has its own plus points. It entirely depends on one's own interests!
Testers do not perform well in development projects (or Testers are poor in coding)
Tester or not, the expertise on developing quality code depends upon one's own programming skills and constant or continuous learning in that area.
Some people, though in testing projects, take time out of their work to improve their programming skills by contributing to coding efforts or taking up projects voluntarily.
Thus, being a Tester does not prevent you in any way from being an expert Programmer or Vice Versa!!!
One way to narrow the communication gap between Tester & Developer community is to include the Testing teams, right from the Requirements/Design Stage meetings so that everyone involved in the life cycle of developing a software product can take part in the discussion & offer valuable suggestions.
This is evident from the below lines, which wonderfully describes the importance of Testing
More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded - indeed, test-design thinking can discover and eliminate bugs at every stage in the creation ofsoftware, from conception to specification, to design, coding and the rest. -Boris Beizer, Software Testing Techniques, "Creating a Software Engineering Culture" by Karl Eugene Wiegers"
No formal training is needed to work in a Testing project... Anyone can be a Tester!
True enough, anyone can be a Tester...but, only a good Tester can come up with quality Test cases (just like how an expert Developer can write quality Code).
It is essential that proper training is imparted to everyone joining Testing projects. This would not only helps one to understand the importance of Testing, but also tune one's mind to the requirements of becoming a good Tester, which would greatly contribute to a good career in Testing...
Testing is often considered as a thankless job.
While developers say with pride: "Wow!! My code is running in production", testers usually don’t say "Wow!! The code that I tested is running in production"!!! This attitude can also be justified if we consider some examples of the usual talk that goes on among colleagues/peers/friends in the IT circle, like:
Mr. A: Which project are you working on?
Mr. B (Tester): Currently. I'm in a Testing project.
Mr. A: Oh...Umm...OK...
Mr. A: Mr. C, how about you?
Mr. C (Programmer/Developer): A Development & Maintenance project
Mr. A: Oohh?? What technology? Which platform? What’s the project all about?? … And so on
Even though there's no denying the fact that Construction/Coding is a very significant phase in the life cycle of any software product, the role of Testing as an activity should be given its due importance, because of the main reason, among others, that its the phase of SDLC just before asoftware product goes to production; i.e.; when your software product/application actually starts functioning in real world.
Therefore, it’s the only phase where you can ensure & gain a reasonable level of confidence that that you are delivering quality products to the customer.
This does not mean that quality assurance starts in the Testing phase. Ensuring & Maintaining quality is a continuous process which should be practiced right from Day 1 of the SDLC cycle.
In other words, during testing phase, you can "bang" your product in different ways, by which I refer to different kinds of testing like functional testing, stress testing, performance testing & so on, and validate whether the software product works fine.
Needless to say, delivering quality software delights customers & helps in getting more business. That said about the importance of Testing, we will now proceed to look into some perceptions or “myths” about software testing which prevails, in general, among the IT community
Testing is done to demonstrate that there are no errors/bugs/defects in the software product being developed
No. Not at all!! Though this is one way of conveying the meaning, it takes us away from
the main objective of testing
Testing is the process of uncovering defects... The objective of any tester should be to
try his best to crack the code. This should not be seen as a destructive activity which points fingers at or find faults with the developers. In fact,testing should be considered as a healthy feedback mechanism to the developer community so that they can make maximum use of the defects found during testing, analyze them, find the root cause & devise appropriate preventive mechanisms. Actually, the defects found during testing helps improving the quality of the code!
A tester should never work under the assumption that the system works!! The software product should be tested with the intent of finding errors. The test, which when executed reveals a defect in the software, is a success. Though Testing, by itself, does not improve the quality of the software product, it is an indicator of the quality. Rather that considering Testing
as a separate phase in the SDLC, it should be an activity which is integrated into each & every phase. The intent should be to Analyze & Test, Design & Test, Develop & Test, Fix Defects & Test more...!!
Testing is done to ensure that the software/application does what it is supposed to do
True enough!! But it’s not just that...The software should also not do what it is not supposed to do. Good test cases are the only way to establish a reasonable level of confidence on thesoftware product. The Tester should think of all possible scenarios based upon the test requirements or test plan. Though there are various methods to prepare a large number of test cases like Equivalence Partioning, Boundary Value Analysis and so on, a lot depends on one's own intuition to come up with some good cases which reveals defects in thesoftware
Testing is easy...!!!
Sometime back, I conducted a short class on Software Testing to a group of new recruits. While we were discussing about different type of projects, one participant said that he is very interested in atesting career. When asked the reason for his interest, prompt came the answer: “Testing is very easy, that’s why!!” This holds good only in some situations.
Though it’s simple to prepare straightforward test cases, at times testing can be a real challenging task.
Any production issues will, in many cases, backfire first to the testing teams. Why was this scenario not covered in the test plan??
Therefore, a Tester should develop the capability to look or think beyond the requirements mentioned in the test plan or specifications.
This is very important in case of System Testers who are responsible for ensuring that the software product works appropriately from "end-to-end ".
Testing does not offer any opportunities for career growth.
There are a wide range of roles that one can take up, if opting for a Testing career.
Pursuing a testing career offers more scope for improving Business/Domain knowledge.
It enables one to adopt a holistic approach of the entire software system instead of concentrating on just a unit or module.
A good number of testing certifications are offered by reputed institutes, which helps you attain a strong foundation in this career path.
This does not mean that you don’t have all these opportunities at all if you are a Developer.
It can be said that a Testing career has its own plus points. It entirely depends on one's own interests!
Testers do not perform well in development projects (or Testers are poor in coding)
Tester or not, the expertise on developing quality code depends upon one's own programming skills and constant or continuous learning in that area.
Some people, though in testing projects, take time out of their work to improve their programming skills by contributing to coding efforts or taking up projects voluntarily.
Thus, being a Tester does not prevent you in any way from being an expert Programmer or Vice Versa!!!
One way to narrow the communication gap between Tester & Developer community is to include the Testing teams, right from the Requirements/Design Stage meetings so that everyone involved in the life cycle of developing a software product can take part in the discussion & offer valuable suggestions.
This is evident from the below lines, which wonderfully describes the importance of Testing
More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded - indeed, test-design thinking can discover and eliminate bugs at every stage in the creation ofsoftware, from conception to specification, to design, coding and the rest. -Boris Beizer, Software Testing Techniques, "Creating a Software Engineering Culture" by Karl Eugene Wiegers"
No formal training is needed to work in a Testing project... Anyone can be a Tester!
True enough, anyone can be a Tester...but, only a good Tester can come up with quality Test cases (just like how an expert Developer can write quality Code).
It is essential that proper training is imparted to everyone joining Testing projects. This would not only helps one to understand the importance of Testing, but also tune one's mind to the requirements of becoming a good Tester, which would greatly contribute to a good career in Testing...
Wednesday, September 8, 2010
QA test plan
Test Plan: The test plan defines the objectives and scope of the testing effort, and identifies the methodology that your team will use to conduct tests. It also identifies the hardware, software, and tools required for testing and the features and functions that will be tested. A well-rounded test plan notes any risk factors that jeopardize testing and includes a testing schedule. The following are the likely components of a test plan:
1 Introduction
- Test Plan Objectives
- Project Overview
- Document Overview
2 Review and Audits
- Work Product
- Client Inputs
3 Testing Scope
- In Scope
- Out Of Scope
4 Roles and Responsibilities
- Training
5 Test Environment
- Test Server
- Test Client
6 Test Strategy
- System Test
- Performance Test
- Security Test
- Automated Test
- Stress and Volume Test
- Recovery Test
- Documentation Test
- Beta Test
- User Acceptance Test
7 Testing Work flow
8 Defect Management System
- Reporting of Bugs
- Fixing
- Regression
- Build Declaration
9 Test Schedule
10 Release Criteria
11 Suspension/Exit Criteria
12 Resumption Criteria
13 Dependencies
- Personnel Dependencies
- Software Dependencies
- Hardware Dependencies
- Test Data & Database
14 Risks
- Schedule
- Technical
- Management
- Personnel
- Requirements
15 Tools
16 Test Deliverable
Why We Need Testing?
Why Testing?
Here are some recent major computer system failures caused by software bugs...
- Email services of a major smartphone system were interrupted or unavailable for nine hours in December 2009, the second service interruption within a week, according to news reports. The problems were believed to be due to bugs in new versions of the email system software.
- It was reported in August 2009 that a large suburban school district introduced a new computer system that was 'plagued with bugs' and resulted in many students starting the school year without schedules or with incorrect schedules, and many problems with grades. Upset students and parents started a social networking site for sharing complaints.
- In February of 2009 users of a major search engine site were prevented from clicking through to sites listed in search results for part of a day. It was reportedly due to software that did not effectively handle a mistakenly-placed "/" in an internal ancillary reference file that was frequently updated for use by the search engine. Users, instead of being able to click thru to listed sites, were instead redirected to an intermediary site which, as a result of the suddenly enormous load, was rendered unusable.
- A large health insurance company was reportedly banned by regulators from selling certain types of insurance policies in January of 2009 due to ongoing computer system problems that resulted in denial of coverage for needed medications and mistaken overcharging or cancelation of benefits. The regulatory agency was quoted as stating that the problems were posing "a serious threat to the health and safety" of beneficiaries.
- A news report in January 2009 indicated that a major IT and management consulting company was still battling years of problems in implementing its own internal accounting systems, including a 2005 implementation that reportedly "was attempted without adequate testing".
- In August of 2008 it was reported that more than 600 U.S. airline flights were significantly delayed due to a software glitch in the U.S. FAA air traffic control system. The problem was claimed to be a 'packet switch' that 'failed due to a database mismatch', and occurred in the part of the system that handles required flight plans.
- Software system problems at a large health insurance company in August 2008 were the cause of a privacy breach of personal health information for several hundred thousand customers, according to news reports. It was claimed that the problem was due to software that 'was not comprehensively tested'.
- A major clothing retailer was reportedly hit with significant software and system problems when attempting to upgrade their online retailing systems in June 2008. Problems remained ongoing for some time. When the company made their public quarterly financial report, the software and system problems were claimed as the cause of the poor financial results.
- Software problems in the automated baggage sorting system of a major airport in February 2008 prevented thousands of passengers from checking baggage for their flights. It was reported that the breakdown occurred during a software upgrade, despite pre-testing of the software. The system continued to have problems in subsequent months.
- News reports in December of 2007 indicated that significant software problems were continuing to occur in a new ERP payroll system for a large urban school system. It was believed that more than one third of employees had received incorrect paychecks at various times since the new system went live the preceding January, resulting in overpayments of $53 million, as well as underpayments. An employees' union brought a lawsuit against the school system, the cost of the ERP system was expected to rise by 40%, and the non-payroll part of the ERP system was delayed. Inadequate testing reportedly contributed to the problems. The school system was still working on cleaning up the aftermath of the problems in December 2009, going so far as to bring lawsuits against some employees to get them to return overpayments.
- In November of 2007 a regional government reportedly brought a multi-million dollar lawsuit against a software services vendor, claiming that the vendor 'minimized quality' in delivering software for a large criminal justice information system and the system did not meet requirements. The vendor also sued its subcontractor on the project.
- In June of 2007 news reports claimed that software flaws in a popular online stock-picking contest could be used to gain an unfair advantage in pursuit of the game's large cash prizes. Outside investigators were called in and in July the contest winner was announced. Reportedly the winner had previously been in 6th place, indicating that the top 5 contestants may have been disqualified.
- A software problem contributed to a rail car fire in a major underground metro system in April of 2007 according to newspaper accounts. The software reportedly failed to perform as expected in detecting and preventing excess power usage in equipment on new passenger rail cars, resulting in overheating and fire in the rail car, and evacuation and shutdown of part of the system.
- Tens of thousands of medical devices were recalled in March of 2007 to correct a software bug. According to news reports, the software would not reliably indicate when available power to the device was too low.
- A September 2006 news report indicated problems with software utilized in a state government's primary election, resulting in periodic unexpected rebooting of voter checkin machines, which were separate from the electronic voting machines, and resulted in confusion and delays at voting sites. The problem was reportedly due to insufficient testing.
- In August of 2006 a U.S. government student loan service erroneously made public the personal data of as many as 21,000 borrowers on it's web site, due to a software error. The bug was fixed and the government department subsequently offered to arrange for free credit monitoring services for those affected.
- A software error reportedly resulted in overbilling of up to several thousand dollars to each of 11,000 customers of a major telecommunications company in June of 2006. It was reported that the software bug was fixed within days, but that correcting the billing errors would take much longer.
- News reports in May of 2006 described a multi-million dollar lawsuit settlement paid by a healthcare software vendor to one of its customers. It was reported that the customer claimed there were problems with the software they had contracted for, including poor integration of software modules, and problems that resulted in missing or incorrect data used by medical personnel.
- In early 2006 problems in a government's financial monitoring software resulted in incorrect election candidate financial reports being made available to the public. The government's election finance reporting web site had to be shut down until the software was repaired.
- Trading on a major Asian stock exchange was brought to a halt in November of 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day.
- A May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights and occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.
- Media reports in January of 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March of 2005 it was decided to scrap the entire project.
- In July 2004 newspapers reported that a new government welfare management system in Canada costing several hundred million dollars was unable to handle a simple benefits rate increase after being put into live operation. Reportedly the original contract allowed for only 6 weeks of acceptance testing and the system was never tested for its ability to handle a rate increase.
- Millions of bank accounts were impacted by errors due to installation of inadequately tested software code in the transaction processing system of a major North American bank, according to mid-2004 news reports. Articles about the incident stated that it took two weeks to fix all the resulting errors, that additional problems resulted when the incident drew a large number of e-mail phishing attacks against the bank's customers, and that the total cost of the incident could exceed $100 million.
- A bug in site management software utilized by companies with a significant percentage of worldwide web traffic was reported in May of 2004. The bug resulted in performance problems for many of the sites simultaneously and required disabling of the software until the bug was fixed.
- According to news reports in April of 2004, a software bug was determined to be a major contributor to the 2003 Northeast blackout, the worst power system failure in North American history. The failure involved loss of electrical power to 50 million customers, forced shutdown of 100 power plants, and economic losses estimated at $6 billion. The bug was reportedly in one utility company's vendor-supplied power monitoring and management system, which was unable to correctly handle and report on an unusual confluence of initially localized events. The error was found and corrected after examining millions of lines of code.
- In early 2004, news reports revealed the intentional use of a software bug as a counter-espionage tool. According to the report, in the early 1980's one nation surreptitiously allowed a hostile nation's espionage service to steal a version of sophisticated industrial software that had intentionally-added flaws. This eventually resulted in major industrial disruption in the country that used the stolen flawed software.
- A major U.S. retailer was reportedly hit with a large government fine in October of 2003 due to web site errors that enabled customers to view one anothers' online orders.
- News stories in the fall of 2003 stated that a manufacturing company recalled all their transportation products in order to fix a software problem causing instability in certain circumstances. The company found and reported the bug itself and initiated the recall procedure in which a software upgrade fixed the problems.
- In August of 2003 a U.S. court ruled that a lawsuit against a large online brokerage company could proceed; the lawsuit reportedly involved claims that the company was not fixing system problems that sometimes resulted in failed stock trades, based on the experiences of 4 plaintiffs during an 8-month period. A previous lower court's ruling that "...six miscues out of more than 400 trades does not indicate negligence." was invalidated.
- In April of 2003 it was announced that a large student loan company in the U.S. made a software error in calculating the monthly payments on 800,000 loans. Although borrowers were to be notified of an increase in their required payments, the company will still reportedly lose $8 million in interest. The error was uncovered when borrowers began reporting inconsistencies in their bills.
- News reports in February of 2003 revealed that the U.S. Treasury Department mailed 50,000 Social Security checks without any beneficiary names. A spokesperson indicated that the missing names were due to an error in a software change. Replacement checks were subsequently mailed out with the problem corrected, and recipients were then able to cash their Social Security checks.
- In March of 2002 it was reported that software bugs in Britain's national tax system resulted in more than 100,000 erroneous tax overcharges. The problem was partly attributed to the difficulty of testing the integration of multiple systems.
- A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-shelf software that had long been used in systems for tracking certain U.S. nuclear materials. The same software had been recently donated to another country to be used in tracking their own nuclear materials, and it was not until scientists in that country discovered the problem, and shared the information, that U.S. officials became aware of the problems.
- According to newspaper stories in mid-2001, a major systems development contractor was fired and sued over problems with a large retirement plan management system. According to the reports, the client claimed that system deliveries were late, the software had excessive defects, and it caused other systems to crash.
- In January of 2001 newspapers reported that a major European railroad was hit by the aftereffects of the Y2K bug. The company found that many of their newer trains would not run due to their inability to recognize the date '31/12/2000'; the trains were started by altering the control system's date settings.
- News reports in September of 2000 told of a software vendor settling a lawsuit with a large mortgage lender; the vendor had reportedly delivered an online mortgage processing system that did not meet specifications, was delivered late, and didn't work.
- In early 2000, major problems were reported with a new computer system in a large suburban U.S. public school district with 100,000+ students; problems included 10,000 erroneous report cards and students left stranded by failed class registration systems; the district's CIO was fired. The school district decided to reinstate it's original 25-year old system for at least a year until the bugs were worked out of the new system by the software vendors.
- A review board concluded that the NASA Mars Polar Lander failed in December 1999 due to software problems that caused improper functioning of retro rockets utilized by the Lander as it entered the Martian atmosphere.
- In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a simple data conversion error. It was determined that spacecraft software used certain data in English units that should have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar Lander mission, which failed for unknown reasons in December 1999. Several investigating panels were convened to determine the process failures that allowed the error to go undetected.
- Bugs in software supporting a large commercial high-speed data network affected 70,000 business customers over a period of 8 days in August of 1999. Among those affected was the electronic trading system of the largest U.S. futures exchange, which was shut down for most of a week as a result of the outages.
- In April of 1999 a software bug caused the failure of a $1.2 billion U.S. military satellite launch, the costliest unmanned accident in the history of Cape Canaveral launches. The failure was the latest in a string of launch failures, triggering a complete military and industry review of U.S. space launch programs, including software integration and testing processes. Congressional oversight hearings were requested.
- A small town in Illinois in the U.S. received an unusually large monthly electric bill of $7 million in March of 1999. This was about 700 times larger than its normal bill. It turned out to be due to bugs in new software that had been purchased by the local power company to deal with Y2K software issues.
- In early 1999 a major computer game company recalled all copies of a popular new product due to software problems. The company made a public apology for releasing a product before it was ready.
- The computer system of a major online U.S. stock trading service failed during trading hours several times over a period of days in February of 1999 according to nationwide news reports. The problem was reportedly due to bugs in a software upgrade intended to speed online trade confirmations.
- In April of 1998 a major U.S. data communications network failed for 24 hours, crippling a large part of some U.S. credit card transaction authorization systems as well as other large U.S. bank, retail, and government data systems. The cause was eventually traced to a software bug.
- January 1998 news reports told of software problems at a major U.S. telecommunications company that resulted in no charges for long distance calls for a month for 400,000 customers. The problem went undetected until customers called up with questions about their bills.
- In November of 1997 the stock of a major health industry company dropped 60% due to reports of failures in computer billing systems, problems with a large database conversion, and inadequate software testing. It was reported that more than $100,000,000 in receivables had to be written off and that multi-million dollar fines were levied on the company by government agencies.
- A retail store chain filed suit in August of 1997 against a transaction processing system vendor (not a credit card company) due to the software's inability to handle credit cards with year 2000 expiration dates.
- In August of 1997 one of the leading consumer credit reporting companies reportedly shut down their new public web site after less than two days of operation due to software problems. The new site allowed web site visitors instant access, for a small fee, to their personal credit reports. However, a number of initial users ended up viewing each others' reports instead of their own, resulting in irate customers and nationwide publicity. The problem was attributed to "...unexpectedly high demand from consumers and faulty software that routed the files to the wrong computers."
- In November of 1996, newspapers reported that software bugs caused the 411 telephone information system of one of the U.S. RBOC's to fail for most of a day. Most of the 2000 operators had to search through phone books instead of using their 13,000,000-listing database. The bugs were introduced by new software modifications and the problem software had been installed on both the production and backup systems. A spokesman for the software vendor reportedly stated that 'It had nothing to do with the integrity of the software. It was human error.'
- On June 4 1996 the first flight of the European Space Agency's new Ariane 5 rocket failed shortly after launching, resulting in an estimated uninsured loss of a half billion dollars. It was reportedly due to the lack of exception handling of a floating-point error in a conversion from a 64-bit integer to a 16-bit signed integer.
- Software bugs caused the bank accounts of 823 customers of a major U.S. bank to be credited with $924,844,208.32 each in May of 1996, according to newspaper reports. The American Bankers Association claimed it was the largest such error in banking history. A bank spokesman said the programming errors were corrected and all funds were recovered.
- In August 1991 the concrete base structure for a North Sea oil platform imploded and sank off the coast of Norway, reportedly due to errors in initially-used design software. The enormous structure, on hitting the seabed, reportedly was detected as a magnitude 3.0 seismic event and resulted in a loss of $700 million. The base structure was eventually redesigned and the full platform was completed two years later, and was still in use as of 2008.
- On January 1 1984 all computers produced by one of the leading minicomputer makers of the time reportedly failed worldwide. The cause was claimed to be a leap year bug in a date handling function utilized in deletion of temporary operating system files. Technicians throughout the world worked for several days to clear up the problem. It was also reported that the same bug affected many of the same computers four years later.
- Software bugs in a Soviet early-warning monitoring system nearly brought on nuclear war in 1983, according to news reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet satellites picking up sunlight reflections off cloud-tops, but failed to do so. Disaster was averted when a Soviet commander, based on what he said was a '...funny feeling in my gut', decided the apparent missile attack was a false alarm. The filtering software code was rewritten.
Bug Life Cycle
Life Cycle of Bug:
1) New: When QA files new bug.
2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.
3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.
4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.
6) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.
7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.
8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.
9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.
1) New: When QA files new bug.
2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.
3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.
4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.
6) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.
7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.
8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.
9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.
How To Design Test Cases_By Digvijay
Designing test cases
2.Work break down: Break the requirements into smaller requirements.
3.Create Test Case: For each Requirement, decide what technique you should use to derive the test cases. The below example(s) are using the Basis Path test approach and the test point test approach, to create a test case.
4.Using Basis Path test approach:
Use the design or code as a foundation, draw corresponding flow graph.
Determine the Cyclomatic complexity of the resultant flow graph.
Determine a basis set of linearly independent paths.
Prepare test cases that will for execution of each path in the basis set.
5.Using Test Point Test approach: This approach requires the creation flow graph from the FSD and then the steps as follows:
6.Listing down main test points: Test Points are the main functional points that define functionality. Breaking down functionality into some logical functions, which in itself serves as a separate entity, can derive test points. Each test point can then be further broken down into scenario and subsequently each scenario is broken down into test cases. In simple terms, any point in a functionality that takes a separate path to the outcome can serve as a test point. For Example: In case of Login module, the test points would be:
Correct Input
Incorrect Input
7.Identify Test scenarios: Test Scenario is a software-testing activity. It 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. For Example: In case of login module, the test scenarios would be:
Correct Input
Security
Welcome page
Incorrect Input
Error Messages
8.Identify the Test Cases: Prepare test cases for each scenario.
9.Define Test Objective for each of the Test Cases
10.Identify the Test data (if applicable)
11.Identify Platform/environment
12.Write Down the steps for the test cases
13.Identify the Expected Result
14.Set up the Severity/ Priority Include in traceability matrix: A method used to validate the compliance of a process or product with the requirements for that process or product. The requirements are each listed in a row of the matrix and the columns of the matrix are used to identify how and where each requirement has been addressed.
Some Unix Interview Question By Digvijay
1) State and explain about features of UNIX?
UNIX operating system originally was developed in 1969. This is an open source operating system developed by AT&T. It is widely used in work stations and servers. It is designed to be multi tasking, multi user and portable. UNIX has many several components packed together.
2) Explain about sh?
Sh is the command line interpreter and it is the primary user interface. This forms the programmable command line interpreter. After windows appeared it still retained the programmable characteristics.
3) Explain about system and user utilities?
There are two utilities they are system and user utilities. System utilities contain administrative tools such as mkfs, fsck, etc. Where as user utilities contain features such as passwd, kill, etc. It basically contains environment values.
4) Explain about document formatting?
UNIX systems were primarily used for typesetting systems and document formatting. Modern UNIX systems used packages such as Tex and Ghostscript. It uses some of the programs such as nroff, tbl, troff, refer, eqn and pic. Document formatting is very used because it forms the base of UNIX.
5) Explain about communication features in UNIX?
Early UNIX systems used inter user communication programs mail and write commands. They never contained a fully embedded inter user communication features. Systems with BSD included TCP/IP protocols.
6) Explain about chmod options filename?
This command allows you to change, write, read and execute permissions on your file. Changes can be done to the file system but at times you need to change permissions for the file systems. At times files should be executable for viewing the files.
7) Explain about gzip filename?
Gzip filename is used to compress the files so that those files take up less space. The size of the file actually gets reduced to half their size but they might also depend upon about the file size and nature of the file systems. Files using gzip file name end with .gz.
8) Explain about refer?
Refer was written in Bell Laboratories and it is implemented as a troff preprocessor. This program is used managing bibliographic references and it is used to cite them in troff documents. It is offered in most of the UNIX packages. It refers with text and reference file.
9) Explain about lpr filename?
This command is used to print a file. If you want to change the default print you can change the printer by using the P option. For double sided print you can use lpr-Pvalkyr-d. This is very useful command in UNIX present in many packages.
10) Explain about lprm job number?
This command is used to remove documents from the printer queue. The job number or the queue number can be found by using lpq. Printer name should be specified but this is not necessary if you want to use your default printer.
11) Brief about the command ff?
This command finds files present anywhere on the system. This command is used to find document location where you forgot the directory in which you kept the file but you do remember about the name. This command is not restricted in finding files it displays files and documents relevant to the name.
12) Brief about finger username?
This command is used to give information about the user; it gives out a profile about the user. This command is very useful for administrators as it gives the log information, email, current log information, etc. finger also displays information such as phone number and name when they use a file called .plan.
13) Explain about the command elm?
This command lets you to send email message from your system. This command is not the only one which sends email there are lots of other messenger systems which can facilitate the process of sending a mail. This command behaves differently on different machines.
14) Brief about the command kill PID?
This command ends the process to which it was assigned (ID). This command cannot be used in multi systems in the network. ID can be obtained by the command ps. This command ignores completely the state at which the process is it kills the process.
15) Explain about the command lynx?
This command helps you to browse web from an ordinary terminal. Text can be seen but not the pictures. URL can be assigned as an argument to the G command. Help section can be obtained by pressing H and Q makes the program to quit.
16) Brief about the command nn?
This command allows you to read the news. First you can read about the local news and then the remote news. "nnl” command makes or allows you to read local news and nnr command is used to read remote news. Manual and help information is available with many popular packages.
17) Brief about ftp hostname?
This command lets you download information, documents, etc from a remote ftp. First it is important to configure an FTP for the process to begin. Some of the important commands relevant to the usage of FTP are as follows get, put, mget, mput, etc. If you are planning to transfer files other than ASCII defined it is imperative to use binary mode.
UNIX operating system originally was developed in 1969. This is an open source operating system developed by AT&T. It is widely used in work stations and servers. It is designed to be multi tasking, multi user and portable. UNIX has many several components packed together.
2) Explain about sh?
Sh is the command line interpreter and it is the primary user interface. This forms the programmable command line interpreter. After windows appeared it still retained the programmable characteristics.
3) Explain about system and user utilities?
There are two utilities they are system and user utilities. System utilities contain administrative tools such as mkfs, fsck, etc. Where as user utilities contain features such as passwd, kill, etc. It basically contains environment values.
4) Explain about document formatting?
UNIX systems were primarily used for typesetting systems and document formatting. Modern UNIX systems used packages such as Tex and Ghostscript. It uses some of the programs such as nroff, tbl, troff, refer, eqn and pic. Document formatting is very used because it forms the base of UNIX.
5) Explain about communication features in UNIX?
Early UNIX systems used inter user communication programs mail and write commands. They never contained a fully embedded inter user communication features. Systems with BSD included TCP/IP protocols.
6) Explain about chmod options filename?
This command allows you to change, write, read and execute permissions on your file. Changes can be done to the file system but at times you need to change permissions for the file systems. At times files should be executable for viewing the files.
7) Explain about gzip filename?
Gzip filename is used to compress the files so that those files take up less space. The size of the file actually gets reduced to half their size but they might also depend upon about the file size and nature of the file systems. Files using gzip file name end with .gz.
8) Explain about refer?
Refer was written in Bell Laboratories and it is implemented as a troff preprocessor. This program is used managing bibliographic references and it is used to cite them in troff documents. It is offered in most of the UNIX packages. It refers with text and reference file.
9) Explain about lpr filename?
This command is used to print a file. If you want to change the default print you can change the printer by using the P option. For double sided print you can use lpr-Pvalkyr-d. This is very useful command in UNIX present in many packages.
10) Explain about lprm job number?
This command is used to remove documents from the printer queue. The job number or the queue number can be found by using lpq. Printer name should be specified but this is not necessary if you want to use your default printer.
11) Brief about the command ff?
This command finds files present anywhere on the system. This command is used to find document location where you forgot the directory in which you kept the file but you do remember about the name. This command is not restricted in finding files it displays files and documents relevant to the name.
12) Brief about finger username?
This command is used to give information about the user; it gives out a profile about the user. This command is very useful for administrators as it gives the log information, email, current log information, etc. finger also displays information such as phone number and name when they use a file called .plan.
13) Explain about the command elm?
This command lets you to send email message from your system. This command is not the only one which sends email there are lots of other messenger systems which can facilitate the process of sending a mail. This command behaves differently on different machines.
14) Brief about the command kill PID?
This command ends the process to which it was assigned (ID). This command cannot be used in multi systems in the network. ID can be obtained by the command ps. This command ignores completely the state at which the process is it kills the process.
15) Explain about the command lynx?
This command helps you to browse web from an ordinary terminal. Text can be seen but not the pictures. URL can be assigned as an argument to the G command. Help section can be obtained by pressing H and Q makes the program to quit.
16) Brief about the command nn?
This command allows you to read the news. First you can read about the local news and then the remote news. "nnl” command makes or allows you to read local news and nnr command is used to read remote news. Manual and help information is available with many popular packages.
17) Brief about ftp hostname?
This command lets you download information, documents, etc from a remote ftp. First it is important to configure an FTP for the process to begin. Some of the important commands relevant to the usage of FTP are as follows get, put, mget, mput, etc. If you are planning to transfer files other than ASCII defined it is imperative to use binary mode.
Monday, September 6, 2010
Today's Flashback
Question: what is traceability matrix??
-------------------------------------------------------------------------------
This matrix defines the mapping between customer requirements and prepared testcases by testengineers.this matrix is requirements traceability matrix or requirements validation matrix.this is used by testing team to verify how far the testcases prepared have covered the requirements of the functionalities to be tested.
-------------------------------------------------------------------------------
This matrix defines the mapping between customer requirements and prepared testcases by testengineers.this matrix is requirements traceability matrix or requirements validation matrix.this is used by testing team to verify how far the testcases prepared have covered the requirements of the functionalities to be tested.
Ajax technology: Must Read
Hi All,
You must read this article to be aware about ajax technology....I know there are many people which are always heard about this technology but don't know about it...Here we go ...
Download
Thanks :)
You must read this article to be aware about ajax technology....I know there are many people which are always heard about this technology but don't know about it...Here we go ...
Download
Thanks :)
Sunday, September 5, 2010
Have a blast with QTP
Hi All,
Its time to say bye bye to all type of manual testing.....Lets start with some automation tool like QTP..
Download Here
For video link click here:
Download Video
Some basic but valuable interview questions
Hi All,
Here some basic but valuable questions for you that will help you to crack any interview.
Download Here
Here some basic but valuable questions for you that will help you to crack any interview.
Download Here
Friday, September 3, 2010
Thursday, September 2, 2010
What is Agile Testing.?
Hi All,
I know there will be lot of Questions in your mind regarding "Agile Testing"...
Agile testing is a software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. Agile testing does not emphasize rigidly defined testing procedures, but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective. In other words, the emphasis is shifted from "testers as quality police" to something more like "entire project team working toward demonstrable quality."
The Word Agile means "Moving Quickly" and this explains the whole concept of Agile Testing. Testers have to adapt to rapid deployment cycles and changes in testing patterns.
Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing.
Since working increments of the software are released often in agile software development, there is also a need to test often. This is commonly done by using automated acceptance testing to minimize the amount of manual labor involved. Undertaking only manual testing in agile development may result in either buggy software or slipping schedules, as it may not be possible to test the entire build manually before each release.
In Agile Testing, testers are no longer a form of Quality Police. Testing moves the project forward leading to new strategy called Test Driven Development. Testers provide information, feedback and suggestions rather than being last phase of defense.
Testing is no more a phase; it integrates closely with Development. Continuous testing is the only way to ensure continuous progress.
Reduce feedback loops, Manual regression tests take longer to execute and, because a resource must be available, may not begin immediately. Feedback time can increase to days or weeks. Manual testing, particularly manual exploratory testing, is still important. However, Agile teams typically find that the fast feedback afforded by automated regression is a key to detecting problems quickly, thus reducing risk and rework.
Keep the code clean. Buggy software is hard to test, harder to modify and slows everything down. Keep the code clean and help fix the bugs fast.
Lightweight Documentation Instead of writing verbose, comprehensive test documentation.
Agile testers:
- Use reusable checklists to suggest tests
- Focus on the essence of the test rather than the incidental details
- Use lightweight documentation styles/tools
- Capturing test ideas in charters for Exploratory Testing
- Leverage documents for multiple purpose
Subscribe to:
Posts (Atom)