Posted in agile, conferences, scrum

How to become Jedi Master

24890461356_1f932371bb_b

Lady Vader strikes again

My previous post was about Quality Excites conference in Gliwice. This time I would like to say something more about vivid conversation that took place during my discussion panel.

I had a chance to meet wonderful people and share inspiring ideas. It was an unique opportunity to hear about personal experiences and best practices worth to share.
As I wrote many times before:

womens-rights

How to become Jedi Master?

I do believe that every software tester is a kind of Jedi Knight. He fights for quality and the Quality is his light saber.
Who is a Jedi Master though? A person, who understands agility, quality and has a need for working together.

My best example of Jedi Master, who should lead all Jedi Testers, is Master Yoda. The same one, who talks about Agile:

“You must unlearn what you have learned”

803e86052f46b83569a8942c976057b9

Going further, I’ve asked people 3 – in my opinion important – questions about cooperation in an Agile team:

  1. How to communicate?
  2. How to introduce new people?
  3. How to share knowledge?

How to communicate

Nowadays, it is in job advertisements, small and large companies, everyone works in Agile.

mus9e8

When scrum team sits together – it is a perfect situation.

My concern was if a spread team (team located in several cities or countries) is still an Agile one.

I – Kinga Witko – claimed that spread team is not a real scrum team.

No one agreed with me 😦 Fine. (Misa no wise)

smutna_zaba

On the other hand, I need to underline here the one and only truth, that emerged as a discussion result:
Spread Agile team MUST use CAMERAS. And talk. Talk. Talk. All the time.

UNIX (1)

This is the fact, which everyone put their attention on. I do agree with that. When we don’t sit together – we talk, ask questions, get angry and happy together. However, when we work together, but there is no day-today interaction between us, we need to stay as close as possible to one another. Talking, laughing (even swearing) are the team-building features.
We are all humans, we have better and worse days. All of us need attention and understating. It is not possible to be achieved via Skype chat or other Slack-ish tool only. Conversation is the key to success within a team.
There is no team without little chats or coffee breaks, sorry!

The other important thing in agile approach is a mindset. If a team member is not eager to cooperate, denies flexibility or talking – it is maybe not the right place for him (or her).

I do agree that agile approach to software making is not suitable for everyone and is not fitted to every project. It is fine.
It is also OK if you are more comfortable with working on legacy code, together with a waterfall approach. You don’t need to force yourself do be AGILE. There is a lot of space within software industry for every style and every tester or developer. Chill!

New team members

help-me-obi-wan-cat-meme-637x412

In every Jedi Master’s life this day comes – he has to train young ‘Padawans’. Either a new team member, company member or a trainee.

Some time ago I was asked if there is a good way to introduce people into the project? The next question is – how will you know that the new team member IS READY to perform on his own.

Surprise! Surprise! (there is none)

People are not robots, it is not possible to predict what will happen. Going this direction – there is as many ways as Masters. The way you teach usually depends on your skills, empathy and understanding. And good will, of course!
There are such things as company values or project – related directions, but – AGAIN – conversation is the key.

People on my discussion panel suggested clever solutions, such as:

  • never imprison new testers with boundaries – let them explore your software
  • teach through example
  • less talking – more doing
  • provide documentation and lot of freedom.

Again, it depends on your skills and new-joiner’s abilities, what is possible to be achieved. Another point in this discussion is a recruitment process. If a correct person is selected, he’ll perform good testing in a short period of time.

People spotted also, that a new team member is fantastic benefit and opportunity for ourselves. In the position of trainer we are able to:

  • learn how much do we know
  • acknowledge our limitations (Context Driven Testing)
  • explore with a fresh look (Exploratory testing)
  • find unknown bugs
  • fix old bugs (for example those, that everyone got used to)
  • avoid knowledge silos.

Knowledge sharing

e598eed939471cf7223948c283b3fd15

Modern companies have lot of ideas to share knowledge. Most of the times, employees are able to run or attend cross-team / cross-technology workshops or presentations, take part in training or read books.

As I love to collect clever knowledge-sharing ideas – I’ve asked people “How do you share knowledge in your teams/organizations”.

