Posted in agile, conferences, team, Uncategorized

Test team will help you out

Test Team

Hi Boys and Girls,

Being close to the test community at Test Warez Conference, on which I am at the moment, made me think about my team and how do we do things at New Voice Media.
I believe it is worth to spread and inspire you to introduce good practices into your test / scrum teams.

Next week I’ll provide you with wider summary of Test Warez – today I want to focus on one aspect that came to my mind yesterday during the discussion panel run by
Łukasz Pietrucha about planning your tests.

20171116_173325
We’ve started with lightweight talk about ISTQB’ish approach to formal documentation and planning across organisations but end up with vivid discussion and sharing good practices and personal project-related experiences (not necessarily related to panel’s subject 🙂 ). It made me think that planning your tests and organising testing in your organisations, in general, is extremely context-related. You might think that one, structured, recommended by ISTQB idea should work, but sometimes, to be honest, it is just useless.

I went back to my roots as a software tester.

One of my very first sources of knowledge about software testing in general was Polish blog.testowka.pl . It is technical, teaches you how to start with Selenium and gives updates about software testing in general – very thought through source of knowledge (For some reason I was convinced that it is run by a girl…. but never mind, just leave it 🙂 – sorry Wiktor! ).
Wiktor Żołnowski – the author – wrote a few words about himself on that blog. However, I’ve read it just a week or two ago. Wiktor wrote ‘It was ‘Agile’ – people and interactions over processes and tools. Then I’ve acknowledged that all things which I knew about testing ans so-called quality processes promoted by different organisations, had little value. Software can be crafted just better.‘ – and I consider it as a quote close to my heart. I still keep thinking about it, that’s why I decided to write today’s post.
Now, at New Voice Media, I can tell the same thing. There was always a missing part in my teams / projects/ organisations, even with their structured processes and diverse working environments, and I don’t speak about faking the agile style of work only – what I mean is – craftsmanship and team spirit (what a cliche).
It suites me better – it may not suit you at all, so don’t feel offended, Dear Reader 🙂

k0lN1UVoMn64u8b

As some of you probably know, at New Voice Media we – the DevOps team – work  in Scrum or Scrumban. This is the first time, where I an able to see theory in practice and it works good for the organisation. We have testers and developers in our team, but we try to widen our responsibilities to enable all team members to learn and improve their skills.

Apart from separated feature teams – we also try to gather in community of interests, Sound ‘Spotify’ish’ 🙂 Maybe. On the other hand, it helps. We try to share knowledge across teams and locations (some of us work in Poland and some in the UK) to avoid silos of knowledge

Ralls_Texas_Grain_Silos_2010

– it means we meet, talk and help one another out. It also means, that when somebody gets sick, has some emergency or has too many tasks to do at once – other testers may (and will!) help. We use different communication tools, chatters, video conferences, Wiki spaces and so on, but first of all – WE WANT to share and WE WANT to learn. It is not the organisation, who makes us do it – it’s us who do it, because it just helps.

I am not sure if that would be an approach for entire corporation – but for small departments – maybe? Would it work in a software house? I don’t know – but at leas you may try it. I know at leas one software house, that has it’s own community of interests and it works great for them. 😉 When you feel the energy and willingness to do something – you can definitely progress at things.

You cannot build (good) your software alone these days, so it is good to have a team which would help you out. Just in case 🙂

As always, you can comment down below or stalk me on Twitter.

Cheers!

Advertisements
Posted in Uncategorized

#Changes

IMG_1651

I’m baaaack 🙂

Three fantastic news to be revealed at the same time, as I promised.

Thrilling news No.1 as a main course:  
My journey at UBS is over. It was a fantastic time and I’ve learned a lot, however, now it is time to move on. As some of you already know, since September I am beginning my adventure with New Voice Media.
I can’t wait and really looking forward to do some awesome things in the area of testing and agile.

Social news – as No.2 –
I’ve started a Facebook page https://www.facebook.com/KingaTest.blog/ to keep in touch with my (not only) Polish readers. It will be in Polish:)
I’ll try to post there updates about fantastic testing events (not only) in Wrocław and maybe more of my mobile-related discoveries. Fell free to Like!, Share or contact me through this channel, comment articles, posts and whatever you wish.
I wish it to be a common social IT-related space.

Conference News No3. –
September is going to be a busy month – I would like to meet you all at 3 fantastic events:
21st – QA talk at DataArt Wrocław
23rd – Wrocław Agile Day
28th – SeeTest in Sofia

Let’s meet and have a chat!

