Testing tours at TdT – a tester’s tale

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 img_3073outside 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

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

slack_activitymonitor_poza3

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

slack_localdata_list_poza4

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

slack_localdata_library_list_poza5

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.

slack_localdata_appsupport_slack_list_poza6

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.

testingtours_originallog

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 😀

img_4069

Hai în Tabăra de Toamnă 2015!

Testeri, mergem la munte în tabără!

tdt toamna 2015_v_cu toti sponsoriiCând? În weekendul 24-27 septembrie, de joi după amiaza/seara până duminică după amiază.

Unde? Ne cazăm la Cabana Balu, în Harghita Băi.

Ce vom face? Vom avea ateliere și prezentări în sesiuni paralele. Consultați programul aici.

Cât? 430 lei pentru cazare în regim de pensiune completă, snacks-uri, cafea/ceai pentru pauze. Suma acoperă comisioanele pentru transferurile bancare. Nu include intrarea în parc (dar vom beneficia de o reducere față de prețul standard) și nici transportul.

Ce e de făcut? Renunțăm pentru aceasta ediție la RSVP-ul din Meetup și facem înscrierile și plățile printr-un formular, până pe 15 septembrie. Răspunsurile pe care le furnizați pentru întrebările din formular vor fi folosite la selecția participanților. De asemenea, prin răspunsurile din formular vă rezervați locurile la ateliere; fiecare are un număr limitat de participanți și devine indisponibil atunci cand limita este atinsă. De aceea vă rugăm să citiți cu atenție descrierile sesiunilor și așteptările content owner-ilor înainte să răspundeți.

În scurt timp după completarea formularului vă vom contacta și vom transmite următorii pași.

Noi revenim cu detalii în curând. Voi puteți veni cu întrebări în secțiunea de comentarii sau prin email la tdtromania at gmail dot com.

Agenda Taberei de Toamnă 2015

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!

ChallengeMe for a Testing Hackathon!

 

Sambata, 9 mai, ne-am intalnit la Cluj Hub sa participam la un hackathon de testare, primul de la TdT Cluj. Ieheeei!!

Andrea si Ionela la TdT cu tricourile de testathon

Cum am ajuns la ideea de hackathon de testare

Acum ceva timp m-am intalnit cu Alex de la ChallengeMe Club care era interesat de servicii de testare pentru a doua versiune a produsului la care a lucrat. El si colegii lui s-au gandit si la crowdsourced testing si asa mi-a venit ideea de a organiza un hackathon de testare la Tabara de Testare.

Optiunea de hackathon de testare mi s-a parut mai potrivita decat crowdsourced testing din mai multe motive:

  • Majoritatea participantilor din comunitatea Tabara de Testare sunt testeri de meserie, cu experienta in domeniu si care lucreaza la abilitatile lor de testeri.
  • Fiind membri intr-o comunitate care se intalneste fata in fata, putem fructifica avantajul prezentei fizice in acelasi loc a testerilor. Asta inseamna si ca putem comunica mai bine, astfel incat sa nu logam buguri duplicate. Aceasta configuratie colaborativa este foarte folositoare. Atunci cand invatam unii de la altii, ajungem mult mai departe cu testele decat fiecare pe cont propriu. Si mai ales ne ajuta sa facem scenarii in care ne corelam actiunile – aceasta a fost marea mea revelatie si voi reveni asupra ei pe parcursul articolului.
  • De multe ori testerii care au participat la meetupurile TdT au cerut evenimente practice. Iar aceasta ocazie a fost perfecta. Pentru asta, am luat framework-ul lui Cem Kaner din cursul de Bug Advocacy numit IMGEA si, in cadrul hackathon-ului de testare, participantii au exersat inregistrarea bugurilor folosind aceasta abordare. IMGEA vine de la Isolate, Maximize, Generalize, Externalize, And say it clearly and dispassionatelly.

Formatul hackathon-ului de testare

Am plecat cu ideea ca adevaratul castig din eveniment sa fie invatarea. Pentru mine a fost important ca motivatia participarii la evenimentele TdT sa fie intrinseca: oamenii sa vina la aceasta intalnire pentru ca ei isi doresc sa invete, sa experimenteze si pentru ca le face placere, nu pentru niste premii. Aceasta motivatie poate fi pe termen lung si se autosustine. Premiile, care au constat in tricouri si agende cu TdT, au venit sa arate aprecierea noastra si nu sa fie o sursa de motivatie in sine. Si au fost pentru toti cei care au participat.

Alex si Vlad de la ChallengeMe Club