Some of you may already know Michał Buczko – he encourages developers and testers to work in pairs (Pair people!) – it is a convenient way of broadening your horizons and extending knowledge.

In order to share knowledge, you may also “rent time”.
It may be an hour / day of a developer, tester or other team or company member.
How to do that? Just book a time with the person and take part in his / her day. You can exchange afterwards – it’s up to you.
I know that there are companies, which even “swap” jobs among completely different departments to FEEL the other person’s real working environment (I’m talking about you – Ocado:). All of those brilliant ideas may seem tiny, but they really work and empower people to do ingenious things.

Maybe some of those practices shall be a software company standard at some point?
I wish it to all of my test-buddies and to myself as well.

Should you have any comments, ideas, things that work fine at your company and you would like to share – comment down below or stalk me on Twitter.

I hope you’ve enjoyed the summary – see you all on my next discussion panel 🙂

Cheers!

 

 

Posted in conferences, Uncategorized

Quality Excites me!

KingaWitko_QualityExcites

Hi Guys!

Last weekend I had a chance to be part of Quality Excites conference in Gliwice.
Fantastic energy, creative people and willingness to learn and share – those are the features which make Quality Excites SOMETHING.

Location location

Gliwice is a city in Poland.
The conference itself took place in inspiring spot, surrounded by post-manufacture buildings, adapted into modern conference rooms. Well planned conference spaces, helpful service, air conditioning ( 🙂 ) made the location work.

DDFS8vWW0AAayoI

The crew

What makes QualityExcites (in Gliwice) and Test:Fest (in Wrocław) special is that they are free of charge. If the tester, developer or any other person REALLY, REALLY, REALLY wants to take part in it (and has a bit of luck) – he can. He has to ‘just’ invest own time to receive knowledge and motivation in return.

It was a unique opportunity to chat with enthusiastic testers, who create local test communities in Poland.

It was my first chance to attend Quality Excites, so I won’t compare it to previous editions.
I am  truly amazed by the event’s QUALITY. I could only imagine the amount of hard work and planning hours to achieve such result. I believe that all attendees felt warmly welcomed, knew where to go and what to expect next.
No one was hungry 🙂
Everyone had coffee 🙂
WELL DONE Future Processing!!!

Me – the speaker

20170624_084129

I was not only the conference attendee, but I was also a speaker! They’ ve chosen me to run a panel “How to become Jedi Master“. (Lady Vader strikes back 😀 )

When I saw it in conference’s agenda – together with two other presentations and a workshop – I was both excited (because it was my panel yey!) and rather not very optimistic about the number of people coming to talk with me about Agile.

However…

Suprise! Suprise!
14 people came (sic!)
They were exchanging ideas … even arguing a bit.

IT WAS AWESOME !!!!!!!!

What was my discussion panel about?

pobrane

When a true Jedi Knight wants to become a Master, first he must answer three important questions: How to communicate in an agile team? How to on-board new hires in the project? How to share knowledge? Basically we were talking about Master Yoda and what he tells us about Agile. Obvious, isn’t it? 😀

After all, it was quite a nice discussion. Thank you, guys! – In some next post I’ll try to go deeper into this subject.

All the best

Quality Excites’ agenda consisted of vibrant workshops, panels and presentations. The pace was diverse, topics differed, so I believe that no one is disappointed.

There were several presentations about Agile, some about test automation and DevOps, what seems to be a hot topic nowadays.

I took part in several lecturers.

I loved keynote’s – Gáspár Nagy – “Behavior Driven Web UI Automation with Selenium and Cucumber/SpecFlow” the most – it was well presented, consistent and brought lots of useful ideas for better UI automation. Gáspár recommended his website bddaddict.com , so if you are interested in BDD – just browse.

One of my favorite speeches was Michał’s Buczko – “DevTest Pairing in DevOps” – during which I was able to acknowledge that:

DDFxIXUXkAEVixY

When you don’t pair – it makes pandas sad.
Words of wisdom
 This year’s conference was full of such brilliant words of wisdom such as:
„Spojrzała w stronę słońca Pokiwała żółtą głową, I wyszeptała do sąsiada- Już po zimie.” (3)
“Testing on production is like a foreplay after sex (“SQA in TestOps era” – Dawid Pacia, Tomasz Janiszewski)

