Chapter One_Quality assurance and testing PDF

Software testing and quality assurance(4055) Intro. To Software testing and quality 5/21/24 1 assurance  Introduction to Software testing and quality assurance...

Software testing and quality assurance(4055) Intro. To Software testing and quality 5/21/24 1 assurance  Introduction to Software testing and quality assurance Intro. To Software testing and quality 5/21/24 2 assurance ˜ Software quality, software quality problems and cases ˜ Quality Assurance, quality control and quality management ˜ Views of quality ˜ Defect detection vs. Prevention ˜ Software verification and Validation ˜ Software testing and its principles ˜ Basics of software testing like bug, error, failure ˜ Generic software testing process and life cycles Intro. To Software testing and quality 5/21/24 3 assurance ˜ Quality refers to the conformance to implicit or explicit requirements, expectations, and standards. ˜ Conformance to o Explicitly stated functional and performance requirements o Explicitly documented development standards, and o Implicit characteristics that are expected of all professionally developed software. (Pressman) Intro. To Software testing and quality 5/21/24 4 assurance ˜ Software specifications are usually incomplete and often inconsistent ˜ There is tension between: o customer quality requirements (efficiency, reliability, etc.) o developer quality requirements (maintainability, reusability, etc.) ˜ Some quality requirements are hard to specify in an unambiguous way o directly measurable qualities (e.g., errors/KLOC), o indirectly measurable qualities (e.g., usability). Quality management is not just about reducing defects! Intro. To Software testing and quality 5/21/24 5 assurance ˜ Low defects level when deployed o Zero defect most preferably ˜ High reliability o Capability of running without crashes ˜ Majority of the user satisfy with software when conducted the survey ˜ Effective customer support ˜ Rapid defect repair Intro. To Software testing and quality 5/21/24 6 assurance Can be ˜ Static quality attributes: structured, maintainable, testable code as well as the availability of correct and complete documentation. ˜ Dynamic quality attributes: software reliability, correctness, completeness, consistency, usability, and performance Intro. To Software testing and quality 5/21/24 7 assurance Correctness ˜ A system is correct if it behaves according to its specification o An absolute property (i.e., a system cannot be “almost correct”) o... in theory and practice undecidable Reliability ˜ The user may rely on the system behaving properly ˜ Reliability is the probability that the system will operate as expected over a specified interval o A relative property (a system has a mean time between failure of 3 weeks) Robustness ˜ A system is robust if it behaves reasonably even in circumstances that were not specified ˜ A vague property (once you specify the abnormal circumstances they become part of the requirements) Intro. To Software testing and quality 5/21/24 8 assurance Efficiency (Performance) ˜ Use of resources such as computing time, memory o Affects user-friendliness and scalability o Hardware technology changes fast! o First do it, then do it right, then do it fast ˜ For process, resources are manpower, time and money o relates to the “productivity” of a process Usability (User Friendliness, Human Factors) ˜ The degree to which the human users find the system (process) both “easy to use” and useful o Depends a lot on the target audience (novices vs. experts) o Often a system has various kinds of users (end-users, operators, installers) o Typically expressed in “amount of time to learn the system” Intro. To Software testing and quality 5/21/24 9 assurance Maintainability ˜ How easy it is to change a system after its initial release o software entropy Þ maintainability gradually decreases over time Repairability ˜ How much work is needed to correct a defect Evolvability (Adaptability) ˜ How much work is needed to adapt to changing requirements (both system and process) Portability ˜ How much work is needed to port to new environment or platforms Intro. To Software testing and quality 5/21/24 10 assurance Verifiability ˜ How easy it is to verify whether desired attributes are there? o internally: e.g., verify requirements, code inspections o externally: e.g., testing, efficiency Understandability ˜ How easy it is to understand the system o internally: contributes to maintainability o externally: contributes to usability Timeliness ˜ Ability to deliver the product on time o important for marketing (“short time to market”) o often a reason to sacrifice other quality attributes o incremental development may provide an answer Intro. To Software testing and quality 5/21/24 11 assurance ˜ Reduced maintenance cost ˜ Stable and useful product ˜ Satisfy customer needs ˜ Better chances for continuing releases ˜ Build corporate culture and identity ˜ Better chances for software and design reuse Intro. To Software testing and quality 5/21/24 12 assurance ˜ Quality assurance – a set of establish framework (procedures & standard) used by an organization to achieve high quality software. ˜ It is the set of actions including facilitation, training, measurement, and analysis needed to provide adequate confidence that processes are established and continuously improved. ˜ Assure each of the software qualities is met o Goal set in requirements specification o Goal realized in the implementation ˜ SQA is applied at every stage of the software process ˜ Quality standard is selected to apply to the software process Intro. To Software testing and quality 5/21/24 13 assurance ˜ why SQA activities pays off Intro. To Software testing and quality 5/21/24 14 assurance  1. Set the standard and quality attributes that a software product must meet o The goal to achieve 2. Measure the quality of software product o There is a way to determine how well the product conforms to the standards and quality attributes 3. Track the values of the quality attributes o It is possible to assess how well we are doing 4. Use the information of software quality to improve the quality of future software product o There is a feedback into the software development process Intro. To Software testing and quality 5/21/24 15 assurance ˜ Quality Control - It is the processes and methods used to compare product quality to requirements and applicable standards, and the actions are taken when a nonconformance is detected. o “ is the activity performed to ensue that a Product is ‘fit for Purpose’ “. ˜ Quality Assurance o “is the activity performed to test the process is being followed” ˜ Quality Management o Responsible choosing the correct process to ensure that the product is ‘fit for purpose’. Intro. To Software testing and quality 5/21/24 16 assurance  Quality Assurance Quality Control QA is an activity that establishes and It is an activity that demonstrates whether calculates the processes that produce the or not the product produced met product. If there is no process, there is no standards. role for QA. QA helps establish process QC relates to a particular product or service QA sets up a measurement program to QC verified whether particular attributes evaluate processes exist, or do not exist, in a explicit product or service. It identifies weakness in processes and It identifies defects for the primary goals of improves them correcting errors. Quality Assurance is a managerial tool. Quality Control is a corrective tool. Verification is an example of QA. Validation is an example of QC. Intro. To Software testing and quality 5/21/24 17 assurance ˜ SQA Management Plan: Make a plan for how you will carry out the SQA throughout the project. Think about which set of software engineering activities are the best for project. check level of SQA team skills. ˜ Set The Check Points: SQA team should set checkpoints. Evaluate the performance of the project on the basis of collected data on different check points. ˜ Measure Change Impact: The changes for making the correction of an error sometimes re introduces more errors keep the measure of impact of change on project. Reset the new change to check the compatibility of this fix with whole project. Intro. To Software testing and quality 5/21/24 18 assurance ˜ Multi testing Strategy: Do not depend on a single testing approach. When you have a lot of testing approaches available use them. ˜ Manage Good Relations: In the working environment managing good relations with other teams involved in the project development is mandatory. Bad relation of SQA team with programmers team will impact directly and badly on project. Don’t play politics. ˜ Managing Reports and Records: Document and share QA activities (test cases, defects, client changes) for future reference and stakeholder alignment. Intro. To Software testing and quality 5/21/24 19 assurance ˜ In software testing, Quality Assurance goes beyond quality control functions and testing activities in order to evaluate software quality according to a range of views o Transcendental view - A notion that we can recognize quality— but cannot measure it. o User view - How the end-user perceives and experiences software quality. Focuses on user needs and expectations Usability, reliability, and efficiency o Manufacturing view - If the product is developed right the first time and without flaws during the end-to-end SDLC process. Does the product satisfy the requirements Defect count and rework cost. Intro. To Software testing and quality 5/21/24 20 assurance  o Product view - How well the internal and inherent characteristics conform to the defined requirements. o Value-based view - How well the product satisfies the requirements of various stakeholders and entities associated with the product. Excellency and worth Economic value Trade-offs between cost and quality Intro. To Software testing and quality 5/21/24 21 assurance ˜ Defect Prevention is a process to identify the root cause of defects and establish the process to avoid defects surfacing. o Improving the quality of the Software from very earlier stage. ˜ Defect Detection- Testers, with complete understanding of application under test, play a key role in Defect Detection process. It also called defect removal efficiency. o E.g System Testing, End to End Testing, Regression-Retesting, Exploratory Testing etc. o It tells you the effectiveness of Testing. o DDP = [Number of defects at the moment of software version release / Total number of defects(raised by internal testing team + customer)] X 100% Intro. To Software testing and quality 5/21/24 22 assurance  Intro. To Software testing and quality 5/21/24 23 assurance ˜ Verification & Validation is the process of investigating that a software system satisfies specifications and standards and it fulfills the required purpose. ˜ Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure whether the product that is developed is right or not. ˜ Verification is Static Testing. Activities involved in verification: - Inspections - Reviews - Walkthroughs - Desk-checking Intro. To Software testing and quality 5/21/24 24 assurance ˜ Validation is the process of checking whether the software product is up to the mark or has high level requirements. o It is the process of checking the validation of product i.e. it checks what we are developing is the right product. o It is validation of actual and expected product. ˜ Validation is the Dynamic Testing. ˜ Activities involved in validation: - Black box testing - White box testing - Unit testing - Integration testing Intro. To Software testing and quality 5/21/24 25 assurance Verification Validation The verifying process includes checking It is a dynamic mechanism of testing documents, design, code, and program and validating the actual product It does not involve executing the code It always involves executing the code It uses methods like reviews, walkthroughs, It uses methods like Black Box, White inspections, and desk- checking etc. Box, and non-functional testing It checks whether the software Whether the software conforms to specification meets the requirements and is checked expectations of a customer It can find bugs that the verification It finds bugs early in the development cycle process can not catch Target is application and software architecture, specification, complete design, high level, and Target is an actual product database design etc. It comes before validation It comes after verification Intro. To Software testing and quality 5/21/24 26 assurance Definition ? ˜ Testing is a process of executing a program with the intent of finding errors, locate errors and to proof system correctness ˜ Testing is conducted based on the developed test cases ˜ Capture actual output ˜ Compare actual output with expected output o Actual == Expected : Test case succeed o Actual != Expected : Test case failed ˜ All test cases result must be recorded Intro. To Software testing and quality 5/21/24 27 assurance Definition ? ˜ In the process of Verification just is the checking or testing of software, for consistency and conformance by evaluating the results aligned with requirements o Are we building the system right? ˜ In the process of Validation just verifying the correctness of system, it means in this process you can check what actual user wants & what has been specified. o Are we building the right system? Intro. To Software testing and quality 5/21/24 28 assurance ˜ Testing is the process of determining if a program has any errors. ˜ When testing reveals an error, the process used to determine the cause of this error and to remove it, is known as debugging. ˜ Debugging is a part of the development activity that identifies, analyses, and removes defects. ˜ Debugging is performed by Developers on their piece of code. ˜ Testing is the activity of identifying defects and is performed by Testers. ˜ Testing is done by testers in an environment similar to production. Intro. To Software testing and quality 5/21/24 29 assurance ˜ Finding defects ˜ Gaining confidence in and providing information about the level of quality. ˜ To prevent defects, ensure reliability and increase functionality ˜ To make sure that the end result meets the business and user requirements. ˜ To ensure that it satisfies the BRS and SRS. ˜ To gain the confidence of the customers by providing them a quality product. Intro. To Software testing and quality 5/21/24 30 assurance ˜ Frequent Breakdowns o crash or freeze, disrupting ˜ Security Risks o might have vulnerabilities ˜ Increased Costs ˜ Poor User Experience o might have glitches or design flaws that make it hard to use ˜ Damaged Reputation o can harm a company’s reputation and user trust Intro. To Software testing and quality 5/21/24 31 assurance ˜ Bug / Defect / fault ˜ Error ˜ Failure Intro. To Software testing and quality 5/21/24 32 assurance ˜ Error- a human action that produces an incorrect result. o An error is a mistake made by human ˜ Defect / bug / fault- it is a problem in the functioning of a software system during testing. o The variation between the actual results and expected results. o a manifestation of an error in software o It is an incorrect step, process or data definition in a software product. o If executed, a fault may cause a failure o It is a flaw in a software system that causes the system to behave in an unintended manner. o E.g an incorrect statement or data definition. Intro. To Software testing and quality 5/21/24 33 assurance ˜ Failure- deviation of the software from its expected delivery or service o A failure is the inability of a software system to perform its operations within the specified performance benchmark. o A defect, if encountered during execution, may cause a failure of the component or system. ˜ Failure is an event; fault is a state of the software, caused by an error Intro. To Software testing and quality 5/21/24 34 assurance Errors and How they occur - Can be introduced at any stage of SDLC Ø We are all prone to making simple human errors Ø Miscommunication, Poor requirements Ø Working under pressures such as tight deadlines, budget restrictions, conflicting priorities Ø Complexity of technologies / infrastructure Ø Poorly documented code Intro. To Software testing and quality 5/21/24 35 assurance Causes of software defects Ø Faulty requirements definition Ø Client-developer communication failures Ø Logical design errors Ø Coding errors Ø Shortcomings of the testing process Ø Documentation, procedure errors Ø Deliberate deviation from software requirements Intro. To Software testing and quality 5/21/24 36 assurance ˜ Itdepends on the process and the associated stakeholders of the project(s). ˜ In most cases, the following professionals are involved in testing a system within their respective capacities − o Software Tester o Software Developer o Project Lead/Manager o End User Intro. To Software testing and quality 5/21/24 37 assurance ˜ An early start to testing reduces the cost and time to rework and produce error-free software that is delivered to the client. ˜ However in Software Development Life Cycle (SDLC), testing can be started from the Requirements Gathering phase and continued till the deployment of the software. ˜ It also depends on the development model that is being used. For example, in the Waterfall model, formal testing is conducted in the testing phase; but in the incremental model, testing is performed at the end of every increment/iteration and the whole application is tested at the end. ˜ Testing is done in different forms at every phase of SDLC − o During the requirement gathering phase, the analysis and verification of requirements are also considered as testing. o Reviewing the design in the design phase with the intent to improve the design is also considered as testing. o Testing performed by a developer on completion of the code is also categorized as testing. Intro. To Software testing and quality 5/21/24 38 assurance ˜ It is difficult to determine when to stop testing, as testing is a never-ending process and no one can claim that a software is 100% tested. The following aspects are to be considered for stopping the testing process − o Testing Deadlines o Completion of test case execution o Completion of functional and code coverage to a certain point o Bug rate falls below a certain level and no high-priority bugs are identified o Management decision Intro. To Software testing and quality 5/21/24 39 assurance ˜ Costeffective(Helps in saving money) ˜ Security ˜ Quality of the product ˜ Satisfaction of the customer ˜ Enhancing the development process ˜ Easy while adding new features ˜ Determining the performance of the software Intro. To Software testing and quality 5/21/24 40 assurance  Intro. To Software testing and quality 5/21/24 41 assurance ˜ Testing shows the presence of defects ( it is not a ghost. It is a fact ) o We test to find Faults (as known as Defects) o As we find more defects, the probability of undiscovered defects remaining in a system reduces ( decreasing nature). o However Testing cannot prove that there are no defects present Intro. To Software testing and quality 5/21/24 42 assurance ˜ Exhaustive Testing is Impossible! o We have learned that we cannot test everything (i.e. all combinations of inputs and pre-conditions). o That is we must Prioritise our testing effort using a Risk Based Approach. Intro. To Software testing and quality 5/21/24 43 assurance ˜Early testing o Testing activities should start as early as possible in the development life cycle o These activities should be focused on defined objectives – outlined in the Test Strategy o Remember from our Definition of Testing, that Testing doesn’t start once the code has been written! Intro. To Software testing and quality 5/21/24 44 assurance  Intro. To Software testing and quality 5/21/24 45 assurance ˜ Defect Clustering o Defects are not evenly distributed in a system o They are ‘clustered’ o In other words, most defects found during testing are usually confined to a small number of modules ( 80% of uncovered errors focused in 20% modules of the whole application) “Pareto law” o Similarly, most operational failures of a system are usually confined to a small number of modules o An important consideration in test prioritisation! Intro. To Software testing and quality 5/21/24 46 assurance ˜ The Pesticide Paradox o Testing identifies bugs, and programmers respond to fix them o As bugs are eliminated by the programmers, the software improves o As software improves the effectiveness of previous tests erodes o Therefore we must learn, create and use new tests based on new techniques to catch new bugs ( i.e. It is not a matter of repetition. It is a matter of learning and improving) Intro. To Software testing and quality 5/21/24 47 assurance ˜ Testing is Context (background)Dependent o Testing is done differently in different contexts o For example, safety-critical software is tested differently from an e-commerce site o Whilst, Testing can be 50% of development costs, in NASA's Apollo program (it was 80% testing) o 3 to 10 failures per thousand lines of code (KLOC) typical for commercial software o 1 to 3 failures per KLOC typical for industrial software o 0.01 failures per KLOC for NASA Shuttle code! o Also different industries impose different testing standards Intro. To Software testing and quality 5/21/24 48 assurance 7. Absence of Errors Fallacy o If we build a system and, in doing so, find and fix defects.... It doesn’t make it a good system o Even after defects have been resolved, it may still be unusable and/or does not fulfil the users’ needs and expectations Intro. To Software testing and quality 5/21/24 49 assurance  1. Planning and Control ˜ Test planning has major tasks such as o To determine the scope and risks and identify the objectives/goals of testing. o To determine the test approach. o To implement the test policy and/or the test strategy. Test strategy is an outline that describes the testing portion of the software development cycle. Intro. To Software testing and quality 5/21/24 50 assurance  1. Planning and Control… ˜ Test planning has major tasks such as… o To determine the required test resources like people, test environments, PCs, etc. o To schedule test analysis and design tasks, test implementation, execution and evaluation. o To determine the Exit criteria Intro. To Software testing and quality 5/21/24 51 assurance  1. Planning and Control ˜ Test control has major tasks such as o To measure and analyze the results of reviews and testing. o To monitor and document progress, test coverage and exit criteria. o To provide information on testing. o To initiate corrective actions. o To make decisions. Intro. To Software testing and quality 5/21/24 52 assurance  2. Analysis and Design ˜ Analysis and design has major tasks such as o To review the test basis(architecture, design, specification, requirements, interfaces…). o To identify test conditions. o To design the tests. o To evaluate testability of the requirements and system. o To design the test environment set-up and identify the required infrastructure and tools. Intro. To Software testing and quality 5/21/24 53 assurance  3. Implementation and Execution ˜ Implementation has major tasks such as o To develop and prioritize our test cases by using techniques and create test data for those tests. o To create test suites from the test cases for efficient test execution. o To implement and verify the environment. Intro. To Software testing and quality 5/21/24 54 assurance  3. Implementation and Execution… o To execute test suites and individual test cases following the test procedures. o To re-execute the tests that previously failed in order to confirm a fix - confirmation testing or re-testing. o To log the outcome of the test execution and record the identities and versions of the software under tests. o To Compare actual results with expected results. Intro. To Software testing and quality 5/21/24 55 assurance  4. Evaluating exit criteria and Reporting ˜ Evaluating exit criteria has major tasks o To check the test logs against the exit criteria specified in test planning. o To assess if more test are needed or if the exit criteria specified should be changed. o To write a test summary report for stakeholders. Intro. To Software testing and quality 5/21/24 56 assurance  4.Evaluating exit criteria and Reporting… ˜ How to measure exit criteria o All the planned requirements must be met o All the high Priority bugs should be closed o All the test cases should be executed o If the scheduled time out is arrived o Test manager must sign off the release Note: All these parameters can be met by percentages( not 100 %) Intro. To Software testing and quality 5/21/24 57 assurance  5. Test Closure activities ˜ Test closure activities are done when software is delivered. ˜ Test closure activities o To check which planned deliverables are actually delivered and to ensure that all incident reports have been resolved. o To finalize and archive testware such as scripts, test environments, etc. for later reuse. o To handover the testware to the maintenance organization. o To evaluate how the testing went and learn lessons for future releases and projects. Intro. To Software testing and quality 5/21/24 58 assurance ˜ Static testing is a verification process used to test the application without implementing the code of the application. ˜ And it is a cost-effective process. ˜ To avoid the errors, we will execute Static testing in the initial stage of development because it is easier to identify the sources of errors, and it can fix easily. ˜ It is also called verification process and can be done by manually or using tools ˜ It is an examination of program code with its associated documentation without execution of a code. ˜ It is also called dry-run testing Intro. To Software testing and quality 5/21/24 59 assurance ˜ Compared with dynamic testing, typical defects that is simple and cheaper to fix using static testing includes o Requirement defect Inconsistence, incomplete, ambiguous, contradictions…. o Design defect Inefficient algorithm/data structure, high coupling, low cohesion o Coding defect All anomalies (DD, UD, KK, dead code, unused code…) o Deviation from standards Lack of coding standards o Incorrect interface specification o Security vulnerability Suspicious to buffer overflow ˜ All the static testing types should follow the general test process activities Intro. To Software testing and quality 5/21/24 60 assurance ˜ Why static testing o To improve the development productivity. o To find the detects in the earlier stages and easily fix them. o To decrease the testing cost, development timescales, and time. o Reduced development timescales o To get fewer defect at a later stage of testing ˜ When – on the following situations occupied o Dynamic Testing is time-consuming o Flaws at earlier stages/identification of Bugs o Dynamic Testing is expensive o Increased size of the software Intro. To Software testing and quality 5/21/24 61 assurance ˜ Things done in static testing are o Business Requirements Document (BRD) o Use Cases o System/Functional Requirements o Prototype o Prototype Specification Document o DB Fields Dictionary Spreadsheet o Test Data o Traceability Matrix Document o User Manual/Training Guides/Documentation o Test Plan Strategy Document/Test Cases o Architecture and design specification o Source codes, contracts, project schedule, budgets Intro. To Software testing and quality 5/21/24 62 assurance ˜ The moderator o Also known as review leader o Performs entry check o Follow up on he rework o Schedule the meeting o Coaches other team o Leads the possible discussion and stories that is collected ˜ The Author o Illuminates the unclear areas and understand the defects found o Basic goal should be to learn as much as possible with regard to improve the quality of documents Intro. To Software testing and quality 5/21/24 63 assurance ˜ The scribe o Scribe is a separate person to logging of defects found during the review ˜ The reviewers o Also called checkers or inspectors o Check any materials for defects mostly prior to meeting o The manager can also be involved in the review depending on his / her background ˜ The manager o The manager decides on the execution of reviews o Allocates time in project schedule and determine whether the review process objective has been meet Intro. To Software testing and quality 5/21/24 64 assurance ˜ Techniques of static testing Intro. To Software testing and quality 5/21/24 65 assurance ˜ Informal review 5/21/24 Intro. To Software testing and quality assurance 66 ˜ Formal review Intro. To Software testing and quality 5/21/24 67 assurance ˜ Technical review Intro. To Software testing and quality 5/21/24 68 assurance ˜ Walkthrough Intro. To Software testing and quality 5/21/24 69 assurance ˜ Walkthrough… o A walk-through is a step-by-step presentation of a document by the author at a walk-through meeting. o The primary objective is to find defects- Quite often the author discovers defects him- or herself just by going through the document. o The secondary objective is to create a common understanding of the contents of the document under testing. o are usually planned to take place at certain times in the development life cycle. o The author of whichever document is being reviewed will explain the document to their team. o Participants will ask questions, and any notes are written down. Intro. To Software testing and quality 5/21/24 70 assurance ˜ Management review o It is performed on management documents. This may be: Project-related plans, such as: Project management plans, including schedules and resources Quality assurance plans Configuration management plans Risk management plans Contingency plans Intro. To Software testing and quality 5/21/24 71 assurance ˜ Management review… o Plans pertaining to the product, such as: Safety plans Installation plans Maintenance plans Backup and recovery plans Disaster plans o Reports, such as: Progress reports Incident reports, including customer complaints Technical review reports Inspection reports Audit reports Intro. To Software testing and quality 5/21/24 72 assurance ˜ Management review… o The primary objective is to find defects in the documents under static testing. o The secondary objective is to monitor progress according to the current plan, to assess status, and to make necessary decisions about any actions to take accordingly, including changes in resources, time, and/or scope/quality and updating the plan accordingly. o The scope and the quality are usually expressed in terms of requirements to fulfil. o Are usually planned to take place at certain times in the development life cycle, typically in connection with defined milestones, that is, transfer from one development phase to the next. Intro. To Software testing and quality 5/21/24 73 assurance ˜ Inspection Intro. To Software testing and quality 5/21/24 74 assurance ˜ Inspection …characteristics o The process to follow must be the formally defined process o The roles must be the defined inspection roles o Source material (basis documentation) must always be used o The inspectors must look for specific kinds of issues o Metrics must be defined and collected Intro. To Software testing and quality 5/21/24 75 assurance ˜ Inspection …main purposes o Product improvement o Process improvement ˜ The formal inspection process consists of the activities: o Planning o Overview o Preparation o Meeting o Rework o Follow-up Intro. To Software testing and quality 5/21/24 76 assurance ˜ Static analysis o Systematic analysis/review of software source code quality without executing the code o Check the syntax of the code, coding standards and code optimization o It is termed as white box testing – it can be done at any stages of the software development o Things revealed A variable with an undefined value A variable that is declared but never used Unreachable code(dead code) Programming standard violation Security vulnerability : Syntax violation , endless loops…… Intro. To Software testing and quality 5/21/24 77 assurance ˜ Static testing technique can also be mixed oInformal review -> Inspection o Technical Review -> Inspection -> Walk-through o Technical review -> Walk-through o Walk-through -> Inspection -> Informal review o Informal review -> Technical review -> Inspection ˜ Some of the tools used for static testing are o Squale o sonarQube o SorceMeter o Jtest o 5/21/24 …… Intro. To Software testing and quality 78 assurance ˜ Static testing ˜ Dynamic testing ˜ It checks the code or the ˜ It checks the code or the application without application by executing the executing the code. code. ˜ It is a Verification Process ˜ It is a Validation Process. ˜ It is used to prevent defects. ˜ used to find and fix the ˜ It can be performed before defects. the compilation of code. ˜ It can be done only after the executable are prepared. Intro. To Software testing and quality 5/21/24 79 assurance ˜ Pros of static testing ˜ Cons of static testing Intro. To Software testing and quality 5/21/24 80 assurance  1. Software quality 2. Software quality problems 3. Software quality factor 4. Causes of software defect 5. Error vs defect vs bug vs fault vs failure 6. Verification vs validation 7. Static vs dynamic testing 8. Quality assurance vs quality control 9. Testing vs debugging 10. Detection vs prevention 11. Views of software quality assurance 12. Testing processes 13. Principles of quality assurance 14. Software testing principles 15. Static testing, types of static testing, pros and cons, tools used for static testing, what type of things are tested, what are the major goals 16. ………. Intro. To Software testing and quality 5/21/24 81 assurance  Questions ? Intro. To Software testing and quality 5/21/24 82 assurance