RST - Makati Testers Meetup
•Als PPTX, PDF herunterladen•
1 gefällt mir•230 views
This presentation was delivered at the Makati Testers Meetup hosted by Sandstone Technology on 4 August 2016. The information in this presentation and some of the slides are taken directly from James Bach & Michael Bolton’s Rapid Software Testing (RST) class and the notes from that class (which are publicly available from satisfice.com). This presentation is intended to provide an overview of some ideas presented in that class, I am not claiming any ownership of these ideas.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (10)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie RST - Makati Testers Meetup
Ähnlich wie RST - Makati Testers Meetup (20)
Mehr von Michele Playfair
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
RST - Makati Testers Meetup
- 1. Makati Testers Meetup Rapid Software Testing – The Controversial Stuff!! August 2016
- 2. Rapid Software Testing Started out as an offshoot of Context Driven Testing Authored by James Bach & Michael Bolton Mind-set, skill-set and testing methodology Contains interesting ideas Deliberately(?) controversial
- 3. There’s no such thing as “Best Practices”
- 4. What do you mean by “context”, anyway? SST PEOPLE Product Technology Client project Agile or Waterfall Co-located
- 5. Does one standard “Best Practice” really make sense?
- 7. “Checking” Operating a product to check specific facts about it An information gathering activity that, in principle, could be done by machine The check itself requires no skills but good checking is surrounded by activities that require many skills, including testing, programming, and project management skills)
- 9. If you’re this guy You have two choices:
- 10. “Testing” Questioning a product in order to evaluate it (RST) Evaluating a product by learning about it through exploration and experimentation (RST) A questioning activity that employs skills, senses, emotions and intelligence that we are unable to automate (RST) A technical investigation for the purpose of revealing the quality of a software product on behalf of stakeholders (Kaner) Gathering information with the intention of informing a decision (Weinberg) Note that nothing in these definitions implies you have to start with an OPERABLE product
- 11. Acquiring the competence, motivation and credibility for... Creating the conditions necessary for... Evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modelling, observation and inference, including... Operating a product to check specific facts about it ...so that you help your clients make informed decisions about risk And perhaps make the product better too! Testing is...
- 12. There’s no such thing as “automated testing” Or “manual testing”
- 14. Test Cases are NOT Testing
- 16. Test Cases are NOT a useful metric
- 17. We finished 5 pieces of fruit today
- 20. It is NOT the Tester’s job to “break the product” or to be the Quality Gatekeeper
Hinweis der Redaktion
- The information in this presentation and many of the slides are taken directly from James Bach & Michael Bolton’s RST class and the notes from that class (which are publicly available from satisfice.com). This presentation is intended to provide an overview of that class, I am not claiming any ownership of these ideas.
- “Rapid Software Testing is a mind-set and a skill-set focused on performing testing more quickly and less expensively while still completely fulfilling the mission of testing. It is a complete testing methodology, designed for a world of barely sufficient resources, information, and time.” Is not a silver bullet that will magically make everything awesome In this presentation I am going to share with you some of the statements from RST that I think are “controversial”, and the ideas behind them. These are good conversation starters and triggers to think about whether these ideas could work in our context.
- There are good practices in context, but there are no best practices. (one of the 7 basic principles of the Context Driven School)
- #1 - People, working together, are the most important part of any project’s context. (another of the CDT principles) Here’s some of the factors that affect our context at Sandstone Technology
- Hence the idea that there are no BEST PRACTICES, only good practices that work well for your context! Maybe not such a crazy idea after all.
- An ongoing topic of contention and source of many arguments on Twitter – insistent (obsessive?) distinction between labelling of TESTING and CHECKING What is your definition of TESTING?
- Note that in this case you NEED to have some form of operable product to check! How does this match up with what you thought of as “Testing”?
- Checking pre-defined requirements Acceptance criteria – these can be automated eg: Cucumber, Fitnesse
- If you only know how to do the exact same tasks as a program can do... “executing checks” - eventually the program will replace you. It is cheaper, more efficient, and less likely to make mistakes.
- So if all that stuff is “Checking”, what on earth is “TESTING”??? EG: when you get a new phone and you’re checking it out, what do you do? Compare it with the manual or just start investigating it - “playing with it”
- Checking is important!! but it is only a part of testing...
- RST is very specific (some say pedantic) around the definition of testing as something done by a thinking human being. This human being may or may not be using tools including say, Selenium, to do this act of TESTING.
- As far as “Manual testing” goes – if real TESTING can’t be automated (but checking can), then all testing by definition is manual meaning “done by hand”... so it’s redundant to say “Manual Testing”.
- What is a “test case”? Test cases vary widely in value from case to case, tester to tester, product to product, project to project, test technique to test technique, and over time... Different testers have different ideas about what constitutes a test case. There’s no specific definition in common use. Sometimes, a test itself is called a test case. Testing is a PERFORMANCE not an ARTEFACT
- The test case is not the test; the test is what you think and what you do. Test cases describe only a fraction of what goes on in testing. Test cases represent what’s EASY to put into a test case. http://www.satisfice.com/presentations/againsttestcases.pdf Do you want test cases? Or do you want to manage risk? When ppl say "we want test cases" what they mean is, We want evidence to confirm you're on top of this testing thing.
- Many metrics for covering test progress seem to fall back on "what percentage of test cases are complete". But what does this tell us? A test case can be long or short or inbetween, can cover one requirement or many!
- I love this analogy from Mike Talks – “If I told you that today my team had finished off 5 pieces of fruit, how much would be left for the next few days? I bet you'd hope (if you're the business owner) that one of those pieces of fruit was the watermelon. But what if it was just 5 grapes? That's what happens when you count test cases, you're saying a grape is the same amount of fruit as an apple ... or a watermelon.” (http://testsheepnz.blogspot.com.au/2014/08/lets-count-test-cases-shall-we.html)
- OK so if you don’t just write test cases, what DO you do?
- Testers are bad at describing the quality of their work... why is it good or not? what made testing harder or slower, story about testability or obstacles... not just to each other (whinging haha) but reporting to clients or the rest of the project - 3 part testing story... the product (BUGS), how you tested it (Oracles/Coverage) and how good the testing was (issues) - - those 3 stories interact/braid/weave around each other Is the product any good? How do you know? Why should I be pleased with your work? See how much richer this is than just “We completed 5 test cases today” or “we’ve completed 47% of our test cases and 82% passed”
- Who’s heard these before? Do you get told to “break the product” or “sign off on the Quality”? Testers don’t break the code, we break your illusions about the code. It was already broken when we got it - we just find out where it's broken
- Testers don’t decide when the product should ship. Testers should not “certify the release”. “We don’t get to make decisions about quality. This can be hard for some testers to accept, but it’s the truth. We provide information to managers; they get to make the hard decisions. They get the big bucks, and we get to sleep at night.” “we (do not) get to determine definitively what should or must be done. Those responsibilities lie with the programmers (including those who design and build the product), and the product owner. We light the way, but we don’t run the project.”
- As testers, we PROVIDE INFORMATION, we don’t ASSURE QUALITY. Cem Kaner - individuals—programmers and testers alike— can certainly assure the quality of their own work, but testers can not assure the quality of the work of others, and shouldn’t try it. The quality assurance role in the company lies with the management and the CEO (the principal quality officer in the company), since it is they—and certainly not the testers—who have the authority to make decisions about quality. I can’t prove the product WORKS, I can only prove that it DOESN”T WORK "Quality is a working hypothesis. When you exercise software and fail to spot a specific problem, you have not proven or demonstrated that “it works.” All you know is that you haven’t yet recognized a failure. All you have demonstrated is that the product can work. The product may have failed in a subtle way you did not or cannot yet detect.“ As testers, we cannot report that there are no Severity 1 defects in the product. At best, we can report that we have found no Severity 1 defects in the product
- To sum up - RST is about learning the ART and SCIENCE of being a better tester. It focuses on increasing your own skills as well as delivering better products to your clients.
- Thank you! Selfie by Santhosh Tuppad with me, Michael Bolton & Paul Crimmins of TEAM