Testability Tours – Testing Tours Meetup

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!p_20160907_190235_pnI 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:

  1. 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?
  2. 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…
  3. 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 😀


TdT Bucuresti – Intalnirea din Iulie

Este Iulie, sau “luna lui cuptor” cum i se mai spune, ceea ce inseamna caldura, concedii si in general un ritm mai lent.

Totusi in comunitatea “Tabara de testare” energia este inca prezenta, si asa s-a intamplat ca joi, 7 Iulie ne-am strans la una dintre locatiile uzuale pentru intalnirile lunare, Optaros, la al lor minunat etaj 12. Trebuie sa folosesc ocazia pentru a le multumi pentru sprijin si ospitalitate!

Despre automatizare in testarea web s-a tot vorbit si au fost multe prezentari si chiar workshop-uri (vezi Selenium weekend workshop), si astfel primul punct de pe agenda (“Automation Testing using an enhanced XLT Framework”) parea cumva o repetitie. Totusi, nu a fost chiar asa, si asteptarile mele cel putin au fost depasite. Prezentarea a fost despre XLT, un tool de testare automata pentru web. Prezentarea a fost mai mult decat o trecere in revista a informatiilor de pe site-ul aplicatiei, si partea cea mai faina a fost exercitiul de la final. Cred ca ar sustinatorii ideii de mob-testing ar fi fericiti, pentru ca sala a participat la crearea unui test de la zero. Ai auzit Maaret Pyhäjärvi ? 🙂

