aa 12 13 14 14a 1.10 1.101 1.10.2 1.103 1.10.3(A) 1.10.3(B) 1.10.3(0) 1d Quality Assurance (SPPU) Introduction to Quality. Historical Perspective of Quality... Quality Definition. 1-3 Core Components of Quality. Difference between Continual Improvement women 1-4 and Continuous Improvement Customers, Suppliers and Processes. Objectives of Testing Testing and Debugging. Testing Debugging. Difference between Testing and Debugging1-6 Need of Testing. 1-7 Quality Assurance and Testing. -8 Why Software has Bugs, Errors, Defects and Failures Reasons for Software Bugs. More reasons for Software Bugs Inter-relation between Error, Failure. Cause of Errors, Defects and Failures in Software., Effect of Errors, Defects and FallreS.su1-14 Total Quality Management (TQM). Quality Practices of TOM Quality Management through - Statistical Process Control. 1-15 Quality Management through - Cultural Changes, 145 1.16 47 1.18 1.18.1 1.19 1.19.4 1.20 1.21 1.22 1.23 1.23.4 1.23.2 1.23.3 1.23.4 1.23.5 1.23.6 1.23.7 1.23.8 1.23.9 1.24 1.25 1.26 1.27 1.28 1.29 130 Continual Improvement cy PDCA Cycle., Problem Solving Software Too Differentiate between So and Techniques. ftware Testing: Software Quality,, Software Quality Attributes, Constraints of Software Product Quality Assessment. Quality and Productivity Relationship _ — Requirements of Product.. Software Development Process or § ti Development Lifecycle Models,, Waterfall Model... Iterative Model mmm Incremental Model... Spiral Model Prototyping Model. Rapid Application Development (RAD) Model. Agile Development Model Maintenance Development Mode. Impact of Defect in Different Phases of Software Development wm ‘Types of Software Product.. Problematic Areas of SDLC... Software Quality Management wm Processes Related to Software Quality... Pillars of Quality Management System Important Aspects of Quality Management.Introduction to Software Testing Introduction : Historical perspective, Definition, suppliers and process, Objective of Testing, Testing Why Software has Error, Core Components, Quality View, Financial Aspect, Customers and Debugging. Need of Testing, Quality Assurance and Testing, Defects and! Failures and its Causes and Effect, Total Quality Management (TOM, Quality Practices of TQM, Quality Management. through ~ Statistical process Control, ‘Cultural Changes, Continual |Amprovement cycle, Quality in different areas, Benchmarking and metrics, Problem Solving Techniques, Problem! Solving Software Tools, | Software Quality : Introduction, Constraints of Software product Quality assessment, Customer is a King, Quality and Productivity Relationship, Requirements of Product, Organization Culture, Characteristics of Software, Software Development Process, Types of Product, Criticality Definitions, Cycle Model Software Quality Management, | Management System's Structure, Problematic areas of SDLC, Software Development Life| Why Software has defects, Processes related to Software Quality, Quality Pillars of Quality Management System, Important aspects of quality management. often described as the ‘fitness for purpose’ of a piece —__emation to Quality of software. ; Human lifestyle is enhanced with the use quality Products and services. Products take physical form | implementation, quality of design measures how valid | whereas services can be termed as virtual form of | the design and requirements are in creating | Product. worthwhile product. i Product (service) quality depends on two factors, one is skill of quality assessor and second, effectiveness of a process used to measure quality. Whereas quality of conformance is concerned with Software quality may be defined as conformance to explicitly stated functional and performance requirements, explicitly documented development Each and every product (service) is composed of | standards and implicit characteristics that are various quality attributes. expected of all professionally developed software. Due to iminense competition, manufacturers must | The key points in this definition focus on keeping good identity of a product (service) ne Sorte 1. Software requirements are the foundations from | uatit f Quality of product (service) depends on few ana Cae characteristics like-satisfying customer's need, cost, features, functionalities, delivery schedule etc 2. Lack of conformance to requirement is lack of quality. In the context of software engineering, software | 3. Specified standards define a set of development quality measures how well software is designed criteria. that guide (quality of design), and how well the software engineering. conforms to that design (quality of conformance), although there are several different definitions. It is the manager is software 4. If criteria are not followed lack of quality will usually result.© software Testing and Quality Assurance (SPPU) 1:2 5. A set of implicit requirements often goes unmentioned, for example ease of use, maintainability et 6. If software confirms to its explicit requirement but fails to meet implicit requirements, software quality is suspected. 1.2 _ Historical Perspective of Quality Concept of quality and quality improvement had emerged 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 maximize agricultural production. This work had conducted in Britain. Some researchers had contributed towards this and is described in below section. 1, Walter Shewhart ~ Developed a quality improvement program with planned efforts. Applied concept to product manufacturing process to reduce cost to customer without decreasing profit. Dr. Edward Deming ‘Suggested Total Quality Management (TQM) program to improve quality methods and practices. Idea is demonstrated through continual improvement in Japan. 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, 2 2. 3. 4 performance, features etc. The Japanese products manufactured itp organization and understanding of procese ts their development. Use of different tools them to monitor and understand processes, Japanese quality management program conjy of interrelated processes. This main across large number of products. With continual process improvement program, causes of defects are identified and removed 3 Quality Definition design specification ete. A quality product must specifications wi needs. It must be built as per design stated, It must also satisfy customer's expectations relate cost, delivery time, support ete. Quality of a product is determined by its in attributes and characteristics. Term quality can k defined from various perceptions as follows. General Software Quality definition SOFTWARE QUALITY is the degree of confo to explicit or implicit requirements and expectati of customer. Definition by IEEE The degree to which a system, component, or pre meets specified requirements. The degree to which a system, component, oF Pr? meets customer or user needs or expectations. Customer based definition A quality product must achieve customers sats# by meeting their needs and expectations. Manufacturing based definition A quality product must be developed 3 PH requirement and design specification. Development methods must be selected a produce required product with less or no defects‘Software Testing and Quality Assurance (SPPU) 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. 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. Core Components of Quality Core Components 1. Customer Satisfaction 72, Qualy Parameters Define Te Measure Wi Monitor iv. Control improve 3 tors for Improvement 7. Gontinua! Continuous Procass 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 a product will be determined based on level of satisfaction of a user. = It is also decided by some attributes like, cost, delivery time ete. 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 improvement (OMMCr 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. (i) Measure Quality of a product must measured in quantitative terms which can be defined as an attribute of quality. = These quantities will act as an indicator for need of quality improvement. = Lack in quality can be observed by comparing expected and delivered product. (ii) Monitor = Organizations must establish monitoring mechanism to observe performance of processes used in development, testing, and delivery:x ss Introduction tos, & software Testing and Quality Assurance (SPPU) tran Cust tion must be ensured through this Quality planning must be done to ach. tomer satisfaction mi ‘monitoring, Deficiencies in product must. be handled by improving product and process. In such cases, organizations must set corrective and preventive action plans ready. (iv) Contro Organizations must have functions like, quality control, validation, verification, and quality assurance, Product progress must be reviewed and controlled through these functions. () Improve Continuous and continual improvement approaches must be followed by organizations to achieve maximum customer satisfaction, tackle the ‘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 improvements. It must include processes, py (Plan-DO-Check-Act), and DMMECI cyce, Progress must be checked at each stage ang corrective actions must be stated, 1.4.1 _ Difference between Continual Improvement and Continuous Improvement Table 1.4.1 Continuous Improvement |- se. | No. Continuous improvement dynamic in nature, Continual improvement dynamic change in nature, is The changes are done at every stage and every time, The changes are dr before taking ney step of improvement It continuously striving for excellence given a continuous improvement. Periodic improvemer followed by stabilization process It is highly depends on peoples innovative skills towards improvement. It is less depends o People and mae depends on innovate Process. In this environment is continuously changed, In this changed i environment follove by stabilization. continual/continuous improvement approach, Customers, Suppliers and Processes rm Te Every organization is managing its overall sUP? chain. For any organization, there are supple supplying required material and customer buying © final product.WF software Testing and Quality Assurance (SPPU) — Customer Supplier Relationship is the business relation between the Istomers and the suppliers in terms of product quality, services, complaint handling, deliveries ete — Supplier and customer any be internal or external to the organization External supplier supplying input to organization and external customer receives final product from Supplier may be also customer or vice versa Customer and supplier are providing required inputs to the organization. Supplier of one organization can bbe the customer for another organization, Intemal functions and projects are termed as internal customers. It is supported and serviced by other functions or projects. During supply chain, it is necessary that each function shall understand needs in order to fulfil requirements. customers, suppliers and their This forms strong basis for TQM. If internal customers will have positive effect on are satisfied then external customers. People that are external to an organization are termed as external customers. This entity is using product and services offered by ‘organizations by paying them. By focusing on satisfaction of external customers, product quality can be improved. 6 _ Objectives of Testing Software Testing has different goals and objectives. 1e major objectives of Software testing are as follows : Finding defects which may get created by the programmer while developing the software, Gaining confidence and providing information about the level of quality. To prevent defects. To make sure that the end result meets the business and user requirements. Introduction to Software Testing To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications. Gain the confidence of the customers by providing them a quality product. Software testing helps in finalizing the software application or produet against business and user requirements. It is very important to have good test coverage in oder to test the software application completely and make it sure that it's performing well and as per the specifications. While determining the coverage the test cases should be designed well with maximum possibilities of finding the errors or bugs. The test cases should be very effective. This objective can be measured by the number of defects reported per test cases. Higher the number of the defects reported the more effective are the test cases. ‘Once the delivery is made to the end users or the customers they should be able to operate it without any complaints. In order to make this happen the tester should know as how the customers are going to use this product and accordingly they should write down the test scenarios and design the test cases. This will help a lot in fulfilling all the customer's requirements. Software testing makes sure that the testing Is being done properly and hence the system is ready for use. Good coverage means that the testing has been done to cover the various areas like functionality of the application, compatibility of the application with the OS, hardware and different types of browsers, performance testing to test the performance of the application and load testing to make sure that the system is reliable and should not crash or there should not be any blocking issues. It also determines that the application can be deployed easily to the machine and without any resistance. Hence the application is easy to install learn and use. Boo171 Testing PDetiaition + Testing ts the process of verifying and dating that a software or application is bus ‘meets the technical requirements as guided by Us design and development and meets the user | requirements effectively and efficiently with andiling all the exoeptional and boundary cases. ~ Testing means verifying correct behaviour. Testing can be done at all stages of module development: Fequirements analysis, interface design, algorithm design, implementation, and integration with other ‘modules. In the following, attention will be directed at implementation testing, Implementation testing is not Testricted to execution testing. An implementation can also be tested using correctness proofs, code tracing, and peer reviews. — Testing involves writing test cases, executing them and observing output. 1.7.2 Debugging bug in the software. It can defined as the) ‘identifying, analyzing-and removing errors. This activity begins after, the software fuils to exeeute| properly and concludes by solving the problem and successfully testing the software. It is considered to| be an extremely complex and tedious task because = Debugging is a cyclic activity involving execution testing and code correction. The testing that is done during debugging has a different aim than final module testing. demonstrate correctness, whereas testing during debugging is primarily aimed at locating errors. This difference has a significant effect on the choice of testing strategies. = Debugging means removing bugs from software that remains there after testing phase. Final module testing aims to = Testing involves writing test cases, executing them and observing output. Introduction 1 Software ty st pebuaging is nether a testing process ny 5 testing domain, in fact It 5 altogether a gig, process. Debugging must be caried Out after testing o,. that identifies symptoms of failure, tracing the, Jocating errors that caused the BUG and cong” these errors. Testing isthe process using which we find errors ng bugs. Debugging is the process Using which yy correct the bugs that we found during the testing process. 1.7.3 Difference between Testing and Debugging Table 3.7.1: Difference between Testing and Debsig oe “Testing Debugging Testing gets started with known conditions with expected results, This is manual step by step unstructured and Unreliable process to find and removes a specific bug from the system. It performed based on the testing type which we It performed based on the type of bug. need to perform unit testing, integration testing, system testing, user acceptance testing, stress, load, performance testing ete. Testing is the process which can be planned, designed and executed. picesones ated exectitet. S| eee eee Itis the process to identify the failure of implemented code. Debugging is the process which cannot be so forced. It is the process to give the absolution to code failure. Rls a display of error or | it is always treated as apparent correctness, deductive process.oftware Testing and Quality Assurance (SPPU) 17 Introduction to Software Testing _ Debugging Testing | Debugging uired for testing the sm under test. Any In with or without case can do testing Detailed design knowledge is definitely required to perform debugging. Testing process based on Debugging process based various levels of testing- on various types of bugs is esting, integration sysiam tesa, nies present in a system. testing, unit testing, ete. ting can be outsourced utside team as well Debugging cannot be outsourced to outside team. It must be done by inside development team. t of the test cases in ing can be automated, Automation inthe debugging cannot possible, ing is the process to tify the bugs in the item under test, Debugging is the process to identify the root cause of the bugs. ing is done by the Debugging is done by either programmer or developer. re is no need of design ledge in the testing Debugging can’t be done without proper design knowledge. Debugging is always manual, Debugging can't be automated, is based on different ing levels i.e. unit ing, integration ing, system testing etc ting is composed of dation and verification oftware, Debugging is based on different types of bugs. While debugging process seeks to match symptom with cause, by that it leads to the error correction, sting is initiated after code is written, Debugging commences with the execution of a test case. 1.8 _Need of Te: 9 Software Testing is Important because if there are any bugs or errors in the software, it can be identified early and can be solved before delivery of the software product. Properly tested software product ensures reliability, security and high performance which further results in time saving, cost effectiveness and customer satisfaction. Tes is important because software bugs could be expensive or even dangerous. Software bugs can save ‘money. Following are the some examples : = In April 2015, Bloomberg terminal in London crashed due to software glitch affected more than 300,000 traders on financial markets. It forced the government to postpone a 3bn pound debt sale. = Nissan cars recalled over 1 million cars from the market due to software fallure in the airbag sensory detectors, There has been reported two accident due to this software failure. — Starbucks was forced to close about 60 percent of stores in the US and Canada due to software failure in its POS system, At one point, the store served coffee for free as they were unable to process the transaction. = Some of Amazon's third-party retailers saw their product price is reduced to 1p due to a software glitch, They were left with heavy losses. ~" Vulnerability in Windows 10. This bug enables users to escape from security sandboxes through a flaw in the win32k system. ~ In 2015 fighter plane F-35 fell victim to a software ‘bug, making it unable to detect targets correctly. Tefen® software Testing and Quality Assurance (SPPUD d due to a software — China Airlines Airbus A300 crashes bug on April 26, 1994, killing 264 innocents live = In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and delivered 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 USS. bank to be credited with 920 million US dollars. 1.9 Quality Assurance and Testing Testing = 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 a 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 accurate visibility of softway t rn developed product to the Pdminseane ‘et = It reviews and audits the software activities throughout the fe set development. eo Objectives of Quality Assurance The objectives of conducting quality tsa follows - ~ To monitor the software development BS the final software developed, es a - To ensure whether the implementing the standards ar the management. Software pg roca = To notify groups and individuals abou te activities and results of these activities, 4 ~ To ensure that the issues, which are net sohed is the software are addressed by the ue management. To identify deficiencies in the product, proces ot standards, and fix them. Difference between Software Testing and Quality Assurance Software Testing is a way | Quality Assurances a of exploring the system to | of methods and acs check how it operates and | designed to ensue find the possible defects. | the developed soft corresponds to al‘ specifications. Software testing refers to | Quality asuare in activities that are | each step. of | Performed on a program | development proc after it has been written. d est Validate the product Ensure that proc in against specifications, | procedures ae! is | eeeeeeeeeentee | ; Focus on actual testing of | Focus the product ieIntroduction to Software Testing controls the quality. _| Itassure the quality Whole team is involved. ting team is involved. Why Software has Bugs, Errors, Defects and Failures Software Bug is a failure or flaw in a program that roduces undesired or incorrect results. I's an error at prevents the application from functioning as it should, ere are many reasons for the occurrence of ‘oftware Bugs. The most. common reason is human stakes in software design and coding, Ince you get to know the causes for Software jefects, then it will be easier for you to take orrective actions to minimize these defects. e software delivered to customer is not completely Jefect free in spite of taking all possible precautions, joing verification and validation activities. 1 Reasons for Software Bugs iscommunication or No Communication : The iccess of any software application depends on the munication between stakeholders, development, 1d testing teams. requirements and interpretation of requirements are the two major ctors that cause defects in software. Also, defects fe introduced in the development stage if the exact uirements are not communicated properly to the jevelopment teams. Unclear ftware Complexity : The complexity of the current foftware applications can be difficult for anyone with 1o experience in modern-day software development. 5 and Communications, oftware Testing and Quality Assurance (SPPU) 19 oftware Testing Quality Assurance Windows-type interfaces, Client-Server, Distributed Applications, Data are testing is | Quality assurance is enormous relational databases, and sheer size of duct oriented brocess oriented applications have all contributed to the exponential inds and fixes defects. | It prevents defects. growth in software/system complexity. Using object- oriented techniques can complicate, instead of corrective method. _| It is preventive method. simplifying, a project unless itis well-engineered. 3. Programming Errors : Programmers, like anyone else, can make common programming mistakes. Not all developers are domain experts. Inexperienced programmers or programmers 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 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 stil. Unrealistic schedules, though not common, the major 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 defects to be introduced, concern in TecateSoftware Testing and Quality Assurance (SPU) &. Egotistical or Overconfident People : People prefer to say things like: ‘no problem’, ‘piece of cake’, ‘I can whip that out in a few hours! — Tt should be easy to update that old code’. Instead Of : That adds a lot of complexity and we could end Lup making a lot of mistakes’. ‘We do not know if we can do that; well wing it. can't estimate how long it wil take until take a closer ‘We can't figure out what that old spaghetti id in the first place’. If there are too many Unrealistic ‘no problem's’, then it results in software bugs. 7. 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 tuming 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 i a huge leatning curve before making any code change. 8. Software Development Tools : Visual tools, class libraries, compilers, scripting tools, ete. 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. often 9. 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. 0 10. tack of Skilled Testers : Having skied tee, domain knowledge is extremely important fg, success of any projet: But BPPCInting a exaeg, le for all companies. Dong: knowledge and the testers ability to find defer. produce high-quality software, Compromise gna.) this can result in buggy software, 4.10.2. More reasons for Software Bugs 1, Not having a proper test setup (test environment testing all requirements. 2. Writing code or test cases without understanding ty requirements clearly. 3. The incorrect design leads to issues being caried oy in all phases of the Software Development Cycle 4, Releasing software patches frequently witha completing the Software Testing Life Cycle. 5. Not providing training to resources for the stil required for developing or testing the applicatee 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 like!) to introduce errors. 10. Any wrong assumption made during coding and testing stages. 1.10.3 _Inter-relation between Error, Defect, and Failure It is well said by Thomas Muller “A person can makt an error (mistake), which produces a defect (fault bug) in the code, in software or a system, of document. If the execution of the defect in cot happens, the system will fil to do what it shot# Go (or something it shouldn't), which causes 4 failure’re Testing and Quality Assurance (SPPU) errors in coding, So, the software with this Went to production. Which, in tum, caused a ral degradation and failure of the system. Detect! taut up aS [rm] 10.1 : Interrelation between Error, Defect and Failure B(A) Errors Error is 2 human mistake. An Error appears not due to the logical mistake in the code made by developer. Anyone in the team can make mistakes the different phases of software development. Br instance, BA (business analyst) may misinterpret or misunderstand requirements. The customer may provide insufficient or incorrect information. The architect may cause a flaw in software design. stakes due People on the team can also make to unclear or insufficient requirements, time pressure, lethargy, or other reasons. 1a Introduction to Software Testing = Let us observe the basic types of ertors 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 handling. fF not, it confuses. Therefore, such errors are known as error handling ‘and meaningful 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, ete. Flow control error : Errors conceming passing the control of the program in an incorrect dire where the software program behaves unexpectedly are flow control errors. Such as the presence of an infinite loop, reporting syntax error during run-time, etc. 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 work, The defect is also known as Fault Teateoaiaye¥ Software Tes Type: ting and Quality Assurance (SPPU) S Of defects L 'YPes of defects based on ‘Severity Basis: Severity, defines the degree of impact. Therefore, the Severity Of the defect reflects the degree or intensity of a Bartcular defect to adversely impact» gottrre product OF its OPeration. Based ‘0n the severity metric, a defect falls under the following categories: 2 Giitieal: Defects that are “eriticat™ require immediate attention and treatment. A eftical defect directly affects the essential fun ethenwise affect a software product ofits largesscale functionality. For instance, feature/functionality or ete, which can failure of a collapse of the entire system, Major : Defects, which are responsible for affecting ‘he main funetions of a software product ate Major Defects, Although, these defects do not result in the Complete failure of a system but may bring several Primary functions of the software to rest Minor : These defects produce less impact and have Re Significant influence on a software product. The Fesults of these defects are visi the operation of the product. However, it does not prevent users from executing the task. The task can be carried out using some other altemative, 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 likelihood or the possibility of @ defect in a software product in terms of percentage is classified in the following ways : LL. High : Almost all users of the application can track the presence of defects probability. This indicates a 2, Medium : Half of the users can ta defects in a software product "oy, 3. Low : In general, no user detect Sit users will be able to detect it bo ML, Types of defects based on Prog, te, ly Pete TUS hay, Likewise, some can solve at a later business where eveything happens Defects also have a business pers The rectification of some defects Stage, 0" 4] acorting current need and demand of the mare ty ied tl ty, probability base, priority classification ales occuy following ways: hal 1. High : The high priority defines the m of company to correct a defect. Th as soon as possible, 8 etic, v8 shout in the same compilation #¥ 2, Medium : Medium priority defects are priority. And any next version or release includes addressing them ext t Of 0 pe, 3. Low : This type of defect does not need to individually. Consideration of repeirin defects, along with any other defects is 1.10.3(C) Failure be con 19 these te Voluntary, Fallure is a consequence of a Defect. iiss observable incorrect behavior of the system fai ‘Occurs when the software falls to perform in th environment. In other words, after the creation & execution’ Software code, if the system does not perorn expected, due to the occurrence of any defect the 's termed as Failure. Not all Defects result in Fal Some remain inactive in the code, and we may otice them, Failures also occur due to the foll reasons : © Any physical damage or overheating i hardware can cause the whole system tof a ' © If the software is not compatible with hardware, then also the system pe Unexpectedly,software Testing and Quali Assurance (SPPU) © 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 in software products Other failures can also = Happen due to a human error in interacting with the software, like entering an incorrect input value, oF 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 a Defect. — Sometimes, tests that result in undetected defects can also cause failure 1.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 tur, introduces errors. Human fallibility : Human beings are prone to make mistakes. t would be foolish to expect the software to be perfect, and without any flaws init Ironically, we have not yet discovered any other non-human agent thet can develop software better than humans. Therefore, we continue to rely on human intelligence to develop software. Thereby, increasing the possibilty 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 if they don't have proper knoviledge of the work. For example, a resource having a good understanding of Introduction to Software Testing the database but having limited knowledge of 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 bbusiness analyst does the requirement gathering, and then some other team member does the documentation of the requirements. Any 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 system and inter-system interfaces mean 0 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 possibilty 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, TareeIntroduct ION to (SPPU) ‘assurance (SPPUL TaM approach desibesinteme “Seu ten and intérnal, external suppliers ¢ 4 for ea project and for entire organization F Software Testing and Quality = New, unfamiliar technologies to develop = developers and testers eae 's unknown t© Pe i rique that I cto ; application using 2 en ge and UM derstanding | - Process ond fenctin of Organization hg, roper kn 5 to i com re ace ot Oe time, they require a certain | down int Ponents ieee can lead to errors. At that time, Toreacha | customer Or supplier to each othe oo + jinins level of R & D, brainstorming, and training workflow. me eu TOM appro8eh is based on Quality pig + Natural disasters, such | — = ital_ condition: . ae floods, lightning, earthquakes, applicable to all aspects of organization gg " : 8) 7 etc. can affect the computers. For example, @ system processes): may not work correctly if the software inside is] _ Fig, 141.1 represents supply chain r i or pollution. between customer and supplier, ty affected by radiation, electromagneti per and supplies, ‘Intemal suppliers} [Organizational __ processes. | ®eralaay 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 ioral ona it ideas for your a new exciting product ideas for your app. eee = The presence of design fiaws in a software system has a negative impact on the quality of the software, as ns of design practices and = Dr. Edward Deming implemented QMS bi TQM and Continual improvement in tay they indicate viok principles, which make a software system harder to | __ environment. understand, maintain, and evolve. Sofware defects | _ resulted into repetitive, costfete px sre congible effects of post softvars GUN. aiming at achieving customer satisfaction. = A software bug is an error, flaw, or fault in an application. This error causes the application to produce an unintended or unexpected result, such as crashing or producing invalid results. = Software testing company Tricentis revealed that in | 1.42 Quality Practices of TQM the year 2017 software failure affected 36 billion | = Dr. Deming proposed 14 quality manage principles that are widely used by practitioners. people and caused $1.7 trillion in financial losses, 1. Create constancy of purpose toward improve . behind this 1.11_ Total Quality Management (TQM) eeeeeeiar ale ee cclae 7 Sess ._t become competitive, to stay in business = Total quality management (TQM) is the continuous | Provide jobs. Organizations must Plan fol process of detecting and reducing errors or defects in quality and profits. ‘any manufacturing process, streamlining supply chain | 2. Adopt the new philosophy as we are in at management, improving the customer experience, | new economic age. It is unacceptable © Mt and ensuring that employees are up to speed with commonly accepted levels of delays. training. mat ; mistakes, defective materials and bad wet ef ~ Total quay management ims to hold all parties | Transformation of Westemn management * involved in the production process accountable for | TOM is necessary to drive business 2” ™ the overall quality of the final product or service towards improvement. _—_¥@e Testing and Quality Assurance (SPPU) ease dependence on inspection to achieve quality. timinate the need for inspection of entire product by smploying quality checks from beginning of jevelopment. inspections will find only lack in quality nd will not help to improve quality. It is commended to use statistical measure to control ind improve development process. top the practice of awarding business on the basis of ice tag. Focus must be kept on minimizing total cost instead of initial cost. Quality is highly dependent on nsistency so if you have less variations in input, bviously there will be less variations in output. A Zngle supplier can be contacted for any one item, on a Joyal, trustworthy, good, long-term relationship. urther, to ensure that suppliers meet your quality andards, quality statistics can be used. Constant improvement in the processes related to roduct and services must be done, This will improve ,, which in turn leads to cost Jse training and development programs for gmployees on the job. This will create strong undation of knowledge and skills required at work stitute leadership at workplace to help people to do better job. Main aim is to provide required support ind resources to people and machines. iminate fear so that everyone can feel free and work ectively for the organization. Make use of open and jonest communication to express ideas or concerns. is will motivate employees, increases respect and terest in doing work. jreak down barriers between departments and staff reas. Focus on collaboration and consensus is very portant. Build shared vision approach by forming 985-functional teams, liminate slogans, exhortations, and targets for the rkforce asking for zero defects and new levels of roductivity. Such exhortations only create adversarial ationships, as the bulk of the causes of low quality ind low productivity belong to the system and thus jie beyond the power of the workforce. Eliminate work tandards (quotas) on the factory floor. Substitute Jeadership. Eliminate management by objective. 115 Introduction to Software Testing 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 program for everyone. Improve the current skills of workers and encourage them to learn new skills to prepare for future changes and challenges. Building required skills will make your workforce more adaptable to change, and better able to find and achieve improvements, provement 14, Clearly define top management's commitment towards improvement in quality and productivity. Employees must perceive the top management ‘commitment for quality and productivity. Employee support is not enough rather, they should take action in order to accomplish the transformation. 1.13 Quality Management through - Statistical Process Control Statistical quality control proposed by Dr. Juran through DMMCI improvement cycle approach, = Quality management must be done based on measurements and by understanding interrelationship between customers, suppliers, and processes of different stages (development, testing etc). aiaeatassurance (SPPU) ; st Statistical Process Control (SPC)is an Indust standard methodology for measuring and controling quality during the manufacturing process. SPC enables realtime tracking of product 3nd process quality to facilitate continuous Improvement efforts There are three factors of this approach and are a5 follows : 1, 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. (At Organization level : Planning must be done at this level in the form of policy document based cn vision, mission etc. Planning activities must identify 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 (i) At Unit level : Planning must be done by people. Quality plans must be inline with policies and strategies and must ensured for consistency. Quality control It 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. 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 ee ees Quality approach is given by Philip Crosby. Improvement through cultural changes These cultural changes are driven by management ofan organization, 16 Introduction £0 Softy, ve It involves identifying different areas t0 improve doing capability measurement ang a) certain areas based On avalable yu benefit analysis, pareto analysis, efforts mane neg organization must SeLUP TOS5 funtion teams and give the awareness about cust, process measurements and quality, My _ Deploying teams under management ite improving development, testing, mine processes can bring cultural changes. = Set goals and targets in each department ey crganzation can helps to improve quality nga, process at all level. Customer satisaction leg, competition are the main sources for deen and targets. = Giving recognition to the teams will increase ng and establishes positive and competitive enon in the organization. — Repeating quality improverent cycles continu by giving next level goals and targets to rat improvement status. 1.15 Continual Improvement Cycle or PDCA Cycle There are many methods for quality impo These cover product improvement. #° improvement and people based improvement. — PDCA Cycle is an iterative four-step mana method used in business to focus on ‘om improvement of processes. The POCA qe of four steps namely Plan, Do, Check and M# ‘one of the key concepts of quality and itis alo the Deming circle/cycle/wheel. Plan. ‘When to Use the PDCA Process 7 The Plan-Do-Check-Act model is 2 hele can be used for a number of applications solos © Exploring and testing multiple small, controlled trial roare Testing and Quality Assurance (SPPU) 17 Introduction to Software Testing Avoiding waste by catching and adapting ineffective solutions before rolling them out on allarge scale Implementing improvement change and continuous Implementing Total Quality Management or Six Sigma initiatives Developing or improving a process intages of PDCA fersatile :It supports a variety of business vironments and for a number of applications. tential use cases include project management, jange management, product development, and ource management. imple and powerful : The POCA model is simple nd easy to understand, yet it is a powerful driver for change and inimizing waste and increasing efficiency. while jeaningful provement ddvantages of PDCA jard to do : Though the model is simple, the work PDCA breaks process improvements into smaller steps, it can be slow and robably isn’t a great solution for urgent projects. isn't easy. Because Requires commitment :PDCA is not 2 one-time levent. It is an ongoing, continuous process and erefore requires commitment and buy-in from the top down, Without committed leadership, the PDCA ‘cycle can't work effectively for the long term. jes in PDCA PDCA have some issues © PDCA oversimplifies what is really needed to improve © Do and Act phases have the same meaning in English © PDCA was meant to be applied for small scale improvements, not for large transformational changes © People are not included in the POCA cycle, but people are the one that to improvement process = Do-Check-Act (PDCA) activities forms a cycle of quality improvement in TQM approach. PDCA 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 : Comparison between planned and actual outcomes will give degree of variation, The observed variations are corrected by taking actions (change in plan), 1.16 Benchmarking and Metrics 1. Benchmarking = It is an useful concept of QFD (Quality Function Deployment) and defines measurable variables (scales), = It is used to create qualitative and quantitative ‘metrics that measures product quality against various scales of a benchmark. Examples of benchmarking variables are - cost, time, defect count, satisfaction level, functionalities etc. WeeWF sofware Testing and Quality Assurance (SPU) 2 Metrics Ttis defined as to collects information about process Variations, product capabilites, product attributes etc Metrics are defined from planning document, benchmarks etc Tt 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. 1.17 Problem Solvi ing Techniques =37 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 Qualitative method. ~ In qualitative problem solving method, problem solutions are understood using quality index such as low, 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 umber of stages. — Problem solving can be achieved by qualitative Problem solving and quantitative problem solving, Qual ive Problem Solving ~ It refers to understanding problem solution using ‘only qualitative parameters such as low, medium and high. It continuously monitoring something ig improving from present status and so forth. — This i typical scehario 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. 1.18 Introduction to 5, Quantitative Problem Solving In quantitative problem solving in exact measurement in numerical vays used. = Wis used in high maturity organs improvements are done on repetitive pa 7" DMMCI gle and measurements are a very accurate, thods OF Daa, ing ~ Process is well understood by apphing i technique on quantitative data. This data ng visualization and analysis of a process = Variations in a process can be identeg 2s actions may be initiated to reduce it ~ Techniques are used to indicate process measurement, analysis, decision maki problem solving. Wed MG diy ~ Techniques are independent of tools but ty used to drive tool usage, ~ Software testing Techniques are used to design ts test cases. Since exhaustive testing is not past through software testing techniques, it is past through testing tools. ~ Testing techniques mostly used for manual tt whereas testing tools are used for automation tai ~ Testing Techniques help reduce the number oft cases to be executed while increasing test covers ~ They help identify test conditions that are othe difficult to recognize, ~ Important software testing techniques are Bound Value Analysis (BVA), Equivalence Class Partito Decision Table based testing, State Transition & Guessing, etc, 1.18 Problem Solving Software Tools +18 Problem Solving Software Tools v9 Organizations need to invest reasonablY 3 Smount to buy analytical tools, data mara software's etc,ests solution based on data inputs. can be hardware, software, physical or logical in re. Quality tools are used by projects teams to problems faced by them, and decision Measurement, analysis, ision supports offered by tool is independent to onal skills and there is very less variation from Is can implement theoretically accessing matrices it quality as defined by business law. ntages of using Software tools Tepetitive or redundant tasks. Test automation uses of special software (separate ffom the software being tested) to control the ecution of tests and the comparison of actual utcomes with predicted outcomes. fest automation can automate some repetitive but fecessary tasks in a formalized testing process 11g Introduction to Software Testing 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 involved 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, finding out transaction response times when multiple users As compared to manual 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 DLLs, Visual Basic Programs, Siebel software, Builder software, databases, stand-alone Java applications etc. Power 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 ‘© Improvement in the quality and reliability of the software. © Drastic reduction in time, effort, and money spent on testing,3 sofware Testing and Quality Assurnce SPEU © Asystematic approach to the testing process: © Efficient management of the testing Process even ifthe teams are at diferent geographical locations, Advantages of using Tools 1. Tools are highly accurate and fast to make calculations and transactions. Calculations acts 25 input for decision making thus need to be accurate. 2. Decisions made by tools are with negligible variations, Some tools can be used on fixed range 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 leamed 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 PAs ‘Differentiate between software testing tools and techniques. : ERG Sr. | Software Testing | Software Testing Tools No. | Techniques 5 1. | Techniques independent to any tool. Usage of tool depends on technique. 2. | Same technique use different tools _to Different techniques may use_same tool to acive 120, st. | Software Testing Introduction & Techniques ‘achieve same result. Software testing Techniques are used to design better test cases. a A Ieis used for manual | 1 used op | testing. testing Software exhaustive testing is rot possible. a | testing possible Itis time consuming, | It is erecteg taking up human | software too, resources significantly fst, : i testing te i approach Investment is Investment is regia required for human | for testing took resources 1.19 Software Quality \ Quality of a software is defined as conforma! the specifications. All functional and non-tnd4 requirements are documented. Some requiem} are not stated. by customer but are neces building product, so such requirements areas by developer, Generally this document is approved by custor# then by developers. , Quality of deliverables is totally de ef documented and approved software Specification document. Again, there 2 — constraints on this document.Wi software Testing and Quality Assurance (SPU) Identity software quality attributes for the following scenarios. SESE i. People visiting popular websites such as You tube, Amazon, Google ote, Antivirus updater showing progress bar of scanning. ii, Software using adapters to connect to SMS gateway of different service providers, Identity software quality attributes for the following scenarios. SPPU=In-Sem:18 i. Internet banking system fi, Game for Children with various input devices ‘such as, mouse, joystick, touch screen ete. fi, 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. Now 2 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. - ji. Company want build a game for the children’s which they should play from any device (Le. mouse, joystick, touch screen etc) may also integrated for playing the a game. | ii, A software company is in a process of building a 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, Justify your answer. 12a Introduction to Software Testing Software quality is the characteristic of the software that defines how well the software meets the customer requirements, business requirements, coding standards etc. It can be divided into two categories : Software Functional Quality : characteristics that define how well the software meets functional requirements, and how well it satisfies the end-users. Software Non-Functional Quality : characteristics that define how well structural requirements are met that support the delivery of functional requirements. It is usually related to software code and internal structure. The different software qualities can be measured through various software testing techniques and tools. Following are the different attributes. (parameters) that are used to measure the software quality : ° Testability : How easy it is to test the software and to what extent it can be tested. Usability : It defines how user friendly the software is. Example: People visiting popular websites such as You tube, Amazon, Google etc. or Internet banking syste Understandability : How easily the software can be made understood to a layman about its functions/purpose Consistency : How far the software is consistent / uniform in terms of GUI 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 can be maintained in terms of enhancements/newThus human senses seeing and measuring features/bug fixes. Example networking site for a Software capability. wil re features in coming Which will add more fet There is huge communication future a customers and development or tei, hy e software is in tn i " performing required functions under diferent Software Is ae) 3 hie scenarios/conditions, x Internet banking there exist smlarties among may as properties like, requiremenn, : ty © Portability: How easily the software can be eens cx, (tea Teusabiy, transported and run in different environments highlight significant differences, eg. platforms like operating systems (Linux Mac, Windows), machines it can run on. Example: Software using adapters to connect to : SMS gateway of different service providers or 1.21 Quality and Productivity Relationship Game for Children with various input devices |_Relationstip such as, mouse, joystick, touch screen ete . ; @. What are the types of requirements and prs ‘Also point out relationship between quay 1 productivity. © Reliability : How reliable th Software cannot be tested fully py a, testing is concerned with cost, “hy © Security: How secured the software is in terms of access authorization and personal data like passwords. Ex: Internet banking system. © Robustness : How robust the software is under unexpected events like software crash, power- | ~ Many organizations or people are thinking that rt testing, inspection, rework gives a good qu product. off etc. and saves its data. 1.20 Constraints of Software Product Quality Assessment — More inspection would find more defects and agit defect free product can be delivered. It implies — Business analyst or system analyst are responsible for cost, time and efforts along with less profit. creating product requirement specification. Tester may or may not have direct access to the customer. Tester gets information from requirement documents - Product quality can be improved by improving qu! in production and testing process. and queries answered by customer or business | ~ This will automatically reduces inspection ret system analyst. testing, wastages etc and improves producti * — Testing personal cannot ‘have direct connect with in turn customer satisfaction. customer and get to know information through | ~ Most of the times, customers are complaining requirement document, feedbacks, queries etc. Problems related to product and services off = Such scenarios are creating some constraints while an organization. oer ~ These problems are the outcome of foul Limitations of product quality assessment are as Used during development that gives rise to ™! : follows : defects, © As compared to other engineered product, a | ~ ImProved quality can reduce cost of evel” software is not produced in a physical form, Cost of quality, selling price thus increas margins, —9isone testing snd QalyAesrance SPP) Employee is treated as an important entity during the phase of quality improvement and performance improvement. 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 @ major problem in the businesses, Miscommunication wrong \which in tur can leads to user's gap and producer's gep. leads to interpretation With management guidance and support, employees are working performing teams. and converts organization into 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 Smart work will help the employees to identify devistions in development process thus can be eliminated easily Research and Development department are carrying out inventions in many organizations. It is directed to develop new technologies and techniques in the process approach of development and testing Six sigma approach suggests refinement, redesign in the existing processes. 22_Requirements of Product TT 2. Point out productivity, relationship between quality and EEE Every product offered to customer must satisfy all his requirements and needs. 1:23 Introduction to Software Testing = To achieve this, all the phases of SDLC are driven according to requirements and needs, = Due to fierce competition in the business world, product requitements are dificult to categorize. = In such cases, organizations are focusing on the customers and decides priorities of requirements. Following are the different categories of requirements, Rogulrements of Produc 1, Slated and Implied Requirements 2. Genoral and Specific Requirements 3, Present and Future Requirements Fig 1.22.1 : Requirements of Product 1. Stated and Implied Requirements - Stated requirements are documented in SRS (oftware Requirement Specification) document and other are implied one, — Business analysts and customer specifies the functional and non-functional requirements in the SRS document. — Development and testing teams must be able to understand stated requirements. ~ There are certain requirements which may not be documented but are considered in product. eg. Readable font size, no spelling mistakes etc. Business analysts are supposed to convert implied requirements in stated one, General and Specific Requirements — Some requirements are generic in nature, which are accepted for particular product and group of users. But some of requirements are specific in nature and are used for specific products only. — General requirements are accepted for a type of product whereas requirements are very specific for a product in development. and group of users, some™ Introduction to softy, are Software Testing and Quality Assurance (SPPU) 1:24 Fy ae Tey dary Requirer General requirements are cor red as implied one eee 3. Re 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 Calculations, Authentication followed by Notification ete, Present and Future Requirements Present requirements are considered for an Future requirements are considered after some time span, application use in current circumstances. 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. fequirement Categories Based on Priority The requirement categories based on priority of their implementation from user's perspective. L = It includes “Should be" and “Should ng ye, requirements. It adds some Value to the pr, aa are appreciated by customers. a = Customer may pay litle extra for having thes requirements in product. Its presence , absence may disappoint ite hy customer an‘ ~ Its denoted by P2 priority and covers “shu, be" requirements also, m 3. Tertiary Requirements ~ includes “Could be" and “Could not be" tye, requlrements. Its not adding Much vale inten price paid by customer. - If two products are same then “could requirements can give competitive advantage 2 receives customer appreciation. = It helps to provide identity to a product and x denoted by P3_ priority. requirements requirements. Tt is lowest piniy and also covers "Could net ty 1.23 Software Development Process of Software Development Lifecycle Models 1. Primary Requirements 2, Secondary Requirements 28, 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 P1 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 f software is being developed. Following are development approaches. 1.23.1 Waterfall Model Itis termed as classical view of software developt and forms foundation for any development acti? 's one of the simplest model but not feasible 1" every time, ' Different variants are avaliable such as, nal Waterfall model, iterative waterfall model ete "™" other development models are basically depend 7 Waterfall model ie! Customer requirements are converted into Io" and high level design, Code is implemented design and tested as per test plan.jaintained in last phase. This model provides short ute for development activities and is highly efficient nd productive in nature. There are some limitations of waterfall model. It is jore useful when projects are having fixed schedule nd price, his model is not having any provision for feedback improvements) because it assumes that requirements re stable and no error will occur during entire SDLC, his model does not involve any kind of rework. Customer Requirements Design coting Testing Deployment Maintenance Fig. 1.23.1 : Waterfall Model intages of the Waterfall Model imple and easy to understand and use asy to manage due to the rigidity of the model. Each hase has specific deliverables and a review process. chases are processed and completed one at a time. forks well for smaller projects where requirements re very well understood, early defined stages. ell understood milestones. asy to arrange tasks. Process and results are well documented. \dvantages of the Waterfall Model No working software is produced until late during the life cycle. Introduction to Software Testing High amounts of risk and uncertainty. Not @ good model for complex and object-oriented projects Poor model for long and ongoing projects. 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. Itis difficult to measure progress within stages. Cannot accommodate changing requirements. Adjusting scope during the life cycle can end a project. 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 Requifgmonts Desien Coding Texting Deployment Maintenance Fig, 1.23.2: Iterative Model© software Testing and Quality Assurance (SPPU) 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. fF Sabeysiem 1 “Subsystem 2 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. 2, Results are obtained early and periodically. 3, Parallel development can be planned. 4, Progress can be measured. 5, Less costly to change the scope/requirements Testing and debugging during smaller iteration is easy. 1:26 =~ Introduction to Software, et 7._ Risks are identified and resolved during itera ‘each iteration is an easily managed milestone. " 8, Easier to manage risk - High risk partis done firs 9, With every increment, operational prod, delivered. ‘ 10, Issues, challenges and risks identified trom eq, increment can be utilized/applied to the es increment, 1LL Risk analysis is bette. 12, It supports changing requirements. 13, Initial Operating time is less. 14, Better suited for large and mission-critical projects, 15. During the life cycle, software is produced eary wih facilitates customer evaluation and feedback Disadvantages of the Iterative and Incremental SDLC Model are as follows : 1. More resources may be required. 2. Although cost of change is lesser, but it is not vey suitable for changing requirements. 3, More management attention is required. 4, System architecture or design issues may atse because not all requirements are gathered in the beginning of the entire life cycle. 5. Defining increments may require definition of the 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 analys# 10. Projects progress is highly dependent upon the " analysis phase. 1.23.4. Spiral Model In this approach, requirements are received multiple and according to it development is Systems iterations carried out with incrementing size are built using spiral model eg. softwares,Software Testing and Quality Assurance (SPPU) 1.27 Introduction to Software Testing Banking system etc. Initially some functionality is created and given to customer. 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. Module 5 [+ Module ¢ Module 1 |-——»] Module 2 Module 3 Fig, 1.23.4 : Spiral Model ivantages of Spiral Model High amount of risk analysis hence, avoidance of Risk is enhanced. Good for large and mission-critical projects. Strong approval and documentation control. ‘Additional Functionality can be added at a later date. Software is produced early in the software life cycle. Project estimates in terms of schedule, cost etc become more and more realistic as the project moves forward and loops in spiral get completed. It is suitable for high risk projects, where business needs may be unstable. A highly customized product can be developed using this. isadvantages of Spiral Model Can be a costly model to use. Risk analysis requires highly specific expertise. Project's success is highly dependent on the risk analysis phase. Doesn't work well for smaller projects. ._Itis not suitable for low risk projects. 6, May be hard to define objective, verifiable milestones. 7. Spiral may continue indefinitely. 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 given to customer. — This will help them to understand their expected product. It is helpful for development team as they can understand system look and feel. = Upon finalizing the requirements system is built and product is delivered. There are some limitations of prototyping model. Model of a system is created not the actual product. = Due to this customer may pressurize development team to deliver it immediately. Advantages of Prototype Model 1. Users are actively involved in the development 2, Since in this methodology a working model of the system is provided, understanding of the system being developed. the users get a better 3. Errors can be detected much earlier. 4. Quicker user feedback is available leading to better solutions. 5. Missing functionality can be identified easily 6 Confusing or difficult functions can be ntified 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, Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans,n not to be used as the full system was designed Incomplete ‘orinadequate problem analysis. 23.6 Rapid Application Development (RAD) Model It develops usable software at a fast speed where user still understands development and application under Process. It works similar to spiral model. Developers starts with very less number of Fequirements and creates design, code it, test it and delivered to customer, Once software is delivered, customer can understand hhis expectations and development in a more clearer way. He can add more or refine earlier requirements, In each iteration this is followed by development. Major constraints in rapid application development ‘model are change in approach and refactoring. Each iteration requires multiple regression testing cycles. Advantages of the RAD mode! 1 2. Reduced development time. Increases reusabi Quick Encourages customer feedback ity of components tial reviews occur Integration from very beginning solves a lot of integration issues. a Disadvantages of RAD model 1. Depends on strong team and individual performances for identifying business requirements. 2. Only system that can be modularized can be built using RAD 3. Requires highly skilled developers/designers. 4. High dependency on modeling skills 5. Inapplicable to cheaper projects as cost of modeling and automated code generation is very high. 1.23.7 Agile Development Model = The model is dynamic in nature and has adaptability to. user product integration. environment and continuous Software Testing and Quality Asurance(SPPU) 28 SON 2 Software Tox Incomplete application may cause applica The importance is given to deliver a working prog. through customer collaboration, instead of fui lin requirements from SRS document. 3 It gives complete freedom to customer to add th requirements at any phase of SDLC and develones must accept those. Agile development consists of methodologies ig scrum, extreme programming, test. development etc. driven Advantages of Agile model 1. Customer satisfaction by rapid, continuous deliver Useful software. 2. People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other. 3. Working software is delivered frequently (weeks rather than months). 4, Face-to-face conversation is the best form of ‘communication. 5. Close, daily cooperation between business people and developers. 6. Continuous attention to technical excellence and good design. 7. Regular adaptation to changing circumstances. 8 Even late changes in requirements are welcomed Disadvantages of Agile model 1._In case of some software deliverables, especially the large ones, itis difficult to assess the effort required at the beginning of the software development lfe cycle. There is lack of emphasis on necessary designing and documentation. The project can easily get taken off track if the customer representative is not clear what final outcome that they want. ‘Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources. TecateffeiTesting and Quality Assurance (SPPU) 1.29 Introduction to Software Testing fare functionalities are ported from logy platform to newer one. Features of are expected to be present in new Due to change in business the impact of detect in diferent phases of | . Ea r the defect is found lesser is the cost of example if error is found in the phase during requirements gathering cheap to fix it. The correction to the ation can be done and then it can = Inthe same way when defect or error is found in the design phase during design review then impact is ow, the design can be corrected, and it can be re-issued, Its costis 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 specifications and is not found til the user acceptance then the cost to fix those errors or defects will be way too expensive. 1.24 Types of Software Product Software products can be categorized based on their criticality ie, 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 jentialedaePU) Software Testing and Quality Assurance (SI 1, Products affecting life ical — Products from this category are the most ci! _ Product since they can directly or indirectly affect : human life. These products are having regulatory an¥ 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 : © Most critical product, where failure resulting into death of a person. Second level critical product, where failure resulting into permanent disability. Gif) Product failure resulting into temporary disability (iv) Product failure resulting into minor injury. (¥) All other products that do not affect health. 2. Products affecting investment = Products from ti list criticality. They can have effect over investment category are ranked second in the 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. eg. products from space research, aeronautics etc = They need large amount of testing but less than above two categories. Other products All products other than above three are put in this category. Introduction to sof, a 30 . 1.25 Problematic Areas of Spic %, Problematic areas of SDLC 4. Problems with quirement phaay 2. Unique product developmen, 3.Dillerence in development appa 4. Impossible exhaustive testing 3, Unaware about bad quality 6. Qualily definition 7. Quality objectives it Fig. 1.25.1 : Problematic Areas of SDL¢ 1. Problems with requirement phase Requirement collection is an important phase ins and having highest probability of introducing deta in the system. Following are some of the problems. () Communication It is considered as major problem in fomiy requirement statement. Many times requirementsz: not communicated in an easy way. (@) Technical requirements are about platform, langu: database, OS etc. It also consist configuration ¢ various technical entities. Generally develop team deals with these requirements. (6) Economics of software is based on its technica #! system requirements. Generally development and customer are dealing with this type © Fequirement. Customer must understand sift approaches and select one out of it. Developm organization must help customer in choosing approach by sharing its experience. © fee Software product may be associated with dif Statutory and regulatory requirements. There may some rules and regulations applicable to produc™ those must be understood by development te”oftware Testing and Quality Assurance (SPPU) (Operational requirements combination of different functional and non-functional req are ments. These are defined by user/customer based on their business needs. It defines what the software must do Jand must not do. Security requirements are combination of physical ‘and logical security requirements. Customer and Idevelopment team are working with these, It consists requirements for backup, restoration, configuration, Jaccess control, hardware ete, Customer may specify quirements for privileges encryption, password rotection ete. hanging nature ynamic nature of requirements resulting many plaints from development teams. hanging requirements may confuse the developers. {ter showing built product to customer, many new ideas are suggested and some of them directly have fect on cost. time, and efforts. fetimes changes suggested may have effect on Jesign, architecture, and methodology also. The time jp between requirement submission and product jelivery plays very essential role. ;proaches like rapid application development, top- jown, joint application development can be used to ccommodate changing requirements. Inique product development software field no two application are same. plementation for same problem, done by two itferent developers differ from each other. fen same solution developed by same developer at different instances may not be similar. Software roduced in such instances may be considered ique. uring maintenance, designers facing difficulties in nderstanding original design whereas developers faces difficulties in reading the code, Difference in development approach rhe approach of developing a software vary from rganization to organization. 131 6 Introduction to Software Testing Different implementation is possible for same requirement set and It is depending on capabilities of developer. The best suitable approach is selected after observing circumstances. Impossible exhaustive testing Inspection and testing activity is aimed at finding flaws from products and development processes. Testing of all possible areas in product is practically impossible. High cost and time will be required to test all permutations and combinations. Unaware about bad quality AAs said earlier, testing of all algorithms, conditions ete. is impractical Such areas 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. Quality det Product quality depends on processes used for its development rather than rigorous inspection/testing activities applied on it. Finding and fixing defect will not improve quality of product and also will not guarantee defect free delivery. Good processes and procedures can only make a good quality software, Quality objectives There is a variation observed in quality objectives of different products. It depends on type of product, customer using it, time and circumstances. Quality objectives represents user ‘expectations and their satisfaction level. They are defined on the basis of factors of quality ie, ‘must be’ ‘could be’ for the applications. ‘should be’ and TeaiesteayWF sofware Testing and Quality Assurance SPRY Quality Factors Following are some of the quality factors ‘unity ttors ii commer Fi) innit er Pvt fe Ls J iy Pertormancr Fr ny (wih Areas coo! —— oc fay Conta i Fig, 1.25.2 : Quality Factors ) Correctness Defines the accuracy of outcomes i) Usability Efforts needed to leatn, operste, prepare input, and understand output. fii) Maintainability Efforts required to find and fix the defects. iv) Portability Efforts required to transfer software from one herdware/software configuretion to another. ¥) Coupling Effons required to integrate system components vi) Performance Amount of resources needed to perform required functionalities. vil) Reliability ‘System remain functional over the longer time period, vill) Access control resources, Protection of from di system juction, modification etc misuse, x) Continuity vataity of essential Procedures, my, tackup information for recovering data, sre operations. “ 1.26 Software Qual ty Management anagement consists of Set of plan, = Quality mé activities (for systematic developmen inaintenance) used to manage qualty of prog, * services. : ie involves management of all iMPUt t0 they processes in order to generate output mating quality criteria. Software quality management is a manager, process used to develop and manage the quai, software in such a way So as the best ensur 5, software product meets the quality stndsy expected by the customer while also meting 3, necessary regulatory and developer requirements However, software quality significantly differs fay the concept of quality generally used manufacturing mainly for the following reasons: © The software specification should refec ts characteristics of the product that the custore wants. However, the development organiza: may also have requirements such maintainability that are not included in te specification. © Certain software quality attributes such # ‘maintainability, usability, reliability cannot # exactly specified and measured. © Atthe early stages of software process itis? difficult to define a complete softt* specification. Therefore, although software ™ conform to its specification, users don't m= their quality expectations. Activities of Software Quality Management Quality Assurance - QA aims at develo? Organizational procedures and standards for 45" at Organizational level“ess applicable proceduy standards for a particular project ang oa and required to develop a quality plan, iy as Quality Control - Ensure that best standards are followed by the software team to produce quality products, Practices and development Quality management activities ensures that software products and processes matches to dof standards, customer requirements ete the ined It presents three levels of handlin 19 problems which are as follows. Correction Iris considered as quality control approach. Defects are found in the system and are quickly fixed, Defect finding and fixing respor line function. lity is handled by Corrective actions K is considered as quality assurance approach, Process related problems are detected and resolved by initisting 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. Responsi actions is handled by project leads. ity of corrective Preventive actions After pot studying root causes of defects, ntially weaker areas are identified. other These areas can suffer from defect occurrence thus preventive actions are applied to them. Actions are initieted after checking similar scenarios or past history. Responsibility of preventive actions is handled by project manager (senior management). 27 Processes Related to Software Quality Organization culture forms a strong foundation for vality. There are different tiers of quality management d are discussed in following section. ewer wy sunvare Lesting Different tiers of quality management 1. Vision 2. Mission 3.Paley 4, Objecives 5. Svategy 8. Goal 7.Valuos Fig, 1.27.1: Different tiers of quality management Vision Every organization has its vision statement states ultimate aim it wishes to achieve in some time horizon, Vision statement is a brief idea 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 different 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 have at least one objective, It is defined in quantifiable terms along with duration for achieving it.achieving the mission of ‘organization is 's strategy, Policies are converted into SMategies, Strategies Set Of objectives and 6. Goal actions with the help of are defined using time duration, goals Small milestones ultimate mission, ~ Obje Underst: not, are termed as goals used to achieve 26 are evaluated by reviewing milestones to ‘and whether progress isin proper direction of 7. Values The way with which organization management think, behave, and believe i is defined by values, Xd Quality Assurance (SPPU) eae Benefits of Quality Management sya m Managing product and process quay, iy Achieve greater consistency in the Rtv, in providing products or services tis Reduce expensive mistakes Inerease efficiency by improving yee 7 resources ti * Improve customer satisfaction Market your business more effective Explotnew market sectors and tertores Manage growth more effectively by making to integrate new employees i Constantly improve your produe tS, races systems ay Structure of Quality Management System Every organization has its own stry meeting customer requirements and enhancing their satisfaction. tur fr ay ~ Organizations are setting business Principles based | management system (QMS) based o. needs yy on values, requirements. Following tiers forms typical struct Qs. 1.28 Quality Management System's cz) Structure Gavan) With respect to quaity management system — explain the following ESSE a) |e 8 g)/ 3) | Tens ~ Quality management isthe process of overseeing all ie Hae activities and tasks needed to maintain a desired level gy: : of excellence, a 3| le 6e ~ Quality management includes the Fig. 1.28.1 : Typical structure of QMS for an Organintin © Determination of a quality policy i 1. Tier 1 - Quality policy © Creating and implementing quality planning ota bet Eee ~ Macts as basic framework in QMS that fa i rol intent, wish, and directions of management to Quality 2 Quality con ‘Out process activities, ° ovement in Quality improvemen ~ Management is the ‘only driving force in * — A quality management system (QMS) is a collection ‘organization so its intent become most important Of business processes focused on consistently | 2, ier 2 - Quality objectives Te helps to measure progress and achievements numerical terms, ms watsoftware Testing and Quality Assurance (SPPU) Quality improvements can be observed by looking at numerical values of achieved quality factors, These achieved values can be compared with planned fone to find out deviation and to initiate further required actions. Tier 3 - Quality manual Itis also termed as policy manual which is established and published by management. It forms a strong foundation for quality planning at ‘organizational level. It provides a framework for ie defining various processes .29. Pillars of Quality Management nd System Pe With respect to Quality Management system. explain the following i. Pillars of Quality Management System. Pillar 01- Quality processes, procedures, methods and work instructions It consists of quality processes, procedures, methods and work instructions. Itis defined at organization level and project/function | by experts from respective functional area separately Processes from organization level acts as umbrella under which project/function level processes are defined, Organization level processes may differ for different Projects/functions. At project level, it is also defined as quality planning. Quality procedure must be synced at an organization level as per the quality manual Pillar 02 - Guidelines and formats It consists of guidelines and formats used to achieve Quality goals for products/services. It is used by Project teams. Guidelines suggest a way of doing the things and can be overruled. Standards are defined by field experts and are mandatory ways of doing things Introduction to Software Testing ~ Customer defined guidelines can be treated as standard for a project. These two things needs constant revision to maintain suitability over time period. 3. Pillar 03- Formats and templates used for tracking projects, function, department information — Ik consists of formats and templates used for tracking projects, function, department information within organization. — It is used to maintain common understanding and consistency across all projects within organization, = Templates can act as standards as they can be made mandatory while formats can act as guidelines as they can be suggestive. 1.30 Important Aspects of Quality Management ; With respect to Quality Management system ‘explain the folowing : | SPPU- In Sem. 18] __iImoortant Aspects of Quality Management. Imporiant aspects of quality management 1. Qualy plennng al Organization evel 2. Qual planning at Proectievel 3. Resource management 4. Work envionment 5, Customer elated processes 6. OMS document and and Data contol 7. Veriton and Validation projec management 9, Solvare configuration management 10. Sotware mais and measurement 15, Software quality eudis 12, Subsonvaet management 1. formation seaunty management 4 Management review Fig, 1.30. Important aspects of quality management Teariealeeof surance (SPPU) 1:36 si Software Testing and Quality Assurance ( @. QMS document and Data control 1. Quality planning at Organization level = Organizations creates quality plan that talks about Vision and mission, policies, strategies, objectives, goals ete. = It sets a framework for defining and implementing various practices, processes, recruitment, infrastructure, hardware, software ete. = Achieved quality is checked against expected one mentioned in quality plan and if needed actions are employed, 2. Quality planning at Project level — Project quality plan must state project level objectives that are in sync with organization level objectives. = It also. defines various roles, responsibilities and actions. 3. Resource management ~ Basic resources can be people, methods, machines, materials etc. If the best combination of technology and process is given to people to work on it then planned results can be achieved, 4. Work environment ‘An essential input for a better product is its work environment. Bad environment can cause problem in achieving organization vision, mission, objectives. Work environment has two components ie. internal (within organization) and extemal (outside the organization) environment. = Good work environment builds strength of organization and achieves customer satisfaction. 5. Customer related processes - Capability of these processes is analysed with respect to services to customer and their satisfaction level. = Processes can be from requirement analysis, design, delivery etc. Capable processes can only achieve good result. In case of deviating results some preventive and corrective action is initiated. Introduction to Softy MS are defined with he ely of cu ang and quality models having specific = Many organizations cua | reurerrs whch ean ben importa a defining QMS. : = Process improvement is done with the hel 4 statistical process control and data marageney techniques. Verification and Validation | = Verification and Validation activities are performed » every level of product development. = Verification consists of project review, technicg review, code review, management review etc = Validation consists of testing activities like unt testing, system testing etc. 8. Software project management Project management consist of tasks like planning 9, staffing, directing, coordinating along with guiding, coaching and organi controlling mentoring. Software configuration management = The product is tested (using verification and validation activities) on regular basis and continuous undergoes updation, integration. Configuration management takes care of creating products, their maintenance, review, and necessa updates 10. Software metrics and measurement prograt = Project management defines various metri to measure process capabilities and product quality attributes, ~ These programs takes current process data 25 * input to check its capability in delivering deste? output, ~The deviations are corrected by applying necess* actions, winkSoftware quality audit is conducted t processes and products for their correctns oa es Ss, Based on result of audit required : rev corrective actions are applied, iain Audits are conducted at predefined level and is of three types ie. internal audit, customer audit ths party audit. Pa 2. Subcontract management ‘A supplier is considered as an important stakeholder of organization. Proper methodologies are defined to build and maintain long-term relationship with suppliers. Input from suppliers are validated for their usefullness an effectiveness. Statistical control is applied supplier processes to avoid lose, delay, and service problems. [3. Information security management Three dimensions of information confidentiality, integrity, and availability. security are Information stored with applications and databases must be protected because this information acts as an provement programs. input for continual |. Management review It is conducted to analyze progress of various projects, departments, functions etc. that will be useful in achieving organization's vision, mission and objectives. ust plan for future development in Management mi . and business, Management review must be a planne systematic. i it Its input, methodology of conduction, and output must be clearly defined. 1 Explain Historical Perspective of Quality. as a6 a7 a8 as ato ant Q.12 Q.13 O14 15 Q.16 Q.17 Q.18 19 Q.20 a2 Q.22 Q,23 Q.24 Explain customer's view and supplier's view with respect to quality, Describe quality according i 1g Dr. Deming, Dr, and Dr. Crosby. seis Describe cultural change requirement for quality improvement, What are the TOM principles of % continual improvement? ‘What are the core components of quality? Difference between Continual Improvement and Continuous Improvement in process. ‘Write Objectives of Testing. ‘Write Difference between Testing and Debugging. What is Need of Testing, What is Difference between Software Testing and Quality Assurance, Explain, Why Software has Errors, Defects and Failures and What are its Causes and Effects on software. Write what are the reasons for Software Bugs. Describe Inter-relation between Error, Defect, and Failure in software. What are Effect of Errors, Defects and Failures. What are Cause of Errors, Defects and Failures on Software. Desoribe Quality Practices of TOM. Explain Quality Management through - Statistical Process Control Describe Quality Management through - Cultural Changes. Explain Continual Improvement Cycle or POCA cycle. Describe Benchmarking and Metrics in terms of quality Explain Problem Solving Techniques of qual. Describe Problem Solving Software Tools. ents. 2 Define quality? Explain quality Core ‘Compont aaaQ. 26 Q.27 Q.28 @. 28 2. 30 Q31 Q.32 @.33 Q.34 Frware Testing and Quality Assurance (SPPU) Write Ditferentiste between software tes and techniques, Explain Software Quality Attributes, Explain Constraints of Software Product Quality Assessment, Explein Quality and Productivity Relationship. Explain requirements of Product, Impact of Defect in Different Phases of Software Development, Explain Types of Software Product, Explain Problematic Areas of SDLC, Describe Software Quality Management. Explain in brief vatious development models, Q.36 Q.37 Q, 38 Q.39 @.40 aa Q.42 Q.43 Discuss product criticality, Explain diferent types of produots ons, Hes ot Sot, Explain QMS structure for organiny Explain different Activi Management. Explain Processes Related to Software Qua Explain Quality Management System's What are the major pillars of Qus? Explain different Important Aspects. of 9 Management. 1inning : Artifacts amp; Strategy, ontents, Test Strategy and Appro: le, Use case Testin 1 Scenario Testing, e Coverage, Defect Acceptance &am | Fectors, Test Report Samp; Assues. Software Quality, Quali goal of @ software tester is to find bugs, find 2s early as possible, and make sure they get To achieve this goal through properly municated and documented the test effort with constructed test plans, test cases, and test sTest Plan is 2 document that describes the scope, proach, resources and schedule required for | — Dnducting test activities. It identifies requirement of Bst items, which features of application to be tested, the different testing tasks, who will perform the spective task, and possible risks and their corrective jeasures. Test Organization : Test Manager &: ach, Test cases & Test Data, Test Monitoring & Pi Rejection, Test Efficiency, Efforts and Schedule Variance, Test Efforts Configuration Management, Quality Assurance Process, ity Management Importance, 21 Test Planning and Quality Management Tester Role, Test plan purpose Test Entry-Evit criteria, Test Execution| Control : Test Metrics : Test Case Productivity, Documentation Risk Quality Best practices. ‘master test plan that directs when and how to carry Out different testing tasks. You can alter the test strategy to suit the requirements of your team and software. A test plan ‘typically includes information on the following: Tequirements, risks, test cases, environments to test in, business and quality objectives, test schedules, and other things. Test planning, the most important activity to ensure that there is initially a list of tasks and milestones in a baseline plan to track the progress of the project. It also defines the size of the test effort. Test Planning ~ Artifacts & The testing process, which is still in its early stages, eds to be managed from a variety of angles. No Q. Explain. following for a testing process--Test fest organisation hierarchy is observed in several ate EEE sectors. stead, all tasks, including testing, are handled by a ingle development team. We require a testing jierarchy of the following ns to do testing effectively: different roles. individuals with Therefore, setting up a test organisation is the first ‘stage in managing a testing process. Next, we need a TI = Test planning is the very first activity of testing team that is used throughout the SDLC. It is defined within the framework created by test strategy and established by test policy. Test plan contains testing at various stages during SDLC. It talks about assumptions, constraints, limitations, and risks associated with testing,