The Autumn Camp 2016: A Trip down Memory Lane


This year, I submitted my first registration for the Autumn Camp, which proved to be a memorable and engaging learning experience. Instead of attending presentations, I had the opportunity to get acquainted with content owners that favoured the workshop format. Hands-on practice was the motto and each session mapped the journey towards a measurable learning goal. The content owners employed scaffolding techniques and strove to accommodate any and all emerging learning needs. My only regret is not having been able to select more than three workshops. On the other hand, having 8 parallel tracks on a daily basis, followed by innovative Test Labs, provided the 76 participants with diversity and the opportunity to pursue their topics of interest at leisure.

Without further ado, I’m just going to walk you through my experience at this year’s edition of the Autumn Camp, powered by TdT (22.-25.09.2016). Since I’m a passionate trainer & coach myself, you’ll also get some insight into that perspective, in addition to my interests in the field of testing. Enjoy! 🙂

  1. To be or not to be Agile?


The first workshop I attended covered an introduction to Agile and it was delivered by Camelia Codarcea, the co-founder of AgileHub in Brasov. A seasoned Scrum Master with hands-on experience in Romania and abroad, Camelia cunningly balanced theory and practice within the allotted time slots. The morning session revisited the Agile Manifesto, while engaging the participants in a lively discussion about the 12 principles. We could each draw on our experience with Agile and its various frameworks, also considering shortcomings in terms of implementation. Another topic that prompted us to contribute revolved around splitting epic features and delivering functional software at the end of each sprint. The challenges and benefits of achieving Simplicity (“the art of maximizing the amount of work not done”) were also on the agenda.

This exchange anticipated the focus of the afternoon session, which featured group work for a practical display of Scrum. Once divided in teams of four, we each received our scenario and handled the assignments, whilst measuring our progress against the Scrum Board. Having phrased the User Stories in our Backlog, we practiced estimating and prioritizing by means of Planning Poker. Allotting as little time as possible for Planning & Grooming allows for more time dedicated to the actual tasks. It also reduces the level of frustration when it comes to the inherent variables of Continuous Delivery. Our hypothetical ride wasn’t smooth either, since the sprint we simulated was interspersed with changes in the customer’s needs, which we had to tackle by redefining priorities. This was aimed at our gaining a deeper understanding of the framework and of the fact that changes are not mere whims that trigger reshuffling of User Stories. The differences between Agile and Waterfall were thus easily traceable. Consequently, we went through Daily, Review and Retrospective, each team designating a speaker for debriefing. However, other team members could always pitch in and add relevant information. I really enjoyed working with my fellow team members Roxana, Paula and Loredana. Our different professional background enabled us to handle change at a faster pace and to take over tasks accordingly. Although we were on a tight schedule (both in terms of the simulated sprint and the actual workshop), the whole endeavor was truly pleasant. Diversity for the win!

  1. Explore all Avenues!


The second workshop I had registered for featured two passionate content owners, “veterans” of the Testing Camp: Oana Casapu (Cluj) and Claudiu Draghia (Bucharest).  Their session placed special emphasis on debunking misconceptions about exploratory testing allegedly not having an underlying structure. The activities Oana and Claudiu had in store for us followed a well-structured progression towards achieving this goal.

The first step dealt with semantics in a technical context. Once we had established the difference between an “approach” and a “technique”, we were prompted to embark on an individual assignment, bearing in mind what Cem Kaner put forward: “Exploration and script-following reflect broad visions about the best way to organize and do testing, not specific tactics for designing individual tests. Therefore, we call them approaches rather than techniques.” The ensuing debriefing session rendered interesting results. However, throughout the individual assignment, the participants favoured techniques they were already confident with or had an intrinsic affinity for: Domain Testing, Risk Testing, Usability Testing, Load and Stress Testing etc.

