Mt s5 levels

DO NOT DISTRIBUTE – HIGHLY CONFIDENTIAL
Agenda:
• Levels of Testing

Levels of Testing:
• Unit Testing
• Integration Testing
• System Testing
• UAT

Levels of Testing:
1. Unit Testing - Done by the developer at unit level
2. Integration Testing - Conducted by the project team
integrating the modules
3. System Testing - Conducted by project team or by
separate testing team if any
4. Acceptance Testing- Conducted by client either in
developer's site and at his site

Unit Testing:
• A smallest separate portion such as programs, functions,
procedures and methods etc in the source code of the
application are called units.
• Testing conducted on these units to check does the code
behind these units are working as expected or not is
called unit testing.
• Unit testing is also called as Module testing/ Component
testing.

Unit Testing:
• Approaches:
 Black Box
 White Box
• Benefits:
1. Ensures code meets the requirements
2. Simplifies integration
• Note: Debugging process is nothing but unit testing.

Why Unit Testing:
1. Test early for each component and prevent the defect from being
carried forward to next stage.
2. To ensure that the design specifications have been correctly
implemented.
3. It is inefficient and ineffective to test the system solely as a ‘Big Black
Box’.
4. The viable approach is to perform a hierarchy of tests.
5. Ensure Reasonable and Consistent behavior at the Lowest level of the
Product.
6. Experience has shown that Unit Testing is cost effective.

Unit testing to uncover errors like:
1. Comparison of different data types.
2. Incorrect logical operators or precedence.
3. Incorrect comparison of variables.
4. Improper or nonexistent loop termination.
5. Failure to exit when divergent iteration is encountered.
6. Improperly modified loop variables, etc.
7. Expectation of equality when precision errors makes
equality unlikely.

Unit Testing Procedure:
1. Unit testing is normally considered as an adjunct to the
coding step.
2. Unit test case design begins ,once the component level
design has been developed, reviewed and verified.
3. A review of design information provides guidance for
establishing test cases that are likely to uncover errors.
4. Each test case should be coupled with a set of expected
results.

Unit Test Steps:
1. The Unit test criteria, the Unit test plan, and the test
case specifications are defined.
2. A code walkthrough for all new or changed programs
or modules is conducted.
3. Unit Test data is created, program or module testing is
performed, and a Unit test report is written.
4. Sign-offs to integration testing must be obtained,
Sign-off can be provided by the lead programmer,
project coordinator, or project administrator.

Unit Testing Activities - 1
Field Level Checks:
• Null / Not Null Checks
• Uniqueness Checks
• Length Checks
• Date field Checks
• Numeric Checks
• Alphanumeric Checks
• Negative Checks
• Default Display

Field Level Validation:
• To Test all Validations for an input field
• Date Range Checks
• Date Check validation with the system date
Functionality Checks:
• Screen Functionality
• Referential Integrity Checks
• Field Dependencies

User Interface Checks:
• Readability of the controls
• Tool Tips Validations
• Ease of usage of interface across
• Consistency with the user interface across the product
• User Interface dialogs
• Tab related checks for screen controls

Integration Testing:
• Once unit testing is completed, programmer will combine
units together and check the interactions among all these
units, which are called integration testing.
• Starts at module level when various modules are
integrated with each other to form a sub-system or
system.
• More stress is given on interfaces between the modules.
• Focuses on design and construction of the software
architecture.

• Four Basic Approaches To Testing While Integrating
Modules
– Top Down
– Bottom Up
– Critical Part First
– Big Bang

Why Integration Testing?
1. Data can be lost across an interface.
2. One module can have an inadvertent, adverse effect on
another.
3. Sub-functions, when combined, may not produce the
desired major function.
4. Individually acceptable imprecision may be magnified to
unacceptable levels.
5. Global data structures can create problems, and so on…

Top-Down Testing Strategy:
• Test the top layer or the controlling subsystem first.
• Then combine all the subsystems that are called by the tested
subsystems and test the resulting collection of subsystems.
• Do this until all subsystems are incorporated into the test.
• Special program is needed to do the testing, test stub.
• A program or a method that simulates the activity of a missing
subsystem by answering to the calling sequence of the calling subsystem
and returning back fake data.
16www.talentsprint.com

