Introduction to Software Testing eae | Introduction : Historical perspective, Definition, suppliers and process, Objective of Testing, | Why Software has Error, Defects and Failur Core Components, Quality View, Financial Aspect, Customers Testing and Debugging. Need of Testing, Quality Assurance and Testing, es and its Causes and Effect, Total Quality Management (TQM), Quality | Practices of TQM, Quality Management through - Statistical process Control, | Improvement cycle, Quality in different areas, Solving Software Tools. Cultural Changes, Continual Benchmarking and metrics, Problem Solving Techniques, Problem Software Quality : Introduction, Constraints of Software product Quality assessment, Customer is a King, Quality and Productivity Relations! Requirements of Product, Organization Culture, Characteristics of Software, Software Development Process, Types of Product, Criticality Definitions, Problematic areas of SDLC, Software Development Life Cycle Model Software Quality Management, Why Software has defects, Processes related to Software Quality, Quality Management System’s Structure, Pillars of Quality Management System, Important aspects of quality management. 1.1 __ Introduction to Quality often described as the ‘fitness for purpose’ of a piece of software. = Human lifestyle is enhanced with the use quality products and services. Products take physical form whereas services can be termed as virtual form of = Whereas quality of conformance is concerned with implementation, quality of design measures how valid the design and requirements are in creating 2 product, worthwhile product. ~ Product (service) quality depends on two factors, one | _ software quality may be defined as conformance to is skill of quality assessor and second, effectiveness of | explicitly stated functional and performance @ process used to measure quality. requirements, explicitly documented development ~ fach and every product (service) is composed of standards and implicit characteristics that are various quality attributes. expected of all professionally developed software. = Due to immense competition, manufacturers must | The key points in this definition ‘ocus on keeping good identiy ofa product Service) | |< eae requirements are the foundations from = Quality of product (service) depends on few characteristics like-satisfying customer's need, cost, features, functionalities, delivery schedule etc which quality is measured. Lack of conformance to requirement is lack of quality. Specified standards define 2 set of development = In the context of software engineering, software quality measures how well software is designed criteria that guide the manager is software (quality of design), and how well the software | engineering conforms to that design (quality of conformance), although there are several different definitions. It is 4. If criteria are not followed lack of quality will usually result. ssAssurance (SPPU) fivvare Testing and A cet of implicit requirements often goes unmentioned, for exarnple ease of use, maintainability ete 6. It software confirms to its explicit requirement but falls to meet implicit requirements, software quality is suspected, 1.2 Historical Perspective of Quality ~ Concept of quality and quality improvement had ernerged from the field of agriculture In the 20” century, farmers were assisted for planning of the crops, rotation of cultivation, maintaining soil quality in order to mavimize agricultural production ~ This work hed conducted in Britain, Some researchers had contributed towards this and is described in below section 1, Wolter Shewhart -- Developed a quality improvement program with planned efforts. Applied concept to product manufacturing process to reduce cost to customer without decreasing profit. 2. Dr. Edward Deming Suggested Total Quality Management (TQM) program to improve quality methods and practices. Idea is demonstrated through continual improvement in Japan. 3. Dr. Joseph Juran - Implemented quality improvement program through measurement processes. ~ He had used different assessment and improvement tools for this. - Concept of TQM was integrated by Japanese industry that leads to generation of quality products in sectors, like, electronics, automotive etc - Product quality was established and continually improved in terms of cost, delivery schedule, performance, features etc. Testi Introduction to So! ~ The Japanese products manufactured with proper organization and understanding of process used for their development. Use of different tools enabled them to monitor and understand processes. = Japanese quality management program consists set of interrelated processes. This maintains same quality across large number of products. = With continual process improvement program, root causes of defects are identified and removed easily. Quality Definition = It is defined as conformance to the specifications Every product is having requirement specification, design specification etc. = A quality product must conform specifications which ultimately satisfies the customer's needs. it must be built as per design stated, ta. these = It must also satisfy customer's expectations related to cost, delivery time, support ete. = Quality of @ product is determined by its inherent attributes and characteristics. Term quality can be defined from various perceptions as follows. 1. General Software Quality definition SOFTWARE QUALITY is the degree of conformance to explicit or implicit requirements and expectations of customer. 2. Definition by IEEE ~The degree to which a system, component, or process meets specified requirements The degree to which a system, component. or process meets customer or user needs or expectations. 3. Customer based definition - Aauality product must achieve customers satisfaction by meeting their needs and expectations. 4, Manufacturing based definition = A quality product must be developed as per its requirement and design specification = Development methods must be selected wisely to produce required product with less or no defects, vW software Testing and Quality Assurance (SPPU) 13 5. Product based definition ~ A quality product must possess set of attributes and characteristics that will help customers to satisfy their needs, ~ These attributes will add great value to a product to make it distinguishable from other competing products, = Such product will make customer to feel proud for having it. . Value based definition - A product is a combination of cost and features (expected by customer) = A customer must get returns for his investment after buying product. — Cost of product depends on value found by customer in the product. Having more value for customer lead to better appreciation, 7. Transcendent Quality ~ Many customers are not clearly knowing what quality is about a product they own. Instead they derive good characteristics from product that will delight them and gives proud feeling of ownership. 1.4 _Core Components of Quality improve 3. Etfors for Improvement ——— 4. Gominua Continuous Process improvement Fig. 1.4.1 : Core Components Introduction to Software Testing 1. Customer Satisfaction ~ Product quality is the perception of a customer made during its usage. = Quality of @ product will be determined based on level of satisfaction of a user. ~ It Is also decided by some attributes like, cost, delivery time etc, 2. Quality Parameters = Manufacturers must know the user expectations in order to achieve quality in product to be developed. - By stating quality in measurable terms, it becomes easy for manufacturers to determine whether it has been achieved or not. = Organizations must follow cycle of improveme: (OMMCD which has following components. () Define ~ Product requirements in terms of attributes and characteristics must be stated in specification document. Acceptance criteria for a product must be defined. - There must be a quantitative measurement of features, functionalities, and attributes of product - Supplier and customer, both must know what is required and what is not. (ii) Measure = Quality of @ product must measured in quantitative terms which can be defined as an attribute of qual = These quantities will act as an indicator for need of quality improvement. = Lack in quality can be observed by comparing expected and delivered product (iil) Monitor ~ Organizations must establish monitoring mechanism to observe performance of processes used development, testing, and delivery: WienW software Testing and Quality Assurance (SPPU) (iv) Control (v) Improve 14 Customer satisfaction must be ensured through this monitoring. Deficiencies in product must improving product and process. In such cases, organizations must set corrective be handled by and preventive action plans ready. Organizations must have functions like, quality control, validation, verification, and quality assurance. Product progress must be reviewed and controlled through these functions. Continuous and continual improvement approaches must be followed by organizations to achieve satisfaction, tackle the maximum customer ‘competition, and overcome the customer complaints. Efforts for Improvement Management of an organization should lead the quality improvement program by defining, vision, mission, objectives, goals, policies, strategies etc. Management must set an example by following these and encourage employees to adopt same. Management must define and approve different procedures, methods, standards etc. Deviations in system must be tracked that becomes the candidate for improvement. Quality plan developed by management always supports the improvement efforts and actions. Continual/ Continuous Process Improvement It is old practice where quality is improved with rework, testing, more inspection etc. Team was fixing defects when they are reported by customers. This has increased cost of inspection and rework, that in turn increases price for customer. Efforts for improving quality must be directed through provement approach, "> match symptom glitch. They with cause, by that it leads Vulnerability in Windows 10. This bug enables users to escape from security sandboxes through a flaw in of software. the win32k system. plane F-35 fell victim to @ software | . | Debugging commences Testing is initiated after In 2015 fighter with the execution of a test “ring it unable to detec 1708 correctly. bug, mi the code is written,ee NG aNd Quality Assurance (sPPu) = Introduction to Software Test 3 Airlines Airbus A300 crashed due to a software aaa Sug on April 26, 1994, killing 264 innocents live In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and Gelivered lethal radiation doses to patients, leaving 3 People dead and critically injuring 3 others. In April of 1999, a software bug caused the failure of a $12 billion military satellite launch, the costliest accident in history In May of 1996, a software bug caused the bank accounts of 823 customers of a major US. bank to be credited with 920 million US dollars. 9 sting Testing is the process or activity that checks the functionality and correctness of software according to specified user requirements in order to improve the quality and reliability of system. It is an expensive, time consuming, and critical approach in system development which requires proper planning of overall testing process. A successful test is one that finds the errors. It executes the program with explicit intention of finding error, ie, making the program fail. It is @ process of evaluating system with an intention of creating a strong system and mainly focuses on the Weak areas of the system or software. Quality Assurance It is the review of system or software products and its documentation for assurance that system meets the requirements and specifications. = Purpose of QA is to provide confidence to the customers by constant delivery of product according to specification Software Quality Assurance (SQA) is a techniques that includes procedures and tools applied by the software professionals to ensure that software meet the specified standard for its intended use and performance. The main aim of SQA is to provide proper and accurate visibility of software project and its developed product to the administration, It reviews and audits the software product and its activities throughout the life cycle of system development. Objectives of Quality Assurance The objectives of conducting quality assurance are as follows - ~ To monitor the software development process and the final software developed. ~ To ensure whether the software project is implementing the standards and procedures set by the management To notify groups and individuals about the SQA activities and results of these activities. To ensure that the issues, which are not solved within the sofware are addressed by the management. upper To identify deficiencies in the product, process, of the standards, and fix them, Difference between Software Testing and Quality Assurance Software Testing Quality Assi Software Testing is 2 way of exploring the system to check how it operates and find the possible defects Quality Assurance is a set of methods and activities designed to ensure that the developed software corresponds to all the | | specifications Software testing refers to activities that are performed on a program after it has been written. Quality assurance includes step of the development process each Ensure that processes and procedures are in place to | achieve quality. | | process t0 Validate the product against specifications. | Focus on actual testing of | Focus on the product. achieve required qual a TeaiaealeytSoftware Testing Quality Assurance | Soteware testing is product oriented Quality process oriented assurance is It finds and fixes defects. | It prevents defects, Itis corrective method. _| It is preventive method, It controls the quality. It assure the quality Whole team is involved. Testing team is involved 1.10 Why Software has Bugs, Errors, Defects and Failures ~ A Software Bug is a failure or flaw in a program that produces undesired or incorrect results, It's an error that prevents the application from functioning as it should. - There are many reasons for the occurrence of Software Bugs. The most common reason is human mistakes in software design and coding = Once you get to know the causes for Software Defects, then it will be easier for you to take corrective actions to minimize these defects. ~The software delivered to customer is not completely defect free in spite of taking all possible precautions, doing verification and validation activities. 1.10.1 Reasons for Software Bugs 1, Miscommunieation or No Communication : The success of any software application depends on the communication between stakeholders, development, and testing requirements and misinterpretation of requirements are the two major factors that cause defects in software. Also, defects are introduced in the development stage if the exact requirements are not communicated properly to the development teams. teams. Unclear 2. Software Complexity : The complexity of the current software applications can be difficult for anyone with no experience in modern-day software development. Sofware Testing and Quality Assurance (SPPU) 1 Introduction to Software TESNDS, Client-Server, and Data Communications, Windows-type interfaces, Distributed Applications, enormous ‘relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. Using object oriented techniques can complicate, instead of simplifying, a project unless it is well-engineered. Programming Errors : Programmers, like anyone else, can make common programming mistakes. Not all developers are domain experts. Inexperienced programmers or without proper domain knowledge can introduce simple mistakes while coding. Lack of simple coding practices, unit testing, debugging are some of the common reasons for these issues to get introduced at the development programmers stage. Changing Requirements : The customer may not understand the effects of changes or may understand and anyway request them to redesign, rescheduling of engineers, effects on the other projects, and the work already completed may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are any minor changes or major changes, known and unknown dependencies, then the parts of the project are likely to interact and cause problems, and the complexity of keeping a track of changes may result in errors. The enthusiasm of engineering staff may be affected. In some fast- changing business environments, _ continuously changed requirements may be a fact of life, In these cases, the management must understand the resulting risks, and QA & test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control. Time Pressures : Scheduling software projects is difficult, often requiring a lot of guesswork, When deadlines loom and the crunch comes, mistakes will be made still, Unrealistic schedules, though not the major concern in small-scale projects/companies results in software bugs. If there is not enough time for proper design, coding, and testing, then it's quite obvious for detects to be introduced. ‘common, WY eticW sotware Testing and Quality Assurance (SPPU) Egotistical or Overconfident People : People prefer to say things like: ‘no problem, ‘piece of cake’, 1 can whip that out in a few hours ‘It should be easy to update that old code’. Instead of : That adds a lot of complexity and we could end up making a lot of mistakes’ ‘We do not know if we can do that; we'll wing it. ‘1 can't estimate how long it will take until I take a closer look at it. ‘We can't figure out what that old spaghetti code did in the first place’. If there are too many Untealistic ‘no problem's, then it results in software bugs. Poorly Documented Code : It's tough to maintain and modify the code that is badly written or poorly documented; the result is Software Bugs. In many ‘organizations, management provides no incentive for Programmers to document their code or write clear, understandable code. In fact, it's usually the opposite they get points mostly for quickly turning out code, and there's job security if nobody else can understand it, Any new programmer working on this code may get confused because of the complexity of the project and the poorly documented code. Many times it takes a longer time to make even slight changes in poorly documented code, as there is a huge learning curve before making any code change. Software Development Tools : Visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs. Continuously changing software tools are used by software programmers. Keeping pace with the different versions and their compatibility is a major ongoing issue. Obsolete Automation Scripts : Writing automation scripts takes a lot of time, especially for complex scenarios. If automation team's record/write any test script but forget to update it over a period, then that test could become obsolete. If the automation test is not validating the results properly: then it won't be able to catch the defects. 1:10 Introduction to Software Testing 10. Lack of Skilled Testers : Having skilled testers with domain knowledge is extremely important for the success of any project. But appointing all experienced testers is not possible for all companies. Domain knowledge and the tester's ability to find defects can Produce high-quality software. Compromise on any of this can result in buggy software. 1.10.2 More reasons for Software Bugs 1. Not having a proper test setup (test environment) for testing all requirements. 2. Writing code or test cases without understanding the requirements clearly. 3. The incorrect design leads to issues being carried out in all phases of the Software Development Cycle. 4. Releasing software patches frequently without completing the Software Testing Life Cycle. 5. Not providing training to resources for the skills required for developing or testing the application properly 6. Giving very little or no time for Regression Testing, 7. Not Automating Repetitive Test Cases and depending on the testers for manual verification every time. 8. Not prioritizing test execution. 9% Not tracking the development and test execution Progress continuously. Last-minute changes are likely to introduce errors. 10. Any wrong assumption made during coding and testing stages. 1.10.3 Inter-relation between Error, Defect, and Failure ~ tis well said by Thomas Muller "A person can make ‘an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or a document. If the execution of the defect in code happens, the system will fail to do what it should do (or something it shouldn't), which causes a failure” Waimeadeveloped # new application named “Saft Promotion System” for their annual appraisal. But employee satisfaction even after the appraisal was low. Becouse they considered it up to the mark, The management, then, decided to analyze the root cause of this dissatisfaction, not Therefore, they backtracked the process and found that the software marked full day leave for the employees who reached office after 10 a.m. This was due to some coding errors. The tester also skipped these errors in coding. So, the software with this defect went to production, Which, in turn, caused a general degradation and failure of the system. The Fig, 1.10.1 shows the interrelation between Error, Detect, and Failur Detect / taut bug Fig, 1.10.2 : Interrs ition between Error, Defect and Failure 1.10,3(A) Errors The Error is a human mistake. An Error appears not only due to the logical mistake in the code made by the developer. Anyone in the team can make mistakes during the different phases of software development. For instance, © BA (business analyst) may misinterpret. or misunderstand requirements. The customer may provide incorrect information. insufficient or The architect may cause a flaw in software design People on the team can also make mistakes due unclear or insufficient requirements, time eetesen inten, oo thes eneeene Let us observe the basic types of errors in software testing Types of Error 1 User Interface Error : These are the errors that Generally appear during user interaction with the System. Such as missing or incorrect functionality of the system, no backup function or reverse function available, etc. 2. Error handling error : Any error that occurs while the user is interacting with the software needs precise and meaningful handling. If not, it confuses, Therefore, such errors are known as error handling errors. 3. Syntactic error : Misspelled words or grammatically incorrect sentences are Syntactic errors and are very evident when testing the software GUL. 4 Calculation errors : These errors occur due to bad logic, incorrect formulas, mismatched data type, etc. 5. Flow control error : Errors concerning passing the control of the program in an incorrect direction where the software program behaves unexpectedly are flow control errors. Such as the presence of an infinite loop, reporting syntax error during run-time, ete. 6. Testing errors : It implies the errors that occurred when implementing and executing the test process. For example, bug scanning failure, inefficiency in reporting an error or defect. 7. Hardware errors : Such errors are related to the hardware device. Such as no availability and no compatibility with the device. 1.10.3(B) Defect A Defect is a variance between expected and actual results. An Error that the tester finds is known as Defect. A Defect in a software product reflects its inability or inefficiency to comply with the specified requirements and criteria and, subsequently, prevent the software application from performing the desired and expected btrneawn ac Faultoftware Testing and Quality Assurance (SPPU) pes of defects Types of detects based on Severity Basis Severity defines the degree of impact. Therefore, the verity of the detect reflects the degree or intensity of @ articular defect to adversely impact a software product ur its operation, Based on the severity metric, a defect alls under the following categories L. Critical : Defects that are “critical” require immediate attention and treatment. A critical defect directly affects the essential functionalities which can otherwise affect a software product or its large-scale functionality instance, failure ofa feature/functionality or collapse of the entire system, For ete Major : Defects, which are responsible for affecting the main functions of a software product are Major Detects. Although, these defects do not result in the complete failure of @ system but may bring several primary functions of the software to rest. Minor : These defects produce less impact and have ‘no significant influence on a software product. The results of these defects are visible in the operation of the product. However, it does not prevent users from executing the task. The task can be cartied out using some other alternative. 4. Trivial : These types of defects have no impact on the operation of a product. Hence, sometimes, we ignore and omit them. For example, spelling or grammatical errors, IL Types of defects based on Probability Basis ‘One more angle to see a defect in a software application is the probability that it will occur, and chances that the user will find it Depending on the likelinood or the possibility of a defect in a software product in terms of percentage is classified in the following ways 1. High : Almost all users of the application can track the presence of defects. This indicates a high probability. Testing Introduction to Softw aif of the users can trace the presence of . Medium defects in a software product no user detects it, or only a few 3, Low : In gener users will be able to detect it. Tl. Types of defects based on Priority B: Defects also have a business perspective comparison. The rectification of some defects must happen first. Likewise, some can solve at a later stage. Just like 2 business where everything happens according to the current need and demand ‘of the market, Just like the probability base, priority classification also occurs in the following ways: 1. High : The high priority defines the most critical need of o company to correct a defect. This should happen as soon as possible, in the same compilation. 2. Medium : Medium priority defects are next to high priority And any next version or release of a product includes addressing them. 3. Low : This type of defect does not need to be corrected individually. Consideration of repairing these types of defects, along with any other defects is voluntary. 1.10.3(C) Failure - Failure is a consequence of a Defect. It is the ‘observable incorrect behavior of the system. Failure occurs when the software fails to perform in the real environment. - In other words, after the creation & execution of software code, if the system does not perform as expected, due to the occurrence of any defect; then it is termed as Failure. Not all Defects result in Failures; some remain inactive in the code, and we may never notice them, Failures also occur due to the following reasons: © Any physical damage or overheating in the hardware can cause the whole system to fail © If the sofware is not compatible with the hardware, then also the unexpectediy. system performs WitenesDther failures in software products Software Testi ere ng 2S Quality Assurance (SPPU) 1-13 OO ll the database but having limited knowledge © © Failures also happen by _ environmental conditions like a radiation burst, a strong magnetic field, electronic fields, or pollution | — could cause faults in hardware or software. Other failures can also Happen due to a human error in interacting with the software, like entering an incorrect input value, or misinterpreting an output. Occur when someone deliberately tries to produce system failure or cause malicious damage. Happen because of the mishandling of test data, test environment, etc. Such conditions are known as defects, but they aren't actually @ Defect. Sometimes, tests that result in undetected defects can also cause failure. 10.4 Cause of Errors, Defects and Failures in Software Some possible causes are as follows : Time pressure : At times, software development happens under limited / insufficient resources with unrealistic deadlines. Developers do not have enough time to test their code before delivering it to the testing team. Which, in turn, introduces errors. Human fallibility ; Human beings are prone to make mistakes, It would be foolish to expect the software to be perfect, and without any flaws in it! Ironically, we have not yet discovered any other non-human agent that can develop software better than humans. Therefore, we continue to rely on human intelligence to develop software. Thereby, increasing the possibility of errors in it. Inexperienced or insufficiently skilled project participants : Allocation of correct work to the correct resource is fundamental for the success of any project. Team members should be assigned a task according to. their skills and abilities, An inexperienced project participant may make mistakes {they don't have proper knowledge of the work. For mple, a resource having @ good understanding of exar HTML/CSS is not suitable for designing a website. Miscommunication between project participants : Improper coordination & poor communication between various departments in a project can result in disrupted progress. Conflicts can arise each time a project participant misinterprets or misunderstands the words or actions of another. For example, the business analyst does the requirement gathering, and team member does the requirements. Any then some other documentation of the miscommunication between the two can lead to incomplete/wrong requirement document, which, in turn, affects the design of the project The complexity of the code, design, architecture, or the technology to be used : As the complexity of the program, concerning code, design or technology increases, the software becomes more critical and more bugs appear. It is because our brains can only deal with a reasonable amount of complexity or change. Our minds may not be able to process complex information like the form of design, architecture or technology, etc. Therefore, resulting in low quality and erroneous coding Misunderstandings about intra-system and inter- system interfaces : There are high chances of error while establishing an intra-system, and Inter-system interfaces. Let's try to understand what is intra- system and inter-system interfaces mean © Intra-system interface - it implies the integration of different modules/features within a system/application. For example, in an online shopping portal, we have three modules: online order, shipping, and supply chain. These three modules form the intra-system for the online shopping portal. When these different modules are combined, there is a possibility of errors in the final product. © The inter-system interface - It is the compatibility of an application with other applications when operated together, For example, compatibility between smartphones and tablets while data transfer via Bluetooth. Wisinwiensesting and Quality Ass Softwe — New, unfamiliar technologies : Sometimes, th developers and testers need to develop an application using a technique that is unknown to them. Lack of proper knowledge and understanding can lead to errors. At that time, they require a certain level of R & D, brainstorming, and training to reach 2 reliable solution. — Environmental conditions : Natural disasters, such as outbreaks of fires, floods, lightning, earthquakes, etc. can affect the computers. For example, @ system may not work correctly if the software inside is affected by radiation, electromagnetic, or pollution. 1.10.5 Effect of Errors, Defects and Failures Poor quality software can even Impact the personal development of your team. If your team are spending valuable time fixing technical debt, they have less time for research, designing new updates and thinking up new exciting product ideas for your app. The presence of design flaws in a software system has a negative impact on the quality of the software, as they indicate violations of design practices and principles, which make a software system harder to understand, maintain, and evolve, Software defects are tangible effects of poor software quality. =A software bug is an error, flaw, or fault in an ‘on. This error causes the application to applicati 3d result, such as produce an unintended or unexpecte crashing or producing invalid results. = Software testing company Tricentis revealed that in the year 2017 software failure affected 3.6 billion people and caused $1.7 trillion in financial losses. Management (TQM) 1.11 Total Q yent (TQM) is the continuous ~ Total quality managem s in process of detecting and reducing errors or defect any manufacturing process, streamlining SuPPIY chain management, improving the customer experience, and ensuring that employees are up to speed with training. — Total quality management aim: involved in the production process the overall quality of the final product 1s to hold all parties accountable for or service. ice (SPPU) 1 Introduction to Software Testing, TQM h describes internal, external customers: ‘and intemal, external suppliers for each process, project and for entire organization. — Process and function of organization can be broken down into different components which may act as customer or supplier to each other during process workflow. ~ TQM approach is based on quality principles and is applicable to all aspects of organization (e.g. business processes). — Fig, 1.111 represents supply between customer and supplier. ‘inteimal suppliers} — ‘Organizational processes chain relationship suppllars} Ln customers} linternal customerg) Fig, 1.11.1 : Supply chain relationship = Dr. Edward Deming implemented QMS based on TQM and Continual improvement in Japanese environment. = It resulted into repetitive, cost-effective processes aiming at achieving customer satisfaction. Dr. Deming proposed 14 quality management principles that are widely used by quality practitioners. 2 Quality Practices of TQM 1. Create constancy of purpose toward improvement of products and services. The aim behind this is to become competith provide jobs. Organizations must Plan for long term quality and profits. 2, Adopt the new philosophy as we are in altogether new economic age. It is unacceptable to live with commonly accepted levels of delays, rejections, mistakes, defective materials and bad workmanship Transformation of Western management style into TQM js necessary to drive business and industry towards improvement. re, to stay in business, and toCease dependence on inspection to achieve quality, Eliminate the need for inspection of entire product by employing quality checks from beginning of development. Inspections will find only lack in quality and will not help to improve quality. It is recommended to use statistical measure to control and improve development process. Stop the practice of awarding business on the basis of price tag. Focus must be kept on minimizing total cost instead of initial cost. Quality is highly dependent on consistency so if you have less variations in input, obviously there will be less variations in output. A single supplier can be contacted for any one item, on a loyal trustworthy, good, fong-term relationship. Further, to ensure that suppliers meet your quality standards, quality statistics can be used. Constant improvement in the processes related to product and services must be done. This will improve quality and productivity, which in turn leads to cost reduction. Use training and development programs for employees on the job. This will create strong foundation of knowledge and skills required at work. Institute leadership at workplace to help people to do a better job. Main aim is to provide required support and resources to people and machines. Eliminate fear so that everyone can feel free and work effectively for the organization. Make use of open and honest communication to express ideas or concerns. This will motivate employees, increases respect and interest in doing work. Break down barriers between departments and staff areas. Focus on collaboration and consensus is very important. Build shared vision approach by forming cross-functional teams. Eliminate slogans, exhortations, and targets for the workforce asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the workforce. Eliminate work standards (quotas) on the factory floor, Substitute leadership. Eliminate management by objective SURE BON LO SOTWETS TESUND Eliminate management by numbers, numerical goals. Substitute leadership. 11, Eliminate work standards that uses numerical quotas for the workforce and numerical goals for management, Substitute it with motivation and helpful leadership that will drive employees to work towards the long term goal and vision of the organization. According to Deming, production targets are always encourage high output and low quality. With proper support and resources, production levels and quality can be high and achievable. Processes must be measured instead of the people behind the process. 12. Remove the barriers that take away pride of workmanship. Everyone should be allowed to take pride in their work without being rated or compared Give similar treatment to each and every worker. and don't make them to compete with other workers for monetary or other kind of rewards. The quality system will automatically raise the level of everyone's work to an equally high level. 13, Implement education, training and self-improvement program for everyone. Improve the current sills cf workers and encourage them to learn new skills to prepare for future changes and challenges. 3uilding required skills will make your workforce more adaptable to change, and better able to find anc achieve improvements. mitment 14, Clearly define top towards improvement in quality and productivity Employees must management commitment for quality and productivity support is not enough rather. they should take action in order to accomplish the transformation management's perceive the top npioyee 1.13 Quality Management through - Statistical Process Control Statistical quality control proposed by Dr. Juran DMMCI improvement cycle approach Quality management be done based on measurements and by understanding interelationship suppliers, and processes of through must between customers. . different stages (development. testing etc) re(SPC) is an industry- Statistical Process Control standard methodology for measuring and controlling quality during the manufacturing process SPC enables real-time tracking of product and process quality to facilitate continuous improvement efforts ‘here are three factors of this approach and are as ollows : .. Quality planning at all levels Quality is a result of planned efforts taken by all involved entities. Quality planning can be done at following two levels. (i) At Organization level : Planning must be done at this level in the form of policy document based on vision, mission etc. Planning activities must identity current and future customers, and their needs. This must be quantified so that actions can be planned and progress can be measured Measurements will highlight level of quality. (il) At Unit level : Planning must be done by people Quality plans must be inline with policies and strategies and must ensured for consistency 2. Quality control Tt examines current product/process across various levels of standard. Process is made defect-free to improve its capability and quality. In case of deviation in process, it is measured against quality plan and actions are taken to minimize it. 3. Quality improvement It is used for continuous improvement of process quality. The quality attributes of a process are measured and improvement areas are identified. 1.14 Quality Management through - _ Cultural Changes through cultural changes These cultural improvement Philip Crosby: Quatity approach is given by changes are driven by management of 2° organizati It involves ee ~ Identifying diferent areas to improve quay doing capability measurement and Give prion, certain areas based on available resources, cost benefit analysis, pareto analysis, efforts required etc ~ Organization must setup cross functional working teams and give the awareness about customer needs, process measurements and quality. ~ Deploying teams under management directions for improving development, _ testing, processes can bring cultural changes. maintenance Set goals and targets in each department or unit of organization can helps to improve quality and quality process at all level. Customer satisfaction levels and competition are the main sources for deciding goals and targets. = Giving recognition to the teams will increase morale and establishes positive and competitive environment in the organization. = Repeating quality improvement cycles continuously by giving next level goals and targets to maintain improvement status 1.15 Continual Improvement Cycle or PDCA Cycl = There are many methods for quality improvement, These cover product process improvement and people based improvement. improvement, = PDCA Cycle is an iterative four-step management method used in business to focus on continuous improvement of processes. The POCA cycle consists of four steps namely Plan, Do, Check, and Act. It is cone of the key concepts of quality and itis also called the Deming circle/cycle/wheel. Plan. When to Use the PDCA Process check-nct model is 3 helpful tool 3" umber of applications ‘ tions in 8 = The Plan-Do-" can be used for 2 9 = exploring and testing multiple sol! small, controlled trialAvoiding waste by Y catching and ineffective sol A adapting ns before rolling them out on a large scale © Implementing change and continuous improvement * Wilermerting Total Queity Managarnare o: sip Sigma initiatives ° Developing or improving a process Advantages of PDCA ~ Versatile :It supports a variety of business environments and for a number of applications Potential use cases include project management, change management, product development, and resource management. ~ Simple and powerful : The POCA model is simple and easy to understand, yet it is a powerful driver for Meaningful change and improvement minimizing waste and increasing efficiency. while Disadvantages of PDCA - Hard to do : Though the model is simple, the work POCA improvements into smaller steps, it can be slow and isn't easy. Because breaks process probably isn’t a great solution for urgent projects. = Requires commitment :PDCA is not a one-time event. It is an ongoing, continuous process and therefore requires commitment and buy-in from the top down. Without committed leadership, the PDCA cycle can’t work effectively for the long term. Issues in PDCA — PDCA have some issues Introduction to Software Testing © People are not included in the POCA cycle, but People are the one that to improvement process ~ Do-Check-Act (POCA) activities forms a cycle of quality improvement in TQM approach. POCA model as follows Fig. 1.15.1: PDCA Cycle 1. Plan : Improvements must be planned using vision and mission of an organization. Synchronize both quality plans ie. organization level and unit level with each other. Define expected outcomes in quantifiable terms and plan actions for deviations. Use baseline studies to understand current progress 2. Do : Execution of set plan is important to achieve decided outcomes. It needs resources like training, hardware, software etc. 3. Check : Actual outcomes must be checked against planned one. It should be in measurable terms for easy analysis. This decides the direction of progress. 4. Act outcomes will give degree of variation. The observed Comparison between planned and actual variations are corrected by taking actions (change in plan). 1.16 Benchmarking and Metrics Benchmarking = It is an useful concept of QFO (Quality Function Deployment) and defines measurable variables i J © POCA oversimplifies what is really neede’ (scales) athe = It is used to create qualitative and quantitative © Do and Act phases have the same meaning in rmetries that measures product quality agent various English scales of a benchmark. POCA was meant to be applied for small scale | oie. of benchmarking variables are - cost, time, ° improvements, not for large transformational defect count, satisfaction level, functionalities etc. changes =yftware Testing and Quality Assurance (SPPU) Metrics t is defined as to collects information about process variations, product capabilities, product attributes etc. Metrics are defined from planning document, benchmarks etc. it represents relative measurement of product parameters and processes used to produce it. For development of organization must develop consistent set of matrices and maintain good performance benchmark. 7 Problem Solving Techniques Problems associated with development and improvement of processes are handled with metrics based methods and techniques. Problem solving is done by both quantitative and qual method. In qualitative problem solving method, problem solutions are understood using quality index such as ow, medium high. This indicates improvement or deterioration in the parameter. It is suitable for low maturity organization where problem size is broad and is divided into number of stages. Problem solving can be achieved by qualitative problem solving and quantitative problem solving. 1alitative Problem Solving It refers to understanding problem solution using only qualitative parameters such as low, medium and high. improving from present status and so forth. It continuously monitoring something is This is typical scenario for low maturity organization, where problems are much borderline and can be classified in different bans very easily. It saves time in defining and measuring data accurately and through this basic maturity can be achieved, __ Quantita Problem Sol In quantitative problem solving methods requires exact measurement in numerical value of parameter is used. It is used in high maturity organization where improvements are done on repetitive basis. It follows DMMCI cycle and measurements are required to be very accurate. Process is well understood by applying statistical technique on quantitative data, This data enables easy visualization and analysis of a process. Variations in a process can be identified easily and actions may be initiated to reduce it. Software Testing Technique 1.18 Problem Solving Software Tools _ Techniques are used to indicate process used in measurement, analysis, decision making during problem solving Techniques are independent of tools but they are used to drive tool usage. Software testing Techniques are used to design better test cases. Since exhaustive testing is not possible through software testing techniques, it is possible through testing tools. Testing techniques mostly used for manual testing, whereas testing tools are used for automation testing Testing Techniques help reduce the number of test cases to be executed while increasing test coverage. They help identify test conditions that are otherwise difficult to recognize. Important software testing techniques are Boundary Value Analysis (BVA), Equivalence Class Partitioning, Decision Table based testing, State Transition, Error Guessing, etc. ‘Organizations need to invest reasonably large amount to buy analytical tools, data management software's ete. Waa# Software Testing and Quality Assurance (SPPU) Tools are helpful in understan suggests solution based on data inputs. 9 the problem and Tools can be hardware, software, physical or logical in nature. Quality tools are used by projects teams to solve problems faced by them Techniques is concemed with process used for measurement, analysis, and decision making. Techniques are independent of tools but supports use of tool, \dvantages of using Software tools Accuracy and speed of the tools are much higher compared to manual calculations and transactions. Decision supports offered by tool is independent to personal skills and there is very less variation from instant to instant. - Tools can implement theoretically accessing matrices about quality as defined by business law. isadvantages of using Software tools It requires training to users so it incurs cost and time All software and hardware prone to bugs, so these tools are not exception to it, Humans take decisions not by tools. - Experience and expert testers are required software Testing Tools - Tools are assets of the organization. It is used to understand problems through data and find possible solution - Automation Testing is the process to reduce manual testing work by using of tools and strategies that reduce human involvement or interaction in unskilled, repetitive or redundant tasks. - Test automation uses of special software (separate from the software being tested) to control the ‘execution of tests and the comparison of actual ‘outcomes with predicted outcomes. Test automation can automate some repetitive but essary tasks in a formalized testing process 1:19 Introduction to Sofware Testi already in place, or perform additional testing that would be difficult to do manually. ~The testing tools reduce manual testing to a large extent and the testing can be done automatically, Using these tools has many advantages — Once the software is ready for testing, the functionality of the software can be tested repeatedly to improve the quality and reliability — Testing can be done unattended, for example, during night time and during holidays. = When the software has to be tested in different environments (different hardware platforms, different operating systems, using different browsers etc), the labor invoived can be reduced. ~ Performance testing can be done without the need for many computers and many test engineers. The test tools simulate multiple users on a single machine. testing, response times when multiple users ‘As compared to manual finding out transaction access the same application will be very easy. Testing process can be planned and managed effectively using these tools, = Test reports can be generated automatically for later analysis and corrective action. = Testing can be done using tools that are available to test not only generic applications such as database applications and web sites, but also for DLs, Visual Basic Programs, Siebel software, Power Builder software, databases, stand-alone Java applications ete ~The testing process can be managed efficiently-the planning can be done systematically, the tests can be scheduled efficiently, and the bug tracking can be done effectively. Hence, using automated test tools results in: © Improvement in the quality and reliability of the software. © Drastic reduction in time, effort, and money ent on testing. sp ma© Asystematic approach to the testing process. © Efficient management of the testing process even if the teams are at different geographical locations. Advantages of using Tools 1. Tools are highly accurate and fast to make calculations and transactions. Calculations acts as input for decision making thus need to be accurate. 2. Decisions are with negligible variations. Some tools can be used on fixed range made by tools whereas some can learn the things and then used. 3. Tools reduces manual work and delivers results faster and accurate. 4. It can be integrated with other systems for complex problem solving Disadvantages of using Tools 1. Tools need to learned by sparing significant amount time. Some needs training that incurs time as well as cost 2. Software and hardware can suffer from defects which may affect decision in future. 3. Tools only suggest solutions but humans make decisions. Some tools can take decisions to a limited range only. 1.18.1 Differentiate between Software Testing Tools and Techniques Cerna Q. Differentiate between software testing tools and techniques, f | sr. | Software Testing | Software Testing Tools No. | Techniques 11. | Techniques Usage of tool depends | independent to any | on technique. tool. | S = 2 Same technique use | Different techniques may | different tools to | use_same tool to _acive Software Testing Tools | sr. |. Software Testing No. Techniques achieve same result. | different results. 3, | Software testing | Software testing tool are used to test software product exhaustively, | Techniques are used to design better test cases 4, | It is used for manual | It is used for automatior testing testing 5, | Software testing | Testing tools exhaustive exhaustive testing is | not possible testing possible. 6, | Itis time consuming, | It is executed by taking up human | software tools, so it is resources significantly faster than a testing _ techniques | approach 7. | Investment is | Investment is required | required for human | for testing tools. | resources ee ee 1.19 Software Quality - Quality of a software is defined as conformance to the specifications. All functional and non-functional requirements are documented. Some requirements are not stated by customer but are necessary for building product, so such requirements are assumed by developer. ~ Generally this document is approved by customer and then by developers ~ Quality of deliverables is totally depend on documented and approved software specification document, requirement Again, constraints on this document there are many i eeee a 19.1 Software Quality Attributes oo University Questions] ). Identify software quality attributes for the following scenarios. i. People visiting popular websites such as You tube, Amazon, Google ete ji. Antivirus updater showing progress bar of scanning. ili, Software using adapters to connect to SMS gateway of different service providers, Identify software quality attributes for the following scenarios. i. Internet banking system ii. Game for Children with various input devices such as, mouse, joystick, touch screen etc. iii, A new social networking site for a Software company which will add more features in coming future. Identity the software quality attributes for the following. i. Now a days most of peoples are using internet banking for online transactions. What could be the top 2 architectural drivers (Quality Attributes) for this system? Justify your answer. {Company want build a game for the children’s which they shouid play from any device mouse, joystick, touch screen etc) may also integrated for playing the a game. li, A. software company is in a process of building 2 social networking site which will have very large number of users in near future. Also company with to add new features in this site and during addition of new features in this site should provide all the current features without any disturbance. What top 2 quality attributes is being addressed by this tactic. Justity your answer. aS Software quality is the characteristic O° jefines how well the software meets the customer ments, coding standards gories | that de requirements, business require! etc It can be divided into two cate: characteristics that junctional \d-users, Software Functional Quality © define how well the software meets fi and how well it satisfies the ent Software Non-Functional Quality : characteristics irements are met requirements, that define how well structural req that support the delivery of functional requirements. ually related to software code and internal It is us structure. _ the different software qualities can be measured isting techniques and through various software te attributes different tools. Following are the sure the software (parameters) that are used to mea: quality : © Testability : How easy it is to test the software and to what extent it can be tested ry: It defines how user friendly the o Usabil software is. Example: People visiting popular websites such as You tube, Amazon. Google etc. or Internet banking system © Understandability : How easily the software can be made understood to a layman about its functions/purpose © Consistency : How far the software is consistent 7 uniform in terms of GUL terminologies, conventions. © Efficiency: It defines the amount of work that the software can do in defined timeframe with minimum resources used. Example: Antivirus updater showing progress bar of scanning. © Effectiveness : The extent to which the software satisfies the user and meets user requirements. © Accuracy : How accurately the software works with gives the correct results. © Maintainability : How easily the software ca. pace ns carne of paee cefeatures/bug fixes. Example : A new soci networking site for a Software company which will add more features in coming future Reliability ; How reliable the software is in Performing required functions under different Scenarios/conditions, Ex: Internet banking system, Portability: How easily the software can be transported and run in different environments £9: platforms like operating systems. (Linux, it can run on Example: Software using adapters to connect to SMS gateway of different service providers or Game for Children with various inpu such as, Mac, Windows), machines it devices Mouse, joystick, touch screen ete Security : How secured the software is in terms Of access authorization and personal data like Passwords. Ex: Intemet banking system © Robustness : How robust the software is under Unexpected events like software crash, power- Off etc. and saves its data, 20 Constraints of Software Product Qua! ity Assessment SER Quality Assessment Business analyst or system analyst are responsible for Sreating product requirement specification. Tester may or may not have direct access to the customer. Tester gets information from requirement documents and queries answered by customer or business system analyst Testing personal cannot have direct connect with Sustomer and get to know information through Fequirement document, feedbacks, queries etc Such scenarios are creating some constraints while 8Sessing product quality. Umitations of product quality assessment are as follows : As compared to other engineered product, a software is not produced in a physical form, Introduction to Software Tes 19 Thus hui NSes like touchin, Seeing and measuring instruments are of limited capability, 9, hearing, There is huge communication gap between customers and development or testing team, Software Is considered as unique Product, but there exist similarities among Many products. Properties ike, Tequirements, design, testing, reusability may architecture, coding, highlight significant differences, Software cannot be tested fully. Exhaustive testing is concerned with cost 1.21 Quality and Productivity Relationship What are the types of rac Also point out relations! productivit quirements and’ product? hip between quality and Many organizations or peo testing, inspection, product, Proved by improving quality In production and testing process This will automatically ly reduces inspection, testing, wastages etc and imy Proves productivity and in turn customer satisfaction Most of the times, customers are complaining about Problems related to product and services offered by an organization, These problems are the outcome of faulty processes used during development that gives tise to number of defects, Improved quality can reduce cost cost of quality, margins, of development, selling price thus increases. profit- and Quality Assurance Empk occa SPP) 1-23 : a tro ployee is treated as an important entity during the : Introduction to Software Testing 0 hi Phase of quality improvement and performance morovement. ~ Employees can detect and correct deviations in development process. This is because they are closely working with processes. ~ Contribution of both, management and employee forms. strong basis for organization improvement. Lack of either will result in customer dissatisfaction, less profit, loss of trust, = Less or excessive amount of communication is considered to be a major problem in the businesses Miscommunication leads to wrong interpretation which in turn can leads to user’s gap and producer's gap. = With management guidance and support, employees are working and converts organization into performing teams. = With daily contribution, a new, improved working process can be innovated. Instead of waiting for inventions for better product, processes can be improved to achieve long term goals k will help the employees to identity = Smart wod in development process thus can be deviations eliminated easily — Research and Development department are carrying in many organizations. — tis directed to develop new technologies and approach of develoament out inventions techniques in the process and testing. _ ix sigma approach suggests refinement redesign in the existing processes 1.22 Req! rements of Product. tionship between quell a. Point out relat roductivily uct offered to cust comer must satisty all Nis Every pro ents and needs require _ hiewe this, all the phases of SDLC are driven according to requirements and needs Due to fierce coms petition in the business world, Product requirements are difficult to categorize. : In such cases, organizations ate focusing on the ‘customers and decides priorities of requirements Following are the different requirements. categories of Requirements of Product 1. Steg and imped Requirements ng Specie Requirements | 3. Present and Fuure Reguremen's ] Fig, 1.22.1 ; Requirements of Product 1. Stated and Implied Requirements = Stated requirements are documented in SRS (Software Requirement Specification) document and ther are implied one. = Business analysts and customer functional and non-functional requirements ia. the SRS document. specifies the Development and testing teams must be able (© understand stated requirements. There are certain requirements which may not be documented but are considered in product. €¢ Readable font size, nO spelling mistakes etc. —pusiness analysts are supposed to convert implies requirements in stated one. 1d Specific Requirements ome requirements are generic 19 nates which are accepted for particular product and group ef users it in nature and ut some of requirements 3° specific 2. General ant are used for specific products only. = General requirements 3° accepted 7 i ae product and gtuP of cap a requirements are ve specific development1d Quality Assurance (SPU) General requirements are considered as implied one and specific requirements are considered as stated. General requirements can be, Multiplication should be correct, Easy to use Interface etc. — Specific requirements can be, Six digit precision in float followed by notification etc. calculations, Authentication 3. Present and Future Requirements, - Present requirements are considered for an application use in current circumstances. Future requirements are considered after some time span - Both requirements are need to be finalized by customer and business analysts. Development team need to identify future needs of customer by doing research - For example, current requirement of a banking software is of 1000 online accounts, but within three years it can grow to 10000. Requirement Categories Based on Priority The requirement categories based on priority of their mplementation from user's perspective. [Requirement categories [based on priority Introduction to Software Testing 2. Secondary Requirements — It includes "Should be* and "Should not be" type of requirements, It adds some value to the product and are appreciated by customers ~ Customer may pay little extra for having these type of Fequirements in product. Its presence may delight Customer and its absence may disappoint little, ~ Itis denoted by P2 priority and covers "Should not be” requirements also, 3. Tertiary Requirements ~ It includes "Could be” and “Could not be” type of requirements. It is not adding much value in terms of price paid by customer. = If two products are same then “could be requirements can give competitive advantage and receives customer appreciation ~ It helps to provide identity to a product and are denoted by P3 priority. It is requirements and also covers requirements. lowest "Could priority not be” 1.23 Software Development Process or Software Development Lifecycle Models 1. Primary Requirements —— 2. Secondary Requirements 3, Tertiary Requirements Fig. 1.22.2 : Requirement Categories Based on Priority Primary Requirements - It includes “Must” and “Must not’ type of requirements for which customer is paying, These are essential requirements and are denoted by Pl indicating high priority. - Value of a product depends on accomplishment of these requirements or else product will be rejected due to dissatisfaction ~ It covers “Must not” requirements also, that are not present in product. It is also referred as SDLC that defines how the software is being developed. following are the development approaches, 1.23.1 Waterfall Model —_Itis termed as classical view of software development and forms foundation for any development activity. It is one of the simplest model but not feasible to work every time, ~ Different variants are available such as, modified waterfall model, iterative waterfall model etc. Many other development models are basically depend upon waterfall model, ~ Customer requirements are converted into low level and high level design. Code is implemented for the design and tested as per test plan. rca rareWF software Testing and Quality Assurance (SPPU) 1 — Tested code deployed at customer site and it is maintained in last phase. This mode! provides short route for development activities and is highly efficient and productive in nature, = There are some limitations of waterfall model. It is more useful when projects are having fixed schedule and price. = This model is not having any provision for feedback improvements) because it assumes that requirements are stable and no error will occur during entire SDLC. = This model does not involve any kind of rework. Customer Requirements Design Coding Testing Deployment Maintenance Fig, 1.23.1 : Waterfall Model Advantages of the Waterfall Model 1. Simple and easy to understand and use 2. Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process. 3, Phases are processed and completed one at a time, 4, Works well for smaller projects where requirements are very well understood. 5, Clearly defined stages. 6. Well understood milestones. 7. Easy to arrange tasks. 8, Process and results are well documented, Disadvantages of the Waterfall Model 1. No working software is produced until late during the life cycle. Introduction to Software Testing 2. High amounts of risk and uncertainty. 3, Not a good model for complex and object-oriented projects. 4. Poor model for long and ongoing projects. 5, Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model. 6. tis difficult to measure progress within stages. 7. Cannot accommodate changing requirements. 8. Adjusting scope during the life cycle can end a project. 9. Integration is done as a "big-bang, at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early. 1.23.2 Iterative model — Unlike waterfall model, this model does not assume that customer will provide requirements in one go and those will be stable one. — Changes are assumed in any phase of SDLC. This is accommodated by introducing feedback loop that makes it different from waterfall model = There are some limitations of iterative model. It consists of many number of cycles of waterfall model. It is not fit for projects having fixed price and schedule. = Due to many iterations, product design and architecture becomes more fragile. Customer Requirements oesion coting Testing (or Maintenance Fig. 1.23.2: Iterative Model1.23.3 Incremental Model - It is generally used to develop large systems consists of many subsystems as their component. These subsystems can be developed using waterfall or iterative model. - Later, these developed subsystems can be connected directly or indirectly (using _ interconnection application). - Incremental model develops a system and customer starts using it. Meanwhile second system is developed and integrated with the first one and so on. This model does not require requirement at the start. - There are some limitations of incremental model Direct connectivity could lose the flexibility of application - System integration can be a big challenge in this approach. Complex integration of subsystems may cost change in system architecture and the loss of flexibility, Sibaysiom | Subeysert Subeystom 1 2 3 ‘Subsystem Soraticl ‘Subsysi ubaystom. | __¥ communication | Subsystem system ‘Subsystem | ‘Subsystem. ‘Subsystem 3 : 3 Fig. 1.23.3 : Incremental Model - Increment requires regression testing to verify correctness of integration, Advantages of the Iterative and Incremental SDLC Model are as follows : \. Some working functionality can be developed quickly and early in the life cycle. > Results are obtained early and periodically, Parallel development can be planned. +. Progress can be measured. Less costly to change the scope/requirements » Testing and debugging during smaller iteration is easy. 7. Risks are identified and resolved during iteratio’ each iteration is an easily managed milestone 8. Easier to manage risk - High risk part is done firs operational produ 9. With every increment, delivered, 10, Issues, challenges and risks identified from increment can be utilized/applied to the increment. LL. Risk analysis is better. 12. It supports changing requirements. 13, Initial Operating time is less. 14, Better suited for large and mission-critical projec 15. During the life cycle, software is produced early facilitates customer evaluation and feedback. Disadvantages of the Iterative and Incremental SDLC Model are as follows : 1. More resources may be required 2. Although cast of change is lesser, but it is not suitable for changing requirements. 3. More management attention is required. 4, System architecture or design issues may because not all requirements are gathered in beginning of the entire life cycle. 5. Defining increments may require definition of complete system 6. Not suitable for smaller projects. 7. Management complexity is more. 8. End of project may not be known which is a risk 9. Highly skilled resources are required for risk analysi 10. Projects progress is highly dependent upon the r analysis phase. 1.23.4 Spiral Model - In this approach, received multiple iterations and according to it th development is carried out. Systems wit incrementing size are built using spiral model e.g. ER softwares, requirements are Gp tedinewiedyeee o. Sanking system etc. initiiy some tunctionaiity is | 6. May be hard to define objective, verifiable mileston 7 , verifiable milestones, 7. Spiral may continue indefinitely. After using it, customer adds few more requirements into it. In this way software is developed in a spiral way. There are some limitations of spiral model. It needs refactoring and change in approach when initial system is non-usable. It also requires multiple regression testing cycles after addition of new functionality. 1.23.5 Prototyping Model This model contains top-bottom reverse integration approach, Many times customers requirements are not clearly understood then prototyping approach can be used there, At the start a prototype of system is created and ven to customer, Module 5 |}-—_——+» 7 = This will help them to understand their expected product. It is helpful for development team as they Module 4 Module 1>+-—+| Module 2 can understand system look and feel. Lege od Upon finalizing the requirements system is built and product is delivered. There are some limitations of Module 3 i prototyping model, Model of a system is created not the actual product. Fig. 1.23.4 I Model Advantages of Spiral Model = Due to this customer may pressurize development team to deliver it immediately 1. High amount of risk analysis hence, avoidance cf Risk | advantages of Prototype Model is enhanced. 1. Users are actively involved in the development 2. Good for large and mission-critical projects. 2. Since in this methodology @ working model of the 3. Strong approval and documentation control syster proved, ‘the: ise -get' a. belt 4. Additional Functionality can be added at a later date understanding of the system being developed. 5, Software is produced early in the software life cycle. | 3, Errors can be detected much earlier. 6. Project estimates in terms of schedule, cost etc | 4, Quicker user feedback is available leading to better become more and more realistic as the project moves | solutions it leted. ‘dened forward and loops in spiral get complet 5, Missing functionality can be identified easily 7. Itis suitabie for high risk projects, where business needs may be unstable. A highly customized product can be developed using this. Disadvantages of Spiral Model Can be a costly model to use. Risk analysis requires highly specific expertise. 3. Project's success is highly dependent on the risk analysis phase. 4 Doesn't work well for smaller projects. 5 not suitable for low risk projects. 6 Confusing or difficult functions can be identified Requirements validation, Quick implementation of, incomplete, but functional, application. Disadvantages of Prototype Model 1. Leads to implementing and then repairing way of building systems. 2. practical, this methodology may increase the complexity of the system as scope of the system may ‘expand beyond original plansoftware Testing and Quality Assurance (sPPu) 6 Introduction to Software Test ting complete application may cause application not to ~The importance is given to deliver a working product through customer collaboration, requirements from SRS document. °e used a5 the full system was designed Incomplete °F inadequate problem analysis, instead of fulfiling 3.6 Rapid Application Development (RAD) | ~ It gives complete freedom to Customer to add their Model requirements at any phase of SDLC and developers , must ac It develops usable software at a fast speed where user eae Still understands development and application under | ~ Ad!® development consists of methodologies like, process. It works similar to spiral model foes ee programming, test driven Developers starts with very development etc. less number of Fequirements and creates design, code it, test it and | Advantages of Agile model delivered to customer. 1. Customer satisfaction by rapid, continuous delivery of Once software is delivered, customer can understand useful software, his expectations and development in a more clearer 2. People and interactions are emphasized rather than way. He can add more or refine requirement y earlier requirements. Process and tools. Customers, developers and testers In each iteration this is followed by development. constantly interact with each other. Major constraints in rapid application development 3. Working software is delivered frequently (weeks model are change in approach and refactoring. rather than months). Each iteration requires multiple regression testing cycles. | 4 face-to-face conversation is the best form of dvantages of the RAD model communication Reduced development time. 5. Close, daily cooperation between business people and developers Increases reusability of components 6 Continuous attention to technical excellence and good design. Quick initial reviews occur feedback ecient 7. Regular adaptation to changing circumstances. Integration from very beginning solves a lot 8. Even late changes in requirements are welcomed of tegration issues. yisadvantages of RAD model Disadvantages of Agile model is: In case of some software deliverables, especially the large ones, itis difficult to assess the effort required at the beginning of the software development life cycle. Depends on strong team and individual performances | 1 for identifying business requirements. it stem that can be modularized can be bul oe nD 2. There is lack of emphasis on necessary designing and usin : documentation. highly skilled developers/designers. aes 3. The project can easily get taken off track if the I oer eee customer representative is not clear what final 5. Inapplicable to cheaper projects as cost of modeling outcome that they want and automated code generation is very high 4, Only senior programmers are capable of taking the ent 122.7. Agile Developmen Move! kind of decisions required during the develop process. Hence it has no place for newbie The model is dynamic in nature and has adaptability ‘ed with experienced programmers, unless combin oduct to user environment and continuous pr eect tegration. _ Freee1.23.8 Maintenance Development Model Maintenance of a software is one of the major costly phase. Defects in a system can create long term problems. ~ New technologies are introduced that offer better performance, services, other option in a cost effective way. ~ Many times new functionalities are added as a part of business need Following are the four mait maintenance activities. categories of software () Bug fixing : Bugs or defects are fixed by doing proper analysis of it. Sometimes fixing old bugs may introduce new one in the system, i) Enhancement : New functionalities are added as per customer requirements or business need. Porting : Software functionalities are ported from older technology platform to newer one. Features of older platform are expected to be present in new platform, (iv) Re-engineering : Due to change in business environment there is need to change logical parts and algorithms used in development. 1.23.9 Impact of Defect in Different Phases of Software Development CaS a. What is the impact of defect in’ditferent phases of software development? — The cost of defects can be measured by the impact of the defects and when we find them in different phases. Earlier the defect is found lesser is the cost of defect. For example is found in the requirement phase during requirements gathering if error and analysis, then it’s impact is low and cost is somewhat cheap to fix it. The correction to the requirement specification can be done and then it can be re-issued. ie LIS s found in the = In the same way when defect or error is fo view then impact is low, design phase during design re ’ it can be re-issued the design can be corrected, and Its cost is relatively little expense ~The same applies for coding phase. If however, @ defect is introduced in the requirement phase and design phase and if itis not detected until the system has been implemented then its impact is more and cost to fix it is much more expensive to fix. This is because rework will be needed in the requirement phase specifications and design before changes can be made in coding; because one defect in the requirements may well propagate into several places in the design and code; and because all the testing phase work done-to that point will need to be repeated in order to reach the confidence level in the software that we require ~ It is quite often the case that defects detected at a very late stage, depending on how serious they are, are not corrected because the cost of doing so is too expensive. But if the error is not caught in the til acceptance then the cost to fix those errors or defects will be way too expensive, specifications and is not found till the user 1.24 Types of Software Product See Software products can be categorized based on their criticality Le. their importance to customer. Following are the four main categories. Types of Software Product 1. Products affecting life ——===== 2, Products affecting investment 3, Simulation based products 4, Other products Fig. 1.24.1 : Types of Software Product a1. Products affecting life Products from this category are the most critical product since they can directly or indirectly affect the human life, These products are having regulatory and safety requirements. It takes normal customer requirement, precise quality requirement and undergoes critical testing process since failure can lead to death or disability. , Such products are again having five subcategories which are as follows : (i) Most critical product, where failure resulting into death of a person. (ii) Second level critical product, where failure resulting into permanent disability. (iii) Product failure resulting into temporary disability (iv) Product failure resulting into rinor injury. () Allother products that do not affect health. 2, Products affecting Investment = Products from this category are ranked second in the list criticality, They can have effect over investment made, ~ It takes many regulatory and statutory requirements along with large testing efforts (but less than the first, category products). e.g, e-commerce softwares, = Quality factors for such products are security, accuracy, confidentiality etc. 3. Simulation based products Products from this category are difficult to test in real world hence are tested with simulators. ~ These products ranked third in the list of criticality, ©, products from space research, aeronautics etc. They need large amount of testing but less than above two categories 4. Other products All products other than above three are put in this category. 1.25 Problematic Areas of SDLC Problematic areas of SDLC 1. Problems with requirement phase 2, Unique product development 3. Difference in development approach 4, Impossible exhaustive testing '5, Unaware about bad quality 6. Quailly definition 7. Quality objectives Fig. 1.25.1 : Problematic Areas of SDLC 1. Problems with requirement phase Requirement collection is an important phase in SDLC and having highest probability of introducing defects in the system. Following are some of the problems. @ Communication It is considered as major problem in forming requirement statement. Many times requirements are not communicated in an easy way. (@) Technical requirements are about platform, language, database, OS etc. It also consist configuration of various technical entities. Generally development team deals with these requirements, (b) Economics of software is based on its technical and system requirements. Generally development team and customer are dealing with this type of requirement. Customer must understand different approaches and select one out of it. Development ‘organization must help customer in choosing right approach by sharing its experience. (Q) Software product may be associated with different statutory and regulatory requirements. There may be some rules and regulations applicable to product and those must be understood by development team.Operabonat requirements are combination different functional and non-functional requirements, These are defined by user/customer based on their | Dusiness needs. It defines what the software must do ty requremen al secunty are combination of physical requirements. Oevelopment team are working with these It consists Customer and requirements for backup, restoration. configuration, access control hardware ete. Customer may specify requirements for privileges encryption password protection ete Changing nature — Dynamic nature of requirements resulting many complaints from development teams. ~ Changing requirements may confuse the developers. Aker showing buitt product to customer, many new ideas are suggested and some of them directly have effect on cost time, and efforts — Sometimes changes suggested may have effect on Sesign, architecture, and methodology also. The time gap between requirement submission and product Gelivery plays very essential role. ~ Approaches like rapid application development. top- own, joint application development can be used to accommodate changing requirements. Unique product development ~ 1h sofware field no two application are same. Implementation for same problem, done by two Gitferent developers differ from each other, ~ Even same solution developed by same developer at ‘two different instances may not be similar. Software Produced in such instances may be considered unique. During maintenance, designers facing difficulties in understanding original design whereas developers faces difficulties in reading the code. Difference in development approach The approach of developing a softwa re vary from organization to organization, | Different implementation is possible for requirement set and Iti depending on capabilities of developer The best suitable approach in selecter! after observing circumstances, 4. Impossible exhaustive testing Inspection and testing activity is aimed at finding flaws from products and development proc ~ Testing of all possible areas in product is practically impossible, High cost and time will be required to test all permutations and combinations, 5, Unaware about bad quality As said earlier, testing of all algorithms, conditions ete. is impractical, = Such ar S remain untested and software is delivered to customer, which then used for longer time, ~ Any problem in such areas will get discovered when particular situation occur, 6 Quality definition ~ Product quality depends on processes used for its development rather than rigorous inspection/testing activities applied on Finding and fixing defect will not improve quality of product and also will not guarantee defect free delivery. — Good processes and procedures can only mal good quality software. 7. Quality objectives — There is a variation observed in quality objectives of different products. = Itdepends on type of product, customer using it time and circumstances. Quality objectives represents user tion level. expectations and their satist — They are defined on the basis of factors of quality ie, ‘must be’, ‘should be’ and ‘could be’ for the applications.© software Testing and Quality ASSUI@0EE Io a ) Continuity Quality Factors Following are some of the quality factors. () Gorectness Availability of essential procedures, methods, and backup information for recovering data, system and ‘operations. 1.26 Software Quality Management (ip Usabitty (i Maintainebity (w) Ponabilly| (0) Coupling (w) Periomance » (vil) Reliability Fx) Conway Fig. 1.25. ality Factors i) Correctness Defines the accuracy of outcomes il) Usability Efforts needed to learn, operate, prepare input, and understand output. ili) Maintainability Efforts required to find and fix the defects. iv) Portability Efforts required to transfer software from one hardware/software configuration to another. v) Coupling Efforts required to integrate system components. vi) Performance Amount of resources needed to perform required functionalities. vii) Refiability System remain functional over the longer time period. viii) Access control Protection of system resources destruction, modification ete. from misuse, Quality management consists of set of planned and systematic (for development and maintenance) used to manage quality of product and activities services. — It involves management of all input to the system processes in order to generate output matching to quality criteria — Software quality management is a management process used to develop and manage the quality of software in such a way so as the best ensure the software product meets the quality standards expected by the customer while also meeting any necessary regulatory and developer requirements. ~ However, software quality significantly differs from the concept of quality generally used in manufacturing mainly for the following reasons : © The software specification should reflect the characteristics of the product that the customer wants. However, the development organization may also have requirements such as maintainability that are not included in the specification © Certain software quality attributes such as maintainability, usability, reliability cannot be exactly specified and measured. © At the early stages of software process it is very difficult to define a complete software specification. Therefore, although software may conform to its specification, users don’t meet their quality expectations. Activities of Software Quality Management ~ Quality Assurance - QA aims at developing Organizational procedures and standards for quality at Organizational level,Quality Planning - Select applicable procedures and standards for a particular project and modify as required to develop 4 quality plan, Quality Control - Ensure that best practices and standards are followed by the software development team to produce quality products ~ Quality management activities ensures that the software products and processes matches to defined standards, customer requirements etc. It presents three levels of handling problems which are as follows. Correction - It is considered as quality contro! approach. Defects are found in the system and are quickly fixed - Defect finding and fixing responsibility is handled by line function. Corrective actions = It is considered as quality assurance approach. Process related problems are detected and resolved by initiating corrective actions. = Root cause analysis of defects is done and their introduction in the system is identified. = Accordingly actions are initiated to stop occurrence of similar defects in future. Responsibility of corrective actions is handled by project leads, 3. Preventive actions - After studying root causes of defects, other potentially weaker areas are identified. — These areas can suffer from defect occurrence thus preventive actions are applied to them. Actions are initiated after checking similar scenarios or past history. = Responsibility of preventive actions is handled by project manager (senior management). 1.27 Processes Related to Software Quality Organization culture forms a strong foundation for Quality, There are different tiers of quality management and are discussed in following section, Vision Every organization has its vision statement states itimate aim it wishes to achieve in some time horizon. Vision statement is a brief ides about what organization wish to achieve and is established by management. Mission Organizations defining several initiatives are termed as mission statements. Success of these will help to achieve vision of organization. Mission statements having cifferent lifespans. Policy Policy statement defines organization's way of doing business, It is generally defined by senior management and helps different stakeholders (customer, supplier, employee) to understand intent of organization. Multiple policies are possible in an organization which will help to achieve mission statements. Objectives Mission success and failure can be measured by using Quantitative means termed as objectives of organization, Every mission statement must Objective. It is defined in with duration for act have at least one quantifiable terms al ing it. -