Risk Analysis in Software Testing cu James Bach

Meetup-ul din octombrie 2016 de la Tabara de Testare Cluj a fost unul special: content owner a fost James Bach care a tinut o prezentare despre Risk Analysis in Software Testing.

In pregatirea pentru cursurile pe care le tine pentru testeri, James a incercat cu participantii un exercitiu privind riscurile, analiza lor si implicatiile pe care le au in testare. James si participantiiau cautat i dei de test pentru o masina autonoma de nivel 4, apoi au comparat notitele. Ce a iesit? Va lasam sa descoperiti singuri:

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

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

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

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

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

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

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

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

Simon says to wisely test security

Ce se întâmplă când pui în aceeași propoziție Tabăra de Testare și OWASP? Se întâmplă un webinar cu însuși Simon Bennetts. Simon și-mai-cum? Simon Bennetts, acel membru al Mozilla Security Team și al OWASP, lead al unor proiecte ca Zed Attack Proxy sau Bodge It Store. Da, da, chiar el… Cu sprijinul mozillienilor, miercurea trecută l-am avut în calitate de content owner la cea de-a 20-a ediție a Taberei din Cluj.

Pentru prima întâlnire cu membrii comunității de testare din Cluj, Simon a pregătit un conținut adecvat pentru profilul cel mai des întâlnit printre participanții TdT, respectiv pentru testerul care în mod uzual verifică funcționalitățile unei aplicații. Iar asta pentru că el crede că tot mai mulți specialiști din IT ar trebui să cunoască această nișă a testării securității aplicațiilor. Cu atât mai mult cu cât transferul de abilități de la testarea funcționalității la testarea securității ar fi unul orizontal: dacă în primul caz, noi, testerii, ne comportăm ca utilizatori aflați în cazuri limită sau dincolo de traiectoria predefinită, în testarea securității trebuie să ne transpunem în rolul atacatorului care, la fel, exersează căi atipice pentru a „sparge” aplicația. Așadar, dispunem de un mindset potrivit. Ceea ce însă diferă este specificul testelor (sau mai bine zis, al atacurilor), care pot fi tehnice sau logice. Cât de tehnice sau logice am văzut mai departe, când Simon ne-a trecut prin fiecare dintre cele zece cele mai critice riscuri privind securitatea aplicațiilor web, evaluate în cadrul proiectului OWASP Top Ten. Și oh, da, ce teren de joacă vast pentru un tester de securitate!

Dar stați să vedeți ce jucării are… Simon ne-a arătat câteva dintre funcționalitățile pe care le are ZAP, insistând pe ideea că, pentru a nu încălca legea, este foarte important să îl folosim pe aplicații pe care avem voie să le testăm. Putem începe cu cele în mod deliberat vulnerabile, cum este Bodge It Store, magazinul online în care Simon ne-a arătat, printre altele, cum putem cumpăra produse într-o cantitate… negativă. Totuși, ni s-a exemplificat și de ce trebuie să fim cumpătați în privința tool-urilor automate, de ce e important să verificăm și manual o aplicație și de ce să nu uităm că în testarea securității nu există panacee.

Mulțumiți să fi avut o prezentare introductivă așa faină, cu demo și tot ce ne trebuie, l-am bombardat pe Simon cu întrebări preț de vreo 20 de minute, probabil având în gând prima întrebare ridicată de colegul nostru, Robin: When do we start?

Selenium Webdriver with Thucydides: In Gods we trust*, everything else we test!

Quote

O fi miercurea cea mai productivă zi pentru angajați? Poate o fi, dar sigur în prima miercuri din lună în Cluj-Napoca are loc o nouă întâlnire a Taberei de Testare. Pentru cei de-ai locului, cea mai recentă ediție a fost a… 18-a, una despre Selenium Webdriver cu Thu… Thucy… Thucydides.

Prin lentilele mele venetice, întâlnirea s-a văzut drept una matură și familiară, cu foc în sobă și chestii frumos colorate: fotolii de puf în jurul mesei și exemple de rapoarte de testare automată proiectate pe perete.

Vlad Voicu și Gabi Kis au demonstrat într-o manieră fluidă cum această combinație de Webdriver cu Thucydides răspunde nevoilor de integrare și raportare, folosind experiențele proprii și proiectându-le în scenariile propuse de participanți. Iar dacă Vlad ne-a explicat tare simpatic cum e cu proiectul, paginile și pașii, cum că As much as Java can do, you can do, Gabi ne-a cucerit cu un demo data driven, un fel de salată de fructe, cu savoare Junit, căutând merele în dicționarul Wiktionary.org și amestecând nițel portocalele cu afinele, așa, de dragul testului care pică.