• Design, implement and test the top modules using stubs (or dummy
modules).
• Stubs do not perform any real computations or manipulate any real
data.
• Tests are conducted as each component is integrated.
• Stubs are removed and integration moves downward in the program
structure.

A
B C D
GFE
Layer I
Layer II
Layer III
Test A
Layer I
Test A, B, C, D
Layer I + II
Test
A, B, C, D,
E, F, G
All Layers

Stub: A simulated program that replaces a called program is called stub.
Problem: A component being tested may call another that is not yet tested!
Solution: Write a special-purpose program to simulate the activity of the
missing component.
The special-purpose program is called a stub.
– If the lowest level of components performs the input and output
operations, stubs for them may be almost identical to the actual
components they replace.

Top-Down Testing Pros:
• Any design faults or major questions about functional feasibility
can be addressed at the beginning of testing instead of the end.
• Early skeletal program allows demonstrations and boosts morale.
• Integrated Testing is done in an environment that closely
resembles that of the reality, so the tested product is more
reliable.
• Stubs are functionally simpler than drivers, and therefore they
can be written with less time.
• Interface errors are discovered early.

Top-Down Testing Cons:
• Writing stubs can be difficult, because they must allow all
possible conditions to be tested.
• Stub may itself needed to be tested to insure it is correct.
• Very large number of stubs may be required.
• Unit Testing of lower modules can be complicated by the
complexity of upper modules.
• In the initial phase of Testing, it is difficult to do coding and
testing simultaneously.
• Errors in critical modules at low levels are found late.

Bottom-up Testing Strategy:
• The subsystem in the lowest layer of the call hierarchy are
tested individually. Then the next subsystems are tested that
call the previously tested subsystems.
• This is done repeatedly until all subsystems are included in
the testing.
• Special program needed to do the testing, Test Driver.
• A routine that calls a subsystem and passes a test case to it.

• The program is combined and tested from the bottom of the tree
to the top.
• Requires a module driver for each module. Put together sub trees
and test until whole tree.
• Very common and effective approach, especially when combined
with the Object Oriented Design.
• Each component at the lowest level of the system hierarchy is
tested individually first, then next components to be tested.

A
B C D
GFE
Layer I
Layer II
Layer III
Test F
Test E
Test G
Test C
Test D,G
Test B, E, F
Test
A, B, C, D,
E, F, G

Bottom-up Testing :
Component Driver:
• A simulated program that replaces a calling program is called Driver.
• A special code to aid the integration.
• A routine that calls a particular component and passes a test case to it.
• Take care of driver’s interface with the test component.
• Driver is a calling module for low level components and is developed for
temporary use.
• It has to be replaced when the actual top level module is ready.

Bottom-up Testing Pros:
• Advantageous if major flaws occur toward the bottom of the
program.
• Test conditions are easier to create.
• Many Programming and testing operations can be carried
out simultaneously, yielding apparent improvement in Software
Development effectiveness.
• Unit Testing of each module can be done very thoroughly.
• Errors in critical modules are found early.

Bottom-up Testing Cons:
• Driver modules must be produced.
• The program as an entity does not exist until the last module is
added.
• Major control and decision problems will be identified later in the
testing process.
• We cannot test the program in the actual environment in which it
will be run.
• Many modules must be integrated before a working program is
available.

Sandwich Testing Strategy:
• Combines top-down strategy with bottom-up strategy.
• The system is view as having three layers
• A target layer in the middle
• A layer above the target
• A layer below the target
• Testing converges at the target layer
• How do you select the target layer if there are more than 3 layers?
• Heuristic: Try to minimize the number of stubs and drivers.

Sandwich Testing Strategy:
A
B C D
GFE
Layer I
Layer II
Layer III
Test E
Test D,G
Test B, E, F
Test
A, B, C, D,
E, F, G
Test F
Test G
Test A
Bottom
Layer
Tests
Top
Layer
Tests
Test A,B,C, D

Critical Part First:
• Design, implement and test the critical part of the system
first.
• Important for time critical systems, where the performance
of critical part makes up for performance of the whole
system.

Big Bang Testing Strategy:
• A common approach in non-process oriented organizations.
• All modules are integrated at once.
• Many disadvantages and few advantages !!
• Hard to debug, hard to check interfaces
• Location of the defect is difficult to find
• No stubs and drivers are required

Module 1
System
Module 2Module 6
Module 5 Module 3
Module 4
Big Bang Integration Testing