And exciting news No.4 –
I do believe that working in IT and earning money obliges us to help the others, who were not as lucky as we are – especially people in need. I always try to support various initiatives such as SiePomaga, Fundacja Gajusz or Fundacja Anny Dymnej.

Can we do more?

Together with quite large group of people from UBS, Credit Suisse, Epam, XL Catlin we’re preparing A MUSICAL called Freedom.
Yeeeeeeeeeees. Kinga Witko will be singing (and dancing – oh Lord) 🙂
All for Fundacja Jaśka Meli.

We do it for charity, but have amazing fun at the same time 🙂

Imagine bunch of IT and bank-related people singing and dancing on a real stage. 🙂 Insane. That will be huge! Our project lasts for couple of months now, but currently it speeds up! Great premiere will take place in April 2018 in one of REAL theaters in Wrocław. I’ll try to keep you updated on social media, as it’s now official 🙂

I would like to invite you all to Wrocław in April to be a part of this fantastic event, but in the meantime – you can support Jasiek Mela – or any other people in need.
Let’s be the change!
Let’s be open.
Let other people grow.

Cheers!

Posted in Uncategorized

Don’t estimate bugs!

 

Don't ESTIMATE bugs!

Hello from abroad!
It seems, that when I am far away from home – I have more time for writing 🙂

Invitation

Bunch of thoughts for today were a base for presentation, which I am preparing for SeeTest in Sofia. I have an honor to be a speaker at this well – known testing conference – it excites me a lot.  I would also like to encourage you all to come, discuss, disagree or simply say “Hi!”. Looking forward to it!

logo270-2017

Bugfixes

The other day I came across this fantastic article about estimating bugs, written by Bob Hartman . He says: “I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!”.

I like the idea of Infinite bugs, because, especially when you are in a project-hurry, all bug fixes seem to least forever.

HTisMpC

To be honest, this is the definition I was looking for a long time. I am not sure if you have similar experiences in your projects, but each time in one of mines pressure appears – the pattern is quite predictable.

PM pushes -> developers try to declare (or predict using black magic) how much time do they need to provide fix.
Let’s state it clear – saying anything like we’ll knock out X bugs this iteration  or I’ll fix it today – that is a lie anyway.

When we are clear about that, let’s try to focus on some Agile theory.

 Scrum anti-pattern

According to Scrum Alliance – estimating or sizing bugs is an Agile anti-pattern. Scrum is such a lightweight way of producing software that things just happen 🙂 We should not interrupt, limit ourselves, state clear deadlines.

On the other hand, when we are focused on quality, but driven by rush – bugs appear.
In addition, they emerge in most unexpected situations. In this case – Agile teams should deal with the problem – fix bugs, but do it within some realistic time frames.
The cleanest way is to add the bug into the current sprint, without sizing it.The context if fresh, so the fixing costs should be low. It’s cheaper and more efficient.

In a contrary – this will (for sure) lower the velocity and reflect the remaining bug-free stories. What is, in my opinion, important – the process should be always a decision of development team – not a PO, PM, manager or whoever is standing above your head and repeating “Is it done yet?”.

67216250

The other option of dealing with bugs and keeping the product in a good shape is to plan separated bug-fixing sprint but instead of scrum – run int in Kanban manner.

Whatever you choose – plan and fix – in a most suitable way.

Time matters

What I wanted to highlight – is not estimating bugs itself – but schedule some time for fixing them.

When?

At the beginning. In each sprint. Each iteration.

The truth is, that development tent to be way too optimistic when scheduling time of their work.

project-optimism

It is not matter of good or bad will, but simply focusing on own tasks.
The problem is, that each software project is not just a pure development.
Apart from writing and testing the code, usually it consists of (at least): setting up the environment, failing environment, meetings, discussions. Altogether it ‘steal’ the time. Ironically, it is THE TIME, we want to save.

When our fixed deadline approaches – the pressure rises. The more pressure there is – the more bugs appear. The more bugs appear – the less time for new lines of good code. And here we are. Chasing our own tail.

My thoughts

I’m not discovering a cure for the cancer at the moment, but just reminding you well known fact:

Nine women can_t make a baby in a month.

Nine women can’t
make
a baby
in a month.

When you add more developers to the project (because you are in a hurry) it won’t help. Either you are a tester or a developer – try to face it:
there are bugs
you’ll have to fix them eventually,
so be prepared 🙂

Schedule time for them at the beginning of the project to avoid the hurry.
Win – Win , isn’t it?

As usual, in case of any comments, ideas (whatever you have in mind) – comment down below or chase me on Twitter.
Have a nice weekend!