Software Testing Fundamentals

• Software testing evaluates software applications or systems to ID defects, ensure requirements, and verify performance. This is a critical phase in development that maintains quality, reliability, and performance.

Objectives of Software Testing

• Identify defects
• Ensure quality
• Verify requirements
• Prevent future issues

Basic Testing Vocabulary

• Audit: Inspection/assessment verifying compliance with plans, policies, and procedures, ensuring resource conservation.
• Baseline: A quantitative measure of current performance level.
• Benchmarking: Comparing products/services/processes against best or competitive to define superior performance.
• Black-box Testing: Testing functionality of program/application against specifications without system construction knowledge.
• Boundary Value Analysis: Data selection from "boundaries" of input/output domain classes, including min/max values plus/minus one.
• Branch Testing: A method where each decision branch is executed at least once.
• Brainstorming: Group process for generating diverse ideas.
• Bug: Catchall term for software defects or errors.
• Debugging: Analyzing, correcting syntactic, logic, and other errors found during testing.
• Decision Coverage: White-box technique measuring decision directions executed by test cases; 100% indicates all directions tested once.
• Decision Table: Tool documenting unique conditions and results to derive unique test cases for validation.
• Defect Tracking Tools: Used to document defects found during tests and tracked to resolution.
• Desk Check: Verification by the artifact author to check their own work for completeness, without involving others.
• Dynamic Analysis: Executing program code to identify errors by analyzing the product's response to input data.
• Entrance Criteria: Standards for work product quality that must be met before entering the next development stage.
• Exit Criteria: Standards blocking incomplete/defective work products from progressing to subsequent development stages.
• Equivalence Partitioning: Test technique with subset of data representing a larger class, done in place of testing exhaustive values of the data class.
• Error or Defect: Discrepancy between a computed value/condition and the true/specified value/condition; also, human action causing software fault.
• Error Guessing: Test data selection based on intuition/experience to find defects.
• Exhaustive Testing: Executing a program with all possible combinations of variable values.
• Flowchart: Pictorial data flow and computer logic representations.
• Formal Analysis: Using math techniques to analyze algorithms for numerical properties, efficiency, and correctness.
• Functional Testing: Ensures functional requirements are met, regardless of program structure.
• Histogram: Graphical description of measured values in dataset, organized by occurrence frequency, including average/variation info.
• Inspection: Formal assessment by qualified independent reviewers to detect defects, standards violations, and other issues.
• Integration Testing: After successful unit testing, validate interaction/communication between integrated components.
• Life Cycle Testing: Verifies consistency, completeness, and correctness of software at each development stage.
• Pass/Fail Criteria: Decision rules to determine if software/feature pass or fails.
• Path Testing: A method satisfying coverage criteria to test each logical program path which are grouped into finite classes, one from each being tested.
• Performance Test: Validates online response and batch run times meet specified performance needs.
• Policy: Management desires/intents for process (objectives) or products(attributes).
• Population Analysis: Analyzing production data to identify data types/frequency for system process/production.
• Procedure: Step-by-step method to ensure standards are met.
• Process: Work effort producing a product or a statement of purpose and essential practices.
• Proof of Correctness: Logic techniques showing relationship between program variables at entry implies another at exit.

QA versus QC

• Quality Assurance (QA): A validation process ensuring product meets requirements, conducted before and during development.
• Quality Control (QC): Ensures necessary procedures/methodology/techniques have been followed for a defect-free product, after software is built.
• Verification confirms product is built correctly, during development.
• Validation confirms the right product is built, after the development.
• Quality Assurance focuses on the process, prevents defects, and involves the entire team.
• Quality Control focuses on the product, identifies/fixes defects, and is the testing phase.

Statistical Techniques

• QA: Process-oriented parameters use SPC (Statistical Process Control) graphs.
• QC: Uses SQC (Statistical Quality Control) graphs for finished products.
• QA consumes less time, while QC is an extensive process that consumes a lot of time.

Cost of Quality

• A tool to quantify and determine business value of testing
• It quantifies control/conformance costs and failure of control/non-conformance.
• Cost of Quality (COQ) = Cost of Control + Cost of Failure of Control
  • Cost of Control = Prevention Cost + Appraisal Cost
  • Cost of Failure of Control = Internal Failure Cost + External Failure Cost
• Objectives are to control budgeted expenditures for SQA prevention and appraisal activities.
• It considers previous year failure cost, and previous project and other department's quality costs.
• Cost of Software Quality Model includes Control Cost (Prevention and Appraisal) and Failure Cost (Internal and External).

Software Quality Factors

