Uploaded byJulen Mohanty
Requirementless testing
The document features a presentation by Julen C. Mohanty from JP Morgan Chase discussing the challenges and techniques of software testing in scenarios with limited or no documentation. It uses an analogy involving monkeys to illustrate the concept of learned behavior in the absence of established processes. The presentation emphasizes risk-based testing, the importance of understanding business needs, and suggests minimizing documentation while maximizing product coverage.
More Related Content
Similar to Requirementless testing
Requirementless testing
- 1. Name of theSpeaker : Julen C. Mohanty Company Name : JP Morgan Chase & Co.
- 2. BasedlessRequirement Julen C Mohanty JPMorgan Service India Pvt Ltd Testing Wednesday, December 16, 2015
- 3. DISCLAIMERS Any views oropinions showcased in this presentation are solely those of the author and may not necessarily represent those of the JP Morgan Services India Pvt Ltd. This document is meant for use of NextGen Testing or it’s members. Has to be used within NextGen Testing or it’s members and not to be forwarded to anyone outside NextGen Testing or it’s members.
- 4. Concept of"This is how it works" Why there could be no documentation Problems & Risk in Testing without documentation Different Testing Activities in Testing How to test when there is no requirements Techniques to be adopted in testing without documentation Maturity Model INDEX
- 5. Only two thingsare infinite : The Universe and Human Stupidity. And I am not sure about the former. – Albert Einstein Introduction
- 6. Scientists put 5monkeys in a room with a ladder and a bunch of banana on top of the ladder. Concept of “This is how it works”
- 7. Every time anymoney goes up the ladder, the scientists sprayed cold water with rest all monkeys Concept of “This is how it works”
- 8. Due to panicthe money on ladder came down & as soon the monkey came down the water spray was stopped Concept of “This is how it works”
- 9. After sometime, anothermonkey tried to reach the banana and as soon as the money climb the scientists again did spray cold water on rest all moneys. Concept of “This is how it works”
- 10. After a while,every time any money went up the ladder, the other monkeys beat up the one climbing on the ladder. After a while no one of the monkeys dare to go up the ladder, in fear of getting beaten up by rest all. Concept of “This is how it works”
- 11. Introducing Concept of “Thisis how it works”
- 12. Scientists then replacedone money with a new one, which was not part of this group. As expected, the first thing the new monkey did was to climb up the ladder for the bananas. Immediately the other monkeys who were left out, started beating up the new monkey. Concept of “This is how it works”
- 13. The new membertried multiple times to climb up but go beaten by rest all monkey every time he tried. After several beatings, the new member learnt not to climb the ladder, but he never knew WHY..?? Concept of “This is how it works”
- 14. Then another oldmoney was substituted by a new monkey. As soon as the new monkey joined, the tried to climb the ladder, as expected. But as usual, the other monkey started beating the new monkey. This time the 1st new monkey also joined the old monkey in beating the 2nd new monkey. Concept of “This is how it works”
- 15. One by onethe other 3 old monkeys were also replaced by new monkeys. But every time a new money comes, it start to climb the ladder and got beaten by rest all present. Concept of “This is how it works”
- 16. After a whilein the room there were 5 new monkey but no one was climbing the ladder. Even though no one received cold spray, they still continued to beat up any monkey climbing the ladder. Concept of “This is how it works”
- 17. Why were theybeating the other monkey who wanted to climb..??? I DO NOT KNOW, BUT THIS IS HOW IT IS DONE AROUND HERE. Concept of “This is how it works”
- 18. Never Documented RequirementsNo Testing for product No Testing Process No enough time for testing - Experienced & Old team members left the firm - No one thought of necessity of documenting, as client was OK with the development - Very old legacy product where documents were never updated thought out changes done by time - No one could develop a document as all were developers - Document were there but all missing & we can’t find any Reasons for No Document availability
- 19. Problem with Testingwhen No Document availability Testers will take more time to understand the product and many times that’s not factored in plan Testers need time from other resources in the project, which they mayn’t have because of their own tasks Testers has to believe on others for their own version of requirements & Functionalities, which may be tangentially different from the actual requirement/ functionality. Missing functionalities (method gap) detected by testers, which is quite late in the project (SDLC) process. Experiment with requirements or Automation of testing becomes difficult as there is less time for delivery.
- 20. When there isno documentation, you will be testing only the Most common features Most known functionalities Most visible changes Most expected requirements You see this (The Obvious Things) You guess this (Without any Facts) IT’S ACTUALLY THIS Risk in Testing when No Document availability
- 21. Write Stories Develop Stories Test Stories Special Non- functional Tests Acceptance Test Regression Test Business Requirements FinalProduct Testing against User Stories Testing in UAT environment Non Functional Testing / Confirms story is met Unit Testing & Integration Testing Testing Activities
- 22. People who developedthe product People who is/will use the product Who can tell you more about the product you are testing ?? The Technology Development Team The Client Team These people are your customers How the product is Designed to work How the product is Expected to works Phase 1 – Explore What to do Continued..
- 23. Start with RiskBased Testing Most Business Critical Highly used features High Value Low effort to implementation Check For Logged Errors Get the problem modules (80-20 rule) Learn Patter of groups Learn Cluster of defects Learn the system behavior Confirm with Client about the behavior Phase 1 – Explore What to do Continued..
- 24. - Put BestEffort - Perform only if you have time Find Areas how to reduce effort or Increase Value Value Effort Map Effort to Implement BusinessValue HIGH HIGH LOW LOW Low Effort – Low Value Low Effort – High Value High Effort – High Value High Effort – Low Value - Thankless Task - Don’t Pursue - Faster Wins Customer - Low Hanging Fruits Assign these as top priority - Major Project - Pursue with Time Identify how to Increase Value Find Areas to reduce time Top resources should get involved here
- 25. Phase 2 –Learn more about what you test Learn the Business need of the product Check Most Business Critical functions & build story around that Confirm test results with Customer Learn how the users generally use the product Learn Competitive product details What Goes In How it is (Expected to get) processed What (should) come Out Why do we need this product What problem they are trying to solve by using the product Who will use it & How
- 26. Business Facing Technology Facing TechnologyTeamTester BusinessTeamTester ExploratoryTesting Functional Testing Unit Testing Specialty Testing Scenario Testing User Acceptance Testing Business Usability Testing Security Testing Load Testing Performance Testing Unit Testing of modules Business Functions Testing (story Testing) Prototype Testing Techniques Manual Test Specialty Test & Automation Test Automation Test Manual Test & Automation Test
- 27. Phase 3 –Create Objet d'art It doesn’t mean to create complete in-depth documentation, but overall product structures & the work process. Opt for minimum documentation & maximum product coverage 1. Context Diagrams 2. Data Flow diagrams 3. Mind Mapping tools 4. Workflow Diagrams 5. Process Flow Diagrams 6. USE CASE Diagrams Check all high level first, before going to the details Keep adding more details as you go deeper & explore
- 28. MAIN MENU Sub Menu1 Sub Menu2 Sub Menu3 Sub Menu4 Sub Menu7 Sub Menu6 Sub Menu5 Sub Menu A Sub Menu B Sub Menu C Sub Menu D Sub Menu E Sub MenuF Sub Menu G Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Sub Menu H Sub Menu I Sub Menu C Sub Menu E Sub Menu F Sub Menu G Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature BACK
- 29. Testing Maturity Business Facing TechnologyFacing TechnologyTeam Tester BusinessTeam Tester Exploratory TestingFunctional Testing Unit Testing Specialty Testing Scenario Testing User Acceptance Testing Business Usability Testing Security Testing Load Testing Performance Testing Unit Testing of modules Business Functions Testing (story Testing) Prototype Testing Manual Test Specialty Test & Automation Test Automation Test Manual Test & Automation Test
- 30. Speaker Name: JulenC Mohanty Email ID: julenmohanty@yahoo.co.uk Organized by UNICOM Trainings & Seminars Pvt. Ltd. contact@unicomlearning.com www.unicomlearning.com/Test_Automation_Summit_Bangalore/ Julen Mohanty