System Testing:
Pre-Condition:
• 100% unit & Integration test should be successful.
• All customer requirements should be base lined.
• All test cases & test data should be reviewed and
approved.
• Application should be successfully installed in the testing
environment.

System Testing:
• System testing is testing conducted on a complete, integrated
system to evaluate the system's compliance with its specified
requirements.
• Validates that the system meets its functional and non-functional
requirements.
• It is also intended to test up to and beyond the bounds defined in
the software/hardware requirements specifications.
• Final phase of testing before delivery.

System Testing:
• This system is broadly classified into
 Functionality system testing
 Non-functional system testing

System Testing:
Functionality System Testing:
• Checking the behavior of the system functionality with valid &
invalid inputs.
• Checking whether all the functionalities in the system working
fine or not as per the specifications.
Non-Functional System Testing:
• Checking whether all the Non functional specifications in the
system working fine or not as per the specifications.

System Testing:
Special Test are grouped on the basis of applications under test and
the type of tests performed –
• Requirements Testing
• Smoke testing
• Sanity testing
• Formal testing
• In formal testing
• Risk based or Priority based testing
• Re-Testing

System Testing:
• Regression Testing
• Exploratory testing
• Monkey/gorilla/zigzag/rattle/uneven testing
• Error-handling testing
• Inter-systems testing
• Parallel testing
• GUI/UI testing
• Usability testing
• Security testing

System Testing:
• Configuration testing
• Load testing & Stress testing
• Performance testing
• Recovery testing
• Installation/Un-Installation testing
• Globalization /Localization testing
• Database Testing
• End to end testing

System Testing:
Specialized systems and applications:
1. Client-server systems
2. Web based systems

System Testing:
Requirements Testing:
• Every system is requirement tested.
• Process begins from requirement phase and continues until
operations and maintenance phase.
• Objectives include –
– User requirements are implemented
– Correctness is maintained
– Processing complies with organization’s policies and
procedures.

System Testing:
Requirements Testing:
• Methods used include –
– Creation of a matrix to determine whether all
requirements are implemented.
– Use of checklist to verify whether system meets
organizational policies and governmental regulations.

System Testing:
Smoke Testing:
• Checking the testability of the software is termed as Smoke
testing.
• Also known as a build verification testing / Basic functional
testing / Link testing.
• The Smoke test scenarios emphasize breadth more than
depth.
• Smoke tests can either be performed manually or using an
automated tool.

System Testing:
Sanity Testing:
• Checking behavior of the system is termed as Sanity testing.
• Also called as narrow regression testing.
• Considered as subset of regression testing.
• Sanity testing is a focused narrow and deep, but cursory.
• Sanity tests are useful both for initial environment
validation and future interactive increments.
• Note: The objective of smoke testing or sanity testing is to
decide whether the application is testable or not to finding the
defects.

System Testing:
Formal Testing:
• If we test an application by following all pre-defined procedures
and proper documents, then it is called formal testing.
In Formal Testing:
• If we test an application as we wish i.e. without following any
procedures and documentation, then it is called informal testing.
This informal testing also called ad-hoc testing.

System Testing:
Risk based testing or priority based testing:
• It is a process of identifying all business scenarios to be
validated then, pre-other the test execution. i.e. deciding
what to test next and what to test last and executing the
test in the same order.

System Testing:
Re-Testing:
• Testing functionality repetitively, i.e. again and again is called
re-testing. Re-testing comes in the two scenarios.
 Testing functionality in any build with multiple inputs to
confirm business validations.
 Testing functionality in a modified build to confirm bug
fixers. It is also called as confirmation testing.

System Testing:
Regression Testing:
• Re-running or re-executing the selective test cases for inter
connected features in the modified build is called regression
testing.
• It is the re-execution of some or all the test cases to check
 Any addition to the software
 Any deletion to the software
 Any modification or fixing of defect has not introduce any
defect in unchanged part of the software

System Testing:
Regression Testing:
• Can be at –
 Unit level
 Module level
 System level
• Is performed when there is a high risk that changes may affect
unchanged components.
• Re-running previously conducted tests to ensure that
unchanged components function correctly.

System Testing:
Purpose of Regression Testing:
 Locate errors
 Increase confidence in correctness
 Preserve quality
 Ensure continued operations
 Check correctness of new logic
 Ensure continuous working of unmodified portions