• Software quality factors are known as software quality attributes or characteristics are key aspects of overall software quality.
• These factors include Functionality, Usability, Performance, Reliability, Maintainability, Portability, Security, and Testability.
• Software quality leads to customer satisfaction, fewer defects, enhanced user experience, brand reputation, competitive advantage, customer retention, cost savings, and business success.
• Best practices for enhancing software quality are early testing, comprehensive test planning, requirement test planning, automated testing, test data management, continuous integration/testing, user acceptance testing, test environment management, performance testing, security testing, collaboration/communication, defect tracking, regression testing, documentation, and continuous learning.
• Challenges come from not following the best practices that enhance software quality.
• The degree to which a product/system meets requirements and satisfies user/stakeholder needs defines software quality.
• The primary reasons for testing software are to identify/address defects, validate requirements, and ensure overall quality.
• Functional testing checks what the software does.
• Non-functional tests check how the software performs.
• Maintenance testing occurs after software release.
• Testing types include Unit, Integration, and System Testing; User Acceptance Tests (UAT).
• Further types also include Performance, Load, Stress, Security, and Usability Testing; Retesting and Regression.

Defects

• Per Merriam-Webster, a defect is an imperfection or abnormality that impairs the software's quality, function, or utility.
• Defects are also, Bugs/Errors
• These include Coding, Requirements, Design, Documentation, and Functionality Defects; Integration, Performance, Usability, Security, and Regression Defects.
• Software testers collaborate with Developers, Project Mangers, Business Analysts, and Product Owners
• SW testers focus on User Interaction, Cross-functional Collaboration, Client/Stakeholder Interaction, and Continuous Improvement.
• Test scope defines which customer product areas to test, functionalities to focus on, bug types of interest, and areas not to test.
• Test scope is a checklist for testers

What Information Makes Up Scope of a Test

• Test environment
• Features
• Bug types and severities
• Test instructions
• Elements include: In-Scope Items, Out-of-Scope Items, Test Levels, Types, Techs, Entry Criteria, Assumptions, Dependencies and Data.
• Testing should occur throughout the entire software development lifecycle.
• Testing stops when all requirements are met, no critical bugs remain, budgets/deadlines are reached, test cases are done, risk is acceptable, and stakeholders decide.
• Testing constraints limit or create challenges that impact process, like Time, Budget, Resources, Scope, Tech, Skills, Env and Changing Requirements.

Software Testing Life Cycle (STLC)

• Systematic planning, design, execution, and managing software testing activities ensuring reliability and quality.
• Phases include requirement analysis, test planning, test case development, test environment setup, test execution, defect reporting/tracking, test closure, and retesting/regression testing.

Independent testing

• Performs software testing with separate, distinct teams apart from development team.
• Two types of independent testing: Testing within, and outside the company.
• Key aspects are Evaluation, Defect Detection, QA and Certification.
• Components of independent testing are professional services, dedicated labs, testing services, consultancy, automation, COE (Center of Excellence).
• Benefits include early bug detection, improved reliability, compliance with healthcare/finance standards, and better risk management.
• A QA Process systemically ensures product/system/service meets requirements/standards, helps detect defects, improves performance, and maintains consistency.
• QA process steps: Requirement Analysis, Test Planning, Test Case Development, QA Enviro Setup, Test Execution, Defect Tracking, Test Closure.
• Types of testing in QA: Functional (Unit, Integration, System, User Acceptance), Non-Functional (Performance, Security, Usability, and Compatibility), Automation (Selenium, JUnit, TestNG), and Regression & Smoke Testing.

The "V" Concept of Testing

• Also called V-Model,(Verification/Validation), develops software and QA via testing in every development stage.
• In the V-Model, the left side focuses on "Building the System", while the right side focuses on "Checking the System". The "V-Model Design" includes
• Requirement Analysis: Gathering and document system needs.
• System Design: Creating System Architecture and Designs, based on the needs.
• High-Level Design: Developing the high-level system design.
• Low-Level Design: Creates the detailed design of indivdual modules
• Implementation:Coding or implementation phase, software occurs due to the current design.

"V-Model Design" Testing Stages

• Unit Testing: Each module is tested independently to ensure that it performs as expected.
• Integration Testing: Modules are combined and tested together to identify any issues in their interaction.
• System testing: Tests complete system for specified requirements.
• User Acceptance Testing (UAT): End-users test software, ensuring their expectations and requirements are met.
• Advantages: Early detection of defects, well-structured processes, better assurance, time/cost savings, ideal for smaller and easier documentation.
• Disadvantages: Rigid and inflexible, unsuitable for complex or evolving projects, time-consuming, high initial costs, limited user input
• Use V-Model when requirements are well-defined and unchanging, quality/reliability are key, and for safety-critical projects such as medical software.