That is why the subsequent activity aimed at encouraging us to forage deeper into our toolbox of techniques and re-think our strategy in context. Coming up with mnemonics to sort through the variety of techniques would prove equally effective. In order to aid us in drawing up our mission, Oana and Claudiu introduced us to Session-Based Test Management and its metrics. This instrument is highly useful in structuring exploratory testing, paradoxical though it may sound. It caters for coverage, quantifies effort and enables backtracking per session. The SBTM format, in addition to a bug reporting tool, can provide more accurate insight into a tester’s activity. The group work we delivered while working with SBTM drew us from our comfort zones and had us tackling not only the challenges of an unfamiliar application, but also those of a different mindset. I, for one, intend to experiment with the SBTM template. And since we tested various functionalities in Impress to reach our conclusions, I’m thinking about carrying on with this activity in my spare time. Because testing is fun!

  1. Let’s Put this to Good Use!


Since I’m keen on all things frontend-related, I chose my third workshop accordingly. This particular afternoon session looked into the ins and outs of Usability. Andreea Popescu (Cluj), a specialist on the matter, gave us an enthusiastic and well-researched view into this concept, while engaging the participants in an interactive and meaningful learning experience.

Andreea defined SMART objectives from the very beginning and enabled us to track them throughout the workshop, by correlating each of them with a practical activity. Group work was the core method. First of all, the four groups brainstormed “Usability” in the broad sense, just to arrive at the conclusion that a single definition is by far not comprehensive. The latter taster paved the way for the second exercise, during which we researched the cultural aspects of the countries we had previously extracted in preparation for this stage. Alex, Levi and I thoroughly enjoyed researching the specifics of the Spanish UI, colour scheme, browsing and spending habits, etc., while efficiently dividing the workload, rating and documenting our findings.

Now that we had the overview, we could put it to good use during the third exercise. Andreea had prepared another batch of information for us to extract. This time, each group drew a website. The assignment revolved around testing the respective website and identifying various usability features and issues. To guide us through this process, we had print-outs with usability questions and tools. Consequently, apart from the “Spain-ready” features (in the words of Alex :-)), we came across aspects that needed to be adapted for the Spanish Go Live, in light of what we had researched. They ranged from the layout and chromatics to various technical and linguistic inconsistencies. The subsequent debriefing session created a lively context for intercultural exchange among the groups. Truly inspiring!

  1. My “Lessons Learned”


Since I’m very fond of drawing up lists, colour-coding and mapping any learning outcome, I couldn’t help but summarize this engaging experience. This is what I’m taking with me:

  • You ARE Agile. You don’t “do” Agile.
  • Scrum is a framework. Not a methodology.
  • “Approach” and “technique” are not interchangeable terms while testing. However, you can apply most techniques in an exploratory and/ or scripted manner.
  • Choosing a technique or another should be done in context.
  • Tracking coverage via Session-Based Test Management enables you to also calculate the effort you put into tasks. Moreover, it helps with backtracking test cases, employed values etc.
  • The definition of Usability is not set in stone. While its main focus lies with identifying patterns or innovating by combining them, the cultural aspect is the one that actually prompts the approach to development and testing alike. Solid arguments rely on thorough research. You sometimes employ a comparative strategy in order to make improvement suggestions. Various tools enable you to conduct usability audits.

Last but not least, this may well have been an “Autumn” Camp, but TdT is in season all year round. If you wish to stay up-to-date with technical topics, learn something new, give a hand in facilitating a workshop or simply experience a sense of belonging, just join the monthly  meet-ups and become part of a passionate community! See you around! 🙂


TdT Cluj Monthly Meetup #11 – Testing Clinic

One challenge I see in organising Tabara de Testare is finding testers that want to share / present their stories. This is something that we struggle with quite often in Cluj, and I know that the other chapters are in a similar situation.

We came up with the following solution for the meetup organised in Cluj: if for a particular month we’re not able to find testers that want to present, we’re having a Testing Clinic, where every participant can come with their own testing / managing / scripting / teaching problem and discuss it with the other attendees.

We had two meetups with this format, and I think they turned out pretty OK as everybody who shared a problem left with some ideas (I saw them writing things down :-D).

I’d like to share with you my impressions and the things I remember from the second Testing Clinic, the one we had this month.

To give you some ideas about how it happened, we were 28 testers, we arranged the chairs in a circle / oval so that we have eye contact with each other, and we waited for someone to break the ice and start with a problem.

