Types of Testing

(Static and Dynamic)

by
Dr. Rizwan
 Software Quality Assurance Defect Perspective

• we can examine the effectiveness of different QA regarding defects under different

environments, as follows:
• Is the QA technique dealing with errors, faults, or failures?
• This question can be broken down further with the execution /observation of the specific
QA activities and the follow-up actions, where different defect perspectives may be taken.
• For example, during testing, failures are observed, which lead to follow-up actions to
locate and fix the faults that caused these observed failures.
Software Quality Assurance Defect Perspective

• Ideally, we would like to have different QA alternatives to provide as much

information as possible to help us deal with the problems observed and to
improve quality for the current and future products.
• For example, in inspection, not only the specific problem can be identified for
immediate defect removal, but sometimes systematic problem patterns can be detected,
leading to process changes or focused remedial actions aimed at preventing similar
problems in the future.
 Software Quality Assurance Techniques

• Reviews
• Personal, peer, pair, FTR
• Testing
• Structural, functional, integration, stress/performance, regression, field, acceptance
• Simulations
• Prototypes, models
• Field Trials
• Prototypes, beta testing
• Mathematical
• Proofs of correctness
 SQA Activities

• The main question is the applicability of specific QA activities to

development environments.
• Inspection, formal verification, and testing can be applied to artefacts of
software engineering.
• For example, when a problem is reported by some customers, we can perform
inspection, verification, or testing activities to locate the problem, as well as to
ensure that the fix indeed would correct the problem.
 SQA:: Static vs Dynamic Testing

• Static Testing involves examining the software without executing it

• Primary objective is to find defects in the early stages of the development cycle, such as
during the requirement gathering or design phase
• Often performed manually by human reviewers, however can be through automated
tools as well
 SQA:: Static vs Dynamic Testing

• Dynamic Testing involves executing the software code and examining its
behavior to identify defects
• It is performed by running the software with test cases and observing its output to
ensure that it meets the specified requirements
• For example, dynamic or timing problems are typically associated with some interface
or interaction among different parts of the software products, which might be more
easily detected through testing than through inspection.
• On the other hand, logical and static problems may be more cost-effectively
detected through inspection.
 SQA:: Static vs Dynamic Testing

• Also known as Static Code Analysis

• Examines source code or other software artifacts without executing them
• It aims to find defects, vulnerabilities, coding errors, and adherence to coding
standards
• Static analysis tools analyze code by parsing it and applying predefined rules or patterns
to detect potential issues
 SQA:: Static vs Dynamic Testing

• Different QA techniques may be suitable for different defect levels/types or

prevalence.
• For example, if defects are pervasive in the system, systematic inspection might be
more appropriate than testing because inspection can continue after some defects are
detected, unlike in the case of testing, which often needs to be stopped once a failure is
observed.
 Walkthrough
• In walkthrough, the author of a document or artifact presents it to a group of stakeholders
for discussion, feedback, and clarification
• Whereas Formal Walk through are Structured and systematic approach to reviewing software artifacts
for defects, errors, and improvements. Which follow predefined processes, involve formal meetings,
and produce documented outcomes
• They both are collaborative process aimed at gaining a shared understanding of the
document's content, identifying potential issues, and improving its quality
• Preparation of document/artifact
• Scheduling of the meeting
• Review and Discussion
• Documentation of Feedback
• Follow-up
 Walkthrough and Formal Technical Review :: Roles

• Author
• The person who created the document or artifact being reviewed and who
presents it during the walkthrough
• Reviewers
• Stakeholders who participate in the walkthrough meeting, including subject
matter experts, team members, project managers, and other relevant
individuals
Walkthrough and Formal Technical Review :: Roles

• Facilitator/Moderator
• The individual responsible for facilitating the walkthrough
meeting, ensuring that the review process runs smoothly, all
topics are addressed, and active participation from all
participants is encouraged.
• Recorder/Scribe
• The person responsible for documenting the findings, decisions,
and action items arising from the inspection meeting in a formal
inspection report or log
 Informal Reviews

• Informal reviews are lightweight and flexible approaches to reviewing software

artifacts for defects, errors, and improvements
• Informal Review Process
• Informal Discussion
• Peer Feedback
• Discussion and Clarification
• Roles
• Author
• Reviewers
 Inspection

• Software inspections are critical examinations of software artifacts by human

inspectors aimed at discovering defects in the software systems.
• Inspection is most commonly applied to code, but it could also be applied to
requirement specifications, designs, test plans and test cases, user manuals, and
other documents or software artifacts.
• A checklist, with questions is a common tool used in inspections.
• The advantages of inspections are that they are very systematic, controlled, and
less stressful.
 Inspection

