100% Job Oriented Instructor Led Face2Face True Live online + Cloud Test Lab =

1. H 2 K I N F O S Y S S O F T W A R E T R A I N I N G 100% Job Oriented Instructor Led Face2Face True Live online + Cloud Test Lab = Better than on site training Trusted by many students world wide. 100% Job Oriented Instructor Led Face2Face True Live online + Cloud Test Lab = Better than on site training Trusted by many students world wide. Attend Classes from Any part of the world North America - South America - Europe - Africa - Asia - Australia Attend Classes from Any part of the world North America - South America - Europe - Africa - Asia - Australia www.H2KINFOSYS.com USA - +1-(770)-777-1269 , UK - (020) 3371 7615 Training@H2KInfosys.com / H2KInfosys@Gmail.com

2. QA :: AGENDA Testing Levels • Static Testing • Dynamic Testing • Unit testing • Integration testing • System Testing • UAT testing : Alpha & Beta Testing

3. QA :: AGENDA Types of Testing: • Black box testing • White box testing • Functional testing, • Regression Test, • Exploratory testing

4. QA :: AGENDA Types of Testing: • Smoke Testing, • Sanity Testing • Browser compatibility Testing, • External Interface Testing • Security Testing, • Cross browser testing,

5. QA :: AGENDA Types of Testing: • Manual Testing, • Automation Testing • Performance Testing.

6. Software Testing Levels Software Testing Levels: • Static • Informal review, Inspection, Walkthrough • Dynamic • Unit, Integration, System, UAT

7. STATIC Testing • Code is not executed • Manual review of code, documents to find the errors. • Requirements specifications, design specifications, code, test plans, test specifications, test cases, test scripts, user guides or web pages • Static techniques find causes of failures (defects)

8. STATIC Testing Benefits: • Early defect detection and correction, • Development productivity • Improvements, • Reduced development timescales, • Reduced testing cost and time, lifetime cost • Reductions, fewer defects and improved communication. • Detect Omissions

9. STATIC Testing • No formal process • May take the form of pair programming or a technical lead reviewing designs and code • Results may be documented • Varies in usefulness depending on the reviewers • Main purpose: inexpensive way to get some benefit Types: • Informal • Inspection • Walkthrough

10. STATIC Testing • Led by trained moderator (not the author) • Usually conducted as a peer examination • Defined roles • Includes metrics gathering • Formal process based on rules and checklists • Specified entry and exit criteria for acceptance of the software product • Pre-meeting preparation • Inspection report including list of findings • Formal follow-up process • Optional process improvement components • Optional reader • Main purpose: finding defects Types: • Informal • Inspection • Walkthrough

11. STATIC Testing • Meeting led by author • May take the form of scenarios, dry runs, peer group participation • Open-ended sessions • Optional pre-meeting preparation of reviewers • Optional preparation of a review report including list of findings • Optional scribe (who is not the author) • May vary in practice from quite informal to very formal • Main purposes: learning, gaining understanding, finding defects Types: • Informal • Inspection • Walkthrough

12. DYNAMIC Testing • Code is executed • Code is compiled & run with different inputs and output is checked. • Levels: • Unit testing • Integration testing • System testing • UAT

13. Unit Testing • Unit: Smallest testable unit of code • By programmers/developers

14. integration Testing • The testing done on a group formed by combining individual software modules (units). • Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing. Integration testing follows unit testing and precedes system testing.

15. integration Testing There are different types of Integration Testing, few are listed below: Big Bang: • In this approach, all or most of the developed modules are coupled together to form a complete software system or major part of the system and then used for integration testing. • The Big Bang method is very effective for saving time in the integration testing process. Bottoms Up: • An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. • The process is repeated until the component at the top of the hierarchy is tested. The main advantage of the Bottom up is easy to find bugs. Top-Down: • It is the procedure where the top integrated modules are tested and the branch of the module is testing step by step till end of the related module. In Top down it is easy to find the missing branch link.

16. system Testing Definition: • It is the testing which is performed on the entire system in context to the functional requirements and particularly satisfies all the business workflows and processes of the Application from one end (GUI) of the application to another (db/GUI). • In the production support scenario of an application, most of the testing validation are end-to-end testing which is performed to assure the change/defect which are fixed are working as expected. Benefits: • Assurance of complete testing of the application in the manner it is to be used.

17. UAT What is UAT? • UAT is always a final step before rolling out the application. • Usually the end users who will be using the applications test the application before accepting’ the application Usually the end users who will be using the applications test the application before ‘accepting’ the application. • This type of testing gives the end users the confidence that the application being delivered to them meets their requirements. Type of black box testing. • Focus is on functionality and the usability of application rather than technical aspects. it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment

18. UAT Prerequisites • User Acceptance testing can be done the application is fully developed • Various levels of testing (Unit, Integration and System) are already completed before UAT • As various levels of testing have been completed most of the technical bugs have already been fixed before UAT What to Test • To ensure an effective User Acceptance Testing Test cases are created. • These Test cases can be created using various use cases identified during the • Requirements definition stage. • The Test cases ensure proper coverage of all the scenarios during testing