Partea a doua a fost dedicata unui exercitiu de grup, o varianta de Activity (https://cf.geekdo-images.com/images/pic1882656.jpg) adaptata pe teme de testare.

Activity Game - Box

Ce pot sa spun, decat ca ne-am distrat cu momentele de mima ale lui Stefan, si cu desenele lui Andrei si ale Adinei (care deja a fost mai rapida cu postarea din care am imprumutat imaginea de mai jos cu o re-interpretare a imaginii lui Jenkins).

Jenkins drawing
Astfel de momente si jocuri fac comunitatea mai frumoasa, si cred ca este de preferat si mai utila comunitatii aceasta cale decat abordarea unei atitudini combative si defensive asa cum s-a mai intamplat cu alte ocazii.

Energie pozitiva, distractie si un sentiment de comunitate, asta insemnat pentru mine ultima intalnire a #tabaradetestare Bucuresti.

Photo credits:



“Examples of Tool-Supported Testing” cu James Bach


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!

Principii de testare – un duet reusit

Vara a luat sfarsit si cu ea s-au dus si intalnirile Test and Beer.

Toamna aceasta a inceput cu o premiera. Doi dintre colegii nostri, Dana Aonofriesei si Gabi Dobritescu, si-au unit fortele pentru prezentarea din septembrie.

Avand in spate experiente diferite au abordat o prezentare in paralel a principiilor de testare. Ne-au impartasit viziunea lor asupra fiecaruia, descriindu-ne problemele de care se lovesc si solutiile pe care le-au incercat.

Principiile atinse au fost:

  • Testarea exhaustiva – De multe ori echipele cu care lucram se asteapta la asa ceva de la noi, sau cel putin asta cred. Ce facem in acest caz? Dana ne-a povestit despre cum foloseste pairwise testing pentru a avea o acoperire buna in timp ce Gabi ne-a spus cum planifica si prioritizeaza in functie de timpul pe care il are la dispozitie.
We Have To Test Everything

We Have To Test Everything

  • Oracole folosite in testare – fac testarea mai grea sau mai usora? Cand si cat de des trebuie updatate?
  • Dependenta de context – am primit cateva exemple de cum influenteaza contextul in care va rula aplicatia tipul de problemele care pot sa apara in productie
  • Test to pass vs. test to fail  – un subiect ce a pornit cateva discutii. Ce e prioritar: sa verificam daca aplicatia se comporta conform cu specificatiile sau sa gasim the big, bad, ugly bugs?
  • Inceperea testarii cat mai devreme in cadrul ciclului de dezvoltare – este unul din primele lucruri pe care le aflam despre testare, cum costul unui bug creste cu cat este descoperit mai tarziu in cadrul ciclului de dezvoltare. Si totusi se intampla des ca testerii sa nu fie inclusi in definirea requirementurilor. Am primit de la Dana si Gabi cateva idei interesante despre cum am putea sa convingem echipa sa includa testarea in discutiile initiale.
  • Popularitatea testerului – Sunt mai importante soft skills sau technical skills pentru un tester? Parerile au fost ca de obicei impartite generand noi subiecte de discutie.

Si intalnirea nu s-a terminat aici. Ca de obicei am continuat discutiile despre testare. Multumim Optaros pentru sala si pizza.

Intalnirea din Octombrie este deja stabilita. Detaliile pot fi gasite pe meetup aici. Ne vedem acolo!

Va las cu cateva poze de la intalnire.

Andra Marin


Intalnire de gradul 5 cu Salesforce si un “ocupant” al acestei aplicatii

La Iasi ne-am intalnit in iunie din nou in cadrul Taberei de Testare, cu ocazia unei prezentari din zona de customer support (reamintim ca unul din obiectivele TdT Iasi pe anul 2014 este sa stranga legatura si sa faciliteze intelegerea altor rolurilor de pe scena dezvoltarii proiectelor IT cum ar fi ingineri de support, business analisti si project manageri).

Victima noastra de luna asta in persoana content ownerului a fost Iulian Mitrea care s-a oferit sa prezinte detalii despre flow-ul unui incident si automatizarea lui prin intermediul aplicatiei Salesforce. Prezentarea sa a fost interactiva, dinamica si presarata cu povestioare amuzante din lumea IT support.

Editia a fost sponsorizata de Embarcadero Technologies, companie careia ii multumim mult pentru primirea calduroasa, ospitalitate, deschidere si atmosfera placuta apreciata de participanti.

Ce am vazut si invatat concret din aceasta prezentare ar fi mecanismul din spatele logarii unui caz, cat de grea e viata fara un CRM, cat de multa vizibilitate ofera Salesforce asupra cerintelor si problemelor clientilor, a eficientei inginerilor de support, plus integrarea cu JIRA pentru a scapa de o alta bataie de cap in calitate de tester cand vrei sa ajuti la rezolvarea unui incident. Aici link-ul catre ppt

Mie personal CRM-urile imi erau un pic straine, dar cred ca pentru toata lumea noutatea prezentarii a venit si din schimbarea de perspectiva asupra rolului de IT support – multe lucruri pe care pana acum eu personal nu le-am realizat au fost puse pe tapet – probleme cu care se confrunta , cat de epuizant poate fi uneori lucrul direct cu clientii dar totodata si plin de satisfactii.

Au fost multe intrebari, subiectul interesant si am ajuns sa stam la povesti cu mult peste ora obisnuita de incheiere a intalnirilor. Iulian a pus mult suflet si pasiune, ne-a impartasit din energia lui, tinand sa ne prezinte cat mai multe functionalitati si dedesubturi ale aplicatiei! Ii multumim mult pentru implicare si tuturor celor care au reusit sa ajunga la intalnire!

TdT#25 Timisoara – Hands on E2E testing for AngularJS apps

Multumim tuturor celor care s-au inscris la “Tabara de Testare” – Timisoara #25.

Ne vedem azi, joi 22 mai, la 18:30 la sediul ARIES, Strada Paris nr2A (cladirea Iprotim , cea cu Registrul Comertului), etajul 4, camera 413.


  • 18:30 – 18:40 – Sosire participanți
  • 18:40 – 20:30 – “Hands on E2E testing for AngularJS apps” cu Lucian Pacurar
  • 20:30 – 20:45 – Concluzii


1. Lucian Pacurar – “Hands on E2E testing for AngularJS apps” 
2. Alina Ionescu – Facilitator
3. Adrian Mirea
4. Daniel Tiron
5. Borislav
6. Oana Radomir
7. Iulian Benea
8. Catalin Nisulescu
9. Robert Călin
10. Maria Dobrotchi
11. Larisa Bulugean +2
12. Alex Bostan
13. Adriana Hazulea
14. Filip Cristian
15. Calin Pinter
16. Andrew Silaghi

Pentru mai multe detalii: http://www.meetup.com/Tabara-de-Testare-Timisoara/events/129617692/

Sell your automation and motivate using metrics

Prezentarea lunii mai in cadrul Taberei de Testare Iasi a venit de la Igor Cernopolc pe tematica metricilor folosite in testarea automata. Editia a fost sponsorizata de Endava, careia ii multumim pentru sala pusa la dispozitie si ospitalitate. Desi ploaia torentiala de afara a incercat sa ne „saboteze” si doar jumatate din cei inscrisi initial au fost prezenti, ne-am bucurat mult ca cei de pe waiting list au reactionat in timp util si ni s-au alaturat.

Igor a vorbit din experienta proprie, imbinand informatia gasita in cartile si articolele citite cu exemplificari practice pe diversele proiecte lucrate, avand de-a face cu clienti diferiti, cu asteptari diferite, rezultand o discutie antrenanta per ansamblu. Metricile discutate se potrivesc in raportarile catre management sau catre client, dar si in analiza propriei munci, in faza de planificare si desfasurare a proiectului, cand prezinti ce ai de oferit si justifici unele costuri, sau vrei sa urmaresti progresul si unde anume te afli conform cu ce ti-ai propus.

Cei prezenti la intalnire au ridicat intrebari din sala, au pus probleme asupra modului de calcul al unor metrici, iar feedback-urile primite la sfarsit asupra prezentarii si prezentatorului au fost bune, exemplele practice fiind cele mai apreciate. Asteptam in continuare comentarii si sa ne spuneti daca ati reusit sa ramaneti cu ceva valoros in urma discutiilor. Intre timp, gasiti aici linkul catre prezentare.

Intalnirea s-a dovedit un inceput de conversatie fructuos pe tema metricilor in testare si cum iti dai seama daca esti eficient in munca desfasurata. Igor a preferat sa insiste mai mult pe o discutie libera decat pe o prezentare propriu-zisa si speram ca din ce in ce mai multi membri ai comunitatii sa ne impartaseasca din propria experienta. Ii multumim ca a acceptat provocarea noastra de a fi content owner!

Din perspectiva organizatorilor TdT Iasi, vom incerca orientarea formatului prezentarilor catre cel al unei clinici de testare in care fiecare sa ridice probleme cu care s-a confruntat si sa cautam raspunsuri din experienta celor prezenti.

Incheiem cu un citat inspirational:
„Before you start some work, always ask yourself three questions: – Why am I doing it, What the results might be and Will I be successful. Only when you think deeply and find satisfactory answers to these questions, go ahead.”

TDT Timisoara #24 – Black Boxes cu colegii de la Cluj

Multumim tuturor celor care s-au inscris la “Tabara de Testare” – Timisoara #24.

Ne intalnim maine, Sambata 26 Aprilie, la ora 10:00 la Haufe-Lexware, Calea Aradului, nr.8, etaj 2 (in cladirea Bosch de langa Mall), Timisoara.


  • 10:00 – 10:10 – Sosire participanți
  • 10:10 – 12:50 – “Black Boxes” cu colegii de la Cluj
  • 12:50 – 13:00 – Concluzii
  • 13:00 – Masa de pranz si voie buna


1. Alex Rotaru
2. Adina Moldovan
3. Alina Ionescu


1. Bonto Carmen
2. Ramona Baleti
3. Iulian Benea
4. Radu Ticiu
5. Bogdan Orasan
6. Ionela Peica
7. Catalin Ilea
8. Alin Stelian
9. Adriana Neicu
10. Silvia Ioana
11. Codruta
12. Ktod Cristi
13., 14. Lavinia Muntean +1
15. Darian
16. Maria Dobrotchi
17. Daniel Tiron
18., 19. Delia Cruceru +1
20. Andrita Vlad
21. Zaharie Dragos
22. Borislav Draghici

Pentru mai multe detalii: http://www.meetup.com/Tabara-de-Testare-Timisoara/events/129617462/

Editie aniversara TdT Iasi

In aprilie am sarbatorit un an plin de evenimente in cadrul comunitatii de testare Iasi sub egida TdT, editie sustinuta de compania Optymyze, careia ii multumim pentru sala pe care au pus-o la dispozitie si tortul delicios de care ne-am bucurat!

Un an de Tabara de Testare Iasi – perioada in care am avut parte de discutii dintr-o gama variata de subiecte, cum ar fi: Mobile testing, Test analysis, Black-box testing, Security testing, Web testing, Automation, Usability, Test management, Test design. Am tinut sa impartasim tuturora bucuria ca initiativa TdT Iasi a prins radacini, ca suntem in continuare entuziasmati, energici si perseveram in a facilita cat mai multe intalniri intre membrii comunitatii!! Mai multe detalii despre evenimentele din ultimul an si ce ne propunem pe viitor se gasesc aici.

In editia de luna aceasta am venit cu o modalitate noua de a colecta recomandarile voastre prin intermediul biletelelor colorate prinse in copacul cu idei! Vom face tot posibilul sa tinem cont de ele in organizarea din acest an!

Ce tine de sugestia foarte des mentionata de a exista mai multe locuri disponibile la o intalnire, vom discuta cu fiecare content owner in parte (cel care decide formatul si conditiile de participare) si vom cauta sustinatori care sa ne puna la dispozitie sali mai incapatoare. Pana acum am profitat de bunavointa companiilor de IT care ne-au sustinut prin oferirea salilor de conferinta de care dispun. Cealalta varianta mai la indemana ar fi ca atunci cand exista multe solicitari de participare la un eveniment, sa rugam content ownerul sa reitereze intalnirea, lucru pe care l-am mai facut si a multumit. Am mai primit sugestii in directia de a avea mai multe prezentari pe test management, test metrics, content owneri din alte domenii, intalniri de brainstorming pe testare si formate gen workshopuri sau peer testing, inregistrarea sesiunilor, socializare dupa intalniri si multe altele, pentru care va multumim! Le avem in vedere!

La aceasta editie am avut parte si de doua prezentari pe subiecte incitate: penetration testing si test management in contextul serviciilor de testare. La prima expunere, dupa o introducere teoretica in domeniu, presarata cu statistici ale pietei si exemple de exploatari celebre, Stefan Hanu ne-a prezentat din capabilitatile Metasploit-ului (un framework foarte complex si flexibil, opensource) prin rularea lui pe o masina virtuala plina de vulnerabilitati. Am avut parte de un atac prin exploatarea unei vulnerabilitati de Java RMI, am vazut cum se pot urmari porturile deschise in cadrul unei retele, cum putem vedea ce aplicatii ruleaza si cat de multe se pot intercepta cu acest framework. A fost impresionant sa vezi cate se pot face cu acest framework, cu atat mai mult cu cat Stefan a tinut sa mentioneze ca nu am facut decat sa zgariem putin suprafata cu aceste teste… O prezentare foarte profesionista, cu exemple concrete si parte practica. Felicitarile noastre pentru reusita! Prezentarea o gasiti aici

Prezentarea Anei Schipor despre rolul unui test manager in cadrul unui proiect de testing services a venit si ea cu o perspectiva noua. A fost povestea unui proiect de testare ETL (extract, transform, load) cu detalii pe activitatile specifice testarii in toate fazele, cu lectii invatate, accentul punandu-se mai ales pe educarea clientului in directia intelegerii procesului de testare, respectarea entry criteria si quality gates. Sa ne reamintim din recomandarile Anei: grija mare in faza de test preparation la cum sunt definite cerintele, accesul la documente, inclusiv cele ce tin de architecture design si tehnologiile folosite, angajamentul din partea clientului pentru a asigura date de test si mai ales suportul oferit testarii in faza de analiza. Pentru faza de executie, atentie la definirea si implementarea unui mediu de testare stabil, la procesul de change management si deployment, existenta unui coverage decent de unit testing pentru functionalitatile majore si sanity check asigurat de developeri. Am avut multe de invatat din experienta bogata a Anei pe acest proiect si ii multumim pentru impartasirea catre comunitate! Prezentarea o gasiti aici

Editia aniversara a fost un success! Am vazut mai multe persoane decat de obicei socializand relaxate in contextul acestei intalniri, fara alte formalitatile, lucru care ne bucura mult! Plecand de la spusele Anei: “Aceste intalniri nu ar fi fost posibile fara ajutorul vostru, al membrilor comunitatii!” (stiu ca suna pompos si poate putin politic, dar este adevarat!) multumim mult celor care au acceptat sa fie content owner in toata aceasta perioada de un an de zile, participantilor la intalniri, implicarea lor prin intrebari si feedback-ul oferit, multumiri sponsorilor care ne-au sustinut si la cat mai multe aniversari TdT Iasi!