Tales of a tester

What we love in testing

This list is coming from the linkedin conversation in the Software Testing & Quality Assurance (QA) group. Thanks for all the people who contributed there! 

Link to that topic is here. 

The list items are grouped based on subjective decisions. All comments welcome! 

If you have more items to add, just ping me!

Team:
- Helping the team forsee possible problems
- The people I've met
- The opportunity to coach and mentor those who are developing their careers
- Team work
- People
- Influencing team mates and colleagues
- Seeing people grow into awesome testers 
- Seeing people grow into awesome developers 
- Going out for drinks with the team- Training the teams

- Learning from the teams

- The test team dynamic

- Those head scratching moments when the whole team come together to get to the bottom of an issue

- Mentoring and teaching about test

Learning:
- The capacity for learning new stuff is vast, almost certainly endless
- Not knowing everything. 
- The endless improvement opportunities
- Ever evolving => Kaizen 
- The huge amount of stuff I don't know and I want to learn
- Always learning new technologies
- Learning what the software does, or is supposed to do, as well as anyone can
- The opportunity to constantly learn   
- Learning new things every day
- Innovation on new techniques for testing
- In automation, working on the latest tools and technologies
- Constant learning

Appreciation:
- Being valued for having a warped and twisted mind
- Noticing the first subtle signs of the bug that nobody else noticed
- Using test results to track down and isolate elusive errors
- The pride from releasing stable, functional and user-friendly product 
- Finding a bug that nobody else knew existed 
- Finding gaps in requirements even when its in testing stage
- The satisfaction gleaned from problem-solving
- Finding high severity bugs
- Finding performance issues
- Finding missing links / broken links
- Finding UI problems
- When you are the one who is asked the last question before the release, is there anything else we should do or are good to go?
- The project go live date is dependent on testers work. In fact the system go live date is indirectly decided by testers
- Two words, challenge and appreciation

Challenge:
- The almost daily problem solving. 
- The sheer variety of problems to solve. 
- Being challenged regularly
- Technical challenges 
- Having a foot in many shoes
- Working "To Deliver" to UAT, etc on time even after many internal delays
- Scavenger hunt through the code to find out why its broken
- Thinking differently and finding design problems that others didn't find 
- Increasing complexities between and within systems
- System building is a creative job, but one need even more creativity in finding defects of system
- Two words, challenge and appreciation
- Learning the unknown Factor
- Challenging work
- Building the system by breaking it 
- Trying out weird workflows

Customer: 
- Working with the customers
- Customers smiles
- Bringing user point of view to the product
- Contributing to the design of the product by thinking like the customer
- End-user's perspective - lot of fun actually
 
Fun: 
- Never a dull day
- My 4 processor 8 core with loads of ram workstation
- Having fun
- Shippers remorse: The night after releasing a complex product wondering "what did I miss?"
- The sheer thrill of breaking code
- Helps me build out-of-box thinking

Developers:
- Making the developers who think outside their bubble
- Proving a developer wrong when they can't see an issue on their 'local machine' 
- Bringing in a different view which sometimes opposite from what developers have thought
- Developers serious about providing any help that can make testing better 

Etc:
- Seeing the big picture
- Communicating with a variety of people
- Being invited to product road map planning meetings
- Unrelenting focus on quality
- Testing as a professional career choice
- Most important thing required in testing is people management skill. One need to interact with different vendors involved in project for testing activity. I love interacting with new people

Tales of a Tester

Learning, learning, learning! Are you the new Mozart?

“Self-education is, I firmly believe, the only kind of education there is.” 

― Isaac Asimov

During job interviews the HR girls often ask us this question: why would you like to change your job?

Yes, more money. The first thing which pops into your mind if...you are young enough, at least from a financial point of view. If you already have enough money to pay the "costs of your life" (family, flat, car, etc), then this is not so obvious. In this case learning is the magic word. Learning something new, leaving your comfort zone, doing some unusual. 

At least for many of us.

In IT industry learning is easy and difficult at the same time. Easy, because there are so many new technologies, ideas and solutions coming up every single day that we can't even follow them. All you have to do is to make a choice, what to learn. And this makes it very difficult. It's like a long term investment. Where should I put my brain power, what's worth to learn it? I can start this one and that one, but if the stock price drops, shall I start something new?

