Am definitivat agenda Taberei din acest an si am deschis inscrierile. Te invitam sa vizualizezi atelierele pe care content owner-ii din acest an le-au propus si sa te inscrii la cele care sunt de interes pentru tine folosind formularul de inscriere!
Daca nu ai participat la editiile anterioare, sa stii ca e un eveniment in care ne adum impreuna cu alti testeri, maxim 80 la numar, si participam la ateliere practice. Adica lucram 2 zile la imbunatatirea unor abilitati utile in activitatea noastra. Avem ocazia sa ii cunoastem pe ceilalti testeri si sa impartasim provocarile, interesele si motivatia noastra.
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:
API – can be used for generating test data
Websockets – same as API
Error messages (UI level, API level and logs) – this would help the tester to better understand when something goes bad
File sharing – can we have access to the cloud storage, but not through the application to control the test data?
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:
Proxy (Charles / Fiddler) or Wireshark – to intercept the calls
data sets – Gabi said that he would like to be able to build specific data sets to put the application in different states.
Top / Perfmon / Nagios – to monitor server side resource utilization
Jmeter – to send requests for load and performance testing
Perfmon / Top / Activity monitor – to check the desktop application resource utilization (the desktop client is a web app packaged as a standalone application)
adb / instruments – to check the mobile application resource utilization
Yslow and Developer tools – for the browser client
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…
ease of identifying elements for UI level test automation
how easy it would be to build our own test environment
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.
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 😀
We had the first longer workshop organised by TdT Cluj, and it was really fun and useful! 27 people (3 instructors, 1 person responsible that we had all we needed, 1 PR and 22 students) spent more than 6 hours to learn how to write tests with Selenium Webdriver and Python for a Mozilla website, and I personally would have continued if the time we had reserved the room for hadn’t been limited.
People started to arrive around 11:30 and we had some tea and coffee until 12:00 when Alex Lakatos started with a short presentation of the mozillawebqa team. Then, Bebe (aka Florin Strugariu) took control of the event :-).
The workshop had three phases:
The setup of the test environment. Something that should have been like a walk in the park, as we already had installed some of the tools, turned out to be a real software project :). We had lots of configurations – Win 7 and Win 8 (one even on a tablet – you should see the picture with the Windows tablet and the Apple keyboard and mouse! As Ioana said, could it have got more hipsterish than that? :-D), MacBooks and Linux machines, different IDEs (Aptana of pyCharm) and even someone with a custom version of Firefox – which revealed many problems. After more than one hour and a half everybody had the setup running:
python virtual environment created and working – I personally struggled with this as I had too many versions of python installed on my laptop, the default being 3.1, and the virtual environment didn’t like that too much
python dependences installed in the virtual environment – that turned out to be quite challenging too as the internet connection wasn’t ready for so many people downloading all at once
we were able to run the two existing tests from the repository.
During this period Bebe, Alex and Alin – our instructors 😀 – moved from one person to the other to solve everybody’s problems. I think they handled this really well, especially as there were so many of us, and only three of them.
The next step for Bebe was to show us how they write tests at Mozilla. He was writing the tests and sharing his screen on the projector, and the rest of us followed along. Together with Alin (and Alex) they answered questions, helped people debug if something didn’t work or presented us some of the practices used by their team. We implemented two tests:
one for going to the Events page of the website, and looking for an element on the page
one for searching an event (entering “test” in the search field) and verifying the number of results returned (in our case we had 1 result).
Eniko had a really nice comment on the meetup page, that it was great to see us working as teams: people were talking and helping each other, debugging failures and trying to understand why something wasn’t working. It was so nice, that we didn’t even feel when time flew. If it wasn’t for the pizza and a small incident in one of the other rooms, most probably we wouldn’t have stopped until the end.
Once the new tests were running, we moved to the next phase of the workshop: writing tests for the tickets opened on github. Unfortunately it was already late, and we had less than an hour for that, so I guess only few were able to finish theirs.
My takeaways from this workshop are:
we start to be a real community! People feel comfortable asking for help, and offering help even if they meet for the first time
open source projects are a great opportunity for people to learn new things and do that in a way that others can benefit from their work
we should have a follow-up for this workshop; now that many of us have the setup running, and know the basics on how it works, we should spend more time on writing tests
Windows 8 tablets are real computers, if one can install the setup for test automation and run tests from one! 😀
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 – http://www.sikuli.org/
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 😀
4 dintre colegii nostri de la Altom s-au hotarat sa participe la concursul TeamSTAR competition organizat de EuroSTAR. Pentru asta au facut un film de 2 minute in care au prezentat pasiunea lor pentru testare si de ce vor sa participe la conferinta.
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 http://summerqamp.org/ 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.
Pentru cei care au urmarit TdT, exista cateva diferente intre conferintele organizate la sfarsitul anului trecut si acest workshop:
durata: deoarece se va intinde pe parcusul a doua zile, vom avea ocazia sa ne cunoastem mai bine si sa acoperim anumite subiecte mai in detaliu.
taxa de participare: nu exista nici o taxa de participare, dar fiecare participant va trebui sa-si acopere cheltuielile cu pranzul. Altom va suporta cheltuielile cu sala, echipamentul , cafeaua / ceaiul si apa.
numarul de participanti: pentru a facilita schimbul de idei si experiente, numarul de participanti este limitat la 15 persoane, incluzandu-i pe James si Maaret.
prezentarile: vom incerca sa alegem mai atent prezentarile, astfel incat fiecare din ele sa fie un raport bazat pe experienta.
participarea: am trimis deja invitatii in functie de gradul de implicare in (incipienta) comunitate a testerilor din Romania. Daca nu ai primit invitatie si vrei sa participi, te rog sa imi dai un email la alex [punct] rotaru [la] altom [punct] ro.
Deoarece vom avea cel putin 2 participanti internationali, limba folosita in timpul conferintei va fi engleza.
What are the things that bother you most in your day-to-day work environment? We want to hear from you experience reports of everyday problems you’ve stumbled upon, the way you dealt with them, and the solutions you have come up with.
In case you haven’t found a solution to the issue, even better, because we love a good challenge! You can present the details of the situation and the steps you’ve taken and we’ll try to identify solutions together/discuss it further.
What we’re looking for: challenges and the ways you chose to deal with them, and not just complaints.
What we’re NOT looking for:
theoretical ideas you’ve read about but have never applied or experienced,
generic stories with no practical bearing,
stories for which the context is not available.
Examples of presentation topics (to guide you in identifying and naming your challenges):
Documenting your testing efficiently
How to deal with the false belief that the solution to every problem is a tool (magic tool to solve any problem)
Fighting against unreasonable requests/expectations from managers/clients (100% automation, complete coverage)
The shift from the traditional mode to more effective and relevant approaches.
As a result of the workshop, we will have a summary report of key learning points and conclusions to share with the testing community through http://tabaradetestare.ro.
În urmă cu 12 zile a avut loc la Iași cea de-a doua întâlnire TdT – Peer Conference.
Pentru mine totul a început joi seara cu un drum București – Cluj cu trenul, urmat vineri de o călătorie Cluj – Iași cu mașina. Recunosc că nu a fost cea mai scurtă rută din București către Iași, dar cred că se putea și mai rău :).
Sâmbăta dimineață în jur de 8:30 am fost la sediul WorldTradeCenter unde ne așteptau Ana-Maria Figher împreuna cu Daniel Buleu care se ocupau de ultimele detalii pentru eveniment.
Toată lumea a fost punctuală, în afară de un participant care nici nu a binevoit să ne anunțe că nu vine. E foarte important să precizez că deoarece el nu ne-a anunțat măcar cu o zi înainte, altcineva nu a putut participa in locul lui. Sunt curios dacă persoana respectivă ar fi avut același comportament / atitudine dacă ar fi plătit o taxă de participare.
Am găsit la Iași oameni pasionați de testare, care vor să învețe lucruri noi și să-și perfecționeze abilitățile, să împărtășească din experiențele lor și să le asculte pe ale celorlalți.
Deși toți participanții au luat parte la discuții, aș vrea să le mulțumesc în mod special celor care s-au implicat cel mai mult și au adus cea mai mare valoare prin întrebările și comentariile lor: Victor Stuiber, Ana-Maria Figher, Maria Bahnareanu și Adina Pitul.
Am continuat ideea de feedback în timp real pe un flip-chart si la acest eveniment. Dacă nu foarte mulți participanți au dorit să folosească această metodă pentru a ne spune părerile lor despre eveniment
aproape toți au completat formularul online pe care l-am trimis.
1. Cum ți s-a părut întâlnirea?
Foarte reușită – 57.1%
Reușită – 42.9%
Mai puțin reușită – 0.0%
2. Cum ți s-au părut prezentările? (Notele sunt date pe o scară de la 1 la 10)
From zero to tester, Adrian Apostolache- 5.50
Help them to help you, Victor Stuiber – 7.54
Test automation techniques for Windows applications, Dragoș Cogean – 6.43
În primul rând vrem să mulțumim tuturor celor care s-au înscris și celor care ne-au ajutat cu promovarea și organizarea evenimentului din Iași.
Motivul pentru care am ales să mergem cu un număr atât de mic de participanți este strâns legat de formatul conferinței care presupune un grad foarte mare de interacțiune.
Evenimentul din Iași are parte de un invitat special: Nevil Patel, Archtiect Quality Assurance @ Embarcadero. Din acest motiv vom încerca să folosim engleza, pe cât posibil, pentru prezentări și discuții.
Mai jos puteți găsi agenda evenimentului și lista finală de participanți.
09:30 – 10:00 – Sosire participanți
10:00 – 11:00 – Introducere
11:00 – 12:00 – Prezentare 1
12:00 – 13:00 – Pauză de masă
13:00 – 14:00 – Prezentare 2
14:00 – 14:15 – Pauză
14:15 – 15:15 – Prezentare 3
15:15 – 15:30 – Pauză
15:30 – 16:30 – Prezentare 4
16:30 – 17:00 – Concluzii
Alexandru Rotaru, Facilitator
Oana Casapu, Content Owner, Prezentator
Adrian Apostolache, Prezentator
Victor Stuiber, Prezentator
Dragos Cogean, Prezentator
Alina Avadani, Participant
Radu Buteica, Participant
Ioana Serediuc, Participant
Adina Pitul, Participant
Raluca Suditu, Participant
Ana-Maria Figher, Participant
Alina Cojocariu, Participant
Maria Bahnareanu, Participant
Adrian Marton, Participant
Cristina Pascarel, Participant
Ioan Catalin Onut, Participant
Oana Alexandru, Participant
Adrian Constantin Culea, Participant
Ioana Miruna Ropota, Participant
Nevil Patel, Invitat Special & Participant
Ne vedem sâmbăta, 19 Noiembrie, în clădirea WorldTradeCenter din Iași, Str. Anastasie Panu 26, la mezanin.
P.S. Sunt semne că evenimentul va ieși cel puțin la fel de bine ca cel din București, astfel încât să-i pară rău lui Cătălin că a mers în India în loc sa vina la Iași. 🙂