Smoke testing involves basic testing to check if a program runs and performs very basic functions like opening a window and buttons responding to clicks. GUI testing focuses on user interface elements like buttons, menus and windows. Functional testing verifies program features and functions according to requirements. Regression testing is done after functional testing to check that changes didn't break existing functionality, and confirmation testing ensures changes were implemented correctly.
10. Testing Order
Smoke
• Executed each time the new build is ready
GUI
+Functional
• Only if Smoke testing passed
Regression
• After all functional tests are executed
• Usually comes with confirmation testing phase
Test types are introduced as a means of clearly defining the objective of a certain test level for a program or project. In this course we will concentrate on Smoke, GUI, Functional, Confirmation and Regression testing types that are applied at System Testing Level.System testing is a process of testing an integrated system to verify that it meets specified requirements.System testing is concerned with the behavior of the whole system/product as defined by the scope of a development project or product. It may include tests based on risks and/or requirements specification, business processes, use cases, or other high level descriptions of system behavior, interactions with the operating system, and system resources. System testing is most often the final test on behalf of development to verify that the system to be delivered meets the specification and its purpose may be to find as many defects as possible. Each of Testing Types specific for System Testing Level are explained on next slides.
A daily build and smoke test are among industry best practices. Microsoft claims that after code reviews, "smoke testing is the most cost effective method for identifying and fixing defects in software". Smoke tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.Smoke tests can be broadly categorized as functional tests. Functional tests exercise the complete program with various inputs. Functional tests may be a scripted series of program inputs, possibly even with an automated mechanism for controlling mouse movements.
In fact, it is rather hard to separate GUI testing and Functional testing, because testing the functionality of a GUI-based application fully covers the GUI interoperability.So when we say GUI testing we mean verification of the application’s GUI compliance with the defined standards.Common standards for some type of applications (Web, Desktop, …) or specific Client’s requirements can be used as basis for testing. This type of testing also is pretty close to Usability testing, because mentioned standards and even specific Client’s requirements usually are based on usability conceptions.As an example Microsoft has a GUI standard which is called: Windows User Experience Interaction Guidelines. Apple has: iOS Human Interface Guidelines, etc…
Functional testing is a type of testingthat bases its test cases on the specifications of the software application under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.Functional testingis intended to test the application functionality to ensure business logic, required algorithms, use cases flows are met according to the defined functional specification(s).The function of a system (or component) is 'what it does'. This is typically described in a requirements specification, a functional specification, or in use cases. Functional tests are based on these functions, described in documents or understood by the testers and may be performed at all test levels (e.g. test for a system may be based on a system specification, while tests of components may be based on a component specification).
When a test fails and we determine that the cause of the failure is a software defect, the defect is reported, and we can expect a new version of the software that has had the defect fixed. In this case we will need to execute the test again to confirm that the defect has indeed been fixed. This is known as confirmation testing (also known as re-testing). As per example shown on a picture - our system has 2 functions: Function A and Function B. Both these functions use Common Library module which contains various specific sub-functions. Our QC Team had written two tests for both functions in correspondence: Test FA and Test FB. Both these tests PASS on the current build 1.0.0 of our system.In the next build (1.0.1), development team had introduced some changes into behavior of Function B and that also required some changes in a Common Library module.Our QC Team had updated test case Test, so it now expects output of a changed Function B.QC Team reruns Test FB and gets the result - PASS. That means we have performed confirmation testing. We had confirmed, that Function B is working as expected after changes applied .