Scientists say you need 10000 (ten thousand) hours practicing to become very professional in something. That's about 5-6 years, counting 8 hours /day, not counting weekends and holidays. Wow! Mozart started to practice music composition when he was 4. Was he a genius? Probably not. He just practiced a lot. A lot lot lot.

Do you have 10000 hours for learning e.g. test automation? No, you don't...you don't even have 2 hours a day, I bet.

Testers should learn different manual testing methods, they should learn bug tracking, different scripting or programming languages to automate their tests, continuous integration and regression (and tools), web technologies, databases, security issues, handling different mobile platforms, test management tools, other testing tools, BDD, TDD, html, http, etc, etc. 

Besides their work. 

Of course, sometimes you learn when you work. But after a time you don't. You just repeat the same things again and again. In this case there is only one solution: you need to find a new project...or an HR girl somewhere.

How much time do you have for learning on a usual day? How do you learn? What are your sources? 

Isn't the effictive learning the most important thing to learn first? 

Do you teach your children to learn? You should.

You can follow me on twitter: @GaborTWTR

Tale of a tester

Tests & trends

Once upon a time I was involved in an international testing team and we were testing a complicated web application for months. I did not move to London ( no way! ), but worked with some guys from the misty, rainy city on a daily basis. You know the stuff: daily meetings, retros, estimations, catch-ups and how-are-you talks. They had the money to visit us a couple of times in the Wild East, which is not that wild, of course and they were fantastic guys. Except their manager.

He was obsessed with the idea of automation. Nothing else matters, only automation! He wanted us to implement every ridiculous, tiny test case he ever saw on the story cards even if it had no sense at all. Testing it manually was much more effective and everyone knew this fact in the team. Still, we had to put a lot of effort to write the code, run it and maintain it under the frame of our precious continuous regression system. 

Why? 

First I thought that he simply wants us to practice the coding. I can accept that, what more, it's a very good idea! Except if the test cases are too simple and you are a senior tester with years of coding behind you. In this case this task can be boring and not too challenging which is a managerial failure. 

But it turned out that it wasn't about practicing. 

It was about trends in testing. 

Yes, you read well. He saw some articles on the Net about automation and how it would replace manual testing. And he became a believer...in a manager role. Bad times are coming...killing manual testing is like hanging on Facebook all day instead of going to meet your friends. You have to find the balance or you are done. 

But this is not about him, actually. It's about the fancy trends in testing. Are you following the trends? If you see a new tool, will you try it out and tell your teammates that this is the future? What do you need to be convinced by a new solution, new process or new tool? When do you say that you had enough and want to try out something new? 

Is the manual testing dead?

Tale of a tester

What's next for us?

I am a tester and was 10 years ago as well. And yes, we used the famous Waterfall model. It was good for us because we did not know anything about Agile. We were waiting for the developers for weeks (months?) and tried to prepare for all the challenges which could have ruined our life when the product arrived the first time to us. It took one (1) week to build the first version of the application and then developers just kicked the code over the wall to the testers and went to have a coffee. Or two. And a table-tennis match as well. Or two. The testers said: "...this something (meaning: the first build) can not even be deployed, can you take a look at it?" Devs abandoned the match with sour faces and fixed the deployment bug. This time they even tried out the deployment process before passing it to the test team. It took another week, of course. And we finally were able to start testing...finding a couple of A-level, blocker bugs in the first ten minutes. Automation? Er...what are you talking about? This is not Toyota!

And then some mysterious wanderer arrived from the mysterious North. Blond hair, blue eyes, finnish accent, big ego. OMG, what's next for us? 

He said: "I need three developers and three testers from this big group to try something new out. Protesting is prohibited." Of course I applied. I did not want to but somehow my hand was high up in the air, waving widely. That was my dark subconsciuos tester in my mind, I guess.

I did not regret it, as it turned out. But one of the developers shouted: "I will never have a standup in every single morning! Never! This blondie can go back to the North!" 

Now he is our Agile guru. Yes, things have changed. And people as well. 

So we started with a small group and all the others continued the Waterfall stuff. We had a meeting every day, we had estimations and retrospective meetings. It was very exciting. The others were just laughing at us and sleeping...sorry, working hard. 