System Testing:
Regression Testing Methods:
• Regression testing can be done either manually or by
automated testing tools.
– Manual testing: Can be done for small systems, where
investing in automated tools might not be feasible enough.
– Automated testing: One class of these tools is called as
Capture-playback tool. This is very helpful in situations
where the system undergoes lots of version changes.

System Testing:
Exploratory testing:
• Exploring the application, add/modify existing test cases for
better testing is called exploratory testing.
Monkey/gorilla/zigzag/rattle/uneven testing:
• If we test an application in a zigzag way i.e. unevenly with an
intension of finding tricky effects then it is called “monkey
testing”. It is a part of Adhoc testing (recommended to be done
by senior/experience person).

System Testing:
Error - Handling Testing:
1. To determine the ability of the system to properly process
erroneous transactions
– All reasonably expected errors are recognizable by the
application system
– Procedures provide high probability that the errors will be
corrected properly
– Reasonable control over errors during correction
2. Should happen throughout development life cycle

System Testing:
Inter - Systems Testing:
1. Testing of interface between two or more application systems.
2. To determine whether –
– Parameters and data are correctly passed between applications
– Documentation for the involved systems is accurate and complete
3. Should be conducted whenever there is a change in parameters
between applications.
4. Representative set of test transactions is prepared in one system and
passed to another system for processing and results are verified for
correctness.

System Testing:
Parallel Testing:
1. Comparison of results from two different systems (old v/s new or manual v/s
automated)
– New version of application or new system performs correctly with reference to
existing system that is working correct
– There is consistency or inconsistency between two systems
3. Still used while accepting a new system
4. Same input data should be used in both systems
5. Input data may be modified as per requirement of new system
6. The new system is used in parallel with the existing system for certain period
7. Thorough cross-checking of the outputs and comparison with outputs from existing
system

System Testing:
Compliance Testing:
1. With Respect to Processes:-
2. Performed to check whether system was developed in accordance with standards,
procedures and guidelines
1. Development and maintenance methodologies are followed
2. Completeness of system documentation
4. Depends upon the management’s desire to have the standards enforced
5. Use of checklists
6. Peer reviews
7. SQA reviews
8. Internal audits

System Testing:
GUI/UI testing:
• Validating/checking does the user interfaces are professionally designed
or not is called “GUI/UI testing”.
Checklist:
 A check does the basic elements are available or not.
 Check spelling of the element/controls/objects.
 Check alignments of objects.
 Check consistency in background colour, font type, font size etc.
 Check does the mandatory fields are highlighted or not.
 Check links and images are displaying alternative descriptions (tool
tip) when they are highlighted.

System Testing:
User Interface testing:
• Performed to check how user-friendly the application is
• To determine whether –
– Appropriate input help is displayed on screen
– Correct messages are displayed when an error is encountered
– Columns have meaningful names
– Navigation within the application is easy
• Should be performed without assistance of system personnel

System Testing:
Usability testing :
• Validating the user friendliness of the application i.e. checking
does the application is understandable and opera table by all
types of users or not is called “usability testing”.

System Testing:
Usability testing :
1. Performed to check ease of use of an application
2. To determine –
– How simple it is to understand application usage
– How easy it is to execute an application process
3. Direct observation of people using the system
4. Usability surveys
5. Beta tests

System Testing:
Usability testing :
1. Checks for human factor problems :
– Are outputs meaningful?
– Are error diagnostics straightforward?
– Does GUI have conformity of Syntax, conventions, format,
style abbreviations?
– Is it easy to use?
– Is there an exit option in all choices?

System Testing:
Usability testing :
2. It should not
– Annoy intended user in function or speed
– Take control from the user without indicating when it will
be returned
3. It should
– Provide on-line help or user manual
– Consistent in its function and overall design

System Testing:
Compatibility testing:
• Testing does the application is compatible with different
hardware and software environments is called “compatibility
testing” or “cross-browser testing”.
• Software compatibility includes operating system
compatibility and browser compatibility.
• Cross-browser testing is one where we check application on
various browsers.

System Testing:
Compatibility testing:
1. Similar to multi-platform testing.
2. Performed to ensure that application functions properly on
multiple system configurations.
3. More significant in case of web-based applications where any
browser can be used to access the application.

