In this article, I will explain important software testing techniques which help you during test and User Acceptance Testing (UAT) processes.

Disclaimer: The knowledge in this article is based on my experiences, understanding, and observation. If you don’t agree on anything in the article, please write a comment and we will discuss the thing that you disagree.

What is User Acceptance Test (UAT)?

Product Owners (PO) and business units generally work on requirements and focus them. Thus, they can use the requirement-based and activity-based test techniques during UAT process. As we testers, we can also use these techniques in test process as well. I am going to explain some of these techniques in this article. But first, let start with what UAT testing is.

In agile methodologies, it is the test activity which performed by generally product owners after the completion of the development and software testing process of the stories. In waterfall and V-model processes, these tests are generally performed by analysts or business units. The purpose of the UAT is to determine whether the user’s requirements for the requested job have been met and to get the approval for the live deployment.

A sample entry and exit criteria for the user acceptance test are summarized in the following table.

Entry Criteria

● Code Written
● Code Reviewed
● Unit Tests Executed and Defects Fixed
● Tests Executed
● Resolved all High and Medium Priority Levels of Defects
● Prepared Test Data to be used in UAT

Exit Criteria

● All UAT Scenarios Executed
● All Acceptance Criteria Tested
● Reached Target Quality Level (> = 90%), (Passed Test Cases / Passed + Failed Test Cases)
● Defects Resolved (Priority> = Major)

1) User Story Testing (AGILE)

A user story can be described as a requested feature that is in the software from the perspective of the end user in agile software development life cycle. In user story, we have to specify the demand, the reason of the demand, and the user who is requesting it.

Definition of Done (DOD) defines the completion criteria such as code is done, unit test is done, testing is done, UAT is done, etc… and Scrum guide states that Scrum team (developers, testers, PO etc.) owns  and  responsible for DOD.

Also, acceptance criteria should be expressed clearly by POs (development team may help PO) and at least one test scenario for each acceptance criteria should be prepared in the test process of a user story and these acceptance criteria has to be tested carefully.

The test entry and exit criteria must also be defined before starting the test run. Here is an example.

Test Entry Criteria

● Does the requested user, the need and the reason of necessity are clearly understood?
● The risk associated with the demand specified in the User Story?
● The impact analysis specified in User Stoy?
● DOD’s acceptance criteria stated clearly?
● Non-functional requirements identified with expected metrics? (Performance, security, etc.)
● If there are integrations of the development, are they specified?
● Development Done?
● Static Code Analysis Done?
Unit Tests were written and defects fixed?
● Code Review?
● Test Scenarios Written?
● Test Cases reviewed by the PO / Analyst?
● Critical tests reviewed and executed with Developers in Dev Environment? (Desk Check)
● Test environment prepared for testing?
● Data required for the test prepared in the test environment?
● Database changes transferred to the test environment?
● Configurational settings applied to the test environment?
● Prerequisites identified before starting the test?

Test Exit Criteria

● All Test Scenarios Executed and All Acceptance Criteria Tested
● Functional and Non-Functional needs were tested.
● Target Quality Level Meet  (> = 85%), (Passed Test Cases / Passed + Failed Test Cases)
● Defects Fixed (Priority> = Medium)

Sample User Story

User Story 1:

As a Product Owner [User], in order to advertise Kariyer.net welcome campaign [reason of demand], I would like the advertisement banner to be added to the top banner section of the Kariyer.net homepage [demand].

Risks:

  • Homepage speed may be reduced
  • A bug in the animation of banner will affect the homepage appearance
  • Continuous deletion of cookies can cause the banner to be continuously visible on the user side.
  • The function of the Close Banner icon critical. It should work continuously and successfully.

Impact Analysis:

  • The banner loading function may be affected in the Admin panel.

Definition of Done:

  • Code Writing Done
  • Code Review Done
  • Unit Testing Done
  • UAT Done

Acceptance Criteria:

  • When Kariyer.net homepage is opened, the top banner is displayed as 200×200 for 8 seconds and then it should be seen as 60×60.
  • When the user clicks on the banner, it should be directed to the Welcome page.
  • If a user visited Kariyer.net more than 4 times from the same computer, AA-kobiBannerClosed cookie value should be 4 and more and banner should not be displayed.
  • The top right corner of the banner must have a cross-shaped closing icon and the banner must be closed when it is clicked.
  • If the banner was previously turned off by the user, it should not be displayed again.

test techniques

2) Use Case Testing

A use case defines the operations that a user/actor performs in the system to achieve a specific purpose. Functional requirements of a system can be defined and managed using use cases. In this way, the scope of the desired or requested job is determined. Tests scenarios are prepared by taking into consideration the inputs and outputs of the steps determined by the user to reach a specific purpose. During the tests, the results of the tests are determined by comparing the expected outputs with the actual outputs.

When writing Use-cases, generally business language is preferred instead of technical language. Therefore they are often used in writing acceptance tests. In order to cover all requirements, at least one test scenario is prepared for each requirement. By this way, test coverage can be increased and we can measure this coverage also by using traceability matrix. In the traceability matrix, we create a matrix table with test scenarios and requirements and put a cross sign in the relevant field if it meets the requirements for each test case. The goal is to cover all the requirements.

Scenario NoS.1
Scenario Name:Changing Login Password
Connected RequirementsR.4
Affected ScreensHome Page, Login Page, Account Page
PrerequisitesAn existing user on the system
Normal Flow:1. The user opens the Kariyer.net homepage and clicks on the Member Login button.

2. Login to the site with the existing username and password on the login screen.

3. Click the “My Account Settings” in the pop-up menu.

4. Click the “Change Password” link under the “Personal Information Settings:” section on the Account Settings page.

5. The old password