„Spojrzała w stronę słońca Pokiwała żółtą głową, I wyszeptała do sąsiada- Już po zimie.” (1)
The bus factor – “Agile mythbusters” Michał Drzewiecki, Monika Januszek, Tomasz Lepiorz
„Spojrzała w stronę słońca Pokiwała żółtą głową, I wyszeptała do sąsiada- Już po zimie.” (2)
Proper-sized DevOps team will be full after 2 pizzas (“DevTest Pairing in DevOps” – Michał Buczko).
As you can see – we had a lot of fun out there:)
It was a pleasure to be a part of such awesome event. See you (hopefully) next year!
Posted in agile, scrum

What is scrum?

I’m going to be an Agile-pedia today. Maybe it will be useful for some of you.

What is Scrum-

It will be a long post today, so grab some sandwiches, sit down and relax 🙂

What is it all about

People are mistaken sometimes. In some cases, they lack of knowledge, but copy what they hear and pass it on and repeat it. What is more, they are even eager to argue about it.

Kim Knup noticed some time ago in her 99 sec talk, that nowadays everybody claim that they work in Agile. Everything is agile now.

We have agile dev teams and agile testers, agile projects – which sounds reasonable. There are Agile organizations. But agile recruitment process? Agile bank account?
I believe that even my dentist would call himself agile, to be honest.

Agile is the new black

The word ‘Agile’ became so trendy that people can’t live without is anymore. Each work advertisements says that an agile organization is looking for an agile tester for an agile project. Being not agile means not to keep up. Old school. Losers. Dinosaurs.

Unfortunately, ‘Agile’ became a convenient replacement for: lack of requirements, lack of documentation,  or, just basically,  a pure mess.

Where are you, Waterfall, my old friend? Nobody likes you anymore.

We have that one, so what about scrum?

Let me state it clear:

What is Scrum- (1)

AGILE DOES NOT EQUAL SCRUM

These are not equivalent words replacing each other. They mean different things.