(For the sake of confidentiality, I won’t use the real name of the testers or the company they work for.)

Problem #1: “I need to make a demo for a possible client, about automating testing for their mobile application (iOS), but I don’t have the code for the app. Does any of you know any tool that can be used for a case like this?”

This is when the discussion began:

  • somebody said that they could look at Sikuli –
  • others asked why they need to have a real demo, as they don’t have the app, and not go with some mockups?
  • others asked why they don’t ask for the code; if they want to make a demo, wouldn’t it make more sense to have a real demo and use the tools they will most probably be using during the project?

Problem #2: “I work on a medical software project, we have no automated scripts but I would like to start implementing some. One of the problems I have is that the management is afraid of doing test automation as they don’t know how it will impact our FDA and ISO certifications. How could I present this to the management?”

  • I shared a story from a medical software project I worked on, where I developed a tool that helped us verify some of the requirements (FDA requires that every requirement of the application needs to be covered by a test). In my case, I had to write a requirements document for my tool, and one other colleague to write a test plan and test my tool. This was required by FDA for the type of medical software that we were building, so I suggested that she checks FDA requirements for their project to see if they need to validate the automation tool.

Problem #3: “I have two teams of testers, team1 works on a mature project, is very organised and everything works fine; team 2 works on a startup project, they don’t use documentation to test, but follow developers instructions and then they do ad-hoc testing and don’t keep track of what they test. Team 2 have trouble giving status reports about their work, and also don’t test some important features asked by the client. For the moment the client is happy with what we deliver, the project manager is also happy, but I’m afraid that in 6 months when the project will be more complex, everything will fall apart. How can I sell the approach used by team 1 to the project manager from project 2?”. We asked some clarifying questions, and understood that he was the test manager for both teams.

  • this was the most discussed problem of the evening; after several questions, we were able to break the problem in two:
    • the testers from team 2 were not motivated to do a good job, and they didn’t want to improve their testing (as long as the client is happy, why should we change anything?)
    • the PM for project 2 was overwriting all the decisions taken by the test manager. The development process, so also the testing process, had been defined by the PM, and she was not willing to change anything
  • several solutions have been suggested for the “PM problem”:
    • go and meet the PM, to have a better relationship with her
    • if you think the quality of the product will suffer in the long run, escalate the problem to the PM’s boss
    • present the reports in such a way that the PM will understand that the testing team is not doing a good job (they don’t cover all the requirements, which causes patch delivery; if this will continue, and the product will grow, it’ll be hard to keep track of things)
    • implement changes and don’t tell the PM; use the results to show her the benefits
    • let the team fail once, and then use the results to show the PM what can happen if the testers are left by themselves (they used 2 weeks sprints, they were in an early stage of the product so it’s better to fail now than in 6 months)
  • several solutions have been suggested for the “team problem”:
    • make a documentation reading session, something like a book club where they could go through the user stories
    • find someone within the team that has the same values as you, and that is willing to help you improve the team’s work
    • go and work with them side by side; spend more time with this team to win their trust
    • go out for beer / dinner with the team, to get closer to them
    • when evaluating the testers, give them negative feedback and decrease their salary; if this won’t wake them up, they might leave the company which in long run might be beneficial
  • one of the testers asked how could he be sure that the approach used by team 1 will work for team 2; after all, they are two different teams, working on two different projects, with different PMs and different clients… His answer was that experience shows that team 1’s approach worked well so far, even on other projects, so from his point of view it will also work on this project.

Problem #4: “I noticed that some of the tests and test data I use on different projects (for example: valid addresses for every EU country, tests for using a Mastercard Card). How can I handle all this test data to be able to search through it if I need it on future projects?”.

