Posted in test automation

It is (sometimes) a good idea to automate your regression testing


Desejando-lhe uma

Let’s start from Wikipedia’s definition of Regression Testing:

Regression testing is a type of software testing which verifies that software, which was previously developed and tested, still performs correctly after it was changed or interfaced with other software. Changes may include software enhancements, patches, configuration changes, etc.

Now, when we are aware of what is all about, let’s get to the point.

How often do you proceed regression testing? Once per sprint? Once per month? Daily?

Here we are. If our regression testing is supposed to make any sense – it has to be performed as often as possible – at least on sprint basis. Ideally – daily. Why? Because  stable test suites would catch any unexpected system behaviors and react to a major change.


There is yet another question – how big your system is.

Small systems usually have rather checklists than test suites. Large ones – even the monsters:)
Deciding what should by automated  is always tough, because having automated test scrips may be just something you could show off with or present in front of the customer. I would rather ask: WHY do you want to automate anything?

The problem is that sometimes automated suites don’t test anything (or anything meaningful) and the effort to keep them alive is big.

If you wonder if it’s worth to automate repetitive stuff? I’d answer – sure mate!

Automation is good. But it is just another tool – NOT THE PURPOSE.


I think that automated regression tests might be brilliant and helpful, but you have to remember that you’ll have to take care of them and update them often. You’ll also spend way more time to prepare test suites than to proceed simple tests manually, so if the testing is not repetitive – it’s good to calculate what is more beneficial for your project.

When automating things – you improve your skills and gain time for other activities – so it’s basically a matter of time – the time you’ll save on running automated regression testing and time you’ll waste (it’s not wasted, I know) on preparing them.

I’m just the beginner , so I might be wrong. Don’t agree? Comment below or stalk me on Twitter.

Posted in agile

Tester is not the quality police

Testeris notaquality Police (2)

I wish I could invent this sentence, but unfortunately I have not. It’s been a while when people discuss the subject on Twitter, so I would like to give my short comment on that as well.

The whole team approach

During my panel about being Jedi tester, people agreed that agile tester:

– executes tests
– gathers requirements
– chases designs
– keeps good product quality
– has technical knowledge
– does multiple tasks apart from testing

He is Agile. Whole team approach. Right. Have you ever heard about developer doing things mentioned above? Or about a developer who gathers requirements, chasing for designs, organizing project or taking care of the quality a whole?

Neither do I 😀

So where is the whole team approach?

For some reasons, it happens sometimes, that a Project Manager, who is introducing the tester into agile (not only) project, thinks that having a member of QA in the team solves all of the  problems. Tester would be some kind of policeman watching developers and defending the code from bugs.


I do agree that tester’s role and certain approach to developing good quality of software products is unique and is a must, but when other team members don’t care about quality – tester’s effort is pointless. The whole team approach means that everyone is responsible  for the product and have good quality in mind.

When we succeed – all of us can celebrate. When we loose – the whole team looses – not just a developer or a tester.

Software tester cannot be a policemen who watches the code. Some people may say that he should be a quality evangelist, who teaches developers proper approach of dealing with code and bugs, but without certain mindset and maturity of team members – single tester is not able to cope with difficulties. He’s role is important, but he is not able to change anything alone.

When thinking about agile project – all of us should think about quality – starting for Project Manager. What is more, each developer should be as quality aware as possible.

On the other hand, tester is a person, who points the purpose and leave some breadcrumbs for developers in order to help them, but the act of quality is whole team’s responsibility.

Don’t think about the testers as villains or policemen. We are neither of them. We care about quality and do our jobs as good as possible 🙂



Posted in conferences

How to become Jedi tester


Lady Vader

That will be the blog post explaining where my new nick name is coming from:) And, in some more details, what my discussion panel at the Test:Fest conference was about.

Can you see the picture above? I used that to describe myself instead of my personal one. Best idea ever. Thanks to Tomek Olszewski – one of the Test:Fest organizers – I become “Lady Vader”.



As you probably know, I had an opportunity to speak at Test:Fest conference that took place in Wrocław last weekend. Title of the discussion panel was “How to become Jedi tester” and I tried to combine agile ideas with Star Wars background there. You’ve asked me if I could write something more abut the panel itself. Let me try:)

My biggest fear was if anyone would talk during the panel, but apparently everyone was eager to speak:)

As agile is my favorite working approach and methodology – I like to talk about it and hear people’s opinion. I believe that everyone would like to be the real Jedi – why not to become Jedi tester?

Our force is quality:) We have power!

My Jedi-related panel consisted of 3 main areas:

Do you Agile?

Will “Tester” survive?

Is agile certification worthless?


It was clear very soon that everyone understands agile in a different way. Some of attendees thought about agile as a whole package (team, scrum, kanban, retrospectives), others implemented just some elements in their projects. On the other hand agile is the ability to be adoptive to changing project environment, so that was also an issue during our discussion.

There was even one brave-heart who confessed that he works in waterfall (We support you). Discussion was vivid, so I am happy with the result.


Will “Tester” survive?

My point is that when we’re talking about whole team approach, roles of each team members should consist of : PM, BI, dev and test duties. During the discussion it occurred to us that everybody thinks that this is a tester role to adopt – to be agile. Did you hear about developer gathering requirements or testing (by heart) his own code? Nice output btw.


Is agile certification worthless?

I’ll leave you with this question as there is as many opinions as people. Should you have any comments, write them down here or tweet me.

I would also thank everyone taking part in the panel and discussion, it was a pleasure to meet you.


Posted in accessibility testing, kiss, mobile testing

Minimalism design in testing


Usability Heuristics