Scrum is very goo in managing agile projects.
Unfortunately, people (PMs, Business, HR) tend to use those terms alternatively.
It makes me sad:(

In the picture below you can see the diversity of Agile methodologies and implementations. They all base on common concept, but allow people to adjust way of work to their needs. As you can see – scrum is just one of the options.

koncepts

In simple words – SCRUM is a lightweight, adaptive framework for managing complex projects.

Look at those yummy donuts (I couldn’t help myself!).

What is Scrum- (2)

There are three obligatory elements of scrum:

  • Roles
  • Artifacts
  • Events

Let me briefly describe each of them for you.

ROLES

There are defined roles in scrum project:

  1. Product Owner
  • Makes a value for the project
  • Manages project backlog
  • Represents the user
  • Is equal to the other team members

Product owner has to be a single person, not a group of people, however this person has to have a large skill set. He is THE ONE who is able to make go / no-go decisions – so – choose wisely. Product owner has to listen and keep up.

      2. Scrum Master

There is often misunderstanding.
However, this short sentence is really worth to remember :
Scrum master is not a project manager.

I can remind you enormous number of ‘inspiring’ (oh, please) LinkedIn’s pictures – Boss vs. Leader. Like this one, for instance:

boss-vs-leader-1024x1024

This is the basic difference between a Project Manager and a Scrum Master.

The Scrum Master has to be technical and social at the same time. He takes care of the project, but he also maintains team member’s requests on daily basis. It is also a Scrum Master, who resolves conflicts within the team, because (surprise, surprise!) – we’re just people.
We do fight at some point. 🙂

3. Development Team

Is a scrum team everyone is a developer. It doesn’t matter what’s your hire key – in the team everyone is equal in the area of responsibilities, activities and knowledge.

A scrum team has to have cross-functional members, who decide about the direction together. No roles. No guidance. Pure collaboration.

That’s why a scrum team consists of 5 – 9 people. Not less not more. And when I hear – ‘Oh, we work in Scrum – our team has 25 people‘ – I’m like:

-WTF-meme-7298

ARTIFACTS

Second group of elements in scrum methodology are Artifacts. Not all of them are considered as obligatory by Scrum Alliance, but is is good to keep all of them in mind when setting up a scrum project.

  1. Product vision

At first – we want to know what we would like to achieve within our project, what our vision is, where do we aim. A scrum team usually states the vision at the beginning of the project and adjusts it during the time.

      2. Product backlog

I believe that most of you heave heard about product backlog.
This is the concept that majority of tools used in agile projects originated from. When we’re talking about project backlog, we usually think of Jira, Rally, Yodiz or other open-source helpers – that’s correct. A scrum team has to keep product backlog in mind, but it is a good idea to visualize it in a convenient form,

Product backlog is a key artifact.
It must be unique, single and constantly updated.

It consist of all tasks that are under development at the moment and all of remaining ones.

All items are ordered by their value to the project and – what is the most important – all of them are estimated by the development team.
Not the Product Owner. Not the business. THE TEAM. 

        3. Release plan

It bases on empirical data – how we did in the past – what to expect. It is a good idea to update the release plan after every sprint or more often – each time we have more information and more data.

Release plan derives directly from the product backlog. It has to be highly visible for everyone in the project and, of course, up to date.

           4. Burn-down chart

A visual artifact that reflects the progress and sprint backlog at the same time. It may be done in Jira, on the full HD super shiny screen in the middle of the room, on paper, whiteboard and so on. It just must be visible and accessible for everyone.

It may look like this:

scrumburn1

or can be more complex. It is absolutely up to you.

5. Impediment list

This is basically a list of every obstacle which blocks the team.

Remember – all artifacts have to be visible and up to date!!!

EVENTS

Apart from roles and Artifacts we have also Events and this is probably the most known and doable element of agile development. How many of you have heard: ‘We work in scrum, because we have daily meetings’?

orly

  1. Sprint Planning

You should obviously have to do a regular sprint planning sessions in scrum projects. You may start from sprint zero, but it is not obligatory. During sprint planning the whole team:

  • decides what will be delivered
  • creates backlog
  • decides about the scope of the sprint

And what sprint is all about – it has to be timeboxed and once you decide about the frequency (from one week to one month) – stick to that. Eventually you’ll learn how fast is your team able to perform, how does the project go and so on. Take your time.

     2. Daily scrum = Stand-up meeting

* no longer than 15 minutes
* daily
* what did we do yesterday?
* what id the plan for today?
* do we have any blockers

        3. Grooming/ Refinement sessions

It used to be called grooming – now the name of this meeting is refinement and it should be used for re-estimating new requirements. Agile, scrum – it is all about the adjustments. During the meeting the whole team should review higher priority items and estimate again, if necessary.

What is essential – you should plan 10% of each sprint for those meetings. You don’t have to use them, but find time for them when you find them useful.

        4. Demo

You’ve probably demoed your development in front of the customer at least once in your career. It may be stressful, but is is necessary to complete definition of done in the scrum project.

The most important thing: Present just those pieces of functionalities that are ready. Basically, it should not be allowed to demo features that are not ready for production. Very simple rule – very useful.

Demo is also an opportunity – you are able to meet your business – gather feedback – think of adjustments. It is beneficial for both sides.

           5. Sprint retrospective

Last but not least – there is no sprint without a proper retrospective meeting. We’ve started sprint during planning session, kept it up during entire development and we would like to close it with some conclusions.

Tiny tip for Product Owners and Scrum Masters – BRING COOKIES 🙂

Retrospective meeting should fulfill our desire to improve our work:

  • what gone well
  • what didn’t go well during the sprint
  • make an improvement plan – ACTION PLAN
  • lessons learned

… and that’s it!

ISTQB DEFINITIONS

As I am a certified Agile tester, I shall probably quote ISTQB syllabus from exam materials:

crVtQK

Scrum is an Agile management framework which contains the following constituent instruments and practices :

* Sprint: Scrum divides a project into iterations (called sprints) of fixed length (usually two to four
weeks).
* Product Increment: Each sprint results in a potentially releasable product
* Product Backlog: The product owner manages a prioritized list of planned product items (called the product backlog). The product backlog evolves from sprint to sprint (called backlog refinement).
* Sprint Backlog: At the start of each sprint, the Scrum team selects a set of highest priority items (called the sprint backlog) from the product backlog. Since the Scrum team, not the product owner, selects the items to be realized within the sprint, the selection is referred to as being on the pull principle rather than the push principle.
* Definition of Done: To make sure that there is a potentially releasable product at each sprint’s end, the Scrum team discusses and defines appropriate criteria for sprint completion. The discussion deepens the team’s understanding of the backlog items and the product requirements.
* Timeboxing: Only those tasks, requirements, or features that the team expects to finish within the sprint are part of the sprint backlog. If the development team cannot finish a task within a sprint, the associated product features are removed from the sprint and the task is moved back into the product backlog.
* Transparency: The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum. This makes the content and progress of the current sprint, including test results, visible to the team, management, and all interested parties.

I hope my summary about scrum was valuable for you.
There is a lot of information about scrum around the web, several good pieces of literature, there is scrum.org as well, so keep on searching.

Any comments? – Don’t hesitate to write down below or on Twitter.

Cheers!

Posted in Uncategorized

Have a chip on your shoulder

real-word-meaning-crowdsourced-dictionary-hip-dict-60-589c703b43341__700

As today we have #Eurovision contest in Kiev (привет! to all of my Ukrainian friends:) ) the warming up would be music-related.

Some time ago I’ve attended a workshop, on which I’ve learned that everyone is able to sing. People claim, that they cannot sing, they have no voice or they are not talented. The truth is, that if you can hear a sound – you are able to repeat it. Less than 10% of population is not able to do it it is not likely you are in that group:) )