• Inspection involves static examination while testing involves dynamic executions.

• Therefore, static problems are more likely to be found during inspection, while
dynamic problems are more likely to be found during testing.
• Inspection and testing are applicable to different situations, and effective for
different defect types at different defect levels.
• Inspection can be performed first to lower defect levels by directly detecting and
removing many localized and static faults, then testing can be performed to
remove the remaining faults related to dynamic scenarios and interactions.
 Inspection
• A more formal type of static review focused on identifying defects and improving the quality of
software artifacts, such as requirements documents, design specifications, code, and test plans
• Unlike walkthroughs, inspections follow a structured process with predefined roles, checklists,
and guidelines to ensure thoroughness and effectiveness
• Inspection Process
• Planning & Preparation
• Kickoff Meeting
• Individual Review
• Meeting for Inspection
• Recording Findings
• Resolution and Follow-up
 Inspection Upon Web Application

• A 2003 study by the Business Internet Group of San Francisco found that:
• 72% (29/40) leading e-commerce sites, and
• 68% (28/41) government sites contained Web application failures
• 25 “technical errors”
• E.g., page not found, multiple attempts to subscribe to a service
• 3 Data Errors
• E.g., page without text, wrong page returned
 Inspection of Web Site

• Web page text should be treated like documentation and tested using the
techniques we described previously.
• Check for …
• correctness of contact information e.g., phone numbers, addresses
• correctness of dates and copyright notices
• title bar text, bookmark text on browser’s favorites
• correctness of the ALT text (i.e., mouse over text)
• layout issues when browser window is resized
 Inspection of Web Site

• Each link should be checked to make sure it jumps to the correct destination
or website.
• Ensure that hyperlinks are obvious:
• E.g., underlined text, mouse pointer changes
• If the link opens an e-mail message, test it
• Send an e-mail and verify that you get a response.
• Check for orphan pages that are part of the website but cannot be accesses
through a hyperlink.
• Someone forgot to create the link. might be intentional … Google will find it, though
 Inspection of Web Site

• Do all graphics load and display properly?

• Is a graphic missing or incorrectly named?
• Does the website intermix text and graphics?
• Does the text wrap around the graphics?
• What happens when the browser window is re-sized?
• Does the page load fast enough?
• Are there too many graphics?
• Did you try to test the website on a dialup connection instead of a high-speed LAN?
 Inspection of Web Site

• Forms are the text boxes, list boxes, and other fields for entering and selecting
information on the web page.
• Are the form fields positioned properly?
• Are the fields the correct size?
• Do they accept correct data?
• Do they reject bad data?
• Are optional fields really optional?
• A favorite entry point for buffer overflow attacks (more on this later).
Visibility of System Status
Consistency and Standards
Error Prevention
User Control and Freedom
Recognition Rather than Recall
Flexibility and Ease of Use
Help users Recognize and Recover from errors
Help and Documentation
 Inspection Upon SRS

• Software Requirement Specification (SRS) phase is the base of all

subsequent phases in software engineering.

• The result is that the requirements are verified to be correct and complete.
• Poor requirements ripple down the software development and results in a
product that does not meet the user’s requirements or expectations.
 Inspection Upon SRS

• Identify Quality attributes of SRS and check list of theses attributes.

• Search SRS Quality attributes e.g. Correctness, Completeness, Unambiguity,
Consistency…..

Requirement Check List Point Defect Explanation

 SRS Check list :: Ambiguity

• An SRS is said to be unambiguous if all the requirements stated have only 1

interpretation.
• SRS is unambiguous when every fixed requirement has only one
interpretation.
• This suggests that each element is uniquely interpreted.
• In case there is a method used with multiple definitions, the requirements
report should determine the implications in the SRS so that it is clear and
simple to understand.
 SRS Check list :: Ambiguity
#
Checklist

1.1 Are functional requirements clearly separated from non-

functional requirements?
1.2 Is any requirement conveying more than one interpretation?

1.3 Are all requirements clearly understandable?

 SRS Check list :: Consistency

• Requirements in SRS are said to be consistent if there are no conflicts

between any set of requirements.
• Examples of conflict include differences in terminologies used at separate
places, logical conflicts like time period of report generation, etc.
 SRS Check list :: Consistency
# Checklist

2.1 Are the requirements stated at the consistent level of details?

2.2 Are the requirements consistent with other documents of the

project?
2.3 Is there any difference in the stated requirements at two
places?
 SRS Check list :: Feasibility

• Feasibility is defined as the practical extent to which a project can be