But it worked. Slowly we became the group to follow. Others wanted to join so we created another scrum team. And a third one. Finally all the people worked in a group and we started to speed up. Building time dropped to two (2) days...and someone said: why don't write scripts for building? So we did. And one tester said: why don't we write test code? So we did. OMG, we won't have time for playing table-tennis...

The blondie went back to the North. He did his work. 

Never mind. After a couple of years we had more than ten (10) thousand implemented test cases running every day in a regression system. These were not unit tests, no...these were socalled functional, high level, E2E tests. And yes, we had lots of unit tests and integration tests as well. Building took 10 minutes...with deployment and smoke tests. From one week to ten minutes...improvement? Yes. Not bad. Build monitors, continuous integration and regression, smoke tests and immediate fault detection. "You broke the build! Pay one dollar, fix it in 2 mins and that's all." And we exchanged the money for beers in a pub called Coma. Hallelujjah! (Yes, that was its name. Do you know the saying 'All roads lead to Rome '? We improved it to this: 'All roads lead to Coma'. Hehe. )

So here we are now. Tale is over. But what's next for us? Good question. After nine (9) years of Agile you have to ask yourself: what is the next step to take? 

Retrospektív - egy hasznos eszköz, de hogyan is...?

Visszatekinteni és végignézni, mit is csináltál jól vagy rosszul egy adott időszakban, mindig jó. Persze csak akkor, ha akció is követi a megbeszélést. Sok helyen, ahol a Scrummal próbálkoznak megfelelő irányba terelni a biteket és byteokat, a sprint végén vagy két sprint után szoktak retrót tartani (aki még nem tudná, a sprint egy időtartam, egy fejlesztési iteráció, 2-4 hét szokott lenni), mert úgy gondolják, hogy addigra már felgyűlt annyi megbeszélnivaló, hogy érdemes összeülni egy kicsit és dumálni egy jót. Jó ez így vagy ezen is lehet tuningolni? Lehet, persze.

Nem jó sokat meetingelni. Az emberek kiesnek a munkatempóból és/vagy elunják magukat, elkezdenek rajzolgatni, a telefonjukkal babrálni, vagy a laptoppal, ha pedig megtiltod nekik, hogy behozzák, akkor te egy despota vagy és tehetsz egy szívességet, és különben is, "nem az óvódában vagyunk, hogy parancsolgass nekem". A túl hosszú meeting nem hatékony és minél később van egy adott napon, annál rosszabb. Szóval csak akkor kell megbeszélni, ha már nincs más kiút.

Akkor hogyan kezeljük a retrókat? Elhagyni nem lehet, hiszen fejlődni mindig kell és az egyik eszköz erre a visszatekintés, mit csináltunk jól, mit rosszul, min és hogyan változtassunk. Viszont nem kell feltétlenül rendszeressé tenni, hanem csak akkor gyűljünk, ha már például összejött annyi megbeszélnivaló, probléma, amit már és még hatékony és gyorsan le tudunk kezelni. Egy 5-8 fős csoport esetében talán a 3-4 elég is lesz. Ha van egy Scrum vagy Kanban tábla használatban (akár elektronyos, akár fizikai formában), akkor elég egy kis sarkot/sort erre kijelölni, ahova mindenki felírja, ha talál valami dolgot, amit szerinte meg kellene beszélni. Ha összegyűlik három, irány a meeting room. Lehet, hogy ez csak három hónap alatt valósul meg, bár erre, valljuk meg, kevés az esély, még nagyon jól működő és kifinomult csoport esetében is (van egyáltalán ilyen?). Sokkal valószínűbb, hogy egyszer 1 hét, másszor 3 hét alatt lesz meg a szükséges mennyiség. Vagy 1 nap. Na és? A lényeg, hogy kezeljük a helyzetet, viszont fölösleges ne meetingeljünk.

Természetesen a három probléma mellé fel lehet vésni azt is, hogy mi működik jól. Hogy hízzon a májunk egy kicsit. A dícséret mindig jól jön és szinkronban tudunk bólogatni, hogy frankók vagyunk, de nagyon. Viszont az akciót sose felejtsük el. Osszuk ki, kinek mit kell csinálni és csináljunk cetliket az inbox vagy to-do oszlopba, bármi is a neve.

