Agile, baby!

One of the purposes of this blog was the battle of better software quality in our everyday lives.

Polish government websites in the past tend to be famous for their lack of testing and missing the standard quality levels, but it was in the past. After several years form debut such amazing pieces of software as PKP or ZUS sites, I naively thought that the situation got better.


Alarmed by the article stating that every taxpayer in Poland should generate their own bank number to be able to pay taxes next year , I decided to go to the government website and generate it for myself.

Such a brilliant occasion for testing! #NeverStopTesting

The idea of the bank account number generation is that you enter your PESEL number (the unique number, that every polish citizen has).

The PESEL is an 11-digit number, containing one’s date of birth.

What you are supposed to do in order to follow the instructions:

  1. Open the website
  2. Select PESEL
  3. Type your PESEL number

Expected result: Account number is generated.

nice and smooth. Worked for me. 🙂

…. and what you are supposed to do when you are a tester 😀

“A Software Tester walks into a bar….”

One of my testing scenarios:

  1. Enter curl …
    for example: curl
  2. Click Enter

Expected result:

What does it mean? The UI of this website, as i tested, was protected from entering -, a, 8946180480104610401 or anything else into input field. good job! On the other hand, the Backed…..

Well, above error speaks for itself. But I decided to explain it in a bit more detailed way:

  • There is no data validation on the backed side
  • Unnecessary information displayed in public
    => in the error’s stack trace
  • The code has been compiled in the debug version (including all information about the source code – you can see it in the file names and rows in the stack trace) deployed in production
    => unnecessary leak of information plus worse performance of the site. The code in debug version is usually not optimized and has additional instructions
  • It is likely that the code has been compiled of the developer’s machine and deployed in production (Mr. Jedrzej Lenart?)
    => it is a violation of security rules – you have no guarantee that the local changes has not been pushed into production as well
  • The website calls this web-service by POST (which is correct), but in the browser and in curl you can see that the parameter “pesel" is called by GET (in the URL)
    => it is not the worst solution, but it usually makes the website more prone to CSFR attacks and the PESEL number is visible in: logs of servers and routers – even when the communication is encrypted (URLs are not encrypted).


It seems that someone in the ministry of Finance IT department deploys code without testing. Bravo for Agile!

Bravo for Continuous Delivery!

Oh why

On the other hand, someone deploys code on GOVERMENT website without testing. Code prone for attack.

It is possible that they were not aware of the micro-service working below, but still…

Funny fact

When I posted that on Twitter it took couple of minutes in the Ministry of Finance for displaying good 500:

So Agile again!

Just wanted to share it with you, because Mr. Jędrzej made my day. (info in the screenshot).

In case of any comments stalk me on Twitter. Cheers!

Exploratory state of mind


Exploratory testing is like agile methodology or unicorns – they’re fashionable, everybody talks about them, but no one actually had seen them.


Let’s start from a little confession – for me – exploratory testing is finally a way to get to the basic of what a software testing is. The pure activity of testing and a joy that comes out of it, without rules and limitations.
You could argue with me now

– Come on ! – exploratory testing without limitations? What about time boxing? What about time frames? What about plan?

Calm down –  I don’t neglect all of that. You can breathe now 🙂

I just wanted to say that exploratory is your state of mind. For some mysterious reason
I found exploratory a way of braking things from scratch. Am I an expert? No. Should I be one to preach you? Sort of… maybe 🙂 Does exploratory work for me? SURE – it does – that’s why I want to share it with you.

Discovering James Bach

Back to square one. James Bach is your must, if you wanted to play with exploratory testing. His famous lecture (from 2011!!!) would give you some hints of how to start with exploratory. What I mean by that is not to tear your ISTQB Foundation Certificate apart and throw it out of the window – but to re-think the way you perform testing.
Jamse’s publications, keynotes sessions and the work that he does may destroy your structured thinking about testing like it destroyed mine. And still –  it’s fine.
The problem might exist in the organisation you are working for – so if exploratory suites you – find yourself a good place to play with it. 🙂

Take your shoe off and smash the keyboard

There is a fantastic tester in my organisation – Elisabeth – who loves exploratory testing. During my work interview she explained exploratory testing as taking your shoe off and hitting the keyboard with it. Surprisingly – it says a lot about exploratory way of testing things. If you don’t know the product – and have no idea how does it work, what does it do and how to approach to testing – every method is good. The more you try – the more you learn about the product and its flaws.

Destroying your expensive keyboard may not, obviously, be the best approach to testing (unless you’re testing external hardware) – however – destroying an expensive software before your customer does that – sounds like the activity you’re paid for. 🙂

It may happen that that there would be a developer from your team asking – Why did you do that in the first place? – but it’s the result that matters.

I had this situation last week – I took out my internet cable off my laptop and plugged it in again during the test session. My test affected the functionality and exposed an error that we had. The result was fantastic, because now we know what to fix now – but the face of a developer when I demoed my test in front of him was unforgettable 😉

Note taking

Exploratory testing is fun when we play around certain functionalities, but our memory is sometimes not as fresh as we would like it to be.

That’s why taking notes during each exploratory session is essential. You may want to prepare mind maps or use some software to help you with gathering notes out of your sessions. In order to take notes,  you can use your laptop, phone or any tool you want


I would recommend you to do go old school.

This is a pencil:


This is a notebook:


These are post-its:


Grab them and take your notes like a pro. At first – doing things manually would stimulate your brain – maybe you’ll came up with another crazy idea for testing? Secondly, nothing would drag your attention from testing. There will be just a feature an you.

Note all important thoughts such as:

  • questions
  • bugs (possible bugs)
  • random notes
  • areas to further exploratory
  • any other important stuff.

Taking notes might be extremely useful to reproduce the path to discovered defect. Additionally, you can record your sessions or combine all methods together. Whatever suits you best.

Maaret Pyhäjärvi thought me this one little trick – to put a sticky note on the top of my notebook page with a purpose of my team (or sprint) written down. It acts like an anchor. I’m reminding myself all the time what is my purpose – to avoid sailing away from the functionality that was supposed to be tested in the first place.


Since my beginnings as a software tester – exploratory – for me – was an appendix for regular testing, according to the plan. It appeared here and there, but has never been fully approved by management or team. It is a main theme now and that suits me best.

As Maaret Pyhäjärvi said at SeeTest conference in Sofia – we all do exploratory testing when we play around different functionalities even during regular test plan – based sessions. We just don’t name it.

On the other hand, it feels like everybody does exploratory now, just like everybody is working in Agile. It’s on the internet, during conferences and in the books. And, just like with the methodologies Agile – it comes with different kinds and flavors.
Is it a bad thing this not defined definition? I don’t think so, as long as we find new bugs and expose issues in our software.

Exploratory testing is not a big bang, it has to be structured somehow – and

Testing without a reason and purpose is just a hitting a keyboard with a shoe. Nothing more. I think that it’s all about being a better tester every day, so learn as much as you can about exploratory – read a book Explore it! by Elisabeth Handrickson and dive into it.

Now – every time you see a unicorn – think about exploratory testing 🙂


You can share your discoveries in the area of exploratory testing in comment below – on Twitter or Facebook. See U there!