Despre aplicatie

ChallengeMe Club este o aplicatie a unui startup din Statele Unite in care se pot crea provocari (aka Challenges, de genul Ice bucket challenge sau “adevar sau provocare”, cum preferati). Utilizatorii pot crea aceste provocari, iar cei care le dau curs pot incarca dovezi foto si video. De asemenea, utilizatorii pot invita prietenii sa participe la provocari. Este o aplicatie nativa iOS, dezvoltata de Alex si a carui design este realizat de Vlad. Poza de alaturi ii surprinde pe cei doi in timpul hackathon-ului de testare.

Cum ne-am pregatit

Ca si oricare eveniment TdT, si acesta a presupus o serie de pregatiri si implicare din partea facilitatorilor. Asa ca, impreuna cu echipa de facilitatori, am discutat cum sa organizam acest hackathon de testare.

Carnetel TdTAdina s-a ocupat de coordonarea brainstorming-ului. Apoi, tot ea a preluat sarcina de a comanda carnetelele si tricourile. A configurat si a pregatit telefoanele si tabletele iOS pentru participantii care nu au putut aduce un telefon sau o tableta. S-a ocupat de comandarea mancarii si a gustarilor din timpul evenimentului. I-a trimis lui Alex UDID-urile pentru toate device-urile pentru buildul distribuit prin Crashlytics.

Eu m-am ocupat de discutiile cu cei de la Cluj Hub, de stabilirea intalnirilor cu Alex, de buget si mici cumparaturi. Tot eu am pregatit cafeaua la expresorul de la birou.

Impreuna cu Adina si cu Alex am facut programul si am stabilit niste repere orare, flow-uri de atins in aplicatie.

Simina a cautat in resursele lui Cem materialul care facea referire la IMGEA, framework-ul de logat buguri. Am ales sa mergem pe versiunea din 2008 pentru ca aceasta este versiunea sub licenta Creative Commons. Uterior Cem a lucrat la imbunatatirea acestui framework, care acum poarta numele de RIMGEN.

Ru ne-a creat o instanta de Mantis pe care sa logam bugurile.

Cei de la ChallengeMe Club au acoperit costurile locatiei, a mancarii si premiile pe care le-am dat participantilor.

Cum s-a desfasurat evenimentul

Din discutiile avute cu Alex si cu facilitatorii, am ajuns la urmatarea agenda: sa incepem cu o scurta descriere a Taberei, sa trecem prin framework-ul de logat buguri, Alex sa ne prezinte aplicatia, sa aplicam framework-ul testand aplicatia ChallengeMe Club si apoi sa urmarim impreuna ce am invatat; sa mancam impreuna la pranz si sa rasplatim participantii cu premii simbolice. Cu mici deviatii, le-am realizat pe toate.

Dimineata a inceput cam greu. Pregatirea cafelei a durat mai mult decat am estimat. Apoi, nu toti participantii au ajuns la ora anuntata, asa ca am decalat timpul de incepere cu jumatate de ora. La asta s-au mai adaugat intarzieri din motive tehnice (adaptoarele pentru videoproiector ne-au facut probleme). Dar cu toate aceste intarzieri la inceput, ceea ce a urmat a fost spectaculos.

ChallengeMe Cluj testathon toti participantii

Am prezentat ce inseamna Tabara de Testare, care e programul, si am trecut la IMGEA. Ne-am uitat la filmul in care Cem prezinta acest framework, dupa care am facut o scurta recapitulare inainte de a incepe.

Alex ne-a prezentat produsul si ne-a dat detalii despre asteptarile lui in legatura cu testarea.

ChallengeMe ClubCea mai interesanta parte din punctul meu de vedere a fost scenariul comun. Discutasem cu Alex despre asta si ne-a zis ca e foarte important pentru el sa afle cum reactioneaza aplicatia cand sunt mai multe persoane pe acelasi challenge si fac diverse actiuni. Asa ca am decis ca primul scenariu de test sa fie facut de noi toti si sa ne corelam actiunile. Unul din participanti a creat un challenge si noi toti am inceput sa facem diverse actiuni in cadrul acestui scenariu. Cel mai util lucru a fost ca puteam sa discutam si sa ne sincronizam testele.

Si bugurile au inceput sa curga. Fiecare participant care nu era sigur de un anumit comportament vorbea cu Alex si cu Vlad (vi-l prezint tocmai pe cel care s-a ocupat de design-ul aplicatiei).