System Testing:
Installation testing:
• Checking are we able to install the application successfully or
not as per the guidelines given in installation document i.e.
read me file is called “installation testing”.
Un-installation testing:
• It is a process of checking or we able to uninstall a product
successfully or not.

System Testing:
Installation testing:
1. To identify the ways in which installation procedures lead to
incorrect results
2. Determines whether –
– Installation procedure is documented
– Personnel are trained in installation process
– Methodology for migration from old system to new system
is documented

System Testing:
Globalization testing:
• Checking does the system is having a provision of changing
languages, currency, date and time etc…if it is designed for
global users.
Localization testing:
• Checking the default languages, currency, date and time format
etc…when an application developed for local users is called as
“localization testing”.

System Testing:
Recovery testing:
• Checking how does the system is handling the unexpected or
unpredictable situations like power failures, system crash etc
is called “recovery testing”
• It also validating does the system is having a provision of back-
up and restore options and checking these operations are
working as expected or not is also called “recovery testing”.

System Testing:
Recovery testing:
1. To determine whether operations can be continued after a
disaster or after integrity of the system has been lost
2. Involves reverting to a point where the integrity of the system
was known and then re-processing transactions up to the
point of failure
3. Is used where continuity of operations is essential

System Testing:
Recovery testing:
Determines whether –
– Adequate backup data is preserved.
– Backup data is stored in secured location and is easily
retrievable.
– Recovery process is documented.
– Recovery personnel are trained.
– Recovery tools are available.

System Testing:
Configuration Tests:
1. Determine the effect of adding or modifying resources
– Memory
– Disk drives
– CPU
– Network Card
2. Test for compatibility issues
3. Determine minimal and optimal hardware and software
configuration

System Testing:
Security testing :
• Validating does all security conditions are properly build in
the system or not is called “security testing”.
Checklist:
 Check for authorization:
– Authorization testing: checking does the system is having a
provision of creating login accounts, settings and changing
permissions or not is called “authorization testing”.

System Testing:
Security testing :
 Check for authentication:
– Authentication testing: checking does the system is able to
recognize the register users and displaying the right info to the
right user or not is called as “authentication testing”.
 Check Firewall Leakage
– Firewall Leakage testing: It is a type of testing where users will
enter into the application as one level of user and try to access
the application beyond the limits. Hence checking when the user
is trying to do the activities beyond the limits whether the
firewall is blocking or not is called Firewall Leakage Testing.

System Testing:
Security testing :
 Check for Encryption.
 Check for Decryption.
 Verify whether the URLS are secured or not.
 Check for session expiry.
 Check for direct url access for secured pages.
 Check browser navigations, i.e. back and forward options for
secured pages.
 Verify the cookies.

System Testing:
Performance Testing:
• Analysing various efficiency characteristics of the system
such as response time, through put, load, volume, stress,
resources, consumption, tps/tpm (transaction per
second/minute) and transaction mix is collectively called as
“performance testing”.

System Testing:
1. Is to determine whether the system meets its performance
requirements.
2. e.g. x transactions should be processed in y seconds or data should
be retrieved in z seconds with say 100 concurrent users.
3. Can also be called as compliance testing with respect to
performance.
4. Design should address performance issues.
5. Design verification can help in determining whether required
measures have been taken to meet performance requirements.

System Testing:
Performance Testing Process:
Load, Stress and Scalability Testing
Problem
Investigation
Conduct the TestTool Identification
Generate ScriptsTest Planning
Generate custom reports
based on:
· Simulated Load
· Round Time
· Response time
· CPU Utilization
· Memory utilization
· Disk utilization Etc
Setup the
environment
Understand
requirements
Step 3
Reporting
Step 2
Execution
Step 1
Planning

System Testing:
Load Testing:
1. Load testing is subjecting a system to a statistically
representative load.
2. It is done to determine if the system performance is
acceptable at pre-determined load level.

System Testing:
Stress Testing:
1. Whether system continues to function when subjected to large volumes (larger
than expected)
2. Areas that may be subjected to test include –
– Input transactions
– Internal tables
– Disk space
– Communication channels etc.
3. System should run as it would in production environment
4. Should be performed when there is uncertainty about volume of expected work
that the system can handle

System Testing:
Database Testing:
• Checking the impact of the front end operations with back end and vice
versa is called DB Testing.
Why Database Testing?
• Software applications are more complex these days with technologies
like android and also with lots of smart phone apps.
• The more complex the front ends, the back ends are even more
intricate.
• So, it is all the more important to learn about DB testing and be able to
validate the databases effectively to ensure secure and quality
databases.