19. UAT • Done by users by referring to requirement document. Alpha Testing • Performed by customers or potential customers at developing organization’s site Beta Testing • Beta testing, or field-testing, is performed by customers or potential customers at their own locations.

20. White Box & Black box testing • Black box testing • By testing team & users • Development skills are not required • This process is also called as behavioral testing or closed box testing • Eg: System testing and Acceptance testing White box testing • By Developers(Programmers) • Programming skills are required • This process is also called as structural testing or glass box testing • Eg.Unit testing and Integration testing

21. functional Testing • It is testing the actual logic of the application is meant for. • Functional testing covers how well the system executes the functions it is supposed to execute—including user commands, data manipulation, searches and business processes, user screens, and integrations. Functional testing covers the obvious surface type of functions, as well as the back-end operations (such as security and how upgrades affect the system).

22. functional Testing Benefits: • Cost saving in terms of minimizing/nullifying post production defects and malfunctioning of the application. • Reduces the risk of low quality product. • Testing is the only way to determine whether the application will work properly before it is deployed. Challenges: • Required business domain knowledge. • Definition of scope to be tested. • Defined Acceptance Criteria for signoff of functional testing. • Definition of Test Coverage Entry Criteria: • Defects identified during Unit and Integration phases are fixed and closed • System test case documents • Test Coverage matrix • System test environment and System test data in place • It happens after smoke testing Exit Criteria: • Filled up Traceability Matrix • Defects logged are fixed and closed or documented as known issues

23. Re-Testing & regression Testing • Re- testing : After a defect is detected and fixed, the software should be re-tested to confirm that the original defect has been successfully removed. This is called confirmation. • Regression testing: is the repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change(s). These defects may be either in the software being tested, or in another related or unrelated software component. It is performed when the software, or its environment, is changed.

24. regression Testing Benefits: • Regression testing forms a critical part of software test plan, since it assures that the existing functionality of the application is working as expected even after the introduction of the new functionality. Challenges: • Choosing the right set of regression test cases. • Understand and quantify the changes being made to the system/application Entry Criteria: • Unit / Integration test summary report • System Test Report for the cycles executed • Defect report (logged during system testing) • Regression test cases Exit Criteria: • Test execution report • Regression review checklist

25. exploratory Testing • Testing done by tester to understand the software. • Usually without documentation • Helps in test design

26. Initial level testing • Smoke testing • Sanity testing

27. Smoke Testing • Smoke testing is shallow and wide approach for all areas of application without going in deep. • It is a term used to refer the first testing made to provide some assurance that the system/application will not fail. • Smoke test is also referred as ‘‘Build Verification Test’’. The tester "touches" all areas of the application without getting too deep, looking for answers to basic questions like, "Can I launch the test item at all?", "Does it open to a window?", "Do the buttons on the window do things?“

28. Smoke Testing • Benefits: • The most cost effective method for identifying and fixing defects in software. • Most of the critical and show stopper defects could be found with this testing. • Ensuring a pretty stable product is available for further testing. • Reduces the risk of low quality product. • Improves morale. Effective Approach: • Identify the critical business processes and workflow in the application which if broken, tests cannot proceed further. • Collate all tests corresponding to the above point which should also include screen navigation Steps: • Prioritize them based on the complexity of the functionality or business process. • Run the above identified tests based on the schedule provided for smoke testing. Entry Criteria: • In daily build before handing over application to functional testing. Exit Criteria: • If core functionality of application get through in smoke testing

29. SANITY Testing • A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. • A sanity test is usually unscripted. • Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.

30. Manual & automation Testing • Testing the application with human observation is called Manual Testing. • Testing the application using tools is called Automation Testing.

31. Performance Testing • Load – users – testing the performance with diff number of users • Stress – resources – testing the performance with diff number of resources • Volume – data – testing the performance with diff amount of data • Soak – duration – testing the performance with varying users, resources & data under the sustained usage of software

32. Testing • Browser compatibility Testing • Cross browser testing • External Interface Testing/ Inter-system Testing • Security Testing • High Availability testing(application supported by multiple/back-up server)

33. H2K INFOSYS ---------------------- WORLD CLASS SOFTWARE TRAINING FOR EVERYONE - WORLD WIDE ------------------------------ ATTEND CLASSES FROM ANY PART OF THE WORLD -------------------------------------------------- SOFTWARE TRAINING – DEVELOPMENT – TECHNICAL STAFFING SOLUTIONS

34. Thank You www.H2KInfosys.com Attend classes from any part of the world Project Work & Job Placement Assistance Visit H2kinfosys Forums, Jobs and blogs True Live online with Face2Face + Cloud Test Lab = Better than on site training trusted by many of students world wide. Instructor Led – Face2Face – True Live online Software Training classes with Cloud Technology USA - +1-(770)-777-1269 , UK - (020) 3371 7615 Training@H2KInfosys.com