“Interactive team activities around communication and soft skills”
This was the title of the February meetup “Tabara de testare Bucuresti”. The speaker was Andrei Dobrin, a very good tester that I have the pleasure of knowing. I attended this meetup and I found it very interesting and fun so I wanted to share my experience with you.
A good tester has many qualities. Some of the important ones are visualizing, communication and experimentation.
How do these abilities relate to the topic above? Stay a while and listen 🙂
The participants split into teams and each team receives a couple of cards.
Some cards have information about a farmer while others about the task that the team must do.
Each team must complete the tasks described on the cards. They also are not allowed to show the cards to other players and can’t write the information on anything.
At first this seemed an easy task. But I remembered that i did this type of logical exercise alone with pen and paper and it still took a while. Imagine with 4–5 people and nothing to write on!
In the first stage we each described the information on our cards. This is also where the first problems may arise. You need to communicate with people you don’t know and some may not have good communication skills.
You need to remember that communication also involves a lot of listening. *If you can’t listen the you will miss important information or ideas*.
To our luck we where all friends and knew each other so there was no issue there. If we were strangers it would have taken us a lot longer to solve the challenge and the tensions would not have been that easily solved. A few minutes later the first stage was complete. We all knew the information on the cards and we needed to start putting it together.
It was here where an important step took place. We started to come up with ideas that would make this exercise easier to solve. We suggested that each one of us would play a certain farmer. I suggested that we also sit in the specific places mentioned on the cards (north, south east west).
To remember the specific items assigned to me i started to imagine (a straw house next to a big grassland, a nice car next to it, a dog, etc ).
A wise tester once told me that if you can visualize how something works then you do not know it well enough to test it. And this helped me many times including this one.
As you can see here we started brainstorming and visualizing. Communication played an important role. Everybody needs to be heard and listened to feel like a part of the team. This prevents conflicts from appearing in the future.
Also every idea we had was tried and tested before we decided to implement it. (professional defect 🙂 )
After this stage we started putting one and two together. Which farmer has which house, what car, what animal and so on. But here things get tricky. The information we had was not as clear as we would have hoped. We did not know for sure what a certain farmers name was. Here we started to test our ideas, to experiment.
Let’s suppose my name is farmer X, then what would happen ?, if I had this car would we still be neighbors ? This is a time consuming and mentally challenging process. You need to keep track of your original ideas and also the ones that you are testing. Frustration and stress may rise here. Be careful how you manage it.
After about 30 minutes of work we thought we had the correct answers to the tasks. We where wrong! 🙂 About one at least, the other one was correct. Stress again. Where did we fail, which assumption was wrong and which one was correct. We started to retrace our steps. It is difficult to think about another solution once you already found one. People started to get quiet, ideas were starting to run out. This was our sink or swim moment. Fortunately we said: “Let’s see what we know for sure” and start from there. It did help that we had known which task we solved because it gave us another clue. And we started again with the experimenting. Another grueling 15 minutes later we managed to answer the tasks.
It is interesting how a game designed to improve team communication can also train other areas as well. Experimenting, visualization, backtracking, critical thinking and more. It was a refreshing activity where as a team we joined together and solved a difficult trial. Our abilities where put to the test and we passed! 🙂
It was a very nice meetup with tester friends where we improved and honed our abilities while having fun. Well we also got stressed and frustrated , but in a fun way.
We also got a sneak preview about the next game that could come up at the next soft skills meetup: “Re-zoom”.
When Andrei explained to us the rules we decided to run and go drinking, it was mind boggling :).
I am glad I attended and recommend to any of you interested to come. The information, the games or the people, they are all great !
In 7 noiembrie 2019, plina de emotie si cu planurile foarte bine structurate in minte, am ajuns la “Tabara de Toamna” de la Albota.
Stiam ca scopul meu cel mai mare (in afara de a invata, a socializa cu persoane din domeniu) era ca in viitorul apropiat sa pun Brasovul pe harta “Tabara de Testare”. Ma framanta ideea ca un oras cu o comunitate IT destul de importanta nu este deja parte a acestui grup fain.
Asa ca am inceput sa vorbesc, sa intreb, sa aflu cum fac altii lucrurile sa mearga, intalnirile sa se desfasoare, speakerii sa fie dornici de a prezenta si in final comunitatea sa se adune luna de luna.
3 luni mai tarziu, in 27 februarie 2020 toate planurile si
ideile au prins viata la “Tabara de Testare Brasov – Kick off meeting”.
Emotii, colegi de la Bucuresti alaturi, o sala faina gata sa ne gazduiasca, suport si incurajari via Slack de la prietenii “Tabara de Testare” din alte orase, prajituri si multe zambete, persoane gata sa sustina ideea si lume noua curioasa sa afle care e planul pentru viitor, o prezentare captivanta sustinuta de Andrei Pirvulescu, multe poze si un joc moderat de Andrei Dobrin, care a cerut munca in echipa si comunicare. Acestea au fost ideile care au caracterizat kick off meeting-ul.
In mai putin de 30 de zile va avea loc cea de-a doua intalnire.
As CodeCamp 2018 is drawing near, I keep perusing my notes and wondering about the upcoming talks. Becoming CodeCamper for a day was such a rewarding experience last year, especially since it gave me a sense of belonging and allowed me to get together with fellow enthusiasts. #ByTheCommunityForTheCommunity is the shared vision that prompted the Testing Camp and the CodeCamp to partner up in the first place. Since April 2016 (Iasi) and May 2016 (Cluj), this partnership has brought together Content Owners as well as Participants from various IT fields, some of which have later on delivered presentations or workshops at the Testing Camp Meetups.
I’ve been switching between the Tester and Developer hats for a while now, which is all the more reason to look forward to the next gathering, with its cross-disciplinary approach. But for now, I’d like to give you an overview of what I took from the previous edition.
When I registered for the 2017 edition of CodeCamp in Timisoara (our first one), I struggled with a different kind of “knapsack problem”. Choosing between 8 parallel tracks and more than 50 speakers was no easy endeavor. Packing them in one day either. Especially since the Testing Camp had been allotted an entire track on the agenda. However, once I had settled on my conference line-up, I simply couldn’t wait to get there and learn the ropes of new testing, marketing and development-related topics.
Just read on for snippets from my Camping Log.
Why do Projects Fail?
I first pitched camp at Track 5 and
attended a presentation delivered by Andreea Bozesan and Andrei Panu
from Softvision. It focused on reasons why projects may start off on the
wrong foot or simply face hurdles along the way, which prevent them
from achieving their milestones or trigger failure altogether. I found
the speakers’ approach highly useful, because it provided examples for
all stages of the Product Life Cycle. Instead of mere theoretical scenarios, these examples illustrated actual challenges from real-life projects, such as:
skipping the feasibility study
budgeting little time for software architecture and QA
poor managing of remote teams and/or cultural differences
insufficient project tracking
(to name but a few of the situations brought to the table).
If I were to find some common ground
between all these examples, I’d say that, more often than not, it all
boils down to (lack of) communication. Among the takeaways suggested for preventing project failure, I jotted down the following:
management and stakeholder support
clear vision & realistic objectives
clear and optimized scope
formal methodology in place
skilled and motivated team
proper testing process
Using Technology in Online Marketing: Chatbots
The second presentation targeted (but was not limited to) the Generation Z
and the marketing strategies that can be employed to engage such users,
which are basically born with a digital footprint and favor social
media interactions. Georgiana Dragomir from Grapefruit gave us a taster
of how Chatbots foster customer loyalty and retention. Several case
studies backed this statement up and provided memorable examples. Here
are some of them:
The Pizza Hut chatbot
(Sales & Advertising) – available via Facebook Messenger and
Twitter. It is meant to simplify the ordering experience and catch up
with Domino’s more advanced technical options. After a mere three
months, Pizza Hut managed to increase its engagement and boost customer
Marketing) – designed as a Personal Bartender Chatbot, which comes up
with recipes based on the ingredients input by the users. To prompt
retention, it also rewards its customers with free drinks and paid taxi
rides to and from the bar, so as to avoid any drunk driving.
Service) – the digital assistant, released by the Bank of America. It is
a proactive chatbot, which uses AI, predictive analytics and cognitive
messages to oversee payments and offer support in developing saving
plans. This initiative is aimed at encouraging customers to change their
Consequently, emphasis was placed on the
marketing aspects, rather than on the technical implementation. This
shift in perspective provided me with valuable interdisciplinary
insights. What I also found interesting in addition to the use cases, is
the fact that Facebook Messenger offers the necessary infrastructure
for developing chatbots. This means that it takes little time to
implement and maintain one, thus making it more accessible to developers
and the end users alike.
Infrastructure Testing for Docker Containers
Next on my line-up was the presentation
delivered by Alina Ionescu from Haufe Group. It brought me closer to a
type of testing, which I was yet unfamiliar with. Consequently, I found
it very useful that Alina focused on an actual project to contextualize
the subject matter. Infrastructure Testing had been conducted for a
large backend project with more than 10 other dependencies. This sheer
scale entails working with an immutable infrastructure. Since some
Docker containers don’t complete at the same time, the need arises to
check that everything is up and running.
Apart from the technical benefits of using such tools as Bash or Docker,
what I found particularly interesting was the process itself, which is
aimed at ensuring transparency and communication at team level. The workflow
involves creating a ticket before the actual deploy, so that all
involved parties are informed. The infrastructure tests are run. If they
pass, the ticket is closed automatically and everyone is again briefed.
In case of test failure, it is possible to roll back and work on a
solution. Prioritizing your tests is also an option.
Having pointed out the process, it is
also well worth mentioning that Infrastructure Testing is only one of
the stages, slotted after the code deploy. Below is a visual rendition
of how testing is parceled out:
(Adapted from Alina’s presentation)
Visualizing the process aided me in understanding each stage better and grasping the benefits of this “Deploy-Destroy-Redeploy”
approach, which is less time-consuming and more performance-oriented.
Writing automated tests in the same environment that the Developers use
is another plus. The deployments thus become more efficient and
predictable, while focus is placed on decreased recovery times and
higher quality. An extensive project like the one in the example
benefits from this approach, which I think can also come in handy when
scaling an initially smaller project.
A Game of Performance
Delivered by Alex Moldovan from Fortech,
this presentation revolved around the mobile aspect of performance,
It was quite intriguing for me to take a
peek behind the curtains, especially since I had already come across
and muddled through some of those issues myself, yet only as a user.
Being introduced to the challenges mobile developers face on the
eclectic and ever-evolving browser and device market really puts things
into perspective. For one, it definitely makes you empathize more with
the struggles put into providing users with an efficient, effective,
satisfactory and accessible experience.
The catchy titles, the well-chosen visuals and the Alice-Developer-Persona made the suggested solutions more memorable.
Here are some of my takeaways:
Testing Trends or Buzzwords?
The last item on the agenda of the
Testing Camp set about rounding off a diverse and engaging Track.
Throughout their sessions, the content owners had offered their view on a
number of topics, ranging from Infrastructure, Front-end, Continuous
Delivery to Planning, as well as Exploratory Testing. Therefore, it
seemed only fitting for Iulian Benea from Steadforce to prompt the
audience to consider how Testing is evolving. Three aspects provided me
with ample food for thought.
First of all, Iulian addressed the current need to automate tests
as much as possible, in order to catch as many bugs as possible at an
early stage. While this approach is cost-effective and less
time-consuming, I think it should still leave room for Exploratory
Testing, which can uncover important bugs in a shorter time span and can
also be conducted in a structured and traceable manner (e.g. through SBTM).
The second aspect revolved around the specialization of testing. Usability,
Performance, Security, Data Analysis and DevOps are just some of the
focus points, which have gained leverage and popularity over time. These
are more often than not connected with or influenced by the new fields,
that are high in demand nowadays and constitute the third course of our
“food for thought” meal: Big Data, Augmented Reality, Artificial
Intelligence, Internet of Things and the coveted Blockchain Technology,
to name but a few.
Drawing on these three aspects, we went
on to discuss how Testers could adapt to such almost paradigmatic
changes, in order to perform their tasks. Developing one’s skills beyond
testing has become paramount. Adding request analysis, scripting,
programming, management and even legal compliance to one’s profile are
some examples in this respect. Specializing in Mobile Development,
DevOps or Big Data has also been requested by various industries. During
the Q&A session, we broached the trend in Timisoara. From the
audience’s experience, Testers are currently learning how to write code,
while Developers are conducting more testing. Some companies are
experimenting with Test-Driven Development, while others favor employing
Automation Testers with JS.
It was a lively discussion and I felt
inwardly glad that I had selected such a varied range of topics at
CodeCamp 2017, that I could add to my technical kit and further explore.
In addition to the various tracks, the
Code Campers had the opportunity to engage in various gamified
activities, designed by the partner companies present at the event.
During the breaks, you could take online quizzes on your topic(s) of
interest, dabble in Augmented Reality, try your hand in technical trivia
or participate in the Code Camp Raffle.
Bottom line: Apart from
dealing with the technical challenges prepared, you could also get to
know fellow campers and network. Which is what getting together on such
occasions is basically all about: experimenting in a safe environment,
exchanging best practices and keeping up-to-date with the most recent
Curious? Then just register here! You can also sign up as a Content Owner and prepare to share your experience with eager Code Campers! See you on April 21st!
If you check our meetup on November 9 we had set up our “usual” second Thursday of the month meetup just that it wasn’t usual at all… We celebrated 5 years of monthly meetups at Tabara de testare Bucuresti!!!
On the agenda for that evening we had the overview of the presentations/workshops we had during 2017 but this time we also prepared an overview of the previous years and afterwards we continued with the workshop on “Storytelling and communication” by Stefan Bratosin.
I’m going to start with Stefan’s workshop first because the 5 years part needs to be saved for last like all the good things.
Stefan’s workshop was inspired by some improvisation classes that he took and while being involved more and more in the classroom he realized how the exercises that he was doing could help other testers better communicate and be better story tellers since this is a big part of what we do.
The workshop had a lot of cool and fun exercises like:
The whole group had to count to 30 without anyone overlapping. The exercise was very interesting and we managed to count to 30 as a whole group(we were about 20) and without anyone overlapping. The “Aha” part of this exercise was when Stefan asked us to close our eyes and try this way to count to 30. We managed to listen and focus way better than the time we had our eyes opened and try to search each others all over the room and see who was the next one that will be going to say a number. We actually listened this time!
Question rally – something similar to “Whose line is it anyway” ( here is an example of the show with Whoopi Goldberg) where there were only questions. We were given a theme and we could answer only with a question. Really fun exercise in which we could see in action: open or closing questions, probing questions or rephrasing.
Another exercise from Stefan’s workshop showed us the difference between using “yes, and” and using “yes, but”. During the exercise we could notice that using “yes, but” was not at all constructive and at least during the exercise it was basically cutting off the conversation
In the story telling exercise we had to create a story and tell it as best as we could from a team of 5 volunteers point of view. It was really fun and again we could notice on how important is to listen to the other ones or things could derail quickly. An example of a story – “The New Year’s Eve “. Our team had to create a story and the main character was our friend “Georgica”. The twist of the exercise was that Stefan would point to us when we had to switch and take the role of the narrator. By the second team which tried telling the story they could notice that they have to better listen to their colleagues rather than focusing on what’s next so they can continue on what the story was all about. If you didn’t do that, in our teams story, the main character didn’t even make it to the new year’s eve party 🙂
Besides all the fun that we had during the workshop, we were reminded how important is communication and storytelling to our tester’s job so a big thank you to Stefan.
Here are some pictures from the exercises that we did:
5 years of Tabara de Testare Bucuresti
5 years means a lot of time but as they say “time flies when you’re having fun”.
So what we wanted to do different this time from the other anniversary editions is to try and summarise all the years, basically a trip down memory lane.
For me personally were the best slides I’ve worked on so far for the anniversary editions. It let me remember how we started, how many people helped us start, what we did these past years and of course how many we accomplished, in the end showing that we are truly a community of software testers and that without the people in it, we wouldn’t have anything.
Was really challenging to summarise all of the above (and many more) so we tried our best to do it through an infographic:
As you could see in the infographic there were 71 meetups in 60 months and we wanted to showcase the meetups in each year and for this we created gifs with pictures from them and verbally mention some of them since there were a lot to go through.
We couldn’t celebrate 5 years of Tabara de Testare Bucuresti without our traditional “Cartoon Tester” special cake . Here is also a big thank you for our supporters of this edition: ING Romania and QTeam Software Solutions which helped us with the cake and snacks/beverages.
That’s a really good question!!! I remember 5 years ago when we started having the meetups I was thinking: ”let’s start it and see where it goes”. Oh well, it went very good, so for the next 5 years I expect even more amazing things, even more cooler meetups, more international speakers, more people being content owners, more workshops during the years and the list could continue.
Not sure what’s next or could say specific how is going to be in the next 5 years, but I certainly know it’s going to be awesome since YOU ARE “TABARA DE TESTARE”!!! and knowing the amazing people that are members of this community there is no other way than an even greater journey in the years to come.
Esti Software Tester sau lucrezi intr-un domeniu conex? Iti doresti sa impartasesti altora din cunostintele tale? Atunci nu mai sta pe ganduri: Sustine un workshop in cadrul Taberei de Toamna!
Indiferent daca ai livrat deja numeroase sesiuni practice ori abia acum te familiarizezi cu vorbitul in public, aici poti sa te perfectionezi in continuare. Vei avea sustinerea noastra in pregatirea atelierului, precum si feedback, pentru a te prezenta cu o varianta imbunatatita la alte evenimente nationale si internationale.
Asemeni editiilor precedente, incurajam o abordare hands-on si te invitam sa participi la un experiment inedit, pe durata unui weekend prelungit.
De ce? Pentru ca editia 2017 sta sub semnul experimentarii cu diverse metode, abordari sau instrumente, intr-un cadru safe, care incurajeaza schimbul de experienta si invatarea continua, fara constrangerile unui produs anume ori a unui mediu de lucru specific.
Daca doresti sa ni te alaturi, completeaza acest formular si trimite-ne intre 01.09. si 10.09. propunerea ta pentru un atelier.
Meetup-ul din octombrie 2016 de la Tabara de Testare Cluj a fost unul special: content owner a fost James Bach care a tinut o prezentare despre Risk Analysis in Software Testing.
In pregatirea pentru cursurile pe care le tine pentru testeri, James a incercat cu participantii un exercitiu privind riscurile, analiza lor si implicatiile pe care le au in testare. James si participantiiau cautat i dei de test pentru o masina autonoma de nivel 4, apoi au comparat notitele. Ce a iesit? Va lasam sa descoperiti singuri:
Last Saturday, I attended my first monthly meet-up hosted by the Testing Camp in Timisoara. This session placed special emphasis on Go.CD and Docker, while aiming at introducing the topic to those of us who are yet unfamiliar with such tools or frameworks. Since I’ve mainly focused on Manual Testing so far, I was eager to get a taster of what Automation is all about, especially in the context of Continuous Delivery. So I packed my laptop and went to join the fellow Meeples who had registered for the session, delivered by Alina Ionescu and facilitated by Camil Bradea, Iulian Benea and Ecaterina Ganenco.
In order to assist us in this process, Alina informed us in advance
about the tools we needed to install on our computers, prior to the
meet-up. During the actual session, she also provided a step-by-step
guideline for us to rely on while creating our testing environment. Once
receiving the instructions, we paired up and started working on our
assignment. It was quite challenging to navigate our way via the
Terminal by typing and executing text-based commands, but it was all the
more satisfactory when the steps started rendering results. Whenever we
seemed to get side-tracked by an error message or some other type of
constraint, we exchanged views with other teams or received support from
the facilitators, who mingled and tackled as many questions as
possible. By the end of the meet-up, I was thrilled to have set up my
own GitHub account and to have performed my first Commit and Push.
Creating the necessary stages and jobs was equally rewarding.
Most of the participants managed to run an automated test on their
machine within the allotted time frame. Even those who had only
succeeded in passing some of the stages, simply resolved to try again at
home, since we could all just revisit the steps in the guideline that
Alina had provided at the beginning of the session.
To sum this whole experience up, I’ll just leave you with my “Lessons Learned”:
Luni pe 10 octombrie la 18:30 te așteptăm la The Office, Cluj pentru un meetup special: James Bach ne va ține o prezentare despre Risk Analysis in Software Testing.
Ca și anul trecut, James Bach vine din nou la Cluj cu ocazia cursurilor RST si Session-Based Test Management organizate de Altom. James a acceptat invitația noastră de a vorbi în cadrul unui meetup despre un subiect foarte relevant pentru mulți dintre noi.
“I’ve noticed that a lot of testers struggle with risk analysis, and yet risk analysis is really the core purpose of testing. So, for this presentation, I want to engage you in a risk analysis exercise.” – James Bach
La sfârșitul prezentării vom avea o oră de networking să ne cunoștem mai bine.
The last TdT meetup was somewhat of a special occasion. For one it was a workshop instead of a presentation, which means that we formed groups to work together then presented and had discussions about our work that we had just done (instead of ONLY speaking from experience gained prior to the discussion). It was also “owned” by four people (instead of the typical one or two) which helped a lot with facilitating the discussion while we were working and as well as after, while discussing challenges and insights. I also had the opportunity to work with people I hadn’t had the chance to, which is always nice :-).
The workshop was structured in a fairly typical way, we arrived at the venue, chatted about random things, I found and solved a rather interesting puzzle game in the kitchen :D, then Dolly, Dorel, Elena and Oana, the content owners, introduced us to the theme of the meeting – learning! – talked about their goals with the workshop – wanting to become teamSTAR this year – go team go! – then described touring and how it fit with the theme.
They also introduced us to the app we were going to test, a chatting platform named slack, similar to an IRC client named – or so I thought before the workshop. They had cue cards printed out with the different tours we could choose from – they went with the FCC CUTS VIDS tours.
Testing tours are not really new, but I’ve rarely seen them being used on projects I’ve been on or talked to other testers about, not to mention being used consistently (this statement is of course limited by my experience :-)). I first heard about touring while doing the BBST Test Design course where one of the techniques we covered was touring, (and where I first read this article by Michael Kelly). While this was my first contact, I only started to understand the power of touring after reading James Whittaker’s take on touring described in his book ‘Exploratory Testing’ (he also has a couple of articles dedicated to this technique here).
I read the book while I was on a project testing medical software and this technique helped me a lot in learning, mapping and better understanding the intricate connections between elements of the product, by touring the application and mapping the central data elements it worked with, then we used this map to vary the data we were working with, after which we moved on to touring the application to figure out what features were important for different types of users, then we created scenarios based on these user types.
While using tours proved invaluable on this project, on my current project I can’t really use the technique consistently (I’m helping in setting up an automation environment and writing automated checks, with a bit of testing sprinkled in when release candidates are promoted).
Given my current situation, attending the workshop was an excellent opportunity to use the technique once more. Participants formed groups of 2 to 4 people and chose a tour type. I had the pleasure to work alongside Tamara and Florin, both fairly new to testing, but eager to start. We chose the Variability tour, because it seemed easy enough: just look for things in the app that you can change and change them. We were somewhat wrong about this.
After choosing the type of tour, we quickly set our laptops up in the corner of the garden outside the venue, and designated roles for each of us: Tamara sat at the keyboard, she did most of the navigating and the “trying things out”, Florin did research as well as compared what we found in the desktop version of slack with his Android version, while I took notes and came with suggestions for what elements to vary.
Our first challenge came in the form of trying to figure out how much to vary the data we were working with, while still learning new things about the app. Our reasoning was that since the goal of the Variability tour was to learn the capabilities of the application by changing the different elements it is comprised of (buttons, settings etc.) we should see these different changes take effect not just compile a list of possible variations. So we limited the amount of variation in the hopes to cover more ground.
We started our tour with the different ways Notifications can be set up in the app. Right from the start, there were a lot of ways to customize it:
Do we want to receive notifications from everyone or just a certain group? How about specific channels within a group?
Do we only want direct notifications and a select group of highlighted words?
Or possibly from specific users?
Next there were specific ways the notification popup window could look and feel:
Should it contain the text being received?
Should it flash the screen?
Should it make a sound? If so, which sound?
Where should it appear on the monitor? How about if there are multiple monitors connected?
We also learned that users can set Do Not Disturb periods (based on Time Zones only reachable from the web version of the app), as well as timers that can act as a temporary DnD when we want to do something uninterrupted. These settings, of course could be further customized on a group/channel level.
After we were done with Notifications, we moved on to varying the look of the app by changing its theme to a different preset, creating a new preset altogether, we even looked at importing themes into slack. We found out that this option is NOT variable in the mobile version of the app. When we started focusing on Advanced options to see if we could find any interesting features, we realized there were only 10 minutes left of the session, and we were at the 3rd point of a 6 point list of settings.
Managing time turned out to be our second challenge.
Needless to say, we tried to wrap up the session by finding elements that were more ephemeral than the settings of the app. We noticed another team had enabled TaskBot, so we varied the different elements of a task created with the bot, created temporary channels made out of our group and tried to send different types of messages. We also ended up talking about the way we varied the messages sent throughout the session so we added that in our notes as well.
After the one hour testing session we gathered inside, where each team talked about their brief experience using tours, and whether they see this as something they could do on their current project:
There were a few feature “tourists”, who had interesting takes on what to include as a feature and what to exclude (my take on this is that while it’s important to have a common understanding of a feature on a given project I am on, this might change if I move on to another project)
There was one group that picked scenario tours, who had a hard time coming up with realistic scenarios – or at least they did not talk about the ways they tried to get to these scenarios. (my conclusion was that understanding the features and the users of the app would greatly help in this, so touring the app from these perspectives before searching for scenarios would probably be a better way to learn the app)
There was a group who did a Configuration tour, which was fairly similar to our Variability tour, since they are related in concept. (my take on the difference between the two is that while in the Variability tour you learn about the application by varying things in the app, the Configuration tour focuses on the permanent changes that you can “inflict” upon the app).
Lastly, there was a team that did a Testability tour, and they hardly dealt with the application itself, and looked for logs, access to local databases, controls within the app to use to automate different checks with, possible bots to use for creating/modifying/deleting key elements of the app. This tour, while very different and interesting, was the least context dependent of all of the tours (making the experience more easily transferable to other projects)
While we didn’t get to discuss about it during the workshop, a third challenge I see with ongoing tours is this: Do we keep the map we created up to date with new changes being added to the app? In other words, is the artefact we create during a tour lose its value? I know it’s valuable for a while, but is it worth it to keep the map/list updated? As I see it, the act of creating the map or list is vastly more valuable, and it keeps its value while you base other tours on it, I am more skeptical of its usefulness after that, though.
All in all, I came away from this workshop with interesting ideas, and a firmer grasp on the technique than before. If i were to sum up the experience of touring an application and engaging in the discussions after in one sentence, it would be this one: Without resorting to assumptions and our previous experience with the application, it will take a lot of time to do each type of tour, and that some of the tours are more useful to do early (Testability, Feature, User tours) while others are better done later (Scenario tours), but ultimately it’s worth the effort.