On the other hand, the problem with singing is more in our heads than in other organs  responsible for the act of singing (like larynx, diaphragm or mouth). Since childhood, most of us is thought that some people have “special abilities” for doing artistic things whereas the other don’t. It’s just not true.

It is our inner critique that imprisons us and makes us more harsh for ourselves than for the people around. That’s why we should open our minds and get back to the natural abilities of each human being, which is shouting, screaming and singing.

The post won’t be about singing though, but about testing and learning new things.

Since the beginning of my professional career in testing I had always a chip on my shoulder that I don’t have technical education. I did my best at work, but still was missing something. People around me – testers, developers – they all had a technical degree. I believed that they KNOW some magical things, which I didn’t know.

My education was a huge obstacle for me at the beginning, but I am not used to giving up quickly :). Eventually, I did my best and learned new things by heart from the web (thank you testerzy.pl), books, workshops and meetups.

I was wondering – am I the only person in IT industry, who thinks this way? What is more, maybe even some experienced testers feel the same way when they leave their comfort zone and start new project, new job, new team, familiarize themselves with a new technology.

Even if you work in the IT industry for a while, at the beginning of each new task you always start like:

187d0444ea4c52cf99f0829950aa10b0983fca85

No matter if you are smart-ass and Technical University graduate or have completely different background (like I do).

What is my point?

Go and learn, girl! Put yourself together, boy!

There is no excuse. You don’t have technical background but want to be a tester? Learn! There is no magic. No mystery. I’ve read that IT industry has a space for anyone. Sure, it has a space for everyone… who wants to learn.

I know a bunch of testers, who graduated from different faculties, such as: English Philology, Chemistry, Architecture…. We have one thing in common – all of us spend free time on reading about agile, SQL, Java, UI, UX… and much more.

Gathering new abilities extends your horizon and exercises your brain. Think of it like of a training, which will help you remain younger and better organized.

After some time of such training you will be able to jump from this position:

e3db1da47e2a7b58f999825a0345fff9

… to be more like:

24890461356_1f932371bb_b

There is no worst thing than a tester who thinks he has enough. There is always not enough. You cannot stop learning, because the web changes, trends change, methodologies change and it is fast, rapid and happens now. If you don’t keep up – you become Windows XP (if you know what I mean 😉 ).

Today I want you to get up and search for something new each day. You’ve been thinking about familiarize yourself with SQL, but have no time for get it done? Find your time – 15 minutes a day, on the bus, in the queue – wherever you can.

If anyone can cook, anyone can sing – what stops you from being the best tester in the world? (Or, at least, in your organisation).

Go and make me proud!

Posted in databases, scripting, Unix

Unix – I did my best

1nnpyr

Hi Boys and Girls!