A while ago I wrote a few words about Usability Heuristics and what is their role in software testing. You might also heard about the KISS (Keep It Simple, Stupid) rule, which seems also to be impotent is such activities like web or mobile design. In this post I would like to focus on one particular issue (or trend), which becomes more and more popular nowadays. On the other hand, it seems to be just the common sense output of your software development – The Minimalism.

Good application – what does it mean?

Each year Android community chooses applications that were outstanding during the year. Competitions might differ in details, but one feature is clear and repeatable among all winners – good design.

When we are talking about design, we might be thinking “wait a minute, isn’t it an art – related stuff like sculptures, paintings or furniture?” Well – yes. But not only. I’d say that web or mobile app design is as important as it’s final working version. At the same time the role of software tester in development process, who is aware of good design importance, is essential as well. If the application works fine and causes no error, but simultaneously it is ugly – no one would use it. Or – in best case scenario – he’ll use it once (and it’s get deleted 🙂 ). Keep in mind that 80% of mobile applications are being deleted after the firs use. Why oh why? Most of all because they don’t work as expected, but sometimes – because they’re ugly 😀

A stunning example of beautiful, thought through application is Hopper – the one and only last year winner of best apps ranks. I’ll recommend you to download it from Google Play or App Store and just play around. Using this app is so pleasant and surprising like playing with a piece of art.

When I think about examples of good mobile design – I recall Hopper all the time. Pure love.


Aesthetic and minimalism design

Minimalism is achieved by reducing a design to only the most essential elements.

This heuristic states that aesthetic (which is rather a subjective feeling) and minimalism design (which can be measured somehow) are important.

For example: dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. This heuristic is extremely important to be followed in mobile app design.

Mobile applications are not supposed to be over packed with tabs, buttons or unnecessary content. App designers should keep layout as tidy and simple as possible. That is also a great challenge for the tester in the very last phase of each development – to make sure that all elements that have originally been designed are delivered within the working application. Always remember about the KISS (Keep It Simple Stupid) rule. It’s equally important on each stage of development process.

Testing usability is somehow about taking beauty into consideration.

Following trends

Essentially, minimalism is about breaking things down to the barest elements necessary for a design to function. In addition, taking things away until nothing else can be removed without interfering with the purpose of the design it’s also a minimalists’ routine. Remember, though, that certain design and graphical elements will directly affect the readability or usability of your website. Note, that it might be highly important in accessibility testing.

Minimalism could be applied to various branches of art or architecture, including web design as well. Testing minimalist websites or mobile applications might seem challenging, but possible for anyone.

Before you test anything in the area of usability – make sure that you are familiar with good web (mobile) design examples. It is good to know what’s on at the moment, keeping in mind basic rules as well. Take advantage of big players like: Twitter, WhatsApp, or less known such as: TheMinimalists, NorthKingdom, Sarah Hultin.

Don’t think it’s easier, because it’s simpler

When it comes to minimalism, don’t think it’s easier just because it’s simpler. Because there are fewer elements, you must provide the same level of usability (perhaps even better) with less interface. To balance aesthetics with functionality, minimalist web design is defined by use of space, amazing visuals, vivid photography, striking typography, and an overall focus on the content itself – and nothing more.


Posted in exploratory testing

Cat testing – why not?



Monkey testing

The term ‘monkey testing’ is rather known in tester’s world. It is a technique where a user tests the application or system by providing random inputs. We believe that unorganized test inputs are able to brake the application in the way that a trained tester won’t even try. It is basically true, because people tend to repeat known moves and actions. Pesticide paradox warns testers that they should change and update their test scripts often, otherwise they’ll stop finding issues. From this point of view – acting as a monkey seems to be tempting especially within the area of regression testing – not as a replacement but rather as the appendix to standard test suites.

Cat testing

On the other hand, animal kingdom is way bigger than just an ape type. If a monkey can test – why a cat can’t?

Today is a World Cat Day so this blog post would be related to my buddy – Greebo.

I am a cat-lover and I spend some part of each day observing my cat playing around with stuff. Trying to better my approach to exploratory testing, I just started thinking – isn’t my cat a great example of such tester?

A cat has any knowledge about things they play with. But they play anyway. This is what exploratory testers are supposed to do.
Exploratory way of testing fits to any kind of testing methodology, any type of company and project. You don’t have to be experienced in any subject (as ISTQB would like you to think), because it’s not the point. The most important aim is to play with application and to achieve a purpose.


Exploratory testing might be dedicated to UI, functions or potential safety risks check. It may help to find out if the software is prone to malicious attacks as well as if it is easy to access for a novice user. Context  is the key to success.

Cat checks random features of stuff so hard in order to know them or to brake them, just like exploratory testers do. Cat does a lot of damage in certain sessions in order to provide fun for himself among naps and snacks.


Purpose is important. Cats have their own purposes of running around and attacking things. Exploratory testers should also have some certain purpose of testing and don’t stop before an exploratory session is finished.


Time frame is essential. When you start exploratory session – you can’t stop. Did you see a cat, who digs in a pot with flower when no one watches  and having brakes for pee? NO WAY. He digs so hard until the destruction is complete and then runs away pretending it wasn’t him. That would be a proper session of exploratory testing description. You specify the time frame, start and fight. You can finish only when you run out of your time.

One major thing that is different between a cat and an exploratory tester is that the cats cannot provide any notes 🙂 Note taking is an essential part of exploratory testing.

On the other hand, cats leave so much mess behind that in most cases you know exactly what they just did. Wondering HOW might take a while. That is also a good hint for you – if you hate taking notes – record what you do using for example Chrome DevTools or other apps. In the end it would be easier to recall what you’ve just did.

I would like to encourage you to level up your daily test routine and try to enrich test sessions in cat-like exploratory testing and just have more fun in what you do. Enjoy!