After asking some clarifying questions, we found out that she doesn’t always remember that she previously tested a similar feature / project or had to use this kind of data, and she would like to have an easy way to search through her documents. Plus the other team members could benefit from her work.

  • one solution was to have all the documents put in a source control system, add tags or descriptions for each file, and then interrogate the SCM to see if something similar can be located. One downside of this approach would be that, depending on how you organise your test data, some files might have lots of tags. Another one is that people need to install SCM clients to access the data.
  • another solution was to have a wiki and enter the details there. As she wanted to search for text, wikis are very good for doing that, and they are also much nicer to use than SCMs (you only need a browser, and you don’t need to be a developer to understand how they work). Plus you can attach any type of files if needed…
    • a tester shared a story where he was bombed with questions from his fellow testers, so he decided to build a wiki and put the things he knew there. Even if he did that, his colleagues still preferred to come directly to him for information, so they come up with an idea to give incentives to people to use the wiki more: they added a Google Analytics account for every page, and the authors will get a bonus at the end of the month based on the number of views their pages had. Another good aspect, from his point of view, was that this way they could see which computers, and thus testers, use the wiki, and which don’t. I found this approach a little too much for me, as people might abuse of such a system, but he said that it has been working OK for them so far.

Problem #5: “I work remotely with a team from Finland, formed of an experienced test lead and several developers. I am the only tester in the office that works on this project. The remote team is not very communicative, moreover they have a culture for not disturbing people with too many questions. Even if they reply to my emails, I sometimes feel the need to talk to somebody about my work, but I don’t have who to talk to as I don’t want to bother the remote team too much, and the local team is too busy. What can I do in this case?”.

  • communicate more with the test lead – they do talk, but the test lead works on another project too, so she’s quite busy…
  • attend team’s meetings – because the developers don’t feel comfortable talking in English, they don’t do that. The test lead attends the meetings and sends her the meeting notes. The developers reply to emails / chat, but when it comes to spoken English they don’t have too much practice.
  • go there and meet the team – the team works remotely most of the time, so when she visited their office, most of them weren’t there. For example, she thinks she communicates better with one of the guys because she has had the chance to meet him.
  • find and use focusing – defocusing techniques to not feel bored.
  • find someone in the office you could talk to; I said that I find it hard to believe that everybody is so busy that she has nobody to talk to.

We had 4 testers that presented 5 problems within the 2.5 hours of the meetup, lots of new testers joining the conversation and presenting their ideas. I would like to thank the ones that dared to share their problems. I also want to thank the testers that joined the conversation and offered solutions.

At the end of this article I’d like to stress that this kind of format will not ensure that you’ll implement the ideas presented by the other participants, and that it’s up to you what you do with all this information. But I think it can be a great way to build an interactive discussion, and get input from testers working in different contexts.


P.S. the evening ended with 8 of us going for a drink and food, and discussing about strange customs from marriage, funeral and baptising ceremonies until midnight, which was a lot of fun 😀

Ce spuneti de-o tabara de testare la vara?

Update: 17.04.2012

Ma bucur sa vad ca exista oameni dornici sa se implice intr-un astfel de eveniment. Tinand cont ca suntem deja la jumatatea lunii aprilie, cred ca ar fi util sa incepem sa vorbim despre lucruri mai concrete.

Voi reveni cu detalii despre o sedinta online, deoarece sunt oameni din diverse locatii care doresc sa participe.


Azi dimineata am dat peste si mi-am dat seama ca asta e unul din rolurile pe care as vrea sa il ia Tabara de Testare.

Urmatorul lucru care mi-a venit in minte a fost: de ce nu organizam o tabara de testare la propriu? Cateva zile (o saptamana 🙂 ) in care sa stam cu oameni care nu stiu ce e aia testare, dar care vor sa afle/descopere si sa invete mai multe despre asta:

  • sa dezbatem despre rolul unui tester
  • sa vorbim despre informatiile pe care poti sa le oferi ca tester
  • sa facem ateliere cu exercitii si puzzle-uri
  • sa vorbim despre ce inseamna sa scrii un bug
  • sa folosim utilitare care pot fi folosite pentru a ne face viata mai usoara si a fi mai eficienti

Asta e doar un gand, si mai e mult de lucru pana sa se concretizeze, insa as vrea sa stiu daca exista voluntari (testeri experimentati, si nu numai) pentru organizarea un astfel de eveniment.