performed successfully.
• To evaluate feasibility, a feasibility study is performed, which determines
whether the solution considered to accomplish the requirements is practical
and workable in the software.
 SRS Check list :: Feasibility

# Checklist
3.1 Are every stated requirement feasible?

3.2 Is there non-feasible requirement due to technical reason?

3.3 Is there non-feasible requirement due to lack of resources?

3.4 Is any requirement feasible but very hard and complex to

implement?
 SRS Check list ::Modifiability

• SRS should be made as modifiable as possible and should be capable of

easily accepting changes to the system to some extent.
• Modifications should be properly indexed and cross-referenced.
 SRS Check list ::Modifiability

# Checklist

4.1 Is every stated requirement modifiable?

4.2 Has the document been designed to incorporated changes?

4.3 Is the format structure and style of the document standard?

4.4 Have redundant requirements been consolidated?

 Software Requirement Specification (SRS)

• User should be ready to search books by their title, author, subject category also by the
publication date.
• Each book will have a singular number and other details including a rack number which
can help to physically locate the book.
• There might be quite one copy of a book, and library members should be ready to check-
out and reserve any copy. We’ll call each copy of a book, a book item.
• The system should be ready to retrieve information like who took a specific book or what
are the books checked-out by a selected library member.
• There should be a maximum limit (5) on what percentage books a member can check-out.
 Software Requirement Specification (SRS)

• There should be a maximum limit (10) on what percentage days a member can keep
a book.
• The system should be ready to collect fines for books returned after the maturity.
• Members should be ready to reserve books that aren’t currently available.
• The system should be ready to send notifications whenever the reserved books
become available, also as when the book isn’t returned within the maturity.
• Each book and member card will have a singular barcode. The system is going to be
ready to read barcodes from books and members’ library cards
Requirements Check List Points Defects
#5.3 Are the requirements stated Ambiguity
The system should use less simply and completely so that they  Specific amount of memory is not
memory and will be easily are unambiguous? mentioned in the requirement
accessible by the user. #5.4 Are the requirements stated  Different people may interpret it
clearly so there is only one differently
interpretation?

A secure way will be provided for #5.3 Are the requirements stated Ambiguity
the billing. simply and completely so that they  The word secure is used in the
are unambiguous? requirement but it is not clearly stated
#5.4 Are the requirements stated that how security will be provided
clearly so there is only one  Different people may interpret it
interpretation? differently

Transactions will be faster even #5.3 Are the requirements stated Ambiguity
physically from the branch simply and completely so that they  The term faster is used in the
because it will be very easy for are unambiguous? requirement but any specific speed is
the bank staff to check the #5.4 Are the requirements stated not mentioned in the requirement
balance of a specific person and clearly so there is only one  Different people may interpret it
update its record if necessary. interpretation? differently
N
o. Checklist Point Description
1
Functionality 1. Test all links, including internal and external links, navigation menus, buttons, form
Testing submissions, search functionality, and interactive elements.
2. Verify user input handling and error messages.
2
Compatibility 1. Test website compatibility across different web browsers (Chrome, Firefox, Safari, Edge, etc.)
Testing and ensure responsiveness on various devices (desktop, laptop, tablet, mobile) and screen sizes.
2. Verify compatibility with different operating systems (Windows, macOS, Linux, iOS, Android).
3 Performance Test website load times, performance under different network conditions, and identify any memory
Testing leaks or excessive resource usage.
4
Usability Testing 1. Evaluate website layout, design, navigation, and user flow.
2. Check for readability, consistency in design elements, and overall user-friendliness.
5 Security Testing
1. Ensure website uses HTTPS protocol for secure data transmission.
2. Test user authentication and authorization mechanisms. Verify protection against common security
vulnerabilities, such as cross-site scripting (XSS) or SQL injection.
 Checklist Point Description
6
Accessibility 1. Evaluate website accessibility for users with disabilities, following WCAG (Web Content
Testing Accessibility Guidelines) standards.
2. Check for proper alt tags on images, appropriate labeling of form elements, and keyboard
accessibility.
7 Content Testing
1. Verify accuracy, relevance, and proper formatting of website content.
2. Check for broken or missing links, images, videos, or other media.
8 Cross-Device 1. Test website functionality and appearance on different devices, including desktops,
Testing laptops, tablets, and smartphones.
2. Verify landscape and portrait orientations for mobile devices.
9
Cross-Platform Test website performance and functionality on different operating systems, such as
Testing Windows, macOS, Linux, iOS, and Android.
1 Localization 1. Check for proper translation and localization of content, including text, date formats,
0 Testing and currency symbols.
2. Test website functionality with different languages and character sets.