What is it?
It’s a process of executing a program or application with the intent of finding evidence of software bugs. (from ISTQB)
It’s an agreement among the software development team. It defines the product they are creating, detailing what it will be, how it will act, and what it can or can’t do.
What are bugs?
Formally, we say that a bug occurs when one or more of the following five rules is true: when the software
- doesn’t do something that the product specification says it should do.
- does something that the product specification says it shouldn’t do.
- does something that the product specification doesn’t mention.
- doesn’t do something that the product specification doesn’t mention but should.
- is difficult to understand, hard to use, slow, or in the software tester’s eyes will be viewed by the end user as just not right.
“Software quality is the degree of conformance to explicit or implicit requirements and expectations.” (ISTQB)
Another definition would be:
Software is reasonably bug or defect free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.
To ensure quality we undertake Software Quality Assurance (SQA) and Software Quality Control (SQC)
Software Quality Assurance
A set of activities for ensuring quality in software engineering processes that ultimately result in quality in software products. SQA focuses on the process and is oriented towards prevention. This includes the activities of auditing, training, and process definition & implementation. Once these are done, this has the responsibility of identify weaknesses in the processes and to correct those weaknesses to continually improve the process.
Software Quality Control
A set of activities for ensuring that the product will meet its expected quality. It focuses on the product and is oriented towards detection. SQC is limited to the Review/Testing phases of the Software Development Life Cycle and the goal is to ensure that the products meet specifications/requirements.
It is involved in:
Software Testing Lifecycle
It might be different in other companies/teams but usually it follows this diagram
They do not necessarily have to be in the order listed; some phases can sometimes run in parallel, be done in reverse order (you’re in trouble), or even be skipped altogether to save time (you’re in really big trouble)
Software Testing Levels
Individual parts of a software are tested separately. The purpose is to validate that each unit of the software performs as designed. Generally conducted by the developers or their team mates. This form of testing is rarely performed by software testers. In order to perform integration testing it is important to first complete the unit testing for all the units.
Individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units. This form of testing is carried out a software testing engineer.
Complete and fully integrated software is tested. The purpose of this test is to evaluate the system’s compliance with the specified requirements. This type of testing is performed by a specialized testing team.
System is tested for acceptability & validates the end to end business flow. Quality assurance team comes and haves a look at the system and test it for quality with the help of predefined test scenarios and test cases. The software is tested for accuracy.
The box approach (coz why not)
- White Box Testing
- Gray Box Testing
- Black Box Testing
White Box Testing
A software testing method in which the internal structure of the item being tested is known to the tester. They go through the code and test conditions and flow of logic.
Black Box Testing
A tester, without knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.
Gray Box Testing
The internal structure is partially known. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level.
and some handout that I can’t find anymore
Why do this?