My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #14: Keep Your Eye on the Ball (The End Goal) - Kate Paulk
What is the point of software testing? Why do we do it? In the simplest sense, as I've said previously, software testing is about providing information about the state of a product or project. It provides guidance to all parties in an organization as to the quality of an application and its functionality. It illuminates risks to value. It highlights areas that may need to be improved. All of these require a variety of skills and attributes, many of which would go well beyond a specific "do this one thing and you'll get better" approach.
For this section, I'm going to focus on the statement "Keep your eye on the ball" as it pertains to software testing in general. Very often, we find ourselves looking at a piece of functionality. As we are asking questions and exploring, we can veer off into directions that, while interesting, can easily get us off track. Don't get me wrong, exploration is part of the job. It's often the most fun part of software testing. Keeping a focus on the areas that matter, at least for that given time, is a skill that all testers should develop.
Workshop #14: Session Based Test Management (SBTM) and Thread Based Test Management (TBTM)
Many testers have heard the term "Session Based Test Management" (SBTM) at one point or another. If you have participated in Weekend Testing, you have seen first hand how SBTM is applied. SBTM is a structured and focused session of exploration. The goal is to make sure that you know where you plan to go, and record what you do along the way. Jonathan Bach has written an excellent overview of this approach.
The main idea behind SBTM is that you set a time to focus on something specific within an application. The time is pre-determined. I prefer sessions to be short, roughly an hour in total duration, though they can be longer or shorter as needed. I also prefer to create very specific missions and charters for these sessions. A mission is the overall goal of the session, and the charter(s) are specific tasks I want to accomplish within the scope of that mission. The more specific the mission and charters, the better my chances of successfully completing them within the given time frame.
Taking notes or capturing what I am doing is important. This can range anywhere from just having a simple text editing application open in the corner while I test, using a dedicated SBTM tool like Rapid Reporter to gather my approach and findings, to actually recording a screen cast of my testing and capturing both my exploration and my commentary of what I am doing. How the session is structured is up to you, but structure the session, take notes of your exploration and your findings, and be sure that you can explain what you did and what you found along the way.
What's this "Thread Based Test Management" (TBTM) think I am referring to? It likewise has its roots in STBM, but think of it as a particular tangent you might take if you were to get involved in while testing. Have you found yourself talking with someone and, as you are discussing a particular area, it would lead you down a path that you might not have considered at the outset? Sometimes those paths are short, and they provide good information to the main topic. Sometimes those paths are much longer, and they seem to take you away from the main point of the discussion, but they are still valuable. What do you do when you find yourself exploring a path that fits your mission or charter, but opens up into areas that you might consider to be too broad or too long for your session. Do you terminate it? Do you go back to the main mission and charters? Using TBTM, you note that you are following a thread, and you see where it takes you. Again, Jonathan Bach has written about his own experiences with using TBTM here.
On a personal level, I like to use the TBTM approach and apply the "rule of three" when it comes to specific threads. If I find myself making more than three steps away from the main mission and charter I am working on, I note that this may be a thread worth exploring later on, but I try to not "rabbit hole" on a given area if I see it's taking me out of the area I've scoped for that particular session. Rabbit holes do, however, offer some great exploration opportunities, so we don't want to forget them. When I find myself taking three or more steps away from the main mission and charter, that's a good indication to me that that thread probably deserves its own session, its own mission, its own charter and dedicated time to focus on it.
ADDENDUM: This was written some time ago and the state of the tooling world has changed a bit. I was asked if I would include the following list of up[dated tools, so if you are seeing this post in 2022 or later, first off, thank you for reviewing my earlier work :) but also, here's a listing of 10 Additional Tools that you can use to support your Exploratory Testing efforts (happy to see Rapid Reporter is among the list :) ).
Bottom Line:
Both Session Based Test Management and Thread Based Test Management offer opportunities to structure or explorations, and reference how we got to key areas in applications s that we can communicate what we found, how we found it, and why it maters to the stakeholders. Above all, it provides a way to keep focus while we are testing. Exploratory testing is often seen as mesh and unstructured, a lark that happens to sometimes find something interesting. Those of us who use SBTM and TBTM approaches know that we can provide a great deal of concrete evidence of where we have tested, what we have learned and how that learning can benefit the team that is developing an application.
The key part of Exploratory Testing is that we learn along the way, and we adapt and focus our efforts base on what we learn. Rather than formulating our plan up front and slavishly following a list of scripts and to-do items. We loosely develop missions and charters, and then try out our ideas based on those missions and charters. By keeping track of the threads that we follow, we can determine which areas might require follow up and additional testing.
The key part of Exploratory Testing is that we learn along the way, and we adapt and focus our efforts base on what we learn. Rather than formulating our plan up front and slavishly following a list of scripts and to-do items. We loosely develop missions and charters, and then try out our ideas based on those missions and charters. By keeping track of the threads that we follow, we can determine which areas might require follow up and additional testing.
No comments:
Post a Comment