STATIC TESTING VS DYNAMIC TESTING
Static Testing Techniques
Reviews:
- Purpose: Ensuring correctness and completeness of documents through a thorough examination.
- Examples: Requirement Reviews, Design Reviews, Code Reviews, Test Plan Reviews, Test Cases Reviews, etc.
- Nature: Informal review where the author discusses documents or code with peers.
- Execution: Not pre-planned, conducted whenever needed.
- Documentation: No formal minutes of the meeting are recorded.
- Formality: The most formal review type involving 3-8 participants, including a reader, writer, and moderator.
- Scheduling: Follows a proper schedule communicated via email to concerned developers or testers.
Dynamic Testing Techniques (Levels of Testing)
- Unit Testing: Testing individual components or functions to verify that they work correctly in isolation.
- Integration Testing: Checking how different modules or components interact with each other to ensure seamless integration.
- System Testing: Evaluating the complete software system to ensure it meets specified requirements and functions as intended.
- UAT (User Acceptance Testing): Real users test the software to verify if it meets their needs and expectations.
TESTING METHODOLOGIES
- White Box Testing:
- What is it: White Box Testing focuses on the internal logic of the software. Testers need programming skills to examine the code, understand its structure, and ensure that it functions correctly.
- Example: Suppose you're testing a calculator application. In white box testing, you would check if the addition and subtraction functions are working correctly by looking at the underlying code.
- Black Box Testing:
- What is it: Black Box Testing looks at the functionality of the software without delving into its internal code. Testers check whether the application works according to the specified requirements, regardless of how it achieves those results.
- Example: Continuing with the calculator application, in black box testing, you would input numbers and operators into the calculator interface to ensure that the addition and subtraction functions produce the correct results without considering how the code accomplishes it.
- Grey Box Testing:
- What is it: Grey Box Testing combines elements of both white box and black box testing. Testers have partial knowledge of the internal workings of the software and use it to design tests that focus on functionality.
- Example: Taking the database of the calculator application as an example, in grey box testing, you might know the structure of the database tables (white box aspect) but you're also checking if the data is stored and retrieved correctly through the application interface (black box aspect).
LEVELS OF TESTING
1) Unit Testing:
- What it is: Testing individual components or functions of the software in isolation to ensure they work as intended.
- Who will do: Developers.
- When to do: During the development phase.
- Techniques used: Basis path testing, control structure testing, conditional coverage, loops coverage, mutation testing.
- How to conduct: Automated tests are written for each function or module, checking if they produce the expected results.
- Example (Banking Application): Testing a function that calculates compound interest to ensure it provides accurate results.
- What it is: Verifying that different components or modules work together seamlessly.
- Who will do: Testers or developers.
- When to do: After unit testing, before system testing.
- Techniques used: Top-down approach, bottom-up approach, big bang approach.
- How to conduct: Testing the interaction between integrated components to ensure they function as a unified system.
- Example (Banking Application): Checking if the customer account creation module integrates smoothly with the transaction processing module.
Integration Testing Types:
1) Top-Down Approach:
- What is it? Start testing from the top and move down.
- How? Test the main parts first, then add and test smaller parts.
- Example: Imagine building a car. Test if the car works as a whole first (top), then add and test components like the engine, wheels, and lights (down).
- What is it? Begin testing from the bottom and move up.
- How? Test smaller parts first, then combine and test bigger parts.
- Example: Using the car analogy, start by testing the engine, wheels, and lights individually (bottom), then combine and test if they work together as a complete car (up).
- What is it? Test everything all at once.
- How? Put all parts together and test them simultaneously.
- Example: In our car example, assemble the entire car and check if the engine, wheels, lights, and all other components work together in one go.
- Top-Down: To see if the whole thing works from the top.
- Bottom-Up: To check if individual parts work well on their own.
- Big Bang: Quick testing of everything together.
- Top-Down: Good for catching big issues early.
- Bottom-Up: Useful for finding problems in specific parts.
- Big Bang: Quick, but may be harder to pinpoint specific issues.
- Example Summary:
- Top-Down: First, check if the fully assembled car works.
- Bottom-Up: Begin by testing each part, then check if they make a working car.
- Big Bang: Assemble the entire car and test everything at once.
Top-Down:
- Advantages: Early identification of high-level issues, progressive integration.
- Challenges: Need for stubs, lower-level modules might not be tested thoroughly until later stages.
- Advantages: Early identification of low-level issues, progressive integration.
- Challenges: Need for drivers, higher-level functionalities are not tested until later stages.
- Advantages: Quick integration, entire system tested simultaneously.
- Challenges: Difficulties in identifying specific module-related issues, dependencies might lead to delays.
3) System Testing:
- What it is: Evaluating the entire software system to ensure it meets specified requirements.
- Who will do: Testers.
- When to do: After integration testing.
- Techniques used: Functional testing, performance testing, security testing.
- How to conduct: Testing the entire application, including all integrated components, to validate its functionality.
- Example (Banking Application): Confirming that the end-to-end process, from account creation to transaction history, works without errors.
- What it is: The final testing phase where end-users validate if the software meets their expectations.
- Who will do: End-users or a designated UAT team.
- When to do: After system testing.
- Techniques used: Alpha testing, beta testing.
- How to conduct: Real users navigate through the application, ensuring it aligns with their needs.
- Example (Banking Application): Users testing the online banking interface, checking if it's user-friendly and meets their banking needs.
QA vs QC
Aspect Quality Assurance (QA) Quality Control (QC) Goal Ensure high-quality software by improving processes and preventing defects. Identify and rectify defects in the developed software to meet quality standards. Focus Process-oriented, concerned with the entire software development life cycle. Product-oriented, concentrated on testing within the SDLC. When Applied Throughout the entire SDLC, from project initiation to closure. Primarily during the testing phase within the larger SDLC. Main Activity Establish and improve processes to avoid errors and issues. Test the software to detect and fix defects before release. Prevention vs. Detection Emphasis on avoiding defects proactively. Focus on detecting and fixing defects reactively. Involvement Everyone involved in the development process contributes to QA. Specific testing teams and processes are involved in QC.
In essence, QA is a proactive approach that aims to build a quality product by implementing effective processes, while QC is a reactive approach that involves testing and identifying defects in the product. Both QA and QC play integral roles in delivering high-quality software, complementing each other to ensure a robust and reliable end product.