Spre final, ni s-a desenat și explicat un model de automatizare a procesului de testare care folosește Jenkins și care integrează foarte elegant niște puncte de control între mediile de development și cele de testare.

Per ansamblu, vă spun că am avut parte de o prezentare interactivă, care a suscitat interesul inițiaților, dacă ne luăm după numeroasele intervenții de tip What if …? și Cum faci … asta?. Pentru autodidacții care nu sunt expuși explicit proiectelor de testare automată s-au enumerat „proiecțele” ale prietenilor unor prieteni care să ilustreze cu ce putem începe să exersăm cu framework-uri de automation. Doar să nu uităm să fim atenți la ce update-uri se fac în timp ce înregistrăm testele, cine știe ce server mai cade extenuat. Just saying 😉

In final, vă urez să aveți rapoarte de testare faine!

*Thucydides has been dubbed the father of “scientific history” because of his strict standards of evidence-gathering and analysis in terms of cause and effect without reference to intervention by the gods, as outlined in his introduction to his work – Wikipedia.

Autumn Camp 6-8.Sept.2013 – Tabara de Testare Cluj

Tabara de Testare > 6-8 septembrie 2013 > Muntele Baisoara, Romania
#TdTCamp #TabaraDeTestare #TdTCluj #TdT #SoftwareTestingCamp

Cand am sarbatorit un an de meetup-uri la Cluj, am scris o poezie:

A year has passed, can’t say ‘gone by’.
We’ve learned, we’ve changed, stayed side by side.
Through sunny days and winter snow
We fought for our right to grow.
QA, software, gadgets, we like,
Made Cluj & Silicon Valley alike.

Si am facut o promisiune de a organiza o adevarata tabara de testare.
Am vrut sa fie o surpriza pentru toata lumea si prin angajamentul public sa nu mai avem cale de-ntoarcere.
Eniko Csokasi m-a sunat intr-o seara si printre ideile pentru tortul aniversar mi-a pus si intrebarea: ‘Iuliana, organizam tabara de testare?’
Si uite asa a inceput totul.

Unde-s doi puterea creste?  Unde-s cinci totu-nfloreste!

TdTCamp@Cluj

It’s time for a real Testing camp!

Impreuna cu Ru Cindrea, Oana Casapu si Alex Rotaru am muncit pentru acest eveniment.

Cred ca am avut toti concedii foarte interesante anul acesta; care mai de care cautand o unda de semnal pentru inca un telefon, inca un e-mail 🙂

 

MacBook @ the country side

Vacation time is study time

Am descoperit ce bine se incadreaza in peisajul de la tara un MacBook si ca poate imparti aceeasi masa cu un Android.

Viata la tara … cu Xcode si Instruments
I’d do it again!

Multumesc Oana si Alex pentru MacBook!

Ru a venit din Finlanda nu doar la atelierul din 6-8 septembrie, ci si la unele intalniri organizatorice.

In the end, we’ve all mixed business with pleasure (i.e. holiday time)

Participantii au fost si ei ingaduitori si rabdatori si le multumesc din nou pentru cooperare, rabdare si atitudinea pozitiva!

Si acum, cateva cuvinte despre cum a fost in tabara:

A fost un weekend foarte frumos! O noua confirmare a faptului ca impreuna putem realiza mai usor ceea ce ne propunem, un anume scop comun, chiar daca are mai multe nuante.

Startul in forta cu setup-ul a fost un energizant super. Atatea cabluri, laptop-uri, Mac-uri, miniMac-uri, parole, conturi, intrebari si solutii (plus un meci de fotbal) pe mp ne-a mobilizat si incantat.

Munca in echipa a fost atat de naturala! Din curiozitate sau din placerea de a ajuta.
Fiecare succes elibera o parere care se transforma in solutie pentru altcineva.
Fiind atatea device-uri, unele detalii trebuiau adaptate. Astfel, am intrevazut deja ce dimensiune are mobile testing (&development) pentru ca mai tarziu sa aflam si de Android fragmentation.

Cu ajutorul lui Ru Cindrea, am scris si teste pentru Android si am aflat de bug-uri interesante in legatura cu detalii carora le acordam o prioritate scazuta incat uneori uitam de ele complet. Oare cate astfel de detalii am putea descoperi in ceea ce facem zi de zi? Ce ni se pare ceva atat de banal incat sa poata fi trecut cu vederea?

Eniko Csokasi ne-a provocat sa invatam cum putem lucra cu Instruments si script-uri JavaScript pentru iOS si ce presupune development-ul pentru produse Apple.

