Hello Everybody.
I’d like to introduce T.E.A.S. to you. This is something I came up with yesterday which requires a lot of fantasy some good thinking planning and enthusiastic people. So, let’s get started.
What is it about?
Testing Exploration Adventure Session is about. Testing! There. No real surprise, eh? TEAS has it’s roots in RPGs. Role Playing Games. If you ever heard or read about M.A.G.U.S. or the more known Dungeons & Dragons you will have a better understanding of the concept behind this phenomena.
Basics of RPG
So now that we know that it has it’s rules in RPGs how will that be applied to testing and learning? Easy. Well it’s not that easy but after you grasp the concept it will get easy.
Just like in an RPG people get together first. There will be players in the group mostly and one or two Dungeon Masters. The task of the Dungeon Master is to facilitate the Game. The Game it self consists of a set of given rules and a World in which these rules are applied too. The Players are placed in this world which is created by the Dungeon Master. They are then given tasks that needs to be fulfilled in some particular way. That choice is of to the Players. The DM only facilitates. He is the Master of the given World. And plots against the players. He incorporates the Non Player Characters or NPCs of the World and tries hard to trifle the effort of the players.
This task can be anything from freeing a princes to twarthing a Magus from gaining Omnipotence or God like powers, to killing a Dragon for its treasures. And Players decide what to do and how to do it. The DM lists the options available. And as the Players move they get experience. They get stronger, faster, better, more intelligente.. They gain Levels.
Now. How does that fit into Testing?
How does this fit into Testing?
If you think about testing and the players what comes into mind? You have a product. And you have testers who explore this product in certain ways. As they go and find bugs ( kill mobs ) they get better and more efficient in finding other bugs based on the previous ones. Tasks get harder and harder as the most easy to find bugs are already taken care of. Elusive bugs will be harder to discover ( kill ).
And who is the Dungeon Master? I would say in this case it’s the Product Owner.
How to begin
So what now? You have your Testers ( Players ) and your Product Owner ( Dungeon Master ). What’s the next move? How does this all begin?
The PO present a software. He builds it. Finds it out. Puts together the pieces. Creates maps, road maps, site maps if it’s a server application then it’s structure maps and database diagrams and whatever helps him to present his product to the Testers. He slips and designs bugs into the system. Harder ones and also easier ones. He has to have a story in the application. Maybe it’s a web site that provides some service. There a lot of components that could go wrong.
The testers begin by asking questions. They begin as Level 1 Testers. They know nothing yet. They know no programming languages and no metrics and nothing. The goal is to have a fully covered product which they are confident enough to release. They can add the whole release process to the Game too. Depends on what the PO has in plan for that Session. Which could take a few hours or a whole day. Depends on the possibilities.
How the Testing works and what’s a level?
So as they go on and Test the product, which they have to do verbally, the PO knows what bugs they come across. As they find bugs they earn Experience points. The more they have the more they level up the more tools will be available to use. That can be given to chance. Throw a dice and select a tool from a pool of tools which are available to the whole Project.
You can have a Random factor to the bug finding process too. For example if a Tester tries to examine an area he throws a dice to determine his ability to find bugs. That ability comes from initial stats that can be defined at the begin of the game. If he succeeds he finds a bug and gets points for it. The tools can increase the ability to find bugs. For example automation can add bonus to finding repetitive bugs but can add minus points to fantasy / finding really nasty elusive bugs because you might concentrate less on details.
So a Level defines the Testers ability to find bugs. The higher level he gets the better his abilities will be to find bugs.
The PO defines the End Game. The Games goal could be to find x number of bugs. Or to release the product. Or to bash it, crack it, hack it destroy it. It could be that you have to sell it or demo it to some stack holders. The possibilities are Legion.
How to go on.
I know that this is all very confusing yet.. I’m still working out the individual rules, plays and numbers and Character sheets and such. Any thoughts and ideas are appreciated.
The merits of this game are many. It practices testing it practices the ability to explore a product only in fantasy. It helps who ever designs a product to get a glimpse into the world of designing.
Also the product might even be not from this time!! It can be a future product of some holographic nature! Or an Audio Visual interface that’s hooked into the users Brain. Or some other advanced future technology. How would you Test that???? How would you test a robot arm controlling algorithm. Or an Artificial Intelligence that controls tactical missiles overseas.
The possibilities are virtually limitless. It’s up to the Product Owners fantasy what he builds. It could be a whole new virtual World like the Holoroom in Star Trek. How would you Test THAT???
If you are interested in this endevour follow me for more details.
And as always,
Thanks for reading!
Gergely.