After my previous Unix-related post some of you complained that it was too short, to little knowledge and more meh than wow. This time I decided to do my best and fulfill all your Unix desires 🙂

One of my biggest discoveries about Unix (and command line in general) is that
YOU HAVE TO KNOW.

You have to know where your file is.

You have to know what is the path to the folder in which your file would be stored.

You have to know how to do things.

In order to know things – I’ve gathered bunch of tips and commands that might be useful. 🙂

At first – commands!

File management:

  • cat – Concatenate and print files
  • chgrp – Change the file group ownership
  • chmod – Change the file modes/attributes/permissions
  • chown – Change the file ownership
  • chattr –  Change file attributes
  • cd   – Change directory
  • cd – – Change to previous directory

(hint: cd without provided directory will take you back to home catalog – with the specified path will take you to that directory.

It is also possible to move up step by step or several parent directories at once, for example:

cd ../../../   – will move you 3 cataloges up)

  • df – Report free disk space
  • echo – Write arguments to standard output
  • file –  Determine file type
  • find –  Find files
  • gzip – Zip files
  • gunzip – Unzip files
  • ln  – Link files
  • ls – List directory contents

(ls –color will list your files with selected color)

  • mkdir – Make directories
  • more – Display files on a page-by-page basis
  • mv – Move or rename files

For examlpe – if you wanna rename test1 file into test45 – your command would be like this:   mv test1 test45

  • pwd – print working directory – Return working directory name
  • rcp – Transfer files to the remote host
  • rm – Remove files and catalogs
  • rmdir – Remove directories, if they are empty.
  • split – Split files into pieces
  • touch – Change file access and modification times
  • umask – Get or set the file mode creation mask
  • unlink – Call the unlink function

File system management:

  • badblocks – badblocks control
  • df – Report free disk space
  • dd – Convert and copy a file

Process management:

  • at – Execute commands at a later time
  • cron – Regular process run during given timeframe.
  • fg – Run jobs in the foreground
  • kill – Terminate or signal process.
  • killall – Terminate or signal all processes with given name.

Sounds Metallica-ish, doesn’t it?

  • ps – Report process status
  • watch – Monitor command result

(For the watch 😉 )

  • nice – Invoke a utility with an altered nice value

Users and systems management:

  • clear – Clear console / terminal
  • login – Log in to the system
  • passwd – Change password
  • su – Log into other user’s account
  • sudo – Run process with root rights
  • who – Display who is on the system
  • whoami – Display what user are you currently using

Text editing:

  • cut – Cut out selected fields of each line of a file
  • grep – Search text for a pattern
  • head – Copy the first part of files
  • more – Display files on a page-by-page basis
  • vi – Screen-oriented (visual) display editor

Comment time

People usually don’t know all Unix commands by heart – they collect the most useful ones in random txt file and use them (or use history command), believe me. To use Unix – you don’t have to know them all. Take it easy.

To manage your Unix account – you’ll need a login and password. Nice tool to manage Unix (or Linux) commands is Putty (such fabulous UI design) – give it a try 🙂

Command line allows you to combine multiple commands and get precise results.

On the other hand, you may be thinking how Unix will be helpful in testing activities? In the same way as in development – you are able to manage your files quickly or run shell scripts. In addition, everyone is able go through the same logs, search for useful scripts, go inside them, look around and modify, if necessary.

You can also narrow down your search results, using grep, or make sure that the log you are looking for at the moment is the same one, which has been generated
a moment ago – not last month.

Furthermore, you are able to color your results, number the rows and save all modifications. All of that  – using just pure commands – without GUI. Sounds strange – but it works – and, to be honest, a lot of people work this way.

One account – multiple users

There is a very important thing to remember when working on Unix account.

I did mention before – companies (projects) use Unix or Linux, because it is possible to work on the remote machine – even by multiple users at once. On the other hand, those users usually have rights to modify the same files. What dose it mean? You have to be precise and careful what you are doing.

I hope that my guide made you curious and you’ll experiment with Unix, Linux and command line. It is not as scary as you think.

Do you have any favorite commands? Did I miss something important? Don’t be shy – you can comment down below.

Stalk me on Twitter (@KingaTest).

Cheers!