Adina la testathonApoi ne-am impartit in echipe si am testat functionalitati specifice. Fiecare echipa si-a ales o zona de interes. Si aici dovada: Adina care scrie pe flipchart ariile pe care sa ne concentram in timpul care a ramas!

Am incercat sa observ si comportamentul participantilor printre cautarile de buguri. La un moment dat, Cristi a venit cu urmatoarea problema: a schimbat ora de pe telefonul mobil si a vrut sa inteleaga cum ar trebui sa reactioneze aplicatia. I-am auzit pe Alex si pe Vlad discutand intre ei ca nu s-ar fi gandit niciodata la acest scenariu. Ada si cu Alex R au avut si niste sugestii legate de un flow din aplicatie, pe langa diversele buguri pe care le-au identificat. Am surprins si intrebarile lui Gabi puse foarte bine pentru a intelege cum ar trebui sa functioneze algoritmul de castigare a challenge-ului. Am observat-o pe Mihaela care era focusata pe aplicatie. Toti participantii au avut o atitudine foarte faina si au fost concentrati pe ce testau si multumiti de fiecare data cand gaseau un bug. Mi-a placut “cautarea verbala”: “a pus cineva bugul despre x?” si oamenii raspundeau. Din cand in cand aceasta cautare nu returna nici un rezultat, semn ca se putea inregistra un bug fara riscul de a introduce duplicate 😉

Au fost iPhone-uri de la versiunea 4 la 6 + iPad-uri. Am observat si un background la o tableta pe care scria: “Do not upgrade the IOS!” :))

La final am facut o sesiune de debriefing sa urmarim cum am aplicat framework-ul IMGEA. S-au mai clarificat dintre concepte si sper ca participantii au luat cu ei acest framework, ca una dintre abordarile structurate in investigarea si raportarea de buguri.

In timpul debriefing-ului, doi participanti au propus ca o abordare de viitor pentru testarea aplicatiei folosirea unei solutii de crowdsourced testing. Cred ca exista cazuri in care aceasta abordare poate sa fie de ajutor, insa a fost surprinzator pentru mine ca in contextul in care noi faceam ceva mai valoros decat asta, testerii au venit cu aceste sugestii. Mi s-a parut ironic ca eu am incercat sa ii conving pe cei de la ChallengeMe Club sa facem un hackathon de testare in loc de crowdsourced testing, iar unii participanti le-au propus chiar asta. Intrebarea lui Vlad care a urmat acestor comentarii mi s-a parut pertinenta: “Sa inteleg ca nu mai vreti sa testati voi?”.

Ii las pe testeri sa reflecteze la urmatoarele aspecte:

  • care e contextul in care crowdsourced testing poate sa fie o optiune in testarea aplicatiilor software
  • cat de important e pentru fiecare sa inteleaga contextul si problema inainte sa ofere solutii
  • ce valoare a adus hackathon-ul de testare pe care l-am organizat la TdT, poate in lumina noilor informatii prezentate in acest articol

Ce a fost extraordinar, din punctul meu de vedere:

  1. Un startup a avut un prim contact cu testarea si a fost ajutat sa isi verifice solutia de catre membrii comunitatii de testare din Cluj.
  2. Testerii au avut ocazia sa exerseze practic un framework de investigare si raportare de buguri. Asta e un exercitiu practic pe care membrii l-au cerut.
  3. O dovada ca diversitatea grupului de testare aduce valoare. Fiecare participant a avut o perspectiva diferita a aplicatiei si au fost gasite buguri variate.

Provocarea #HackathondeTestareTdT

Organizatori TdT din celelalte orase, am o provocare pentru voi! Ce spuneti, organizam cate un hackathon de testare in Bucuresti, Timisoara si Iasi cu ceea ce am invatat din editia de la Cluj?

Ada cu tricou TdT la testathon-ul ChallengeMe

Autumn Camp 2014

TdT Cluj pune la cale un weekend testăresc la munte:

Unde? În inima munților Apuseni, la pensiunea Carpathia.

Când? În weekendul 26-28 septembrie, de vineri după amiaza/seara până duminică după amiază.

Ce vom face? Sâmbătă vom avea sesiuni back to basics, iar duminică sesiuni de performance testing; un laptop îți va fi necesar. În plus, vom avea jocuri, activități sportive, saună, party.

Cât? 275 lei ne costă cazarea și masa pentru vineri seara, sâmbătă și duminică.

