Gearing up for CodeCamp

Posted on March 5, 2018 by Raluca Weber

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
scope creep
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
user involvement

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 retention.
SIMI (Creative 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.
ERICA (Customer 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 spending habits.

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, suggesting various approaches to handling browser issues, app size and JavaScript.

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.

Gamification

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 trends.

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!

Risk Analysis in Software Testing cu James Bach

Posted on January 25, 2017 by Simina Rendler

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:

Happy Testing!

Posted on January 6, 2017 by Raluca Weber

Vezi versiunea în engleză aici.

The Autumn Camp 2016: A Trip down Memory Lane

Posted on October 12, 2016 by Raluca Weber

Vezi versiunea în engleză aici.

Testing tours at TdT – a tester’s tale

Posted on September 14, 2016 by Levente Balint

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.

Testability Tours – Testing Tours Meetup

Posted on September 13, 2016 by Alexandru Rotaru

Last week at the monthly meetup organized by Tabara de Testare four of our colleagues organized a workshop on Testing Tours – we call them content-owners @ Tabara de Testare. Even though many people have written on touring over the past 10 – 15 years, this technique seems very little known and used by practitioners. This is why when my colleagues chose this theme I thought it was a great idea. Also, there are many tours that I’m not familiar with, so it was a good learning opportunity for me.

About 25 people gathered for this meetup and, after the introduction delivered by the content-owners, we split in teams of 2, 3 or 4 testers and we went out in the garden to get started. This month’s venue was ClujHub, and the great thing about this co-working space, besides the downtown location, is this garden!I teamed up with Gabi Kis, a fellow facilitator from Tabara de Testare. We took the tours cards prepared by the content-owners and went through all of them to see which tour we’d like to perform – all the other teams already chose their tour, so it seemed to me that we were a little behind; now that I’m thinking back, I’m surprised that I was not stressed by this :). Having the cards in a physical form, not on a PowerPoint slide, made it easy for us to take them in the garden – I also noticed that all teams took the card for the chosen tour with them One other aspect I liked at having the cards was that most of them contained enough information to give starting ideas on how to approach the tour.

Out of all the tours, we stopped at the following 3:

Scenario Tour – List realistic scenarios for how different types of users would use the product.

Testability Tour – Find features and tools to help in testing the application.

Complexity Tour – Identify the most complex things present in the application.

For the Scenario Tour we weren’t sure if we just needed to list the scenarios or also perform them. For the Complexity Tour we couldn’t find a working definition for “complexity in the application”. We decided to choose the Testability Tour.

Testability Tour on Slack

The application we had to work with was Slack, and luckily for me I was familiar with it as we use it at Altom and also on several projects. Gabi didn’t know the application very well, so for him it was a good opportunity to discover it.

As we didn’t have access to the internal documentation of Slack, we started listing the items we thought would make the application easier to test. We structured our notes in 3 sections:

App Features
1. API – can be used for generating test data
2. Websockets – same as API
3. Logs
4. Error messages (UI level, API level and logs) – this would help the tester to better understand when something goes bad
5. File sharing – can we have access to the cloud storage, but not through the application to control the test data?
6. Bots – can we use them in our chat tests to get responses?
Tools – as this is a client-server application, we started to think about what kind of tools we could use to test it:
1. Proxy (Charles / Fiddler) or Wireshark – to intercept the calls
2. data sets – Gabi said that he would like to be able to build specific data sets to put the application in different states.
3. server side
  1. Top / Perfmon / Nagios – to monitor server side resource utilization
  2. Jmeter – to send requests for load and performance testing
4. client side
  1. Perfmon / Top / Activity monitor – to check the desktop application resource utilization (the desktop client is a web app packaged as a standalone application)
  2. adb / instruments – to check the mobile application resource utilization
  3. Yslow and Developer tools – for the browser client
5. spider tools – to discover and list different features from the application; one aspect we thought of was that if the app uses custom controls the tool won’t be able to find too many things…
App Structure
1. ease of identifying elements for UI level test automation
2. how easy it would be to build our own test environment
3. client app installation – do we have a silent install? We asked ourselves if this is an app feature, as it can be used by sys admin to install Slack on large networks, or a testability feature, as it would allow us to setup the test environment easier.
4. server side installation – Can it be installed on premise? If yes, how easy can it be set up?

The above list was not created in the order it is now displayed, but more as a brainstorming session: when we identified one item, we would seek to explain why it could be relevant and try to categorise it in one of the main sections. What I find interesting is that we initially started with 2 sections, Features and Tools, and while coming up with new ideas we thought of adding a new section, App Structure (one could argue that this last section could easily be part of the App Features section).

About 45 minutes into the exercise there was still no touring of the application. We thought of taking one item from our list and start investigating it, so we chose the logs feature: we wanted to know if there are any client side logs on the desktop client.

I was using a Mac, so I thought Slack would save the data under the user’s Library folder, but nothing was there. We looked in Application Support and in Cache and we couldn’t see anything relevant. I looked in the System / Library folder, and still nothing.

I googled a bit for Slack logs and local storage, and for some reason Google decided to return https://status.slack.com, which is a nice status overview of the application. This makes me think that there should be more detailed monitoring on the server :). Unfortunately we didn’t find anything else relevant in the google search.

I looked in the application package from /Application. Nothing relevant there either.

The next step was to open Activity Monitor and double-click on the Slack process, and then I went to the Open Files and Ports and noticed that the user files are saved in ~/Library/Containers/com.tinyspeck.slackmacgap/Data

So this is where all the goodies are! Listing the folder content we noticed that most of the folders are aliases for system folders

We looked into Library, and found the same behaviour: lots of Aliases.

We also noticed the Logs folder. Unfortunately it was empty…

Next we went to Application Support and found Crashes and Slack. We digged into Slack and found what we were looking for: the log file.

OS X comes with a pretty neat tool, Console, which helped us to inspect the log. Below is an example of what my Slack log shows today. You can find information about users joining teams and channels, who left a channel, if websockets are opened, etc.

Now that we found our log, we decided to also look in what is saved locally, so we googled for an SQLite browser and found http://sqlitebrowser.org. We downloaded it and first opened localStorage.sqlite, but this had data from 2015. We then opened localCache.sqlite and found the cached data. We also tried to also open localCache.sqlite-wal but it was password-protected.

Going back to inspect the other folders from Application Support, we noticed that Slack has an alias for AddressBook, which made us wonder about the integration from these two applications and if we can use Address Book to inject data in Slack for testing purposes.

One of our last thoughts before the time was up was that we might have to define what we wanted to test. We approached this tour as if we wanted to test “everything” (we thought of client and server features, tools for performance and UI level automation). Had we have started with a more focused mission, our notes would have been very different.

What I liked about this session with Gabi was that we started with a brainstorming based on our previous experiences with similar applications and then chose one aspect – client side logging – and drilled in it. During all this time we tried to take notes so that we would use them for future, maybe more focused, touring. Here is our log, with notes in English and Romanian, to have a better view of what our outcome was after the tour.

After one hour of touring, it was time to go back inside and do a debriefing. Each team presented their work and the discussions were facilitated by the content-owners (what they learned, how they organized their work and notes…).

One thing I learned during the debriefing is that the order in which the tours are performed matters. For example the Scenario Tour more suitable to be done after the User Tour, as one needs a list of users to identify the scenarios, or the Feature and Configuration Tour to get familiar with what the application can do. This makes total sense now.

One interesting discussion was between Team #4 (Variability Tour) and Team #5 (Configuration Tour) as they toured around similar areas, and they were debating if their work was relevant for the tour taken. One of the content owners clarified that the Configuration tour can be seen as a sub-tour of the Variability Tour, the main difference being that the Configuration Tour is focused on persistent changes, while the Variability Tour is focused on temporary changes.

All in all it was a great workshop. People were highly engaged, showing thirst for knowledge and discussion. I challenge you to try testing tours with your team as an exercise and see the benefits for yourself.

P.S. of course such a meetup couldn’t have finished without a beer 😀

“Examples of Tool-Supported Testing” cu James Bach

Posted on January 6, 2016 by Oana

Pe 29 octombrie, James Bach a tinut o prezentare cu tema “Examples of Tool-Supported Testing” in cadrul Taberei de Testare Cluj. Ideile prezentate de el aduc o noua perspectiva asupra a ceea ce numim “testare automata”. De aceea ne-am hotarat sa publicam discursul lui “electrizant”, asa cum l-a caracterizat unul din participantii la eveniment, si pe site-ul TdT, pentru a fi disponibil tuturor membrilor TdT si nu numai.

Filmul are o surpriza la minutul dupa 1 ora si 32 de min, cand ramane doar sunetul disponibil din cauza unei probleme tehnice. Totusi am hotarat sa pastram si ultima parte din inregistrare pentru a prezenta intreg mesajul.

Exemplele de tooluri despre care vorbeste James pot fi gasite pe pagina de meetup a evenimentului.

II multumim lui James ca a raspuns invitatiei de a tine aceasta prezentare!

Agenda Taberei de Toamnă 2015

Posted on August 23, 2015 by Oana

ZIUA 0 – joi, 24 septembrie


20:00-21:00	Cina
21:00-22:30	Prezentarea participanților

ZIUA 1 – vineri, 25 septembrie

Attention: The internal data of table “2” is corrupted!

ZIUA 2 – sâmbătă, 26 septembrie

Attention: The internal data of table “3” is corrupted!

ZIUA 3 – duminică, 27 septembrie


8:30-9:30	Micul Dejun
9:30-12:30	Aventură în parc
12:30-14:00	Prânzul

Detaliile pentru inregistrare le gasesti aici . Te asteptam!

Attending the EuroSTAR conference 2014 in Dublin

Posted on February 24, 2015 by Alin

Working as a software tester you always have to stay in touch with everything that is new in the field: technologies, tools, platforms, best practices etc. You read articles, blog posts, books or even syllabuses for various certifications. But joining software testing communities and attending conferences stays on top of all these because it is the best way to meet new people, share ideas and get in touch with the latest trends in the software domain. There are many events worldwide where people present their work in the field of software testing and EuroSTAR is one of the greatest events.

The way to EuroSTAR 2014

Since 2012 I have attended the events organized by the national community of software testing in my home city of Timisoara. It is called “Tabăra de Testare” (the testing camp) and it is a community of testers and other professionals in the IT industry where people share their knowledge and learn from the professional experiences of other members during informal monthly meetings. Monthly meetings at the Tabăra de Testare are organized by using Meetup, a dedicated events platform.

In October 2014 Tabăra de Testare organized the contest called “Tabăra de Testare is camping at EuroSTAR !”. I have entered the contest and written an article called “Tabăra de Testare – meeting people and sharing ideas”. I was fortunate enough to have my article drawn as the winner of the contest. So, I have won the prize: a 3 day conference ticket to EuroSTAR! The company I work for has taken care of accommodation and transport expenses.

The EuroSTAR conference

Every time I have searched for the main events that are held in Europe, EuroSTAR was always the most interesting conference found in the results list. The agenda always includes the most relevant topics presented by well known and experienced speakers from around the world. I always wanted to attend such a great event and now I got this opportunity!

The location in 2014

EuroSTAR is the premier and largest gathering of European software testing professionals. It takes place every year since 1993 in different cities like London, Edinburgh, Munich, Stockholm, Amsterdam and Brussels. In 2014 EuroSTAR was held in Dublin, Ireland. The venue was the CCD (Convention Center Dublin), a perfect place to host it.

The agenda

The first day was reserved for tutorials and the next 3 days for the conference. As I have written before, I had access to the 3 days conference. There were keynotes held in the main auditorium followed by parallel presentation sessions which you could attend. You could choose between 4 different topics. The fact that you could see a short preview of all the topics on the conference website was very welcome. I liked the way each keynote started: before each keynote in the auditorium, highlights videos were displayed on the large screen above the stage while the official conference music was played. After that, the programme chair Paul Gerrard introduced the topic and its speaker and welcomed the speaker on stage. This also proves why EuroSTAR is such a great event! There were plenty of brakes for discussions between participants and speakers. An expo area for companies was also organized. There, you could interact both with companies that offer software testing services and with companies that develop software testing tools. For testing your skills and social activities, there was a testing lab available. Social events were held every evening in various places including the famous Trinity College and Guinness brewery for people to interact, chat and share experiences. In the lunch break I could try the traditional Irish food that was offered to the participants and in the evening an Irish band entertained us with traditional Irish music for about a half an hour.

In the end, the closing ceremony was really impressive because Paul Gerrard presented a summary of the 2014 edition and all organizers went on stage while a traditional Irish song was played in the background. He concluded the 2014 event by welcoming on stage the programme chair (Ruud Teunissen) for the next EuroSTAR conference that will be organized in 2015 in Maastricht, the Netherlands. Ruud announced the EuroSTAR 2015 theme “Walking the testing talk” and invited us to join the conference in 2015. During this closing ceremony I had a feeling I was attending the Olympic Games closing ceremony!

The topics

I have attended different presentations covering various topics like automation, skills, leadership, test strategy, agile and security. All of them were interesting and it was quite hard to decide which one to attend. I will further describe some of them which I liked very much.

The Internet of things presented by Andy Stanford-Clark (UK): Andy gave us an insight on how the Internet is growing and its impact on our lives. Nowadays, you can see in real time if your train, plane or ship is running on time. You can also monitor the electricity consumption in your home and the consumption of every home appliance like TVs or refrigerators directly on your smartphone or tablet via the Internet. All these require a large amount of data to be transmitted and the systems must be designed accordingly. Solutions should be based on some key aspects like scalability, availability and security

Gamification – How to engage and get help from users of a test framework, presented by Kristoffer Nordtröm (Sweden): Kristoffer presented to us how his company implemented a method to get more feedback for a test framework developed inside the company. All the employees were involved in a game: they were asked to participate with any idea that could improve the tool and they were rewarded with points for that. After obtaining a specific number of points, they got some prizes: t-shirts, pencils or coffee mugs. Basically, this activity is fun to do and it helps improve the activity within a company and the communication between people inside it.

Testing Traps to Avoid in Agile Testing presented by Janet Gregory (Canada): Janet summarized her experience with different problems she faced when applying the agile testing concept and she has put them into 5 categories called: Waiting for Tuesday’s Build, Testers aren’t “really” part of the team, Maintaining a “Quality Police” mindset, Trying to test everything manually, Forgetting the big picture. She has also presented the risks for every category and proposed some solutions in order to avoid problems.

What ? Why? Who ?How ? Of Application presented by Declan O’Riordan (UK) won the best presentation award at EuroSTAR 2014. Declan has a lot of experience in web application security and he has described to us the web applications vulnerabilities and he provided us with examples for possible risks and attacks. He also invited us to read some guidelines written by him which contain some best practices regarding web application security.

Diversity in your team – embrace it or lose the best thing you have presented by Julie Gardiner (Sweden) was my favorite presentation. She described a method to assess the testers’ working style by answering a set of questions. She identified 4 tester styles: the pragmatist, the pioneer, the analyst and the facilitator. The presentation was quite interactive because Julie let us complete the questionnaire and so we could discover our own testing style! To better understand these types, she explained the 4 types by giving examples on a certain situation and told us how a person belonging to each type would react in that specific situation.

Changing Mindsets – Learn, Test, Lead [by Example] presented by Alexandru Rotaru (Romania): Alexandru presented a way to change the mindset regarding the software testing activity and emphasized the importance of it. He talked about the software testing community in Romania called “Tabăra de Testare” (the testing camp), a community that he co-founded.

Final thoughts

Attending the EuroSTAR conference was a great experience. It is simply one of the most important events in the software industry in Europe, a perfectly organized gathering of the best professionals in the domain and a tremendous opportunity for me to discover the latest trends in software testing.

Thank you EuroSTAR for organizing this great event and “Tabăra de Testare” for offering me the opportunity to attend the EuroSTAR conference!

Cheers,

Alin

Tester and PM: The two way road with Anca Rarău at TdT Cluj

Posted on August 1, 2014 by Simina Rendler

On the first Wednesday of each month it’s tradition for the testing community from Cluj to gather around for intense testing related discussions followed by more chilling discussions involving beers. Or tea.

On July 2nd, we invited Anca Rarău, Senior Project Manager, at TdT Cluj to discuss about the interaction between the project manager and the tester. Quite a new approach for the members of the community, that lately have been wandering between automation frameworks, security testing tools, occasionally going back to the basics of testing, to eventually return to cool or fresh testing techniques and methods.

Why would we even consider such a topic? Personally, I was convinced by its value a little time ago, within an internal event, when Anca has made her case on how should we, PMs and testers, help each other. So I invited her to continue her research on a larger group of testers having various backgrounds, experiences and a reputation of critical thinkers.

The topic was divided into two sections. First, Anca presented the qualities of a good enough tester and, furthermore, ones that an excellent tester should have, as per her perspective. Then the focus changed and the testers answered the same questions with respect to the project manager role. The second section was even more pragmatic, as we went through the most important project management knowledge areas to stress on the ways the tester could and should help the project manager. And for the equilibrium in the universe, we ended with the ways we would like to be helped by the project manager.

If, at first, the agenda predicted some common sense discussions, the more we got into the subject the better we realized how helpful it was to have such a nice structured memento from a PM. For more than 2 hours, we went with Anca through 5 slides of expectations and action items and countless examples: some from her, with how-to’s or how-not-to’s, some from the participants on how-should-I or what-is-the-best-approach. Looking over the feedback we received, Anca was really appreciated for the real live situations she based her arguments upon, for the steadiness she stated her opinions and handled the most skeptical participants. (More feedback, kudos, pictures and follow up discussions are available for the group members on Meetup.)

As we checked the 27th local Meetup, we proudly achieved another goal we had, of inviting more non-testers talking with our testers. And we are ready to return the invitation to our peers’ communities, just drop a line. In the meanwhile, we are preparing for a cooler, summer adequate meetup, involving beer. Or iced tea.

Tabara de Testare

Despre testare software si nu numai

Category Archives: Software Testing