Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Technical Testing Webinar

5,985 views

Published on

What does Technical Testing mean? For Alan, it means going beyond requirements and using Technical Information about the implementation and an understanding of the technologies used in the building of the system to add to the risk profile and use to help derive test approaches. Using Web Testing as an example we explain how approaching testing from a technical perspective changes how you view the system and how you test. Also explained, how a technical understanding leads to a different use of tooling an automation. This webinar presented 1st April 2015 to Tabara De Testare

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Technical Testing Webinar

  1. 1. Technical Testing Webinar 1st April 2015 for Tabara de Testare 4 Romanian Cities, 1 Webinar http://www.eviltester.com http://www.meetup.com/Tabara-de-Testare-Cluj/
  2. 2. ● On 1st April 2015, this webinar was presented live via Google Hangouts to the Tabara de Testare Romanian Testing Group ● An audience spread across rooms in 4 Romanian Cities, with 70+ people tuning in from the comfort of their own home and workplace ● The Webinar consisted of the slides and talky bits, a hands on demo, followed by a Q&A section
  3. 3. Blogs and Websites ● CompendiumDev.co.uk ● SeleniumSimplified.com ● EvilTester.com ● JavaForTesters.com ● Twitter: @eviltester Online Training Courses ● Technical Web Testing 101 Unow.be/at/techwebtest101 ● Intro to Selenium Unow.be/at/startwebdriver ● Selenium 2 WebDriver API Unow.be/at/webdriverapi Videos youtube.com/user/EviltesterVideos Books Selenium Simplified Unow.be/rc/selsimp Java For Testers leanpub.com/javaForTesters Alan Richardson uk.linkedin.com/in/eviltester Independent Test Consultant & Custom Training Contact Alan http://compendiumdev.co.uk/contact
  4. 4. But first some surface structure examples: ● Non-Technical Testing of a Web App – Tester → Browser ● Technical Testing of a Web App – Tester → Browser → Proxy → Server → DB
  5. 5. Non-Technical Testing of a Web App
  6. 6. Technical Testing of a Web App
  7. 7. Technical Testing of a Web App ● Log monitoring ● DB access ● DB monitoring ● Profiling on the server ● Etc.
  8. 8. Surface Structure ● What it looks like from the outside ● Not a deep model ● It's not just addition of tools ● Attitude ● Philosophy
  9. 9. What do I mean by Testing?
  10. 10. All the normal stuff we learn ● Testing Techniques, Testing Object Oriented Systems ● Boundaries, Equiv, Domain Testing, Graphs, Entities
  11. 11. All the Lessons we've learned over the years ● Testing Computer Software, Lessons Learned in software testing
  12. 12. Over the years we build up models of what we do ● Heuristics, ● Mnemonics ● Rapid Software Testing, http://www.qualityperspectives.ca/ resources_mnemonics.html http://www.satisfice.com/info_rst.shtml
  13. 13. Build your own model ● Observe what you do ● Reflect on why you do it ● Ask yourself how else you could do it
  14. 14. 14 MORIM ● Model – What I think I understand. Different viewpoints. ● Observe – at different points to corroborate/invalidate model ● Reflect – find gaps, lack of depth, derive intent ● Interrogate – Focussed, deep dive observation with intent ● Manipulate – Hypothesis exploration and “how we do stuff”
  15. 15. 15 MORIM from Psychotherapy ● Model – “Work with the client you have, not the client you want” ● Observe – What language patterns do people use? ● Reflect – Remodel. Figure out what questions to ask next ● Interrogate – Specific questions to ask ● Manipulate – To effect change, manipulate - Hypnosis
  16. 16. 16 Tools ● Systems Thinking & Modelling – Modelling, – Cybernetics, – Psychotherapy, – ... ● Testing Knowledge – Techniques, – Exploration, – Note Taking, – etc.
  17. 17. 17 Fundamentally, everything I do is modelling and model exploration. ● 'Technical' means going deeper into the models
  18. 18. 18 MORIM & Technical Web Testing
  19. 19. 19 Web Context: A Browser Model
  20. 20. 20 Web Context: A Browser Model – Technical Risks
  21. 21. 21 Generic Web Application Model Browser ↔ Server ↔ Database What happens where? What could we observe where? Where could we manipulate?
  22. 22. 22 Generic Web Application Browser ↔ Server ↔ Database HTTP Traffic Cookie Creation JSON, XML Files: img, pdf, etc. Rendering CSS Cookies JavaScript HTTP Logs Application Logs Schema Data
  23. 23. 23 Modelling & Reflection lead to tooling to augment our testing ● What can we observe? – How would that help me? ● How can I observe it? → tools ● What can I manipulate? – Why would I manipulate it? ● How can I manipulate it? → tools
  24. 24. 24 Web Context: A Browser Model – Technical Tooling Augmented
  25. 25. 25 What tools could we use? ● What can we observe? – Http traffic, cookies, javascript execution, log files, data in the database, DB schema used ● What tools do we need to observe? – HTTP Proxy (Burpsuite, ZAP Proxy, Fiddler), Browser Developer Tools (in browser), DB Tool (mysql, mysql workbench), Text Editors, Log File Viewers (tail -f) ● What can we manipulate? – HTTP Traffic, DOM, Cookies, DB, Config ● What tools do we need to manipulate? – All of the above
  26. 26. 26 Tools lead to new ideas ● Don't start with tools ● But once you have tools – Tools are technology – Look at their features – expand your models – How could you use that? – What does that teach you?
  27. 27. 27 e.g. Fuzzing ● Fuzzing – repeating requests while varying data ● Some proxy tools have Fuzzers ● Traditional use as templated security testing... ● We could 'repeat requests while varying data' – Quick tool supported exploration of a controlled data set – Fuzz data sets as data we would never use
  28. 28. 28 Reflections on Technical Testing
  29. 29. 29 A description of Technical Testing ● A reminder to keep “going deeper” ● Tool Augmentation ● Technical details will: – inspire more testing – identify more risks – Identify different problems ● Not limit our testing to Acceptance Criteria
  30. 30. 30 It means "Tool Augmentation" ● Is not automation, it uses automation ● Tools to passively observe, maintain history of observations ● Tools to alert on specific conditions ● Tools to observe the unobserved, and interrogate the inaccessible ● Tools to help me model and reflect ● Tools to help me manipulate ● ... etc. Never tools to control. Tools to augment.
  31. 31. 31 How I describe what I do ● Not a definition ● A description of my current approaches ● I try get as deep and technical as I can ● I need to keep learning so that I can understand the technology
  32. 32. 32 Go Beyond the surface structure ● Transformational Grammar – Surface & Deep Structure – Chomsky – Multiple surface structures – Single Deep structure ● Filtered, biased, distorted → Surface Structure ● Questions operate as tools to investigate Surface to Deep mapping people
  33. 33. 33 Go Beyond the surface structure ● A Blueish Ball ● A Silvery round object ● A Bean Bag ● A Shiny Juggling prop
  34. 34. 34 Go Beyond the surface structure ● It's An Alien ● A Silvery round object ● A Bean Bag ● A Shiny Juggling prop
  35. 35. 35 It's not an alien “'Say whatever you choose about the object, and whatever you might say is not it.' Or, in other words: Whatever you might say the object “is”, well it is not.'” Alfred Korzybski, Science and Sanity, 5th ed, pg 35
  36. 36. 36 How to do Technical Testing? ● Identify tools to work with System Surface Structures ● Questioning Systems at different Surface Levels ● Learning System Structure Technology ● Model System Surface Structures ● Observe System Surface Structures
  37. 37. 37 Technical Testing Risks & Issues ● Take responsibility for your testing ● Is anyone really going to stop you from doing the best testing you can? ● You can learn, as you add value. Take small steps. ● You can learn, as you pair. Ask questions, take notes. Apply your 'testing super powers' to the information you get. ● Use technical testing to 'push' for more access to environments and system internals
  38. 38. 38 Resources
  39. 39. 39 Resources - Testing ● Books – Testing Techniques (Beizer) – Testing Object Oriented Systems (Binder) – Testing Computer Software, – Lessons Learned in Software Testing ● Mnemonics lists – qualityperspectives.ca/resources_mnemonics.html ● Rapid Software Testing – by James Bach & Michael Bolton – satisfice.com/info_rst.shtml
  40. 40. 40 Resources - Modelling ● Rethinking Systems Analysis & Design – by Gerald M. Weinberg ● Domain Driven Design – by Eric Evans ● Diagnosing the System For Organisations – by Stafford Beer ● Software Requirements & Specifications – by Michael Jackson ● Principles of Experimentation And Measurement – by Gordon M. Bragg
  41. 41. 41 Resources - Observation & Interrogation ● Observation – The Structure of Magic Volumes 1 & 2 ● by Richard Bandler and John Grinder ● Interrogation – The Web Application Hackers Handbook – Provocative Therapy by Frank Farrelly – NLP For Testers, by Alan Richardson ● compendiumdev.co.uk/page/nlp
  42. 42. 42 Resources – Reflection & Manipulation ● Reflection – Quantum Psychology by Robert Anton Wilson ● Manipulation – How to Break Software, How to Break Web Software, How to Break Security ● by Whittaker (and others) – Patterns of the Hypnotic Techniques of Milton Erickson ● by Richard Bandler & John Grinder – Changing with Families ● by Bandler, Grinder & Virginia Satir
  43. 43. 43 ● Thank you to Tabara De Testare for organising the webinar ● And thanks to everyone who attended at the various venues and from their own homes and workplaces ● http://www.meetup.com/Tabara-de-Testare-Cluj/

×