Software Quality Assurance


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Quality Assurance

  1. 1. Software Testing<br />Sneak-peek into the world of testing<br />Vikash Mishra(<br />
  2. 2. Software Testing<br />Software Testing is the process of analyzing a software item to detect differences between existing and required conditions(that is bugs) and to evaluate features of software items.<br />Software Testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.<br />No software can be 100% bug free. The aim of software testing is to give the best product to users/customers with minimum number of bugs/defects.<br />Vikash Mishra(<br />
  3. 3. Need of Testing<br />To demonstrate software does what it is supposed to do and does not do something which it is not supposed to do.<br />To find defects as early as possible and get them fixed.<br />To meet compliance with contractual or legal requirements<br />Testing should provide sufficient information to the stake holders for decision making regarding release of the software/ system , for the next development step or handover to customers.<br />Vikash Mishra(<br />
  4. 4. Test Plan<br />Test plan is a document that describes how testing will be accomplished. It is similar to Project Plan.<br />Five key characteristics defined in a Test Plan:<br />Scope & Objectives: Defining what will be covered in a project <br />Resource: What type and number of resources to be used to accomplish the objectives <br />Schedule: Tasks and their schedules.<br />Quality: Standards to be used and/or customized.<br />Risk: Defines in advance what may happen to drive the plan off course, and what will be done to recover the situation.<br />Vikash Mishra(<br />
  5. 5. Need for Test Plan<br />Discuss issues early.<br />Enables to decide in advance:<br />How a project’s objectives will be met. <br />What resources are available and what resources are required.. <br />Time scales required. <br />Quality desired.<br />Controlling risk.<br />Vikash Mishra(<br />
  6. 6. Functional Testing and Non-Functional Testing<br />Functional Testing:<br />Functional Testing refers to testing very specific action or function of the code.<br />Functional testing tends to answer the question: <br />CAN WE DO THIS?<br />DOES THIS PARTICULAR FEATURE WORK?<br />Functional Test – white box<br />Tests at micro level of the programs that test each and every implemented functional task, ensuring that all code options are exercised. Requires knowledge of the internal code<br />Functional Test – black box<br />Testing that focuses solely on the outputs generated in response to selected inputs and execution conditions. Requirements are the only test basis and knowledge of the internal code is not required.<br />Vikash Mishra(<br />
  7. 7. Functional Testing and Non-Functional Testing<br />Non-Functional Testing:<br />Non-Functional Testing refers to that aspect of software that may not relate to specific function or user action such as scalability or security.<br />Non-Functional testing tends to answer the question:<br />HOW MANY PEOPLE CAN LOG IN IT AT ONCE?<br />HOW EASY IT IS TO HACK THE SOFTWARE?<br />Testing that concentrates on the performance of the system like the response time, speed of execution, usability, availability etc.<br />First check for “Functionality” and then for “Performance”<br />Vikash Mishra(<br />
  8. 8. Four levels of Testing done in any Testing Project<br />Unit Testing:Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. May require developing test driver modules or test harnesses. Unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use. A unit is the smallest testable part of an application.<br />Integration Testing:In this type of testing both software component and hardware components are combined together and tested. Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. <br />Vikash Mishra(<br />
  9. 9. Four levels of Testing done in any Testing Project<br />System Testing: System testing involves putting the new program in many different environments to ensure program works in typical customer environment. System testing is conducted on complete, integrated system to evaluate the system compliance with its specified requirements. The entire system is tested as per requirements.<br />Acceptance Testing:Performed by customers or user representative. Supposed to be final level of testing and verifies whether product meets the agreed upon product acceptance criteria.<br />Vikash Mishra(<br />
  10. 10. Black Box Testing<br />Black Box Testing treats system as black box, so it does not use knowledge of internal structure or code.<br />Black-box techniques (also called specification-based techniques) are a way to derive and select test conditions or test cases based on an analysis of the test basis documentation, whether functional or non-functional, for a component or system without reference to its internal structure.<br />Main focus in black box testing is on the functionality of system as whole.<br />Behavioural testing is also used for black box testing.<br />Black-box techniques is also called specification-based techniques.<br />Vikash Mishra(<br />
  11. 11. Black Box Testing<br />Advantages of Black Box Testing:<br />Tester can be non-technical.<br />Used to verify contradictions in actual system and the specifications.<br />Test cases can be designed as soon as the functional specifications are complete<br />Disadvantages of Black Box Testing:<br />The test inputs needs to be from large sample space.<br />It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult.<br />Chances of having unidentified paths during this testing.<br />Vikash Mishra(<br />
  12. 12. White Box Testing<br />White box testing (WBT) is also called Structural or Glass box testing. <br />White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised.<br />White Box Testing is coverage of the specification in the code.<br />Vikash Mishra(<br />
  13. 13. White Box Testing<br />Need of White Box Testing?<br />To discover the following types of bugs:<br />Logical error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program.<br />The design errors due to difference between logical flow of the program and the actual implementation.<br />Typographical errors and syntax checking.<br />Limitations of White Box Testing:<br />Not possible for testing each and every path of the loops in program. This means exhaustive testing is impossible for large systems.<br />This does not mean that WBT is not effective. By selecting important logical paths and data structure for testing is practically possible and effective. <br />Vikash Mishra(<br />
  14. 14. Defect<br />Variance of actual result from expected result.<br />The difference between actual behaviour and the desired behaviour as stipulated by the requirements specifications<br />A Defect that causes an error or negatively impacts a user/ customer is categorised as Failure<br />Software does not do something which it is supposed to do.<br />Does something which it is not supposed to do.<br />Vikash Mishra(<br />
  15. 15. Defect Life Cycle<br />New<br />Opened<br />Review<br />Deferred<br />Assign<br />Duplicate<br />Reopened<br />Fixed<br />Not a defect<br />Retested<br />Closed<br />Vikash Mishra(<br />
  16. 16. Severity and Priority<br />Severity indicates how bad the bug is and reflects its impact on the product and its users.<br />Priority determines the order in which the product is to fixed.<br />PRIORITY>> SEVERITY<br />Vikash Mishra(<br />
  17. 17. Software Verification and Validation<br />Verification: Process of evaluating a system or a component whether the products of a given development phase satisfy the conditions imposed on the start of phase.<br />HAVE WE BUILD THE RIGHT SOFTWARE?<br />DOES IT MATCH THE SPECIFICATIONS?<br />Validation: Process of evaluating system or component during or at the end of development process to see whether it satisfies the specific requirements.<br />HAVE WE BUILT THE RIGHT SOFTWARE?<br />IS THIS WHAT CUSTOMER WANTS?<br />Vikash Mishra(<br />
  18. 18. Retesting and Regression Testing<br />Retest is the act of repeating a test to verify that the found defect has been correctly fixed.<br />Regression Testing is the act of repeating other tests in the parallel area to ensure that the applied fix or change of the code has not introduced other errors or unexpected behaviour.<br />Vikash Mishra(<br />
  19. 19. Inspection Review and Walkthrough<br />Inspection: It is a technique in which the work product is examined for its compliance to specific standards and also checked against a history of common errors.<br />Review: It is a technique in which the work product is discussed upon by a group of two or more persons and re-examined or revaluated for possible corrections.<br />Walkthrough: It is a technique mostly done on the code developed, where the code is traced manually to monitor the state of the program variables as a way of analyzing the logic. This is Verification portion of Verification and Validation.<br />Vikash Mishra(<br />
  20. 20. Difference between QA,QC and Testing<br />Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.<br />QA is process oriented.<br />As a QA, you question the ambiguous requirements and prepare proper documentation for the projects.<br />All these practices help in preventing bugs/defects from an early stage. <br />Quality Assurance makes sure you are doing the right things, the right way.<br />Vikash Mishra(<br />
  21. 21. Difference between QA,QC and Testing<br />Quality Control:A set of activities designed to evaluate a developed work product.<br />QC is product oriented.<br />QC implements the process developed by QA team.<br />QC activities focus on finding defects in specific deliverables - e.g., are the defined requirements the right requirements.<br />Quality Control makes sure the results of what you've done are what you expected.<br />Vikash Mishra(<br />
  22. 22. Difference between QA,QC and Testing<br />Testing: The process of executing a system with the intent of finding defect.<br />Testing is product oriented and thus is in the QC domain. <br />Testing for quality isn't assuring quality, it's controlling it.<br />Vikash Mishra(<br />
  23. 23. Thank You<br />VikashMishra<br />Email:<br />Twitter:<br />VikashMishra(<br />