Retrózni kell, de csináljuk úgy, hogy ne az elv legyen a fontos, hanem az eredmény!

Indulás - csak semmi planning!

Elég sokat keresgéltem a neten cikkeket, leírásokat, blogokat a szoftverfejlesztés, azon belül is a munkaszervezési módszerek világából, különös tekintettel a legújabb (de már így is több éves) trendekre, azaz az Agile-ra, a Scrum-ra, a Kanban-ra és végül, de egyáltalán nem utolsósorban a LEAN-re. Angol nyelven viszonylag sok van, ha kitartó az ember és van elég ideje (és miért ne lenne, például munkaidőben?), akkor találhat dögivel. 

Ha azonban magyar szóra szomjazik az egyszeri szoftverfejlesztő, akkor már sokkal, de sokkal nehezebb dolga van. Persze, olvashat a Wikipedián vagy találhat még 1-2 leírást itt-ott, de friss bejegyzések szinte sehol nincsenek, mintha senki nem követné nyomon a "szakma" változásait (javíts ki, ha tévedek!). Márpedig az egyik alapelv ebben a nem fantasy világban a folyamatos fejlődés, amit angolul a "continuous improvement" néven szokták emlegetni, míg japánul a kaizen a megfelelője. Ezen a ponton megkérdezhetnéd, hogy miért pont japánul említem ezt, miért nem mondjuk szuahéliül?

A válasz egyszerű. Azért, mert ez az egész Lean "okoskodás" a Toyota autógyáraiban indult el. Igen, ott, ahol nagy darab vasakkal, motorblokkokkal meg csavarkulcsokkal rohangáltak az emberek és még véletlenül sem öltönyben, laptoppal, okostelefonnal és fontoskodó arckifejezéssel, mint manapság a tipikus Manager az IT iparban. Hát szóval messziről indult és szerencsére már elég messze is jutott.

Visszatérve a kaizen-re, azaz a folyamatos fejlődés fogalmára, ami az úgynevezett Lean ház egyik alappillére (a másik maga az ember), azt gondolná a kockafejű kódtologató ülőmunkás, hogy józan paraszti ésszel is arra törekedik (törekszik?) mindenki, minden egyedi példány és minden csoport, hogy mindig előrébb lépjen. De sajnos ki kell ábrándítsalak, ez nem így van. Pláne nem csoport szinten és pláne nem akkor, ha egy vállalati környezetben a szerepek már kialakultak és minél feljebb tekintesz, annál jobban ragaszkodik az épp ott ülő a kialakult viselkedési normákhoz (tisztelet a kivételnek). Azaz, alapból mindenki elutasítja a változást, mert az ugye sokkhatással jár, még ha az kicsike is. Nem jó, pfúj. Ilyen az emberi természet. És ez az, amin kicsit változtatni kellene...a Lean talán segíthet ebben. A japánoknak mindenesetre segített, ugyanis a Toyota világelső lett az autóeladásokat tekintve - hát akkor nekünk miért ne? Állítólag még rokonok is vagyunk valamilyen szinten...

Ennyi bevezető után rátérnék a blog céljaira. Nem az, hogy definiáljam a fogalmakat, mi mit jelent, mi mivel hogyan függ össze. Ezeket megkeresheted a neten. Nem is az, hogy megmondjam, mit hogyan kell csinálnod, hogy jobb minőségű szoftver(rom)halmazt állíts elő sokkal rövidebb idő alatt. Mindössze a lehetőségeket szeretném bemutatni, merre megy a világ, mik az aktuális trendek, hova lehet fejlődni - mert azt bizony mindig kell. Fejlődni, tanulni, okosodni és merni változtatni!

Elsőként itt egy nagyszerű cikk az agilis szoftverfejlesztés jövőjéről. Meg jelenéről. Nem teljesen pozitív a vélemény, de ilyenek is kellenek. Azaz néha fel kell emelnünk a fejünket, hogy messzebbre lássunk...valaki azt mondaná, h húzzuk ki végre a s...ünkből. Hehe. Attól még hogy agilisek vagyunk, lehet ennél jobb is odakinn. Vagy odaát.

Remélem, sikerül felkelteni a nagyérdemű figyelmét!