Successfully reported this slideshow.
Your SlideShare is downloading. ×

Testing material (1).docx

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
9/23/2022 Manual Testing
Bharath Goli
Contents
1. SDLC
 Requirement phase
 Analysis phase
 Design phase
 Coding phase
 Testing phase
 Deploy & Maintenance...
SDLC
1. What is SDLC?
A. SDLC stands for Software Development Life Cycle which defines the process how to develop a
qualit...
Advertisement
Advertisement
Advertisement
Advertisement
Loading in …3
×

Check these out next

1 of 23 Ad
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

Testing material (1).docx

  1. 1. 9/23/2022 Manual Testing Bharath Goli
  2. 2. Contents 1. SDLC  Requirement phase  Analysis phase  Design phase  Coding phase  Testing phase  Deploy & Maintenance phase 2. STLC  Stages in STLC o Requirement Analysis o Test Planning o Test case Development o Environment setup o Test Execution o Test Closure  Entry and Exit criteria  Functional testing  Non-functional testing 3. Bug life cycle  Definitions  Flow chart o Defect status  Purpose
  3. 3. SDLC 1. What is SDLC? A. SDLC stands for Software Development Life Cycle which defines the process how to develop a quality software application. Without using this method, we can’t estimate the budget, application release, resources, and requirements to be needed for development. It is a more efficient way to develop software applications. SDLC divides application development into phases and each phase has its process. Stages in SDLC: 1. Requirements phase 2. Analysis phase 3. Design phase 4. Coding phase 5. Testing phase 6. Deploy and Maintenance phase Analysis phase Design phase Requirement phase Deploy & Maintenance phas Testing phase Coding phase
  4. 4. Requirement phase: Aim: Collecting requirements from clients. Involvement: Business Analyst (BA), Engagement manager(EM) Process:  BA is the person who will contact the client in the initial stage and gathers requirement from the client.  Later Engagement manager study the requirements. Suppose he didn’t get clarity on requirements then he will ask respectively team to build a prototype and that prototype will share with client and take clear requirements.  Based on the situation, the Project manager acts like BA takes requirements from the clients.  Prototype: Prototype is a demo model of a product which is used to present in front of clients for their approval and gathering requirements. Engagement manager: An engagement manager is responsible for building a positive relationship with a client after they have signed a contract. They are responsible for solving any issue that a client experiences.  In this phase, all the gathered requirements information will be present in the document. That document will be called a Business Requirement speciation (BRS). After that, they made a few requirement documents based on their convenience. They are 1. FRS: Functional Requirement Specifications 2. CRS: Customer (or) Client Requirement Specifications 3. URS: User Requirement Specifications 4. BRS: Business Requirement Specifications 5. BDD: Business Design Document 6. SRS: Software Requirement Specification
  5. 5. Analysis phase: Aim: Analyzing the requirements which was gathered from client. Involvement: System Analyst (SA), Project Manager(PM), Technical Manager(TM) Process:  Analysis phase is to define and develop the software needs. This process conducted with the help of Software Requirement Specification document also known as SRS document. It includes everything which should be designed and developed during the project life cycle.  Feasibility study: After study the requirements, they are verifying whether it is possible to develop the requirements with available resource, time, budget or not. Tentative planning: In this phase resource planning and time planning will be temporarily done. Technology selection & Environment confirmation: In this phase they select the technology and environment for accomplish those requirements. Law: Can we develop the application as per cyber laws. *Here requirements may be Human resources, software’s, and Hardware’s.  Systems analysts is a person who is thoroughly aware of the system and guides the system development project by giving proper directions. He is an expert having technical and interpersonal skills to carry out development tasks required at each phase.  Project managers are in charge of the planning, scheduling, budgeting, execution, and delivery of software and web projects.  Technical manager generally oversees the development, implementation and maintenance of technological company systems and processes, including troubleshooting any potential issues.
  6. 6. Difference between Project manager and Technical manager: A project manager is normally making sure people carry out their tasks, and manages the timeline of each task finishing in time with the allocated resources etc. Generally technical manager also did the same thing what project manager do but with slight difference, he will understand the technical part, what they are doing and also you can explain to non-technical people. Design phase: Aim: Here system and software design documents are prepared as per the requirement specification document. Involvement:  High level design is done by chief Architect (CA)  Low level design is done by Technical Lead (TL) Process:  Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS - Design Document Specification.  This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product.  A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation.  The chief architect will divide the whole project into modules by drawing some diagrams using unified modeling language (UML).  The Technical lead will divide the modules into sub modules by drawing some diagrams using the same UML. LLD: Ex: DFD-Data Flow Diagram, E-R Diagram, Class Diagram, Object Diagram. Example of UML diagram
  7. 7.  In this phase they will also design GUI part of the application, as well as PSEUDO CODE also developed. Pseudocode is an artificial and informal language that helps programmers develop algorithms. Pseudocode is a "text-based" detail (algorithmic) design tool. Ex: Set total to zero Set grade counter to one While grade counter is less than or equal to ten Input the next grade Add the grade into the total Set the class average to the total divided by ten Print the class average. Coding Phase: Aim: They write code for developing the software product. Involvement: Developers Process:  In this phase, developers start build the entire system by writing code using the chosen programming language. In the coding phase, tasks are divided into units or modules and assigned to the various developers. It is the longest phase of the Software Development Life Cycle process.  They also need to use programming tools like compiler, interpreters, debugger to generate and implement the code.  In this phase, Developer needs to follow certain predefined coding guidelines. Difference between Design and coding phase: In developing they build product which requires coding knowledge, where in design phase requires knowledge around usability and functionality.
  8. 8. Examples of coding standards: 1. Limited use of globals 2. Standard headers for different modules etc. Testing Phase: Aim: To give quality product to the customer. Involvement: Tester Engineer, Test lead, QA manager Process:  This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC.  After receiving the requirements documents, QA manager makes test plan and test engineer develop test cases.  After developing completed they deploy build in the testing environment. The testing team starts testing the functionality of the entire system with the help of test cases.  During testing they find any defects, it will report to the developer. After they fix the bug again it will send it to tester for re-test. This process continues until all the requirements passed. o Here quality means reaching customer requirements. o Build means a finally integrated all modules set .EXE form is called a Build. o Test case is a document which describes step by step procedure of how to test the application.
  9. 9. Deploy & Maintenance phase: Aim: Hand over the quality product to client. Involvement: Delivery manager Process:  The Delivery manager will go to the customers place, install the application into the customers environment and handover the original software to the client.  The final official agreement made between the customer and company is proof document for Delivery.  Once the application is delivered. The customer will start using it, while using if at all they face any problems then that particular problem will be created as tasks.  They will define the process and solves the problem. This process is known as Normal Maintenance.  But some customers may request for continuous Maintenance, in that case a team of members will be continuously working in the client site to take care of their Software. Popular SDLC models 1. Waterfall model 2. Incremental model 3. Spiral model 4. V- model 5. Agile model
  10. 10. STLC 1. What is STLC? A. STLC stands for Software testing life cycle. Software Testing life cycle is a process which is used to test the software application to confirm whether the developed application meets the requirements or not. (Or) Software Testing is a process for identifying errors, bugs, defects, gaps, or any missing requirements as compared to the actual requirements given by the client. STLC is an integral part of the SDLC, but it only deals with testing phases. Stages in STLC 1. Requirement Analysis 2. Test Planning 3. Test case Development 4. Environment Setup 5. Test Execution 6. Test Closure Requirement Analysis:
  11. 11. In this phase test team studies, the requirements from a testing point of view to identify testable requirements and the QA team may interact with various stakeholders to understand requirements in detail. Requirements could be either functional or non-functional. Automation feasibility for the testing project is also done in this stage. Activities in Requirement Phase Testing  Identify types of tests to be performed.  Prepare Requirement Traceability Matrix (RTM).  Identify test environment details where testing is supposed to be carried out.  Automation feasibility analysis (if required). Deliverables of Requirement Phase Testing  Automation feasibility report. (if applicable)  Requirement Traceability Matrix. Below you can see the sample RTM.
  12. 12. Test Planning: In this phase Senior QA manager determines the test plan strategy along with efforts and cost estimates for the project. At the same time resources, test environment, test limitations and the testing schedule are also determined. The Test Plan gets prepared and finalized in the same phase. Test Planning Activities  Preparation of test plan/strategy document for various types of testing  Test tool selection (if applicable)  Test effort estimation  Resource planning and determining roles and responsibilities.  Training requirement Deliverables of Test Planning  Test plan /strategy document.  Effort estimation document. What is an Effort estimation document? Effort estimation is one the core components of project estimation, along with resource estimation and cost estimation. Project estimation is the process of analyzing available data to predict the time, cost, and resources needed to complete a project.
  13. 13. Test Case Development: After understanding the requirements in SRS document tester develops the test cases for individual units. Test Case Development Activities  Create test cases, automation scripts (if applicable)  Review and baseline test cases  Create test data (If Test Environment is available) Deliverables of Test Case Development  Test cases  Test data Below you can see the test case document. This is only for reference. They won’t follow the same format. Test Environment setup: The test environment is a collection of hardware and software, which helps us to execute the test cases.
  14. 14.  The test environment has a software configuration (operating systems), hardware configuration (RAM, Hard Disk, and Processor), and the test console, which help us to execute the test cases.  Test team may not be involved in this activity if the development team provides the test environment. The test team is required to do a readiness check (smoke testing) of the given environment. Test Environment Setup Activities  Setup test Environment and test data  Perform smoke test on the build Deliverables of Test Environment Setup  Environment ready with test data set up  Smoke Test Results. Test Execution phase: Test Execution Phase is carried out by the testers in which testing of the software build is done based on test plans and test cases prepared. The process consists of test script execution and bug reporting. If bugs are reported, then it is reverted back to development team for correction and retesting will be performed. Test Execution Activities  Execute tests as per plan  Document test results, and log defects for failed cases  Map defects to test cases in RTM  Retest the Defect fixes  Track the defects to closure Deliverables of Test Execution  Completed RTM with the execution status  Test cases updated with results  Defect reports. Below you can see the sample bug report for your reference.
  15. 15. Test Closure: Test Closure, which is the last stage of software testing life cycle, is a report that is prepared by the team manager or lead after the completion of software testing process. Test Closure is a document that gives a summary of all the tests conducted during the software development life cycle. It also gives detailed analysis of the bugs removed and error found. Test Closure Activities  Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical Business Objectives, Quality  Prepare Test closure report  Prepare test metrics based on the above parameters.  Test result analysis to find out the defect distribution by type and severity. Deliverables of Test Cycle Closure  Test Closure report  Test metrics Simply, Metric is a unit used for describing an attribute. Metric is a scale for measurement. Software testing metrics are a way to measure and monitor your test activities. More importantly, they give insights into your team's test progress, productivity, and the quality of the system under test. Parameters are freely configurable input values that can be assigned to different test types and used in a variety of ways. They help to define tests by defining test data.
  16. 16. What is Entry and Exit Criteria in Test closure?  Entry Criteria: 1. Test closure has been completed 2. Test results are available 3. Defect logs are available  Exit Criteria: 1. Test Closure report signed off by client What is Entry and Exit Criteria in STLC?  Entry Criteria: Entry Criteria gives the prerequisite items that must be completed before testing can begin.  Exit Criteria: Exit Criteria defines the items that must be completed before testing can be concluded Types of Testing: They are two types of testing. 1. Manual testing 2. Automation testing. Manual Testing: Manual testing is a software testing process in which test cases are executed manually without using any automated tool. All test cases executed by the tester manually according to the end user's perspective. It ensures whether the application is working, as mentioned in the requirement document or not. Automation testing: Automation Testing is the process of using tools, scripts, and software to perform test cases by repeating pre-defined actions.
  17. 17. Types of Software application testing 1. Functional testing 2. Non-functional testing Functional testing: Functional testing is performed by tester to test the functional aspects of a software application. Every function should be tested to verify if the functional requirements are met. There are various types of functional testing. 1. Smoke testing 2. Sanity testing 3. Unit testing 4. Integration testing 5. Re-testing 6. Regression testing 7. UAT etc... Smoke testing: Smoke Testing is a software testing process that determines whether the deployed software build is stable or not. Smoke testing is a confirmation for QA team to proceed with further software testing.
  18. 18. Sanity testing: Sanity Testing is a type of software testing which is usually performed on a stable build to ascertain that bugs have been resolved and there are no new defects introduced due to changes in the code, or functionality of software product. Unit testing: Unit testing involves the testing of each unit or an individual component of the software application. It is the first level of functional testing. Integration testing: Integration testing is used to check the data flow between the combined modules. It is the second level of testing. Retesting: Retesting is a type of testing which is used to check that the previous failed functionality is working as per requirements after bug fixed by developer.
  19. 19. Regression testing: Regression testing is a type of testing which is used to check whether the existing functionality remains same or not after modifies the code. User Acceptance testing: UAT is a type of testing which can be performed by the end-user or the client to verify/accept the software system before moving the software app to the production environment. Non-Functional Testing: Non-functional testing is done to test the performance, security, and usability of the application. This testing helps to improve the quality of the application. Non-functional testing is performed using certain tools and not done manually. 1. Performance testing 2. Scalability testing 3. Recovery testing 4. Security testing 5. Compatibility testing 6. Configuration testing 7. Configuration testing 8. Soak testing etc... Performance testing: Performance testing is a type of software testing which is used to check that the software application performs properly under their expected workload. Scalability testing: Scalability testing is a type of load testing that tests how the system is going tp perform during a sudden spike or fall of users. Recovery testing: It is a type of testing where the testers will test the application to check how well the software application recovers from disasters or crashes.
  20. 20. Security testing: It is a type of testing that uncovers vulnerabilities, threats, risks in a software application and prevents malicious attacks from intruders. Compatibility testing: It is a type of testing to check whether your software is capable of running on different hardware, operating system, network environments or mobile devices. Bug life cycle 1.Definitions 1. What is Error? A. A mistake in code found by the developer while developing the application, then it is called an Error. 2. What is Defect? A. If the tester finds any deviations in functionality while testing the application, then it is called a Defect. 3. What is Bug? A. A defect is accepted by the developer, then it is called a Bug. What is Defect Life Cycle? Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that defect or bug goes through in its entire life. The purpose of Defect life cycle is to easily coordinate and communicate status of defect which changes to various assignees and make the defect fixing process systematic and efficient.
  21. 21. 2.Flow Chart:  Bug life cycle Fail Pass NEW ASSIGN DEFERRED OPEN FIXED TEST CLOSED DUPLICATE REJECTED REOPENED AS PER DESIGN
  22. 22. Defect Status: Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or bug in order to better track and understand the actual progress of the defect life cycle. New: If the tester finds any new deviation while testing the application, then the tester reports the bug to the Team lead/Project Manager and creates a status “New”. Assign: The team lead/Project Manager validates the deviation which was submitted by the tester. If the deviation is valid then they will assign that bug to the development lead or respective developer and change the status to “Assign” otherwise he rejects the deviation. If Bug is accepted by the Development lead, then he will assign that bug to the associate developer. Open: If the developer accepts the deviation, then it will be treated as Bug, and he/she will change the status to “Open”. Fixed: After Bug fixed by the developer then he will change the status to “Fixed”. Test: Here testers test the fixed deviation, for knowing if it is fixed or not. If it is fixed, then he/she will change the status to “Closed”, other he/she will move the status to “Reopen”. Reopened: If a bug is not working properly after rectification, then the tester will change the status to “Reopen”. Closed: After the tester confirms that the bug was fixed then the tester will change the Status to “Closed”. Deferred: If the developer accepts the defect and wants to rectify it later then he/she will change the status to “Deferred”. Rejected: If the Development lead/developer doesn’t accept the defect, then they will change the status to “Rejected”.
  23. 23. As Per Design: If the tester raised a defect without knowing the latest requirements, then the developer lead/ developer will change the status to “As Per Design”. Duplicate: If the developer/ Development lead finds the defect is repeated, then they will change the status to “Duplicate”. 3.Purpose 1. Why do we use the Defect life cycle? A. The main intention is to easily coordinate and communicate the status of the defect and the process of defect fixing to make it efficient.

×