Ne-am prins urechile in modificarea testelor pentru iOS, dar asta nu ne-a facut decat sa comunicam si mai mult.
Si daca nu au fost intrebari de la unii, au fost de la altii si mereu aparea cel putin o provocare din vecini.

Am descoperit si Firefox OS prin intermediul lui Ioana Chiorean si Florin Strugariu.
Informatiile despre comunitatea si proiectele Mozilla au oferit baza unor posibile oportunitati de dezvoltare pentru noi intr-un cadru international.

Am invatat si ne-am reamintit o abordare pentru crearea unui test strategy.
Pentru implementare am folosit principiul Mind Maps si tool-ul XMind. Si am descoperit cat potential are aceasta abordare si pentru proiecte inafara testarii software.

Oana Casapu ne-a fotografiat in ipostazele noastre creative si a fost coordonatorul administrativ ceea ce a insemnat enorm pentru desfasurarea activitatilor noastre ‘testaresti’. Ne-a provocat la debriefing, un exercitiu foarte util, doar ca mie nu imi place sa il fac ‘live’. (Tocmai de aceia e un exercitiu bun pentru mine? 🙂 )

Alex Rotaru a avut, ca de obicei, o prezenta foarte energica, cu intrebari si alternative si voie buna.
Ajuns devreme la locul evenimentului s-a si ‘luptat’ cu amenajarea salii.
Ajunsi mai repede la fata locului au fost si Ru (venita tocmai din Finlanda pentru aceste workshop-uri), Costin Ion si Marius Ioana (veniti tocmai din Bucuresti) care i-au dat o mana de ajutor lui Alex.

Am primit toti tricouri ‘Tabara de Testare’ cu sprijinul Altom Consulting. Eu cu siguranta am sa il port si cu alte ocazii.

Sper sa ii revad pe participantii din aceasta tabara si la alte evenimente #TdT organizate de @Tabara de Testare. M-am bucurat sa cunosc alti testeri din Cluj si Bucuresti si sa descopar oameni cu diverse interese si idei. As putea spune si din Iasi, dar Simina Rendler tocmai s-a mutat la Cluj 🙂

Ne-am tinut cuvantul si am facut si sport dimineata de la 7:30.

Sambata dimineata am alergat aproximativ 3.5km, iar duminica am avut un antrenament variat pe terenul de sport al pensiunii.
Setul de activitati sportive propuse de Eniko ne-a cam lucrat toti muschii.
Ma bucur ca am facut aceasta activitate, deci se poate si ce-ar fi sa ne continuam diminetile asa? (chiar daca nu impreuna:)

Weekend-ul a fost foarte incarcat, nu prea a fost timp de relaxare, dar tot ne-am gasit energia sa si petrecem sambata noaptea.
Eu n-am mai dansat de foarte mult timp, asa ca a fost super!
Ada Coste m-a invatat o noua miscare de dans – trebuie s-o mai exersez.

Jocul de biliard este cam solicitant cand de abia putem distinge culorile bilelor… We need a re-match, Dorel Natea! 🙂

Sper ca in viitor sa fiu si mai cooperanta, mai relaxata, mai pozitiva si mai vorbareata la debriefing, sa ascult mai mult si sa ii cunosc pe ceilalti mai bine.

Cu drag,

.Iuliana Silvasan

Cateva poze:

Setup - how it's done @ Tabara de Testare

Setup – how it’s done!
Tabara de Testare Cluj > Autumn Camp > 6-8.sept.2013

Work in Progress @ Tabara de Testare

Work in Progress @ Tabara de Testare Cluj > Autumn Camp > 6-8.sept.2013

Setup = How it's done

Setup – how it’s done @ Tabara de Testare – Autumn Camp > 6-8.sept.2013

Networking @ Tabara de Testare

Networking @ Tabara de Testare Cluj – Autumn Camp > 6-8.sept.2013

Team Spirit

The team @ Tabara de Testare Cluj – Autumn Camp 6-8.sept.2013
(photo by Denis Rendler)

TdT Cluj – Workshop #1 – Webdriver and Python with mozillawebqa

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:
    • github client installed
    • github project forked and cloned: https://github.com/mozilla/remo-tests/
    • 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
    • IDEs configured
    • 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! 😀

Alex

P.S. you can check the photos and follow-up comments for this meetup here: http://www.meetup.com/Tabara-de-Testare-Cluj/events/107519592/

P.P.S. thanks to Ioana, our PR :-D, more photos can be found here: https://reps.mozilla.org/e/webqa-selenium-workshop/

TdT Cluj Monthly Meetup #11 – Testing Clinic

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

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

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

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

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

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

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

This is when the discussion began:

  • somebody said that they could look at Sikuli – 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.

Alex

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 😀