Ce e de făcut? Renunțăm pentru aceasta ediție la RSVP-ul din Meetup și facem înscrierile printr-un formular, până pe 7 septembrie. Apoi, până pe 10 septembrie facem selecția participanților, în funcție de răspunsurile furnizate în formularul de înscriere. Mai departe, participanții vor avea drept termen limită 15 septembrie ca ultima zi în care să facă plata și să ne trimită dovada acesteia.

Noi revenim cu detalii în curând. Voi puteți veni cu întrebări în secțiunea de comentarii.

10462509_744325698946368_2196057479109238272_n

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.

Agenda:

  • 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

Participanți:

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/

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.

Agenda:

  • 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

Organizatori:

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

Participanți:

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/

TdT #20 – Editie Aniversara – Automation – Fast, Good, Cheap: Pick any two!

banner_site

Multumim tuturor celor care s-au inscris la “Tabara de Testare” – Timisoara #20 – Editie Aniversara.
Ne intalnim Sambata 16 Noiembrie,  de la 10:00 la sediul ACI Worldwide, Str. Pestalozzi, Nr. 22, Et. 2, Timisoara.

Agenda:

10:00 – 10:30 Wake-up coffee
10:30 – 13:00 Automation – Fast, Good, Cheap: Pick any two!
13:00 – 14:00 Taste the Buffet
14:00 – 16:00 Lightning Talks
16:00 –  TdT  Happy Birthday!

Organizatori:

1. Dan Zirmer
2. Laura Kobau
3. Ramona Baleti
4. Mihai Voda
5. Bogdan Vuscan
6. Bogdan Orasan

Participanți:

7. Neaga Septimiu
8. Letitia Virag
9. Ramona Borcan
10. Paul Prodan
11. Vasile Pop
12. Sorin Zaharia
13. Cosmin Durac
14. Awad Mohamed
15. Sanda-Maria Botoaca
16. Leonard Lehocz
17. Mihaela Lemeni
18. Alina Ionescu
19. Chitic Diana
20. Carmen Bonto
21. Madalina Lukacs
22. Adrian Mirea
23. Alin Groza
24. Benea Iulian
25. Adrian Vornic
26. Neicu Adriana
27. Daniel Jurescu
28. Radomir Oana
29. Ionut Iova
30. Alex Bostan
31. Vali Voinea
32. Nikola Trajkovski
33. Maria
34. Mocioi Adelina Maria
35. Naniu Minodora
36. Cosmin Padineanu
37. Bogdan Borchescu
38. Dana Luchian
39. Teodora Alexandra Ursulescu
40. Neagoie Claudiu
41. Adina Jian
42. Anders§
43. Paraschiv Alin
44. Rascol Laurentiu
45. Andrita Vlad
46. Dusa
47. Cosmin Traistaru
48. Cristian Lupu
49. Darian Popescu
50. Calin Pinter
51. Paclisan Alexandra
52. Volosencu Alexandru
53. Axinte
54. Codruta Morariu
55. Dragos Zaharie
56. Catalin Nisulescu
57. Lipovan Silvia

Pentru mai multe detalii:

http://tabaradetestare.ro/2013/11/05/tdt-20-editie-aniversara-automation-fast-good-cheap-pick-any-two/

sau

http://www.meetup.com/Tabara-de-Testare-Timisoara/events/95059712/

 

 

 

TdT #20 – Editie Aniversara – Automation – Fast, Good, Cheap: Pick any two!

banner_site

In luna Noiembrie sarbatorim un eveniment important. Se fac 2 ani de cand Tabara de Testare a tinut prima intalnire in Timisoara.

Asadar va invitam Sambata, 16 Noiembrie, incepand cu ora 10:00, la un workshop la care vom intoarce automatizarea pe toate partile.

Cei de la ACI Worldwide ne-au invitat sa ne aniversam la ei acasa, anul acesta.
“Let’s take a day to discuss automation principles and real life situations. We will address topics from user interface automation to real time complex systems. Bring your topics of interest and they will spark debates!”

Iata si Agenda:
10:00 – 10:30 Wake-up coffee
10:30 – 13:00 Automation – Fast, Good, Cheap: Pick any two!
13:00 – 14:00 Taste the Buffet
14:00 – 16:00 Lightning Talks
16:00 –  TdT  Happy Birthday!

Pentru inscrieri: https://sites.google.com/site/acitdt20/
RSVP-ul pe meetup o sa fie dezactivat, sa avem un singur loc pentru inscrieri.

Atentie: Inscrierile se fac pana pe 13 Noiembrie ora 18:00. Inscrieti-va din timp, sa prindeti un loc 🙂

Ar fi pacat sa ratati asemenea editie !