HOV QA Engineers
  • ๐Ÿ”HOV QA Engineers
  • AGILE TESTING
    • ๐Ÿ’ปCSS elements for QA
    • ๐Ÿ›ซOn-boarding QA
    • ๐ŸคTesters Communications, Task and Responsibilities
    • โ™ป๏ธSoftware Testing Life cycle
    • ๐Ÿ““Test Plan
    • ๐ŸŽŸ๏ธKanban board and ticket flows
    • ๐Ÿ““User Stories and Acceptance Criteria
    • ๐Ÿ‘ฃGherkin syntax
    • ๐Ÿค–Test Design
    • ๐Ÿ“…Test Strategy
    • ๐Ÿ‘ฌTypes of Testing strategy
    • ๐ŸงชTesting types
    • ๐Ÿ›Bug and Bug life Cycle
    • โœ๏ธManual Testing
    • Automation testing
    • ๐Ÿ‘ทโ€โ™‚๏ธE2E Testing
    • E2E testing best practices
    • Accessibility testing
    • Performance testing
    • Mobile Testing
  • Tools and Guidelines
    • Software QA Engineer Roadmap
    • ๐Ÿ’ปSetup Cypress v10 E2E testing
    • ๐ŸงชSetup End to end test with Cypress test suite
    • Setup Performance test with k6
    • API testing with postman
    • Building GitHub Action part 1
    • โœ๏ธPlaywright + Cucumber
  • Training Videos
    • SQA Trainings
  • Research
    • ๐Ÿ“ฑMobile Automation with Appium
      • Setup Project and Configuration (Android)
    • ๐ŸŽญPlaywright - Web Apps E2E Testing Tool
      • Setup Project and Configuration (Android)
    • Testing Library
  • PROJECTS
    • Page 2
    • Opexa
    • ๐Ÿ“ฃIdentifi
      • โš–๏ธSQA Metrics and Testing progress
      • ๐ŸงชManual testing
        • WEB
          • Sanity Testing
          • Regression Test cases
          • Credentials and URLs
        • Android
          • Sanity Testing
          • Regression Testing
          • End to end Testing
          • Credentials
        • IOS
          • Sanity Testing
          • Regression Testing
      • ๐Ÿ“”API Testing
      • ๐Ÿค–Web Automation
        • E2E Automation Test Plan
        • Web Automation Setup
          • ๐ŸšงSetup WSL2 Environment for Windows
          • ๐Ÿ—๏ธSetup local Environment (Linux/Ubuntu)
        • Regression Testing Coverage
        • Sanity Testing Coverage
      • ๐ŸŽญPerformance Testing
        • K6 Test Runs
      • ๐Ÿ“ดMobile Automation
        • Mobile Automation Test Plan
        • Identifi Mobile Automation Setup
      • Page 1
    • ๐Ÿ–ผ๏ธsubsit
      • Test plan
      • Smoke Test cases
      • ๐ŸงชTest Scenarios
      • ๐Ÿ•ธ๏ธWeb Automation
    • ๐ŸงตThreadSync
      • Test Plan
    • ๐Ÿ‘๏ธUpWatch
      • Product Requirement
      • Test plan
      • Monitoring & Bug Reporting
      • E2E Test
        • E2E UpWatch Test
      • E2E QA Automation
    • ๐ŸŽฒWallet
      • ๐ŸงฌTest Plan
      • ๐Ÿ’ปE2E Wallet Automation Test Plan
      • ๐Ÿ“–E2E Test Automation Docs
      • ๐Ÿ“‘Credentials| Urls
      • ๐Ÿ“šWallet Feature List
    • ๐Ÿ‘จโ€๐Ÿ’ปDevLuvs
      • ๐ŸงชTest Cases
      • ๐Ÿ”‘Credentials For Automation
        • ๐Ÿค–Automation Test Cases
      • ๐Ÿ“ŠAutomation Board
    • โš™๏ธMehira
      • ๐Ÿ•ธ๏ธWeb Automation
      • Sanity Testing Document
      • How to start running Mehira application from your local using Docker engine via Ubuntu platform
Powered by GitBook
On this page
  • Two distinct ways of preparing and performing tests
  • Reporting based on test results
  1. AGILE TESTING

Test Design

PreviousGherkin syntaxNextTest Strategy

Last updated 2 years ago

Test design is a process that describes โ€œhowโ€ testing should be done. It includes processes for the identifying test cases by enumerating steps of the defined test conditions. The testing techniques defined in test --

In short it focuses on the creation and execution of the test. It can be as simple as exploratory testing or a coverage base with test cases.

Two distinct ways of preparing and performing tests

Test approach are divided into two:

A group of test approach where it do not follow strict rules, instead testers rely based on their skills, intuition and experience of the test.

Pursued value: Requirements and Specifications

A structured approach to testing that aims to demonstrate a specific type of coverage by applying one or more test design techniques. A structured way of detailing information from one level to another.

Pursued value = Requirements and Specifications

Base from the requirements and specifics, the Quality risk is identified. And with those two, the Test situations are identified. Given with Test situations, test cases and test data can be created. Test cases then be combined into scenarios and be written into test scripts(automated). The actual outcome then be compared to the expected outcomes.

Outcome possibilities:

  • If the outcomes match, this means the test has passed, the quality risk is covered, the requirement implemented and the stakeholders can be informed through the reports that this part of the pursued value seems to be achievable.

  • If the expected and actual outcomes do not match, this means the test failed and a quality risk has materialized, and the requirement is not yet implemented. Therefore, the stakeholders must be informed through the reports that this part of the pursued value is not yet achievable.

Reporting based on test results

  • Detailed reporting for the members of the DevOps team and their direct contacts.

  • Overview reporting for people that look upon the test object from a business perspective such as the product owner and users.

  • High-level reporting for the stakeholders that are more distant to the team's activities such as high-level managers.

It is wise to combine Experience and Coverage base testing when performing and preparing test.

When the quality risks are relatively low, testers may decide to mainly apply experience-based testing. Still, if the tester for example encounters a boundary value during exploratory testing, it is very wise to apply boundary value analysis on the spot and make a test for each boundary value.

On the other hand, when the quality risk level (or any other good reason) is such that coverage-based testing is the main approach, then some experience-based testing is still a good thing to do. For example, investigating unexpected outcomes, or giving an important stakeholder a chance to see for themselves that the system actually works (because nothing adds so much to confidence as seeing it with their own eyes).

๐Ÿค–
Page cover image
http://tryqa.com/