MANUAL TESTING By DURGASOFT
Durgasoft
SOFTWARE SOFTWARE TESTING It is the process of checking any software application is meeting all the customer requirements or not
QUALITY When we have reached validating all the requirements and found application is defect free then we can say project or product is quality. PROJECT Any software application is developed based on the single customer requirement then we can say it is a project. Ex: ICICI Application, Stitching Shirt
PRODUCT Any software application is developing based on the software industry requirement then we can say it is a product. Ex: Windows XP XP,, GMAIL
Durgasoft
QUALITY ASSURANCE It is the process of verifying all the standards and processes of company for giving right product to the customer cu stomer.. We are going to verify are we building the right product or not. QUALITY CONTROL It is the process of validating the application, based on the requirements and verify are we building the product right or not.
VERIFICATION It is a technique in quality assurance and we will verify the process for delivering the right product to the customer cu stomer.. VALIDATION It is a technique under quality control, here we will do the actual testing for delivering quality software to the customer. Durgasoft
SOFTWARE DEVELOPMENT LIFE CYCLE SDLC is divided into 6 phases for developing any software , we have to choose one of the process for successfully delivering quality product to the customer. The phases as follows: Requirement Analysis Design Coding Testing Delivery and Maintenance
REQUIREMENT Participant: Business Analyst, PM, Technical Lead, Development Lead Process: Based on the appointment date given by the client along with project manager, development lead, technical lead( all are optional ) along with business analyst will go to the client location and gather all the requirements of a customer. After gathering the requirements from the client, they will come back to the company and they will start documenting the requirements which is easily Durgasoft
understandable to all the teams. After that business analyst will share documented requirements to the customer, he will verify all his requirements are covered or documented and he will update to the business analyst if at all any requirements need to updating documented requirements. Once business analyst will get the approval from the client then he will give sign off to the requirement document. Output: SRS - Software requirement specification BRS - Business requirement specification FRS - Functional requirement specification BD - Business document BDD - Business design document
Durgasoft
ANALYSIS PHASE 1. Feasibility Study 2. Selection of Technology and Environment 3. Requirement Analysis 4. Team Building 5. Understanding Document 6. Planning Feasibility Study: As per the budget and time provided by the bidding teams here we are going to cross verify whether we are able to complete entire project by above budget and time. If there discussion demands any changes in the budget or time with the help of business analyst they will take it to the customer. Selection of technology and environment: Project manager will discuss with the architects of development lead for selecting the which technology is suitable for our project along with the environment based on the type of project. Requirement Analysis: project manager , development lead, test lead are going to discuss with the business analyst for understanding of the requirements more clearly, if at all they are having any doubts or queries they are going to ask in this session. Durgasoft
Team Building: Based on the understanding of the requirements in the above analysis phase, they are going to find out how many number of resources are required for both development and testing. Based on the availability of resources they may use from the bench strength or they may recruit from outside. Understanding Document: For understanding all the requirements business analyst is going to provide a requirement sessions to the both development and testing teams.(nearly it will be for 7 to 10 days) Based on the understanding they have to prepare their own understanding document which is going to use for giving reverse knowledge transfer presentation to the client. Planning: With the help of development lead and testing lead, project manager is going to prepare plan and he will send it to the client for approval. Participants: BA, PM, TL, Test Lead, Development Team, Test Team, Architects Output: Understanding Document and Project Plan Durgasoft
Note: requirement query document is the document containing questions of both development and testing people and then either development or test lead are going to share this document to business analyst for update.
DESIGN PHASE: Participants: Architects Process: Based on the understanding of the requirements architects will prepare the design documents which are going to use for developing the GUI part of the application along with understanding of the application flow. Output: 1. Design document a) High level design document b) Low level design document Note: unified modelling language is used for creating the diagrams, flow charts with the effective manner and easily understanding to the all team members. Durgasoft
CODING PHASE Participants: development team Process: Developing the programming statements Output: Programming statements (build) Note: it is a part of software containing some features and deliver to the testing team for verifying the application functionality SRN – Software/Service Release Note
TESTING PHASE 1. 2. 3. 4. 5. 6.
Test Plan Test Scenario and test cases Test Case execution Results analysis Bug Tracking Reporting
Durgasoft
Testing is the process for ensuring quality of the software and update to the client on periodic basis about status of this software application. Test Plan: It is a document containing all the project activities under testing. This document will tell us when and what need to do by the testing team. Based on this document we are going to start activities accordingly. Test Scenarios: Usecases: Usecases are having diagram representation of actors, actions involved as per the requirements(Architechs will prepare these diagrams). Scenarios: These are high level verification points or high level ways of testing the entire application. We need to derive test scenarios from requirements document and knowledge of all the requirements.
Durgasoft
Test Cases: These are low level verification points which we need to derive from test scenarios. There is no mandatory need to derive few test cases. We can derive any number of test cases based on the requirements. Test cases having unique id, test steps, description, expected results, actual results, comment section which will allow us to easily understand what we need to verify in our application.
Test Case Execution: Here we are going to validate all the low level verification points and going to justify what is the quality of part or entire application. Based on this if at all any test cases not meeting expected result then we have to update issue to the development team. Once development team fix above raised issues, then they will update to the testing team so that we need to test again same feature whether it is working according to the requirements or not.
Durgasoft
Status Reports: Based on the above test case execution, we need to update to the client through daily status reports for the update daily activities and weekly status reports for the update of week activities. Based on these reports client will understand what is the stability of the part or entire application. 100% Quality Software: Based on the test case execution and if we have done with all the test cases and there is no more number of defects opened then we can deliver 100% quality software to the client and if we are able to do all these activities as per the test plan then we can say we are giving quality software to the client in on time and on budget. Delivery and Maintenance Phase: Delivery: Whenever testing phase is completed, it means all the test cases need to execute by the testing team and there are no open defects with the development team then we are going to deliver quality software to the client. Based on the client, with the help of his own team going to deploy it in real time environment so that it can be used by the end users. Durgasoft
Maintenance: Whenever end users keep on working on our software, when they get any issues which leads to stop their business then with the help of client or vendors they are going to post those all issues to the specific development team for fixing. The same process will continue number of years as per mentioned in SOW(Statement of Work).
Durgasoft
Testing methodology The number of methods of testing we used to do for getting quality on entire application to find whether it is working according to the requirements or not. There are 4 different methods we can use for ensuring application quality. 1. Static Testing a. Review b. Walk-through c. Inspection 2. White Box 3. Black Box 4. Grey Box 1. Static Testing: It is the type of testing done by the people who are having 100% knowledge on entire project requirements. Here we are going to check entire process and documentation as per the company standards and process.
Durgasoft
Review: It is type of verification technique to check something is as per the requirements, whether it is prepared according to the all the standards or not. It is informal meeting and there is no prior intimation to the team members. Review are divided into 2 types 1. Peer Review 2. Lead Review Peer Review: This is the review done by the same designation people, will update us any enhancements on the same document. Lead review: This is the review done by all the test leads, he will go through the all the team members documents and will update whether we are on right track to deliver the right product to the client. Walk-through: It is more formal than review, here we are going to discuss about specific document (requirements, test scenarios, test cases, test case results, defects ) whether these all are according to the client requirements are not, we are going to verify. Moderator will be sending a clear note to the members who are required with prior intimation. Durgasoft
Inspection: It is more formal then walk-through, separate quality assurance(QA) team is going to inspect our standards and processes, whether we are following or not. If at all they found anything not following by the company standards it should be escalated to the higher management. Ex: 1) Maintaining documents in configuration management tool 2) Using the company standard format for all documentations. 3) Sending the daily and weekly status reports to the client ( as per the discussion with the client) These all process verification will be handled by auditing department (QA Team) White Box Testing: It is type of testing done by the development team for restricting number of defects moving from development phase to testing phase. Development team will cross check or do testing through programming source code and if at all they find any issues they will update or for those all and updated software will be delivered to the testing team.
Durgasoft
Black Box Testing: It is a type of testing done by all the testing team through application GUI based on the client requirements, they are able to find application is working according to the given requirements. Before getting the software for testing team will prepare the test scenarios, test cases and perform the execution so that they are able to justify whether it is working according to the requirements or not. Grey Box Testing: It is type of testing done by the team who are having knowledge on both programming (developing the source code) and how to test the application (writing test scenarios, test cases and execution). Earlier days grey box testing will be done by the development team due to budget saving with that process they could not able to deliver the quality projects to the customers hence they are maintaining separate testing team.
Durgasoft
Testing Levels Software development life cycle(SDLC), once software is developed by the development team is giving to deliver to the testing team then we have to perform below levels of testing for ensuring 100% quality for his project/product. 1. 2. 3. 4. 5. 6.
Module Level Testing Integration Level Testing System Level Testing User Acceptance Testing Pre-production Testing Production or Production validating Testing
Module Level Testing: Based on the features or functionality developed in the number of builds, testing team have to test all these features or functionalities individually, they have to ensure each feature or functionality or collection of features working according to the client requirements. Module: It contains collection of features and we are able to perform one specific Operation or activity. In this level of testing we are going to get quality on all modules individually. Durgasoft
Integration Level Testing: Once module testing is done, we are going to verify interrelations between individual modules whether data is passing from one module to another modules or not. Here we will test all the modules integration and ensure entire application is integrated very well.
System Level Testing: Testing team is going to test entire application end-to-end and they have to ensure all the requirements are covered and working according to the client expectations. We are going to test entire system on multiple browsers and multiple operating systems and we have to ensure entire system is working according to the client requirements. Note: System testing justifies whether we are able to deliver quality product to the client and when we can deliver. User Acceptance Testing (UAT): It is a type of testing done by the client side testing team to ensure one more time whether all functionalities are covered and those all are working according to the client requirements. UAT team will perform End-to-End testing in front of the client at offshore location is called alpha testing. Here they will KRISHNA ensure entire system functionality VENKATA
Developed software will be taken to the client location or on-site location and application will be tested in this location with the help of installation engineers (Deployment engineers) and they will continue one more round of testing for ensuring application quality and stability in his location. This type of testing is beta testing. Pre-production Testing: It is a type of testing done by the client side team to ensure system is working and stable in the production simulated environment. It will be similar to the production testing but before going to deploy it in production, we will create duplicate environment to the production and we will ensure application is stable. Production Testing: It is a type of testing done on real time environment or live environment, along with the end users, client side testing team will perform End-to-End testing to ensure everything is working according to the client expectations.
Durgasoft
White Box Testing Level Before application is delivered to the testing team, development team will perform few types of testing's for restricting number of defects moving from development phase to testing phase. 1. Unit Testing 2. Integration Level Testing Unit Testing: It is a type of testing done by the development team by checking every piece of code and ensure every unit is working according to the requirements. Technical Integration Level Testing: It is a type of testing done by the development team through source code for checking inter relations between multiple modules whether those are working or inter relations are happening or not. Development team will follow few types of integration levels for integrating multiple modules. Top Down Approach Bottom Up Approach Hybrid Approach
Durgasoft
Top Down Approach: Started developing modules or features from high priority to low priority or from parent to child and integrated accordingly. Here integration will be happened from top to bottom till end of all the parent and child modules.
Parent1
Parent1
Child1
Child2
Parent1
Child3
Child n
Bottom Up Approach: Development team will start developing from low priority or child module to high priority or parent module and integrated accordingly from bottom to top till end of all the parent and child modules Durgasoft
Parent1
Parent1
Child1
Parent1
Child2
Child3
Hybrid Approach: It is a type of approach covers combination of both top down and bottom up approaches. The way development team is comfortable for developing either parent or child, they will integrate both the ways till end of all the parent and child modules. Parent1 Parent1
Child1
Child2
Parent1
Durgasoft
Child3
Stub and Driver: It is a temporary program developed by the development team for replacing the
mandatory module which is required for testing people to test all the integrated modules. It will work as a normal behavior and based on the SRN document. We have to find what
are all the features or functionalities this temporary program is going to provide. If it is a top down approach integration, then we are calling this temporary program as
stub. If it is a bottom up approach integration, then we are calling this temporary program as
driver.
Durgasoft
SDLC Models Waterfall Model: Requirement
Analysis
Design
Coding
Testing
Delivery & Maintenance
Durgasoft
In waterfall model all the phases will move from top to bottom and should not go bottom
to up. Once completion of each phase then only we are moving to the next phase. How the water falls from top to bottom, in the same manner this model going to work from requirements to delivery and maintenance phase.
Advantages: For any project if all the requirements are stable, then this is the suitable model to deliver quality product. Minimal budget is required for the project if requirement are stable. Drawbacks: It will not allow moving from bottom to up when there is a change in requirement then again we have to start from requirement phase. Verification technique will not be available so that we cannot ensure everything is happening in each phase according to the requirement. Hence all the issues leads to find in testing phase For any project which are having unstable requirements, it is not at all suitable, if we continue then it will become a deliver quality product in unexpected time and lot of budget required.
Durgasoft
Spiral Model: This model is going to overcome few of the disadvantages getting in the waterfall model. In this model we will deliver entire project in multiple cycles and we are going to deliver few of the requirements in each cycle so that in ‘n’ number of cycles we will deliver entire project. If at all client asked us to change or update any of the requirements, we should need to incorporate and continue with the next cycle. Advantages: High visibility will be there for client on his product or project. For every cycle client will be receive some part of the application based on that client may give feedback to the company for updating or changing the any of the features. Risk management will be handled properly for each cycle, it will allow us to deliver in ontime, if at all we did not get any major changes from the client. Drawbacks: Defect identification will be happen only in the testing phase. More time consuming. More budget is required.
Durgasoft
n Requirement
Analysis 1
Testing Designing Coding
Prototype Model: Based on the requirements received from the client company is going to start
preparing prototype by covering all the requirements. Company will share the same to the client for approval. If at all client reviewed and updated few more changes then we have to update our prototype and share it with the client. This process will continue till either acceptance or rejection of the prototype. Durgasoft
If the client rejected the prototype then we have to stop our work on it. If at all he accepted the prototype then we have to kick start with the actual work on it.
Advantages: Client visibility will be more. Scope of getting the projects from the client will be more based on the client satisfaction on prototype. Requirement
Analysis
Prototype Send
Client Accept
Not Accept
Waterfall model
Stop Durgasoft
Drawbacks: The prototype cost will be taken care by the company, if at all client rejects the Prototype, company is going to loose entire cost spent on prototype. Mistake done in requirement, analysis, design, coding are going to find in testing phase, due to this we may deliver in ontime or not.
V – V MODEL We can also call it as a verification and validation model. By using verification in all the phases we are going to verify all the documents and
standards whether we are on right track to deliver right product to the customer. Testing team involvement will be there right from starting of the project. Parallely to all the phases we will involve and we will design various scenarios and test cases. Once we get the build from development team we need to use designed test cases and go ahead with test case execution.
Durgasoft
Verification
Validation
Requirement
UAT
Analysis
System Testing
Designing
Integration Testing
Coding
Unit Testing
Advantages: With the verification we can cross check in every phase whether we are on right track as
per the requirement. Testing team will be involving from start, any deviations to the requirements they can identify in the earlier stage. We can assure quality product or project deliver to the client in ontime and onbudget. Durgasoft
Disadvantages: Stable requirements are required to continue this model. More budget is required due to maintaining testing team from beginning of the
project.
AGILE MODEL For any projects/products which are not having stable requirements then they have to
approach agile model as it is most suitable and more visibility to the client on daily basis. Scrum master is the person who is going to manage all the testing and development
activities on daily basis, he will monitor and ensure every thing is going on as per the sprint time lines. Product owner is the person from client side and he will cross check all the activities
from both development and testing team are working according to the client requirements.
Durgasoft
All the requirements are splited into stories by the scrum master and he will derive tasks from the stories based on the priority to the client and depends on the time lines given by the team(Estimations) and he will include all those tasks into that sprint and according teams needs to work. Usually sprint duration will be nearly 2-3 weeks. This process will continue till end of all the stories given by the client. Coding
Scrum Meeting
Testing
Design
Sprint Delivery
Project requirements
Divide
Stories (scrum masters)
Analysis
High priority
Tasks
Enhancements Defects Durgasoft
Sprint Demo
Testing
Scrum Meeting/Daily Stand up meetings: This is the meeting conducted by the scrum masters with development and testing teams for tracking the project/product development activities. If at all anybody struck with any issues they can update those issues and resolutions will be found in this meeting. Here every body need to update tasks covered on that day and planning of tomorrow and regarding the issues. Advantages High visibility will be there to the client On daily basis client will check this product or project features if at all he found to
change any thing then immediately he can update to the scrum master so that development teams will try to change those feature instantly in coming sprints. It wont take more time for the development and testing activities.
Disadvantages Poor documentation will be there Both development and testing team will be allocated with some tasks. So that teams
feels more busy with work.
Durgasoft
TYPES OF ENVIRONMENTS The place or area where we are going to develop the application or accessing the application is called environment. Four types of environment will be there 1. 2. 3. 4.
Standalone environment or 1-tier architecture Client-server environment or 2-tier architecture Web environment or 3-tier architecture Distributed environment or n-tier architecture
1. Standalone Environment: Any application or software is installing or using in single system for personal usage
then that environment is called standalone environment. We cannot access the data from other systems because it will be limited to specific system. PL BL DL Durgasoft
2. Client Server Environment: The application or software which we are able to access in the specific area or
limited environment is called client server environment. We are making one system as a server and installing the application after that it will allow us to access the application from the server Ex: companies internal sites, siri technologies SERVER
SYSTEM
DL PL BL 3. Web Environment: Any application or software which we are able to access from world wide web that environment is called web environment. Application will be displayed into the server and it will be linked with the internet by making or giving a URL based on that we can access the application by using the same URL in the internet. Durgasoft
SERVER
SERVER
CLIENT
DL
BL
PL
4. Distributed Environment: Any application or software is installing or deploying into the server system in multiple locations using many business logic layers and database layers is called distributed environment. In this environment even though load is getting increased and though one or more servers will be down, then automatically requests will connect to the other business logic layers and database layers and it will give the response. Ex: Gmail application, Google SERVER
SERVER
CLIENT
DBL DBL DBL
BL BL BL
PL PL PL
Durgasoft
TYPES OF TESTING
1. Smoke Testing 2. Sanity Testing 3. Retesting 4. Regression Testing 5. Compatibility Testing 6. Performance Testing 7. Install/Uninstall Testing 8. Adhoc Testing 9. Usability Testing 10. Security Testing 11. Functional Testing 12. GUI Testing 13. End to End Testing 14. Recovery Testing
Durgasoft
1. Smoke Testing It is type of testing conducted by the testing team for checking build stability whether
it is meeting the acceptance criteria or not In this testing we are going to verify all the basic functionalities are working or not
based on this we will accept or reject the build. In smoke testing, atleast 70-80% of the basic functionalities should work, then only we
can say that it meets the acceptance criteria, accordingly our test lead will send a mail to development lead saying that we are accepting the build for major testing. If build is not meeting the acceptance criteria then our test lead will send a mail to
development lead saying that rejecting the build by specifying what all the features are not working. Usually smoke testing will be done in 2-3 hours, but based on the company, it may
vary.
Durgasoft
2. Sanity Testing: It is used for finding the build stability for accepting the build for major testing by executing all the basic functionalities related test cases and next level major test cases. If it meets acceptance criteria, then we will accept the build for major testing. 3. Retesting: It is first type of testing after smoke testing, whenever we have started our test case execution, then it there will be a chance for finding deviations in our application, then we have to update, these deviations or issues or bugs or defects to the development team. Development team will cross check all the deviations and they will fix these all issues and sending back to the testing team for testing again to find whether fixed deviations are working according to the requirements are not. This type of testing is called retesting. 4. Regression Testing: It is type of testing used for finding the stability of the entire application. This is used for finding the impacted features due to the fixing of the defects or addition of the new features. Durgasoft
With these above two cases we are having chance of getting impacted, with this existing functionalities will not work even though changed feature or added feature are working. After retesting we have to do the regression testing ex: car repair of head lights 5. Compatibility Testing: This type of testing comes under system level testing. Here we are going to check entire application is supporting multiple software, hardware, browsers. Compatibility will give us result our application is supporting all the browsers, operating system, environments, based on the client request. Note: what are all the environments we have to check in the compatibility given by the client.
Durgasoft
6. Performance Testing: It is used for finding the application response time based on the multiple sets of load putting on the application. Application is giving response in less time with multiple set of loads then we can say application performance is very high and it will be satisfactory to the customers. If at all application is taking more time for giving the response then we can say application performance is very poor. Performance testing is combination of 1. Load testing 2. Stress testing Load Testing: By giving the multiple set of loads, analyzing the performance time or response time is called load testing. Here in this testing we are going to find application response times for the different level of loads. Stress Testing: By giving different set of loads continuously for some time, we are going to find application stability and where it is getting crashed will be analyzed in the stress testing. Durgasoft
If at all they find peak level of load for the application is bearing, then they have to follow
some other ways to overcome the same. Note: for the application which are used by the number of customers or end users globally then they have to concentrate more on performance testing for giving high satisfaction to the customers or end users. 7. Install/Uninstall Testing: Install Testing: Here in this section we are going to find how our product is installing properly or not for multiple hardware, software is called installation testing. This testing will be available only for the products which are used in standalone environments Uninstall Testing: If at all we install any product then it is going to create supporting data into our machine by using uninstallation testing we have to ensure supported data is getting removed properly or not.
Durgasoft
8. Adhoc Testing: Due to the lack of time, we could not able to manage the testing activities effectively then adhoc testing will be the testing playing major role. Here we are not maintaining documentation like test scenario, test cases because due to insufficient time. Adhoc testing is the testing done by the experienced testers based on experience they are having understanding on the requirements. Note: adhoc testing will not give 100% quality application but as per the client request we have to do and deliver application to the client. 9. Usability Testing: It is the type of testing for finding the application graphical user interface (GUI) is user friendly or not. Here we have to justify the entire application GUI using client or end user perspective whether it is easily understanding to the end user or not. For doing the usability testing we need to have end user expectation on our application. Durgasoft
Note: UAT team is having high visibility on client or end user expectations then it will be easier for them to do the usability testing. 10. Security Testing: Security is nothing but how effectively protecting the entire application is called security. In this testing we are finding or checking how much application or network is getting protected from unauthorised sources. Majorly we will concentrate on below three types of testings under on security 1. Authentication 2. Network 3. Application URL Authentication: Here we will check whether the application is successfully protecting from unauthorised people when they do some of the miscellaneous actions on it. Network: Here we are having bunch of systems connected to the network, we have to protect the information of entire network , For that we have to use the firewalls for restricting unauthorized sources. Durgasoft
Application URL: Here we are going to check applications security based on the URL, getting the URL from other source and trying to perform other operations . It should restrict for the unauthorized sources, it means should not allow to access the information. 11. Functional Testing: Testing: It is the type of testing for finding application behaviour. By using this testing we can justify whether entire application functionality is working
according to the client requirements or not. By doing some actions or operations on our application, we have to check application
behaviour is according according to the client expectations. expectations. It is divided into 2 types:
1. Functi Functiona onall Posi Positiv tive e Testing esting 2. Functi Functiona onall Nega Negativ tive e Testing esting
Durgasoft
Functional Positive Testing: We are checking functionality of the entire application with positive data or valid Data and we have to justify whether our application is working according to the client expectations. Ex: entering entering valid username, username, password into into gmail login page Functional Negative Testing: By doing some operations or activities activitie s with the negative data or invalid invalid data, we have to find out whether our application is restricting or not. Ex: entering entering invalid invalid data into into gmail login page 12. GUI Testing: We are checking GUI of the application according to the client specifications given in SRS document. Here we will do testing on GUI elements, such as all the elements or controls are properly displaying, alignment is fine or not, Tab Order. Ex: in gmail username, pwd pwd field, login and Cancel buttons buttons are displaying displaying or not. Durgasoft
13. End to End Testing: Testing: It is a type of testing where we can test all the functionalities of entire application to justify every feature is working according to the given client requirement. Based on this testing we can find stability of the entire system with one environment. Note: It is come under System Testing. Combination of End to End Testing and Compatibility testing is called System Testing. 14. Recovery Testing: It is a type of testing used for finding the capability of the application, whenever it is getting crashed whether we are able to recover automatically or not. If at all any application is not getting recovered then we can say it does not have enough quality. Note: For Security Applications, testing team need to concentrate by making forcible application crashes and we have to check whether it is getting automatically recovered or not.
Durgasoft
SOFTWARE TESTING LIFE CYCLE (STLC) In STLC software testing is playing major role for delivering the quality product to the client. We should plan our testing activities accordingly based on the client request. Testing phase is divided into 6 phases: 1. 2. 3. 4. 5. 6.
Test Planning Test Development Test Execution Result Analysis Defect Tracking Reporting
Test Planning: We are going to plan our testing activities for entire project along with scope, staffing, schedule. By including all above test lead is going to prepare test plan document and he will share it to the client for approval. Once we get the approval from the client we are going to start our actual testing activities. Note: test plan is the first deliverable to the client from testing team. Durgasoft
Test Development: Based on the test plan we are going to start writing test scenarios, test cases. We have to complete preparing scenarios and test cases as per the schedule mentioned in our plan. Test Execution: By using test cases, once we get the build from the development team then we have to start performing all these validations to find what are all working and what are all not working. Result Analysis: Based on the test case execution, here we are going to verify the test case results and analyzing the results for finding genuine issues. Defect Tracking: If at all any failed test cases we are going to update all those issues to the development team by using any of the tools like bugzilla, jira, QC, testopia, tfs(Team foundation server) Durgasoft
Reporting: Based on the above phase and test cases results, defect reports, we have to update to the client on stability of the application. We have to report on daily basis, weekly basis, monthly basis based on the client request.
Durgasoft
TEST PLAN Test Plan Contents: 1. Introduction 2. Purpose 3. Scope and Goals 4. Features that are not to be tested 5. Definitions and Abbreviations 6. References 7. Product/Project Architecture 8. Test Environment a) Required Hardware b) Required Software 9. Assumptions 10. Constraints 11. Test Coverage a) Functional Testing b) User Interface Testing c) Performance Testing d) Security Testing e) Recovery Testing f) Compatibility Testing
Durgasoft
12. Test Strategy / Approach 13. Test Deliverables 14. Human Resource Requirement a) Staff Requirement for Testing b) Roles and Responsibilities 15. Test Schedule 16. Readiness Criteria 17. Acceptance Criteria 18. Defect Classification 19. Defect Management 20. Testing Resumption Criteria 21. Tools and Techniques 22. Risk Identification and Contingency Planning 23. Test Case List 24. Test data 25. Traceability Matrix
Durgasoft
1. Introduction: Here we are going to update overview of the test plan document. It will describe basic thing of this document. 2. Purpose: Here in this section we are going to update use of this document more clearly which is understandable to everybody in our project. 3. Scope and Goals: This section having all the features in our scope for testing and what are all goals we have to achieve in time manner.
4. Features that are not to be tested: Here in this section we are having features list which are out of scope. Note: Mainly in security application, the client will give non-security features to the companies and he will take care testing of the security features. 5. Definitions and Abbreviations: Here we are having all the short names and their abbreviations Ex: SIT = System Integration Testing UAT = User Acceptance Testing PVT = Production Validation Testing NA = Not Applicable Durgasoft
6. References: For preparing this document , All required documents list will be given in this section. Ex: SRS, FRD, BRS 7. Product Architecture: Here in this section, we are having entire project or product functionality flow in the single diagram. It will represent overview of entire application. 8. Test Environment: Here we are having environment related data and based on the environment, required hardware and software details will be mentioned in this section.
Required Hardware:
Category • RAM • MONITOR • INTEL
Description • 1GB • 17/19 INCHES
Durgasoft
Required Software:
Category • • • • •
Operating system Ms - Office Bugzilla QC QTP
Description • • • • •
Windows XP 2007 1.6 10.0 11.0
9. Assumptions and Dependences: Here in this section for releasing or delivering the quality product to the customer in ontime, what are all the solutions for the problems and their dependencies will be analyzed and those assumptions will be mentioned. Here assumption means assuming something and hoping deliver the product in ontime. Ex: 1) getting build from the development team in ontime 2) We are going to complete test case execution in ontime. 3) Having all the requirements in SRS and test plan will be accepted by the client. Durgasoft
10. Constraints: Here in this section we are having all the conditions for delivering quality product to the customer. Ex: 1) Some hardware is meeting or not available. 2) Lack of the resources. 11. Test Coverage: Here we will mention what are all the testing types we are going to use in our project will be mentioned here. Functionality Testing User Interface Testing Security Testing Recovery Testing
12. Test Strategy or Approach: Here in this section we will keep how we are going to test the entire application, what are all the testing levels we are following for the project mentioned here. Unit testing Module testing Integration testing System testing User acceptance testing , preproductionDurgasoft testing, production testing
13. Tests Deliverables: Here we will mention what are all the documents or information need to pass to the client in periodic fashion will be mentioned here. Test plan Test scenario Test case Test case execution results Bug report Build stability report Application functionality report 14. Human Resource Requirement: Here in this section, we are having testing team resource names and their responsibilities will be mentioned clearly in this section. Skill Level
Specific Areas for Testing
Effort
Training Required
SI No
Resource Name
Designation
Responsibilites
Durgasoft
15. Test Schedule: Here we will mention clear dates for entire project testing activities more clearly along with who are all responsible for completing the tasks in deadlines will be mentioned here. Based on this schedule testing team will follow and they will start and end their activities accordingly. Levels of testing
Person responsible
Documents and records
Approval authority
To be completed on
Testing strategy
16. Readiness Criteria: Here in this section what are all the requirements needed for continuing with testing after we get the build from the development team will be mentioned here. Ex: SRS document should be signoff from the client. Test plan should be approved from the client Test cases and scenarios should be prepared ontime. Environment should be ready for testing.
Durgasoft
17. Acceptance Criteria: Here in this section we will update customers acceptance condition of entire project, when delivering the project to the customer. Based on the test cases results and defect status. Client will conclude whether we may accept or will give few more enhancements. 18. Defect Classifications: Here we will mention different defect types which we are going to rise in our project. Ex: Critical, high, medium, low 19. Defect Management: Here in this section we are having all the process how we are going to manage our issues or defects in our project. ex: 1) To whom we need to assign the defect either to development lead or development member will be mentioned here. 20. Testing Resumption Criteria: Here in this section we will mention when we are going to resume our testing activities after suspending the build, it will be clearly mentioned in this section.
Durgasoft
21. Tools and Techniques: Here in this section we will update required tools information and required techniques for continuing with testing comfortably. 22. Risk Identification and Contingency Planning: Here in this section we will mention all the possible risks and their solutions clearly mentioned here. Note: Contingency planning means identifying the solution. S No
Risk
Nature of Impact
1
2 resources are not available Work is getting effected
Recreate another 2 resources
2
Build not delivered on time
Test plan should need to be updated
Test plan gets effected
Contingency Planning
23. Test Case List: Here we will mention test case document name, once we have done with test case preparation, test case document name and location should need to update in our test plan document for all the testing team members reference.
Durgasoft
24. Test Data: Here we will mention the data required for testing clearly. 25. Traceability Matrix: Will be discussed in coming classes.
Durgasoft
Test Development: Here in this phase we are developing the test cases by deriving from scenarios which are derived from requirements. Note: Deliverable(Output) from test development phase is test case document. 1. Test Bed: It is type of environment where we are going to work on application is called test bed. 2. Test Scenario: It is high level verification point for testing the application. We can derive scenarios from the client requirement document.
S No
Scenario Id
Scenario description
Requirement document ID
Durgasoft
Expected TC Count
Time Required for TC’s
3. Test Case: It is a low level verification point which we can derive from test scenarios. For testing the application we have to come up with as many number of cases from the requirements for delivering the quality product to the customer. TC Id
Scenario Id
Test PreTest Expected Actual Pass Descrip requisi steps results results / fail tion te
Durgasoft
Comm ents
Positive/ negative
Durgasoft
Requirements: 1. Siri Technologies Functionality 1.1 By entering valid username, password it should allow us to login 1.2 Valid username should contain 5-20 characters and combination is upper case, lower case 1. 3 Valid password should contain 5-10 chars with combination is upper and special chars 2. Graphical user interface of the app 2.1 Siri title should be available along with siri technologies header, username, password, text labels, text fields. 2.2 Ok, cancel buttons 3. Error Messages should be displayed when entered invalid data
Durgasoft
Scenario Types: Scenarios are divided into 4 types GUI Scenario Functional Positive scenario Functional Negative scenario Non-functional Scenario Field level validation scenarios.
Note: 1) Non-functional testing covers security testing, recovery testing, performance testing. 2) Based on the project requirement we are going to cover scenarios for the same. Test Case Types: Test cases are divided into 4 types and we are deriving these cases from the designed scenarios. GUI test cases are derived from GUI scenarios Functional positive test cases are derived from functional positive scenarios Functional negative test cases are derived from functional negative scenarios Non-functional test cases are derived from non-functional scenarios Field level validation test cases derived from Field level validation scenarios. Durgasoft
Test Case Technique: For deciding on the length of the input data we need to use below techniques for finalizing the positive and negative length. If once length is finalized then we can play with type of data with number of combinations with that length. Positive data will be the positive length and having the any type of data as per our requirement. Negative type of data will be the negative length with positive and negative type of data. Boundary Value Analysis: By using this technique we can decide length of the text fields by using 6 combinations min – 1 5-20 chars min 4 min + 1 5 max – 1 6 max 19 max + 1 20 21
Durgasoft
Equivalence class partitioning: By using this technique we can finalize the length of the data for the text field by using 3 values. < min < min & max > max > Error Guessing Technique: By using testing people experience and knowledge, if somebody will work on similar type of projects continuously for long time then there will be a chance for guessing the frequent errors or hidden errors in our application. For all these errors they will prepare corresponding test cases and they will add it into original test case document. Usually test lead or senior test engineer will involve in this technique because they are having sufficient knowledge for guessing the errors. Decision Table: It is a technique used for deriving the regression and integration related test cases. It is a table containing all the functionality names in left and top sections. Whenever any relation between any of the functionalities, for those all functionalities we need to put a mark for identifying those all are interrelated. For regression and integration we can derive the test cases very easily by using this Durgasoft table.
Usually it will be prepared by the persons who are having entire project knowledge, obviously test lead will prepare or in some cases senior test engineers also involve while preparing.
Function 1
Function 2
Function 3
-------- Function N
Function 1 Function 2 Function 3 | | Function N
Test Case Execution: Based on the test plan schedule, we will get the build from the development team then we have to start validating test cases as per the test steps mentioned and based on expected results.
Durgasoft
This process continues till end of all the test cases related to features developed in that build. This process will continues till end of all the features or covered of all the requirements in many numbers of builds, testing people will receive and validate the same. If at all they have validated all the test cases by covering all the requirements, it means test case execution phase is completed. Result Analysis: Based on the execution phase and depend upon the test cases status, here we are going to analyze or cross check test case results. Based on the analysis we will come to know what are all the features are not working. Features which are not working based on the analysis we need to update to the development team. Bug Tracking: Based on the result analysis phase we will finalize or confirm list of issues or bugs or defects. For all those confirmed issues we need to track somewhere by using any of the bug tracking tool.
Durgasoft
Mandatory fields or data required for rising the Bugs: 1. Summary: It is a single line description about the specific defect which is required for understanding the defect in simple manner.
2.Description: It is having some more detailed description about the bug which we can use for understanding the defect more clearly. 3. Steps to Reproduce: Here we are updating all the sequential steps which we required for reproducing the issues by the development team. 4. Project: It is a drop-down field containing all the project names, here we have to select, specific project of us. 5. Module: It is a drop-down list containing all the modules name, here we have to select specific modules related to the defect or issue. Durgasoft
6. Build No: It is a drop down list containing all the build numbers from starting to latest one we have to select latest build number which we are working on currently. It can be found from BRN document. 7. Severity: It will notifies seriousness of the issue based on the issue seriousness or issue complexity. We have to update severity any of the below: Intermediate (Show Stopper or Critical) High Medium Low Based on the severity ,development people will analyze the issue seriousness and based on that they may update the priority on top of tester priority value. 8. Priority: It will notify how much urgently to fix the issue by the development team. Based on the severity given by testing team, they will update their priority. Based on that they will work on fixing the issues in the following order. Intermediate High Medium Low Durgasoft
9. Founded By: Here we need to update the test engineer name who found this issue. It is a drop down list containing all the team members, in those we have to select one. 10. Assigned To: Here we need to update the developer name from the drop down list. Test lead will update the entire team regarding developer names for respective features. 11. Comments: Here we will update any other information required for this issue.
12. Status: It is a drop down list containing different status for the bug or defect and statuses are: ->New ->Open ->Fixed ->Closed ->Reopen ->Reject
Durgasoft
Bug Life Cycle or Defect Life Cycle: In our test case execution, test cases are validating based on the expected results
and actual results from the application, we are analyzing and confirming the test cases passed or failed. Whenever any test case is failed we need to update this deviation to the
development team In the form of bug or defect we will update to the development team. By updating all the mandatory fields required (based on the tool mandatory fields
will change) for rising the bug or defect need to update and saving the issue as it will create unique bug-id along with the status new. Development team will work on all the new issues and if at all they confirm the same
issue is getting reproduced in their environment then they will accept the issue for fixing by changing the status to open. If at all they could not able to reproduce then they may reject the bug by changing
the status to reject by updating with proper comments. Durgasoft
Whenever development team will work on all the open issues and if at all they fix
any issues then they will change the status to be fixed. Testing team have to verify all the fixed issues and if at all issued is resolved then we
are going to close the defect by changing the status to closed. If at all any issue is fails in retesting then again we need to update it to the
development team by making the status reopen. Based on the comments entered for rejecting the bugs we need to cross check one
more time in the functionality and confirms everything is working then we have to close the defect by making the status to closed. Even though some of the closed issues may get reopened while doing regression
testing whenever any new features are added or any defects are fixed.
Durgasoft
New
Reject
Dev verify
Not accept
Accept
Test verify
Open/Reopen Fixed
Fixed
Testing team verify
Not working
Work Work
Closed
Durgasoft
Bug Life Cycle
Reporting: We will send multiple status of application in many builds to the client in periodic manner for updating the status of the application. These reports include daily status, weekly status, monthly status and project status report. 1. Daily Status Report: This is the report we are sending everyday to the client for updating on the activities covered on the same day. It will be prepared and send by the team lead. 2. Weekly Status Report: It is a report containing all the activities done in that week. Here we will update tasks like test cases and scenarios writing, test case execution, test results are mentioned clearly and update to the client. 3. Monthly Status: It is a report containing activities done in that month will be mentioned clearly along with clear explanation on tasks covered. It will notifies to the client that activities covered by the testing team in that month.
Durgasoft
4. Project Closure report: It is a report containing stability of the entire application. We will mention clearly number of test cases executed , number of bugs found, based on that client will analyze stability of the application at that time. Based on the analysis he may update or talk with the project manager regarding the application status. If client satisfied, we will deliver project or product to client and he will continue next level of testing. Build 1 10
Testing
Build 2 10 + 10
regression
FT Testing
Build 3 20 + 10
Build n 100 FT
regression Testing
Durgasoft
Bugs Build 1&2 bugs
resolve
Requirement Traceability Matrix: This document is used for tracking the requirements for checking the scenarios and test cases coverage. Defaultly, this matrix is having columns requirement id, scenario id and test case id. Requirement id will be updated by the test lead and he will share this document to the entire testing team for updating the scenario ids and test case ids. Once entire team is updated with their scenario ids and test case ids, test lead is going to verify every requirement is covered for writing the test case or not. If at all he finds any of the requirements is not covered which means scenario ids and test case ids will be empty for corresponding requirements, then he will assign those requirements to somebody in our team for writing scenarios and test cases. Requirement Id
Scenario Id
Durgasoft
Test Case Id
Test Metrics: The purpose of the metrics is to find the efficiency of the test team & Quality of the application. 1. Test Coverage:This metrics will be used to deside when to stop the testing of a certain feature. If the Test coverage is 100% & If most of the Test cases is pass, Then we can stop the testing. To estimate the testers efficiency by lead or P.M Test Coverage = Total No.of Test cases executed / Total No.of Test cases*100. 2. Remark V/s Defect Ratio:- (Defect V/s Remark Ratio) The result of metrics should be in B/W 80% - 95%. If it is less than 80% we can derive that Test team is not clear with the requirements & If it is more than 95% we can derive that the tester might be interacted with the developer before logging a defect to confirm, Whether the issue is really defect or not. This metrics will be use to find out the efficiency of a tester by Lead or PM Remark to defect ratio = Total No.of Valid defects/ Total No.of Remarks *100
Durgasoft
3. Defects per KLOC (or) Defect Dencity:This metrics is use to estimate the developer efficiency Defects per KLOC = Total No.of Valid defects / KLOC OR Defects per KLOC = Total No.of Valid defects / LOC * 1000 LCL & UCL for this metrics are 5 &7. 4. Defect Severity Index:The purpose of this metrics is to find how stable the application or module. D.S.I = 10*I + 5*H + 3*M + 2*L / I + H + M + L Defect Severity Index on Open defects = <7 Defect Severity Index must be = <5 5. Bad fix Ratio :To define the developer efficiency, & it will calculation at the end of the project for each developer. Bad fix Ratio = Total No.of reopened defects / Total No.of Fixed defects * 100 It should not be more than 10%
Durgasoft
6. Effort Variance :- For hours Schedule Variance:- For Days This metrics purpose is to define the stability of a PM EX:Given time to complete the project is 1000 hrs , Then the acceptable time should be B/W 950 to 1050 hrs Effort variance 950 to 1050 days Schedule variance Effort Variance :- Actual Time / Estimated Time * 100 Schedule Variance :- Actual Days / Estimated Days * 100
Durgasoft
Software process: A Sequence of steps followed for getting quality on documentation and on Project/project. A set of predefined activities should follow by every project team for ensuring quality and deliver the project in on time with quality. If at all we are not following process: a) Not able to reach project deadlines b) May not able to maintain Quality e) More rework is required f) Client may not able to satisfy with the quality g) More resources are required h) More gaps will identify in end of the project in testing phase due to the gaps in documentation. Benefits Of Process: a) 100% Quality b) Defect Prevention c) Reduce the project cost d) Reduce the no of resources e) Assurance on project quality to Client f) Client satisfaction will be very high
Durgasoft
What is Process model: A model is contains collection of processes used for getting quality in all areas of the project such as documentation and functionalities of project. SEI (Software Engineering Institute) was developed Capability Maturity Models(CMM) model and This will certifies the companies in various levels based on processes follow and implementing in the Organization. CMMI(Capability Maturity Model integration)replaces CMM in now a days and it is developed by the same SEI. It is a model of 5 levels of process and SEI will determine the companies based on standards followed in the Organizations.
Durgasoft
Capability Maturity Models:1)Performed 2)Managed 3)Defined 4)Quantitatively Managed 5)Optimizing Process Areas by Maturity Levels: 1) Performed – Overview: Introduction Structure of the model Maturity Levels, Common Features Understanding the Model Using the Model
VENKATA KRISHNA
2) Managed - Basic Project Management Key Process Areas: Requirement Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and product quality Assurance Configuration Management 3. Defined – Process Standardization:Key Process Areas: Requirement Development Technical Solution Product Integration Verification Validation Organizational process Focus Organizational Process Definition Integrated project management Organizational Training Risk Management Durgasoft
4) Quantitatively Managed: Key Process Areas: Organizational process performance Quantitative project management Metrics are used to track productivity processes and products projects is predictable and quality is consistently high.
5) Optimizing – Continuous process improvements : Key process Areas: Organizational Innovation and Development Innovating the new standards and updating the same to CMMI
Durgasoft
QUALITY CENTER Quality center is divided into 2 sections those are: 1. Site Administration 2. Quality Center Site Administration: By using this component we can manage the administration part for quality center. We can manage activities like Creating domain Creating projects Creating users Assigning user to the projects Creating domain: Based on the client requirements they may mention ‘n’ number of domains in the single tool then we need to create those domains by using the option under site administration login Site project create domain Site project delete domain Durgasoft
Creating projects: Based on the client requirements we can create ‘n’ number of projects under each domain. We have to provide unique project name while creating Site administration login Site projects create project Site projects delete project Site projects rename project
Creating User: Based on the requirements we need to create ‘n’ number of users under each project under specific domain. Site Administration Site User New User Site User Delete User Site User password
Durgasoft
Assigning the user to the project: By using create users we can assign it to the existing projects. One user can be assigned to ‘n’ number of projects. While logging into the quality center it should need to display all the assigned domains in the assigned drop down list and all the assigned projects under project drop down list. Site projects project users add user from the users list
Quality Center: It is a test management tool provided by the Hp. By using this tool we can manage our
testing activities effectively from starting to ending. By using this we can store all the project related documents related to testing will be maintained as a central repository and it will allow us to access the data parallely by team members. We can store requirements, test cases, test case results, defects or bugs. It will allow us to generate user friendly reports for our test case execution or defect details.
Durgasoft
Quality center is divided into majorly 4 modules related to testing those are: 1. Requirement 2. Test Plan 3. Test Lab 4. Defects 1. Requirements: It is used for storing all the requirements documents in the necessary hierarchy. It will allow us to create ‘n’ number of parent and child requirements and we can associate or attach requirements documents for the same. The options in this phase are New Requirement: used for creating new parent requirements New Child Requirements: used for creating child requirements Delete: used for deleting either existing parent or child requirement. Whenever we have created any requirement, then quality center will generate requirement id automatically. Ex: RQ0001 and RQ0002 Durgasoft
Test Plan: It is used for maintaining all our test cases documents in the necessary hierarchy by creating number of folders and sub folders. We can classify test cases into different sections and we can create test cases under that. For creating test cases mandatory fields are Test Case Description Step Numbers Expected Results Description Author Created of Date and Time
We can update the test case with ‘n’ number of steps.
New Folder: used for creating the folder. New Test Case: used for creating the test case under folder structure. Delete: used for deleting the either test case or folder. Durgasoft
3. Test Lab: It is used for maintaining test case results by linking defects as well for the failed test cases. By using select test option we are able to see all the available test cases in test plan tab then it will allow us to drag test cases from test plan to test lab tab. By using test set option we can maintain similar type of test cases under single name. By using run option we can run the test cases one by one. By using run test set option we can run all the test cases under that test set. It will take care to show the test case step one by one for updating the results. Delete option is used for deleting the folders and test sets.
4. Defects: It is used for maintaining all the issues or bugs found in the test case execution phase.
Durgasoft
By using new defect option we can update all the defect details such as Summary Detected by Severity Detected in version Project Status Detected on date Assigned to Priority Reproducable Subject Description
If at all we want to associate any screen shots for giving better understanding to the developer it will allow us to attach attachments by using attach option.
Durgasoft
Visual Safe Source: It is a configuration management tool. Configuration management is the process for maintaining all our projects documentation with the version control feature. ( version control means, it will maintain ‘n’ number of copies for each document whenever we did only modifications or updation. It is having authentication as it required unique username and password for each member for logging into the VSS. VSS. With this version control we can track track what are all the changes done by the individual team members. The features included in VSS are: Set Working Folder Create Project Check Out Check In Get Latest Version Add File
Durgasoft
Set Working Folder: Once we logged into the VSS by using this option, it will allow us to create working folder which will allow us to upload or download data from the VSS. Create Project: It is used for creating the projects for classifying the data of multiple projects. Check Out: By using this we can download files from the VSS specifically to the working folder. Note: Anybody did check out for any file it is not going to allow to do the check out by anybody else. Check In: This option is used for upload the files from working folder to VSS. It will be enabled for any file after we do the check out. Get Latest Version: It is used for fetching the latest file from the VSS. At a time ‘n’ number of persons can get the latest version from VSS.
Durgasoft