System Testing:
Database Testing Process:
• Prepare the environment
• Run a test
• Check test result
• Validate according to the expected results
• Report the findings to the respective stakeholders

System Testing:
What to Test in Database :
• Data Mapping
• Atomicity
• Consistency
• Isolation
• Durability
• Data Integrity
• Business rules conformity

System Testing:
Database Testing Approaches:
• Manually
• Automation Tools- ETL Tool

System Testing:
End to end testing:
• It is a process of identifying all core/important business
scenarios in the system testing and testing these scenarios
right from one to the other end including the data integration
(recommended to be done by domain expert).

Client - Server Systems:
1. Key components of client-server technology
– Client installation
– Security
– Data
– Standards
2. Testing should be adjusted to address these four key components

Web - Based Systems:
Key factors:
– Security
– Performance
– Correctness
– Compatibility
– Reliability
– Data integrity
– Usability
– Recoverability

Security:
– External intrusions
– Secured transactions
– Viruses
– Access control
– Authorization
Performance (Load testing):
– Concurrency
– Stress
– Throughput

Correctness:
– Functionality
– Calculations
– Navigation
Compatibility:
– Operating system
– Browser
Reliability:
– Consistently correct results
– Server and system availability

Data integrity:
– Correct data is accepted
– Data stays in correct state
Usability:
– Easy to use and understand
– Navigation is correct
Recoverability:
– Lost connections
– Client system crashes
– Server system crashes

UAT- User Acceptance Testing:
• Testing conducted on the completed application by domain experts or
by end users to confirm whether the application is ready for live
production or not is called as “user acceptance testing”.
• Final stage of testing before the system is accepted for operational use.
• Done with data supplied by the client/ Domain Experts.
• Validates –
1. User Needs (Functional)
2. System Performance (Non-Functional)
• Is the process of comparing a program to its requirements.

• Testing the system with the intent of confirming readiness of the
product and customer acceptance.
• The performance and reliability of the system will be tested and
confirmed.
• Formal testing conducted to enable a user, customer or other authorized
entity to determine whether to accept a system or component.
• An acceptance test is a test that the user defines, to tell whether the
system as a whole works the way the user expects.
Purpose:
– The purpose of acceptance testing is to verify system from user
perspective.

Assumptions/Pre-Conditions:
• Completed system and regression testing
• All the defects must be fixed successfully
• Configuration Manager access
• Test data (optional)
• Final versions of all documents ready
• Overview to the testing procedures
• Exit decision
• Specific procedures

Assumptions/Pre-Conditions:
• Acceptance Criteria MUST be documented
– Acceptance Testing
– Project stakeholders

Expectations:
• Verification from the user’s perspective
• Performance testing should be conducted again
• Extra time
• User manual to the testers
• Non-testable requirements
• Review with the Sponsor and User
• Plans for the Implementation

Stages of UAT:
– Alpha Testing
– Beta Testing

Alpha Testing:
• Tested at developer site by customer.
• Developer "looks over shoulder" and records
errors & usage problems.
• Tests conducted in a controlled environment.

Beta Testing:
• Beta testing conducted at one or more customer sites by
end user of software.
• Live application environment cannot be controlled by
developer.
• Customer records all problems encountered and reports
to developer at regular intervals.

Summary:
In this Session, we have learnt about:
1. Levels of testing
2. Integration techniques
3. Functional and Non-functional testing types
4. Classification of Software applications based on the
architecture

Review Questions:
1.You are supposed to integrate a new but extensive database module to
the existing Payroll module; which of the following integration
strategies will be the appropriate one?
a) Top-down integration strategy
b) Bottom-up integration strategy
c) Sandwich integration strategy
d) Bing bang integration strategy
2. Component drivers will have some functionality and where as the
Stubs are dummy.
a) TRUE
b) FALSE

Review Questions:
3. Unit Testing both black-box and White-box testing in it.
a)TRUE
b) FALSE
4. During UAT the integration strategies are required and
Top-down approach is the most used method.
a) TRUE
b) FALSE

Mt s5 levels

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Mt s5 levels

Similar to Mt s5 levels (20)

More from TestingGeeks

More from TestingGeeks (20)

Mt s5 levels