Hubbry Logo
Functional testingFunctional testingMain
Open search
Functional testing
Community hub
Functional testing
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Functional testing
Functional testing
Functional testing
View on Wikipedia
from Wikipedia

In software development, functional testing is a form of software testing that verifies whether a system meets its functional requirements.[1][2]

Generally, functional testing is black-box, meaning the internal program structure is ignored (unlike for white-box testing).[3]

Sometimes, functional testing is a quality assurance (QA) process.[4]

As a form of system testing, functional testing tests slices of functionality of the whole system. Despite similar naming, functional testing is not testing the code of a single function.

The concept of incorporating testing earlier in the delivery cycle is not restricted to functional testing.[5]

Types

[edit]

Functional testing includes but is not limited to:[3]

Sanity testing

[edit]
These paragraphs are an excerpt from Sanity check.[edit]

A sanity check or sanity test is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true. It is a simple check to see if the produced material is rational (that the material's creator was thinking rationally, applying sanity). The point of a sanity test is to rule out certain classes of obviously false results, not to catch every possible error. A rule-of-thumb or back-of-the-envelope calculation may be checked to perform the test. The advantage of performing an initial sanity test is that of speedily evaluating basic function.

Smoke testing

[edit]
These paragraphs are an excerpt from Smoke testing (software).[edit]

In computer programming and software testing, smoke testing (also confidence testing, sanity testing,[6] build verification test (BVT)[7][8][9] and build acceptance test) is preliminary testing or sanity testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of test cases that cover the most important functionality of a component or system, used to aid assessment of whether main functions of the software appear to work correctly.[6][7] When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called a pretest[10] or an intake test.[6] Alternatively, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team.[11] In the DevOps paradigm, use of a build verification test step is one hallmark of the continuous integration maturity stage.[12]

Regression testing

[edit]
These paragraphs are an excerpt from Regression testing.[edit]

Regression testing (rarely, non-regression testing[13]) is re-running functional and non-functional tests to ensure that previously developed and tested software still performs as expected after a change.[14] If not, that would be called a regression.

Usability testing

[edit]
These paragraphs are an excerpt from Usability testing.[edit]

Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system.[15] It is more concerned with the design intuitiveness of the product and tested with users who have no prior exposure to it. Such testing is paramount to the success of an end product as a fully functioning application that creates confusion amongst its users will not last for long.[16] This is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users.

Six steps

[edit]

Functional testing typically involves six steps[citation needed]

  1. The identification of functions that the software is expected to perform
  2. The creation of input data based on the function's specifications
  3. The determination of output based on the function's specifications
  4. The execution of the test case
  5. The comparison of actual and expected outputs
  6. To check whether the application works as per the customer need

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Functional testing

View on Grokipedia
from Grokipedia
Functional testing is a type of that verifies whether a software application or system meets its specified functional requirements by evaluating the actual output against expected results based on the product's specifications. It focuses on the core functionalities of the software, ensuring that each feature performs as intended from the end-user's perspective, without examining the internal code structure. As a form of , functional testing treats the software as an opaque entity, prioritizing inputs, outputs, and user interactions over details. The process typically involves identifying key functions, creating relevant test data, defining expected outcomes, executing test cases, and comparing results to detect discrepancies. This approach is essential for , as it confirms that the software aligns with business requirements and supports reliable workflows, thereby reducing the risk of functional defects in production. Functional testing encompasses several levels, each targeting different scopes of the software: examines individual components or modules in isolation to verify their standalone functionality; assesses how multiple components interact when combined; evaluates the complete, integrated system against overall requirements; and involves end-users to confirm the software meets operational needs. These levels build progressively, often automated for efficiency in pipelines, and differ from , which addresses aspects like , , and rather than behavioral correctness.

Fundamentals

Definition and Scope

Functional testing is a software testing methodology that verifies whether a component or system complies with specified functional requirements by evaluating its behavior in response to various inputs, focusing on expected outputs and user interactions rather than internal implementation details. This approach treats the software as a "," assessing external functionality without examining the underlying code structure, thereby ensuring the system performs as intended from an end-user perspective. The scope of functional testing extends to validating end-to-end behaviors across user interfaces, application programming interfaces (APIs), and core business logic, confirming that the software meets its documented specifications under normal and edge-case conditions. It deliberately excludes non-functional attributes such as performance efficiency, security vulnerabilities, or usability ergonomics, which are addressed through separate testing paradigms. This boundary ensures focused validation of "what" the software does, aligning directly with requirement specifications to support overall . Functional testing originated in the 1970s amid the adoption of paradigms, which promoted specification-driven development and , necessitating rigorous verification of functional behaviors. Its formalization came with the publication of IEEE Standard 829-1983, which established standardized documentation practices for test plans, cases, and reports to support systematic functional validation in software projects. While IEEE 829-1983 provided early formalization, it has been superseded by ISO/IEC/IEEE 29119-3:2013 for modern test documentation practices. Central attributes of functional testing include requirement traceability, achieved through mechanisms like the Requirements Traceability Matrix (RTM) to map tests back to originating specifications, ensuring comprehensive coverage and impact analysis for changes. Pass/fail determinations rely strictly on conformance to these specifications, with success indicating alignment between observed outputs and required behaviors. The black-box methodology underpins these attributes, promoting tester independence and reproducibility across development cycles.

Key Principles

Functional testing incorporates several key concepts and practices from established standards in software testing, such as those outlined by ISTQB, to guide the design, execution, and evaluation of tests for reliable outcomes. The concept of emphasizes that every test case should be directly linked to a specific or user need, enabling comprehensive coverage and facilitating impact when requirements change. This linkage, often documented via a matrix, allows testers to verify that all functional aspects are addressed and to identify gaps in test coverage efficiently. By maintaining bidirectional —forward from requirements to tests and backward from tests to requirements—teams can ensure that testing aligns precisely with business objectives, reducing the risk of overlooked functionalities. Independence in functional testing benefits from levels of independence, ranging from low (e.g., developer self-testing) to high (e.g., fully independent external teams), with higher often yielding more objective results in functional validation, as per ISTQB guidelines. This separation promotes thorough scrutiny of user interfaces, workflows, and without preconceived assumptions about the code's behavior. Repeatability ensures that functional test cases yield consistent results when executed under identical conditions, which is crucial for validating fixes and . Well-defined test procedures, including precise inputs, expected outputs, and environmental setups, allow tests to be rerun reliably, supporting where variability from human intervention is eliminated. This practice underpins the reliability of functional testing by confirming that observed behaviors are reproducible, thereby building confidence in the software's stability across iterations. Defect clustering recognizes that a disproportionate number of defects tend to concentrate in specific modules or functionalities, often those with high complexity or frequent changes, informing risk-based prioritization in functional testing efforts. As outlined in ISTQB principles, this uneven distribution—sometimes following the 80/20 rule where 80% of defects arise from 20% of the components—guides testers to allocate more resources to vulnerable areas, such as critical user paths or integrations, rather than spreading efforts uniformly. Analyzing historical defect data helps predict and target these clusters, optimizing coverage without exhaustive testing. Early testing integrates functional verification activities from the requirements phase onward, allowing defects to be identified and resolved upstream to minimize downstream costs and rework. Per ISTQB, initiating testing during —through reviews and static analysis—prevents issues from propagating into design and implementation, where fixes are more expensive; for instance, a misunderstood caught early avoids extensive code revisions later. This proactive approach aligns functional testing with the lifecycle, fostering iterative improvements and higher overall quality.

Comparison with Other Testing Approaches

Functional vs Non-Functional Testing

Functional testing evaluates whether a software component or system satisfies its specified functional requirements, verifying that it produces the correct outputs for given inputs based on or user needs. For instance, in an application, functional testing would confirm that adding items to a updates the total price accurately and proceeds to checkout without errors. The primary criteria here are the correctness and completeness of features against documented , often conducted as without examining internal code structure. In contrast, determines if the software complies with non-functional requirements, which encompass qualities such as , reliability, , and . Continuing the example, non-functional testing might assess how quickly the cart updates under concurrent user loads or whether the system remains accessible during peak traffic without . Evaluation relies on quantitative metrics, including response times, error rates under stress, or resource utilization, to ensure the system meets operational standards beyond mere behavioral correctness. Although functional testing may incidentally uncover non-functional issues—such as a feature working correctly but too slowly to be usable—it does not systematically quantify or target these qualities, avoiding overlap in measurement and focus. This distinction maintains clear boundaries, as functional tests prioritize requirement for feature validation, while non-functional tests emphasize quality attribute mapping. Within the software development lifecycle, functional testing typically precedes or parallels in structured models like the , where it verifies requirements during unit and integration phases before broader system qualities are assessed. In agile environments, both occur iteratively across sprints, enabling ongoing feedback on features and to support rapid increments. Maintaining this separation benefits overall by ensuring comprehensive coverage of both behavioral accuracy and systemic attributes; misclassifying tests can lead to gaps, such as overlooking flaws in a functionally sound application.

Functional vs Structural Testing

Functional testing, also known as specification-based or , involves evaluating a software component or system against its specified requirements without knowledge of its internal structure. This approach focuses on verifying the external behavior, inputs, and outputs to ensure the software meets user expectations and functional specifications, such as checking if a feature authenticates users correctly based on provided credentials. In contrast, structural testing, referred to as structure-based or , examines the internal of the software, including paths, branches, and flows, to assess details. It employs metrics like statement coverage, which measures the percentage of lines executed during testing, or path coverage, which evaluates the completeness of execution paths through conditional branches. Key differences between the two lie in their methodologies and perspectives: functional testing relies on requirements documents or user stories to derive test cases, treating the system as opaque, whereas structural testing uses code analysis tools, such as static analyzers or debuggers, to design tests that probe internal logic. Functional testing adopts a user-centric viewpoint, simulating real-world usage to validate end-to-end functionality, while structural testing is developer-centric, aiming to uncover defects in that might not manifest externally. These distinctions ensure complementary coverage, with functional tests addressing "what" the software does and structural tests focusing on "how" it achieves that behavior. Functional testing is typically applied for end-user validation after development, such as in or phases, to confirm the software aligns with needs without requiring access. Structural testing, however, is employed during the unit testing phase to enhance quality, identifying issues like unhandled branches or inefficient algorithms early in the lifecycle. This phased usage aligns with the testing pyramid, where functional tests occupy higher layers for broader validation, while structural tests form the foundational unit level. Since the 2010s, the rise of practices has driven a shift toward hybrid models that integrate functional and structural testing within pipelines, enabling automated execution of both for faster feedback loops. Despite this integration, the core distinctions remain intact, as outlined in ISO/IEC/IEEE 29119 standards, which classify test techniques into specification-based and structure-based categories to support adaptable yet rigorous processes.

Types of Functional Testing

Unit and Component Testing

Unit testing involves verifying the smallest testable parts of an application, such as individual functions or methods, to ensure they behave as specified in isolation from other components. These tests are typically automated and use techniques like mocking or stubbing to simulate dependencies, allowing developers to focus on the unit's logic without external interference. For instance, testing a function might involve inputs like 2 + 3 to confirm an output of 5, checking boundary conditions such as zero or negative numbers. Component testing extends this approach to larger assemblies, such as a service module or class, verifying not only individual elements but also their internal interactions while still isolating the component from the broader system. According to ISTQB standards, component testing—often synonymous with module or —targets individual software components to detect defects early and confirm functionality. This level of testing remains focused on developer-written code, using stubs and drivers to mimic external interfaces. Both unit and component testing are developer-led activities conducted early in the life cycle (SDLC), ideally during or immediately after coding, to catch issues before integration. They emphasize high , with industry targets typically aiming for 70-80% to ensure comprehensive validation of executed paths without pursuing exhaustive 100% coverage, which can be inefficient. Frameworks like facilitate this by providing annotations, assertions, and runner classes for Java-based automated tests. These testing practices achieve notable defect detection efficiency, with studies reporting an average rate of 25% of total defects identified at the level, underscoring their role in reducing downstream costs.

Integration Testing

is a level of functional testing that focuses on verifying the interactions between integrated software components or modules, exposing defects in interfaces and flows. It ensures that individually tested units work correctly when combined, such as in database-to-module-to-API integrations, where consistency and communication protocols are validated. This testing detects interface mismatches, incorrect passing, or unexpected behaviors arising from component interactions that alone cannot reveal. Several approaches are employed in integration testing to systematically combine and verify components. The top-down approach starts with higher-level modules, using stubs to simulate lower-level ones, allowing early testing of main control flows. In contrast, the bottom-up approach begins with lower-level modules, employing drivers to mimic higher-level interactions, which facilitates thorough validation of foundational elements before broader assembly. The big-bang approach integrates all components simultaneously, which is simpler to set up but risks difficult due to the complexity of tracing issues across multiple interfaces at once. Unit testing serves as a prerequisite, providing isolated, verified components for these integration efforts. Common scenarios in integration testing include API endpoint validation, where request-response cycles between services are checked for accuracy, error handling, and performance under load. For instance, testing a user registration flow might involve verifying that frontend inputs correctly propagate to backend validation, database storage, and notification services, ensuring seamless data flow without loss or corruption. These scenarios highlight how integration testing confirms end-to-end functionality at module boundaries without encompassing full system scope. Integration testing aims to achieve at component joints, confirming that combined modules fulfill specified behaviors collectively. It commonly uncovers issues like data mismatches, where formats or values fail to align between units, contributing to a significant portion of overall defects—studies indicate around 35% are identified during this phase. Effective coverage metrics, such as interface interaction paths and data flow traces, help quantify these assurances, prioritizing high-risk integrations to maximize defect detection efficiency. In modern practices, containerization technologies like Docker, introduced in 2013, enable isolated integration environments by encapsulating components with their dependencies, facilitating repeatable tests without environmental conflicts. This approach supports rapid setup of mock services and databases, reducing flakiness and accelerating feedback in continuous integration pipelines.

System and Acceptance Testing

System testing represents a critical level of functional testing that evaluates the behavior of a fully integrated software system against its specified functional requirements. This end-to-end process verifies that all components work together seamlessly to deliver the intended functionality, often simulating complete user workflows in a controlled environment. For instance, in an e-commerce application, system testing might encompass the full checkout process, from browsing products and adding items to a cart, through payment processing and order confirmation, ensuring no disruptions occur across the integrated modules. According to the International Software Testing Qualifications Board (ISTQB), system testing focuses on confirming that the system as a whole meets the documented specifications, typically following integration testing to assess the assembled product holistically. Acceptance testing serves as the final validation phase in functional testing, where stakeholders, end-users, or clients confirm that the system aligns with objectives and is suitable for deployment. This includes , conducted by intended users in a simulated operational setting to evaluate and compliance with requirements, as well as alpha testing by internal teams and beta testing with select external users to identify issues in real-world contexts. The primary goal is to ascertain production readiness, with pass/fail criteria directly linked to contractual or needs rather than technical details. The ISTQB defines as formal evaluation respecting user needs, business processes, and requirements, often incorporating exploratory scenarios to mimic actual usage. Both and share key characteristics, such as execution in production-like environments to replicate live conditions, emphasis on realistic user scenarios over isolated components, and alignment of outcomes with overarching functional and business specifications. These phases prioritize defect detection in high-level interactions, such as gaps that disrupt end-to-end processes; industry reports indicate such issues can appear in a significant portion of releases, often stemming from unmet user expectations or integration oversights in broader flows. For example, in a banking application, might validate the complete transaction flow, including initiating a transfer, verifying account balances, and receiving confirmations, to ensure seamless operation without data inconsistencies. Since 2020, a notable trend in these testing practices has been the integration of acceptance validation into pipelines, enabling automated and ongoing checks rather than isolated phases. This shift, driven by adoption, allows for frequent, incremental validations against business criteria, reducing release delays and enhancing agility in dynamic development environments. Research highlights how facilitates , including acceptance elements, to support rapid iterations while maintaining quality gates tied to functional specifications.

Testing Process

Preparation and Planning

Preparation and planning form the foundational stages of functional testing, ensuring that testing activities align with project goals and efficiently verify software functionality. This phase begins with , where the test team reviews software specifications, user stories, and other test bases to identify testable functions and assess their completeness, correctness, and . Defects in requirements are detected early, and additional information is gathered as needed to clarify ambiguities. A requirements traceability matrix (RTM) is developed to link requirements to test conditions and cases, promoting full coverage and enabling throughout the testing lifecycle. Test planning follows, defining the overall scope, objectives, approach, resources, and for functional testing. The scope delineates features to be tested, excluding non-functional aspects, while objectives specify expected outcomes like defect detection rates. Resources include personnel, tools, and budget, with schedules outlining timelines for each activity. is integral, identifying product risks such as failure in critical business functions and prioritizing high-risk areas for intensive testing to optimize effort and mitigate potential impacts. For instance, features with high or receive precedence in test allocation. In test design, detailed test cases are derived from requirements and risk priorities, employing black-box techniques to cover functional suitability characteristics like completeness and correctness. Effort estimation occurs here, using models such as Boehm's Constructive Cost Model () to predict time and resources needed for design, execution, and maintenance, ensuring realistic planning within project constraints. The overview of techniques—such as equivalence partitioning or decision tables—guides case development, with full methodological details addressed in execution phases. Environment setup prepares the for reliable testing, including hardware, software configurations, and network settings that replicate production conditions to avoid false positives or negatives. Test data is generated or selected to match real-world scenarios, ensuring coverage of boundary values and maintaining data confidentiality through anonymization where required. systems manage test artifacts, environments, and code under test to track changes and support . Documentation culminates in the test plan, structured per IEEE Std 829-2008, which outlines the testing approach, deliverables, and responsibilities. It specifies entry criteria—such as availability of stable requirements and environment readiness—and exit criteria, including achievement of coverage goals and resolution of critical defects, to determine phase completion. This standardized format ensures clarity, auditability, and alignment across stakeholders.

Execution and Techniques

The execution phase of functional testing begins with running the predefined test cases against the software application to validate its behavior against specified requirements. Testers execute these cases in a controlled environment, observing outputs and comparing them to expected results, while meticulously pass/fail statuses, defects encountered, and any environmental factors influencing outcomes. Upon identifying failures, defects are reported for resolution, followed by retesting of fixes to confirm corrections; this iterative process ensures ongoing alignment with functional specifications. A key aspect of execution involves , which re-executes selected or all previous test cases after code changes, such as bug fixes or feature additions, to verify that modifications have not introduced new defects or regressed existing functionalities. This practice is essential in iterative development cycles, where frequent updates could otherwise compromise system reliability. Among the primary techniques for designing effective test cases during execution, groups input data into partitions where the software is anticipated to process elements equivalently, enabling testers to select representative values from each group for comprehensive yet efficient coverage without exhaustive enumeration. For instance, for a field accepting ages 18-65, partitions might include invalid (under 18), valid (18-65), and invalid (over 65), with one test per partition. (referencing ISTQB Foundation Syllabus v4.0, Section 4.2) Boundary value analysis enhances partitioning by emphasizing tests at the edges of these equivalence classes, as defects often occur at boundaries due to off-by-one errors or range mishandling; typical cases include the minimum, just above minimum, just below maximum, and maximum values. In an array size input limited to 1-100, tests would target 0 (invalid boundary), 1, 99, 100, and 101 to probe edge behaviors. For scenarios involving intricate conditional logic, decision table testing structures tests via a tabular format that enumerates all combinations of input conditions and corresponding actions, reducing redundancy and ensuring complete combinatorial coverage. An example is an quote system where conditions like age, driving history, and type determine premium actions (e.g., approve, deny, or adjust rate), with the table deriving test cases for each rule intersection. State transition testing focuses on validating finite state machines by modeling valid and invalid transitions between system states in response to events, confirming that the software maintains integrity across sequences. For an order process, states might progress from "pending" to "paid" upon confirmation, then to "shipped," with tests verifying transitions like successful payment and rejecting invalid paths such as shipping without payment. Complementing these structured methods, error guessing employs , experience-driven approaches to devise ad-hoc test cases targeting intuitively probable defect locations, such as common pitfalls in user inputs or integration points, thereby uncovering issues that formal techniques might overlook. In practice, this can involve crafting informal scripts for automated execution of repetitive UI interactions to simulate real-world anomalies.

Tools and Best Practices

Testing Tools and Frameworks

Functional testing employs a range of tools and frameworks to support manual , automated execution, and integration within development pipelines, ensuring comprehensive verification of software behavior. Manual tools focus on organizing and tracking test cases without . Jira, an issue-tracking platform from , facilitates functional test management by allowing teams to create test plans, assign cases, and generate execution reports integrated with agile workflows. TestRail serves as a specialized test case management system, enabling detailed documentation of functional requirements, real-time execution tracking, and customizable reporting dashboards for teams conducting manual tests. Automation frameworks streamline repetitive functional testing tasks across interfaces. Selenium, an open-source project, automates web UI interactions and supports multiple programming languages such as , Python, and , making it suitable for cross-browser functional validation. , built on Selenium's WebDriver protocol, extends automation to mobile functional testing for Android and iOS apps using native, hybrid, or web app elements via a unified . Postman aids API functional testing by providing an intuitive interface for designing requests, asserting responses, and automating collections to verify endpoint behaviors in service-oriented architectures. Unit testing tools underpin functional verification at the component level and often connect to broader ecosystems. , the for unit testing, uses annotations like @Test and assertion methods to isolate and validate individual methods' functionality. Pytest, a flexible Python framework, simplifies unit test writing with its concise syntax, parameterized tests, and plugin ecosystem for functional coverage analysis. Both integrate seamlessly with Jenkins, an open-source server that automates functional test runs in pipelines, triggering executions on code commits to maintain continuous quality checks. Commercial tools offer robust, scalable solutions for complex functional testing needs. (formerly Unified Functional Testing) provides a keyword-driven automation environment for functional tests across desktop, web, mobile, and layers, supporting scripting in alongside visual test design. adopts a approach, allowing codeless functional test creation through risk-based modules that automatically adjust to UI changes, reducing maintenance efforts in enterprise environments. Recent trends emphasize intelligent and distributed testing capabilities. AI-assisted tools like Testim, introduced in 2014 and acquired by in 2022, leverage for self-healing tests and automated generation of functional scenarios, enhancing stability in dynamic web applications. Cloud-based platforms such as enable parallel functional testing on real devices and browsers in the cloud, supporting and scripts to achieve broad compatibility without local infrastructure.

Common Challenges and Solutions

One prevalent challenge in functional testing arises from frequently changing requirements, which can lead to outdated test cases and increased rework as software evolves rapidly in dynamic development environments. To address this, adopting agile iterative testing practices, including of testing into sprints and regular stakeholder reviews, enables teams to adapt test suites incrementally and maintain alignment with evolving specifications. Flaky tests in automated functional testing, where outcomes vary inconsistently due to non-deterministic factors like network latency or race conditions, undermine confidence in test results and waste developer time on false positives. Solutions involve developing robust scripting techniques, such as explicit waits and idempotent test designs, alongside environment stabilization efforts like isolating test runs in containerized setups to minimize timing dependencies. Tools like can help mitigate flakiness through reliable element locators and retry mechanisms. Coverage gaps occur when test suites fail to adequately verify all functional requirements, potentially allowing undetected defects to propagate. Effective countermeasures include tracking key metrics, such as achieving requirement coverage exceeding 90% through traceability matrices, combined with risk-based testing that prioritizes high-impact areas like critical user paths to optimize limited testing efforts. Resource constraints, including limited budgets and personnel, often restrict the scope of functional testing activities, particularly in user acceptance testing (UAT). Strategies to overcome this encompass using prioritization matrices to focus on high-risk functionalities first and UAT to specialized third-party providers, ensuring comprehensive validation without overburdening internal teams. Since 2020, remote functional testing in distributed teams has introduced obstacles like coordination delays and inconsistent environments, exacerbated by the shift to hybrid work models. Cloud-based platforms facilitate resolution by providing scalable, on-demand test environments, while collaboration tools such as TestRail integrations enable real-time test case sharing and progress tracking across geographies. A key metric for evaluating success in addressing these challenges is the defect leakage rate, which measures the percentage of defects escaping to production; industry benchmarks target reductions below 5% through enhanced testing rigor, indicating robust functional validation processes.

References

  1. https://glossary.istqb.org/en_US/term/functional-testing
  2. https://www.ibm.com/think/topics/functional-testing
  3. https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
  4. https://ieeexplore.ieee.org/document/536464
  5. https://ieeexplore.ieee.org/document/810408
  6. https://www.cs.cmu.edu/~luluo/Courses/17939Report.pdf
  7. https://standards.ieee.org/ieee/829/1217/
  8. https://www.iso.org/standard/45142.html
  9. https://glossary.istqb.org/en_US/term/requirements%20traceability
  10. https://istqb.org/?sdm_process_download=1&download_id=3345
  11. https://astqb.org/istqb-foundation-level-seven-testing-principles/
  12. https://astqb.org/assets/documents/ISTQB_CTFL_v4.0_Sample-Exam-C-Answers_v1.0.pdf
  13. https://www.browserstack.com/guide/functional-vs-non-functional-testing
  14. https://www.geeksforgeeks.org/software-engineering/differences-between-functional-and-non-functional-testing/
  15. https://glossary.istqb.org/en_US/term/non-functional-testing
  16. https://circleci.com/blog/functional-vs-non-functional-testing/
  17. https://www.istqb.org/?sdm_process_download=1&download_id=3345
  18. https://www.iso.org/obp/ui/en/#iso:std:iso-iec-ieee:29119:-1:ed-2:v1:en
  19. https://www.erikvanveenendaal.nl/site/wp-content/uploads/ISTQB-Glossary-3.2-terms-used-in-FL2018.pdf
  20. https://wildart.github.io/MISG5020/standards/ISO-IEC-IEEE-29119-1.pdf
  21. https://martinfowler.com/articles/practical-test-pyramid.html
  22. https://onlinelibrary.wiley.com/doi/full/10.1002/smr.2448
  23. https://glossary.istqb.org/en_US/term/component-testing/1
  24. https://istqb-glossary.page/unit-test-framework/
  25. https://toolsqa.com/software-testing/istqb/component-testing/
  26. https://glossary.istqb.org/en_US/term/component-testing
  27. https://www.geeksforgeeks.org/software-engineering/difference-between-component-and-unit-testing/
  28. https://www.headspin.io/blog/testing-early-in-software-development-lifecycle
  29. https://www.sonarsource.com/resources/library/code-coverage-unit-tests/
  30. https://junit.org/
  31. http://carver.cs.ua.edu/Slides/2019/URSSI-WinterSchool/URSSI-WinterSchool-PeerCodeReview.pdf
  32. https://glossary.istqb.org/en_US/term/integration-testing
  33. https://www.browserstack.com/guide/integration-testing
  34. https://www.ranorex.com/blog/integration-testing/
  35. https://athena.ecs.csus.edu/~buckley/CSc231_files/231_Ch21.pdf
  36. https://www.docker.com/blog/shift-left-testing-with-testcontainers/
  37. https://glossary.istqb.org/en_US/term/system-testing
  38. https://glossary.istqb.org/en_US/term/user-acceptance-testing
  39. https://istqb.org/certifications/certified-tester-acceptance-testing/
  40. https://katalon.com/resources-center/blog/test-cases-for-banking-application
  41. https://automationhq.ai/ci-cd-automated-testing-trends/
  42. https://istqb.org/wp-content/uploads/sdm-uploads/ISTQB-CTAL-TA-Syllabus-v4.0-EN-4.pdf
  43. http://img105.job1001.com/upload/adminnew/2015-02-04/1423058832-HCSCIRY.pdf
  44. https://pmc.ncbi.nlm.nih.gov/articles/PMC7251618/
  45. https://glossary.istqb.org/en_US/term/regression-testing
  46. https://people.eecs.ku.edu/~saiedian/Teaching/814/Readings/Neates-BVA-Testing.pdf
  47. https://www.mdpi.com/2076-3417/12/19/10016
  48. https://www.tmap.net/wiki/state-transition-testing/
  49. https://www.geeksforgeeks.org/software-testing/error-guessing-in-software-testing/
  50. https://investors.opentext.com/press-releases/press-releases-details/2023/OpenText-Buys-Micro-Focus/default.aspx
  51. https://www.calcalistech.com/ctech/articles/0,7340,L-3929092,00.html
  52. https://www.tricentis.com/news/tricentis-acquires-ai-based-saas-test-automation-platform-testim
  53. https://dl.acm.org/doi/10.1016/j.chb.2014.10.046
  54. https://www.ranorex.com/blog/agile-testing/
  55. https://dl.acm.org/doi/fullHtml/10.1145/3476105
  56. https://ieeexplore.ieee.org/document/9284119
  57. https://www.researchgate.net/publication/378977416_Strategies_for_Mitigating_Flaky_Tests_in_Automated_Environments
  58. https://dl.acm.org/doi/10.5555/2639037.2639044
  59. https://www.browserstack.com/guide/test-coverage-techniques
  60. https://www.ranorex.com/blog/test-coverage-techniques-to-guide-your-software-testing/
  61. https://www.testingxperts.com/blog/functional-testing/
  62. https://www.testdevlab.com/blog/how-to-ensure-successful-software-testing-project
  63. https://qalified.com/blog/risk-based-testing/
  64. https://www.testrail.com/blog/managing-distributed-teams/
  65. https://www.linkedin.com/pulse/qa-remote-work-environments-adapting-testing-processes-distributed-nadoc
  66. https://qualitrix.com/blogs/implementing-test-automation-and-qa-in-cloud/
  67. https://www.qamentor.com/wisdom-center/sample-deliverables-showcase/defect-leakage-analysis/
  68. https://www.virtuosoqa.com/post/software-testing-metrics
Add your contribution
Related Hubs
User Avatar
No comments yet.