Dipping One’s Toes Into Testing

Aline Lanckneus, Experience Reports, Software Testing

How does one get into testing? From what I’ve heard, most testers don’t go to “testing school” but they simply fall into it. The same applies to me. 4 weeks ago I was attending a coding bootcamp where I found myself longing for any kind of feedback and mentorship. About 3 weeks ago I was offered a contract by Isle of IT as a junior test consultant. That’s how many weeks I have dedicated so far attempting to learn everything there is to learn about testing. 

Before all of this I was realising a lifelong dream, becoming a veterinarian. Obviously, if you’ve read the paragraph above, you’ll know this particular dream didn’t work out in the end. Instead of talking about why I decided to end my veterinarian career, a question I have had to answer too many times in the last couple of months, I’ll briefly talk about the skills I believe and hope are transferable to testing. 

Aline and Geert in Ardennes

Aline and Geert in Ardennes

Testing Powers and Veterinarians

Asking questions for example. When diagnosing an animal, we learn to ask questions. In general, you aim to ask just the right amount of questions. Ask too many, you might annoy the owners, ask too few, you might miss crucial information necessary to achieve a correct diagnosis for your patient. 

Communicating, unfortunately as a veterinarian sometimes you need to deliver really, really bad news to people. Delivering this news in a thoughtful and compassionate way is of the utmost importance. Obviously, communicating skills are useful when dealing with people in general. I remember one of my professors once saying, imagine a brilliant and greatly skilled veterinarian who doesn’t have the best social skills. Most owners would eventually stop seeing this veterinarian, despite his/her geniousness. Now imagine a veterinarian who cuts corners, delivers mediocre work and is mostly interested in ways to earn as much money as possible, with the least amount of effort. (I’d like to think this particular kind of veterinarian is rare) This incredibly charismatic veterinarian could sell his/her customers anything. You better believe customers will keep coming back, despite not necessarily getting the best possible treatment for their beloved pets. Now I don’t believe I fit into either of these categories, I imagine myself sitting somewhere in the middle. I do feel like I learned some very valuable communication skills during my training and while I was working. And I believe those skills transfer to testing.

The ability to observe, as a veterinarian a trained eye and attention to details comes in handy. Diagnosing orthopaedic conditions for example includes observing an animal from every angle, in motion but also when standing still or sitting. The slightest abnormality in stance or gait could be caused by an orthopaedic problem.When imaging techniques are not possible for whatever reason, a veterinarian depends solely on his/her capability to observe.

Lastly, my favourite subject in university was pathology, you might think that’s quite a morbid statement. What kind of veterinarian prefers to work with animals who are already deceased? Well, what I personally loved about it was the detective work. I thoroughly enjoyed searching for clues, every clue being a piece of the puzzle. I assume testing resembles detective work in a way and that you end up searching for clues in order to understand the bigger picture.

An Island with Herons nesting, Belgium

An Island with Herons nesting, Belgium

Start with Why

Back to testing. At the very beginning, the amount of information was overwhelming. Where does one start learning? I had the books, memberships on all kinds of online learning platforms, about a million online resources bookmarked and the entire internet to my disposal. I was all set, I’d spend 8 to 10 hours per day studying, weekends included. I couldn’t tear myself away from my desk. It almost became an obsession to me. I had a lot to prove, to my new co-workers, to my parents and most of all, to myself.

After two weeks of studying I was fortunate enough to get a one on one training with Mark Winteringham (DojoBoss at Ministry of Testing, Automation in Testing advocate, co-founder at Software Testing Clinic, …). I’ll admit I was a bit nervous beforehand, scared I would end up asking stupid questions. I was relieved to hear stupid questions are rare in testing. Luckily Mark did a great job making me feel at ease. 

But then came the question that would give me my first aha moment: 

Why do we test

Weirdly enough, despite my best studying efforts and countless hours spent in front of my computer, I wasn’t prepared for that question. How silly is that? I guess studying for 8 years at university, mostly learning how to jam as much information as possible into my brain, didn’t help me during my current quest.

In the end, I was able to give a decent answer. But only thanks to Mark leading me in the right direction and asking me lots of other questions. 

What is testing? What is quality? What happens when we test? What could happen if we don’t test

The remaining hours we talked a lot about the thought process behind testing. How testing should be about understanding the product and supporting the entire team in understanding it. Testing should be a team effort and as a tester you play an important role in that process. I assume everyone has a different understanding of what testing is, but what Mark was talking about made a lot of sense to me. He also talked about testing strategies and the importance of risks. 

We chose a simple todo-list app and brainstormed about the possible risks. After choosing one risk in particular, Mark asked me to think about how I could test it and on which level of the application we should test. He shared his mnemonic “Say Tatta to your Tuttu’s” that would ignite a certain thinking process which I found immensely interesting. 

He also talked about how visualising the application you are testing can help you in deciding where to test for a certain risk. I was relieved to find out a simple pen and paper can suffice to assist you in your thinking process and in seeing the bigger picture.

I was happy to hear Mark’s view on the role of automation in testing because from what I’ve read and heard so far, this subject in particular is controversial to say the least. We touched on some other subjects like what programming language you should learn when you’re starting out in testing, the asynchronous nature of JavaScript, the importance of distinguishing models from heuristics and so on. 

We were now nearing the end of our online training session. He gave me some final advice on how to structure my learning process, what I should be focusing on first en he provided me with a list of interesting resources. 

Every Learning Journey is Different

This training made me realise I had spent a disproportionate amount of my time learning about automation tools. It was easier to measure my progress this way. Completing tutorials gave me a false sense of progress. But I was fooling myself. I’m very thankful to Mark for helping me reach this conclusion. Now I can continue my learning journey in a way that will benefit me in the end. Focusing on understanding the problem and risks involved first and only at the very end start thinking about which tools to use.

Everything I’ve written down here is my interpretation and I am aware I may have misinterpreted or misunderstood certain things. Maybe I’ll read this blogpost again 5 years from now and have a good laugh. If somehow this blog post would be published publicly and people would actually read it, I am more than happy to hear anyone’s thoughts, questions or comments.

Beren on Nosal, Tatra Mountains

Beren on Nosal, Tatra Mountains

If you made it to the end of this blogpost, bravo! Considering I felt slightly reluctant to write it in the first place it turned out to be way more lengthy than I expected. But it did help me to digest all of the information I have been absorbing these last couple of weeks. Therefore I thank the person who asked me to do this in the first place. I want to thank him as well for introducing me to this fascinating world of testing and for continuously believing in me. Despite the current economic situation we find ourselves in, I feel motivated and hopeful that there is an opportunity out there for me. And I’m excited to represent Isle of IT in the best way I can.

The Relevance of a TestSphere Expansion

Beren Van Daele, Software Testing, TestSphere

The word is out! A new TestSphere expansion is available on the Ministry of Testing Store. I’ll give you the ‘short sell’ first, before going into my personal story of why this deck is a worthy addition.

  1. It’s got an amazing box. No longer will your feeble cardboard box break or tear as it tries to contain your TestSphere cards. The new box is stronger, big enough to hold both the orginal as the expansion.
  2. There are two new categories. The orignial cards focused much on known test techniques, patterns and heuristics which most testers already knew by name or by concept already. The two new categories venture into Operations and Architecture. Why those two? Because I personally feel they are/will become more relevant than anything else for testers across the globe.
  3. 7 Blank bonus cards. For every colour a blank card is added. This means you can customise a bit. We’ll make these empty cards available as a free to print template.
  4. 5 New cards for each colour. Each of the 5 existing colours got 5 new cards that further diversifies and deepens the dimension.

Image from iOS (1)

This is a pretty cool addition that will take your sphere of knowledge into quite different directions. You’ll be exposed to architectural concepts, observability strategies, increased availability measures and processes that will make your application more resilient.

Remember picking “stability”, “performance”, “operations” or… as a primary Quality Aspect during RiskStorming? Well, you now will have a more diverse set of techniques to tackle its possible risks. More improtantly though, the discussions you will have concerning quality will draw more diverse people in and will go wider, much wider than testing. This brings me to my personal insights…

A Bubbling Cauldron

Three years ago, I was a tester with some experience, launching a TestSphere deck that was largely a culmination of what I learned from others. Someone once said I threw some books and blogposts together into a card deck and resold that. I’d debate that, but then again, what’s the point?
This month, again with Ministry of Testing and the test community’s aid, we launch a very different addition to this deck. One that, in my opinion, is extremely relevant now and for the years to come.
Imagine me carrying around a big cauldron for the past 3 years. Consider all the possible ingredients I put in and where I picked them up:

  • Around 50 RiskStorming workshops on various projects all around Europe and one in Africa. 50 workshops, 15+ countries, about 1000 different testers/non-testers. That’s a lot of introspection and feedback.
  • Worked as a Product Owner and Quality Coach on top of growing my own business, employing people in my own special vision.
  • Supporting and advising the launch of a Europe-wide conference on Diversity & Inclusion and the human aspects in IT.
  • Attending numerous Testing Conferences, Development Conferences,…

It’s a lot to digest. Furthermore, because the cauldron has been bubbling so wildly and for so long, the dish wasn’t quite ready up until now.

Some digestible bites

The following are bits and pieces of my thought process, hopefully making clear to you, the reader, why this expansion is relevant.

  • ‘Testing’, be it manual, automated, exploratory, mobbed, isolated, executed, performed,… is a word very few people are concerned about. Many people feel burdened that they ‘should’ be concerned about it, but most people don’t want to be. Compare it to having to clean up your room. Some people really like doing it. Some people really like putting in hours automating some tasks, optimising and tweaking them. But most people just want a clean room and don’t need details on how it got there. I’d be the first person to say that this is irresponsible behaviour, degrading and probably a ticking timebomb. Yet after at least to deckades of trying to convince people of the importance, the industry as a whole becomes more and more hostile.
  • I was hired on a project as a ‘Quality Coach’ where they were vehemently against hiring testing. They had all the fancy stuff: Kubernetes, all the dockers, Kafka, Grafana, some scaling scrum thingy, communities of practice, SUPER COOL STUFF YO. The project had been running for more than a year when I joined. During the two months I was there the project release vision had yet to take shape. When it did, it changed several times and was eventually communicated to the teamleads. Then everyone assumed it would trickle down and the whole team would know ‘the plan’. Three months later, just before the massively important deadline, everyone is working overtime.

20191201_150724-effects

  • Test Automation on the UI and sometimes API level, as in the checking off things we already know, is largely a waste of time and in many, many cases a bad trade-off. A great number of projects could save lots of money by delivering with a bit of a delay and having one person check some flows or printscreens or whatever. The time invested in ‘pushing everything all the time and checking all the things all the time’ is exceptionally expensive. Some projects pull this off, most can’t (efficiently).
  • A very large portion of software projects are driven by personal wants, such as having the new state-of-the-art fancy thingy on one’s CV. Maybe someone wants to show a new shiny on the next demo. What happens even more often is someone saying at the start of the year: “This year we’ll grow by 10%.” with no plan, no risk assessment, only a feeling. I don’t see too much of that sustainable pace or good, honest communication between individuals from all ‘levels.

This works for the most of us. We can do cool things, earn a decent wage and most of us are bathing in luxuary nobody in the course of history could have ever imagined, anyway. So what’s the problem? … we’ll get to that.
I can only conclude that sweeping the dirt under the rug, or stashing all the garbage in the cellar is a good tactic to sell more, as long as the outside is shiny. This saddens, angers even, the idealist in me.

  • People with good testing knowledge, who can also transfer this knowledge to especially managers, leaders, anyone calling shots are worth their weight in gold. Your projects are an endless series of trade-offs. Investing in one thing means neglecting or breaking another. People with a testing mindset, who also know architecture systems or running an application in production, are in a unique position to point out these tradeoffs and can actually point out what is at risk.
  • Marcel Gehlen, a tester/developer/architect/.. turned manager says that Testing is a skill that is very difficult to sell. It is, however, a skill that will help people be loved. His advice is: get a skill, any skill, that gets you through the door. Then do testing.
    Following  the above clean-your-room analogy; customers buy roombas by the dozens. They pay good money for them. When the roomba starts cleaning up a lot more than just dust from the floor, there’s no way they want anything else.
  • Architects & Operations people are the closest people to us who are also focused and reliant on risks. We need to work together, not only mitigate risk, but also accept, tranfer and sometimes ignore risk.
    Only by discussing quality, risks and measures to improve our chances of success, can we do our jobs most effectively. Everything else is a waste of time and money.
  • Testing is an amazing skill. Testing is an amazing mindset. Testing itself isn’t that hard, but being a tester often is. (This is true for many roles in software development)

20191201_151555

My Advice

Expand your knowledge and your vocabulary. No, I’m not telling you you need to code or learn some whatever UI automation tool that’s just a shell on top of Selenium.
I AM telling you to play to your tester strengths:

  • Understand, explain, advocate for- and find holes in systems. Architectural systems, systems that Operations people use to ensure the application runs carefree. You’ll be surprised about the posibilities.
  • Find Allies. You are not the only one concerned about risks. Most people just lack the vocabulary and skills to advocate for measures to be taken. Find people who have those skills and learn how to advance conversations into plans.
  • Have a project-wide conversation on Quality. I’m super biased when it comes to RiskStorming, but in all honesty: I don’t are if you use TestSphere or any other tool. Just please, please, for the love of all the deities: have a conversation and prioritisation on quality aspects, risks to these quality aspects and come up with a plan that manages these risks and measures. It’s not easy, but it’s your job!

And that’s why this expansion is so relevant.

A Heartfelt Thank You to:

The Ministry of Testing, Abigail Bangser, Benny Hofman, Benjamin Fellows, Marcel Gehlen, Melissa Eaden and Thomas Harvey


Still not convinced? Here are a few examples:

Examples

Impartiality
This card is a result from a RiskStoming workshop. Questions started arising such as:
What if the person sat in a wheelchair?
What about facial types?
What about people of colour, different genders…

With the new rage of ‘Artificial Intelligence’ that is being taught by ‘data on the internet’, or whatever subset we feed it, this ‘new’ Quality Aspect is growing ever important.

Will your product amplify our biases & prejudices, or will it enable us to do something about it?

Dark Launch

 

 

“Releasing a project shouldn’t be a big deal anymore, certainly not a reason to party.”

Using Dark Launch, you can minimise risks in releasing by greatly lowering the target sample. Combined with several monitoring techniques, this can be a very cost-effective way to mitigate risk.

 

Distributed Systems

 

 

 

 

 

I guess this would qualify as a ‘new shiny’. Microservices have been on the rise for some time now and they certainly have their use in a great many products. Not all of them, mind you, but many.

They add a layer of complexity that rises exponentially with each added system. They come with their own risks. Risks you better know about when testing these systems as a whole.

In my experience, very little people are actually testing ‘the whole, connected system’, but are content to make suretheir own small microservice does what it should.

 

Feature toggles

 

Another staple in ‘new ways of releasing’. Feature toggles lets you (theoretically) test safely in production. They allow for very, very cool tactics in releasing software.
Just make sure you don’t overdo it.

There’s usually not a good case to keep feature toggles for a long time. If they have fulfilled their use, remove them.

Exploring Company Ideology

Beren Van Daele, Running Isle of IT

The world is undergoing an interesting transition. People being isolated. Negative economic impact. Personal stress, anxiety and financial harships. This is a time that will shape our future in ways we can’t quite imagine. On the other hand there are many positive initiatives rising up on social media. People offering help to the weaker. Companies taking up their social responsibilities and large scale empathy.

Challenging, interesting, worrying.

“Worry, but know that worrying is as effective as trying to solve an algebra equation by chewing Bubble gum”
– Baz Luhrmann

 

Over the past two years my company grew from a one-man-show to a micro-organisation of four. This corona virus situation is also the first real threat to our business since its conception. It’s the first time our company, our values and people are under fire. This post explores several experiences I’ve had in the past days and dealt with in my personal way.

No Secrets, Fairness

The spread of the virus is fast. Very fast. Yet in human time, a couple of weeks, days even seem long when you’re right in the middle of them. We had just hired our fourth team-member and were looking forward to Test Bash Brighton, an event that which would be a milestone for us. As the days unfurled, the certainty it would be cancelled and the questions of personal safety & planning grew unbearably.

When the event was finally cancelled, it was a trigger, at least for me.
I shared to the team an explanation of our financial situation. That it is stable enough for none of them to worry about their jobs at least for several months. The priority is each of our health, both physically and mentally. Daily, we check up on each other.

Because we are a fully transparent company, they know exactly what kind of money we have on the bank, what’s coming in and going out. I gave it to them straight, as I always have. I enjoy the conversations, the ideas and discussions we have and the mutual understanding it brings.

Joanna kicking off ITMatters meetup in Wroclaw.

Joanna kicking off ITMatters meetup in Wroclaw.

Stability & People over Greed

People approached me with suggestions to cut their personal wages by a third or even half. They felt they could make do with less and help the company survive longer with these sacrifices.
I refused.
When we started working together we signed a contract. But much more than that contract, I made a pledge to them, that as long as they are comitted to the survival of the company, the company will support them back. If I can not pay them what they were promised in times of trouble I will have failed them miserably.

Maybe I’m too idealistic and/or I’m unaware of my privilege, but when I read that big companies are cutting down wages or forcing unpaid leave I get very angry. Paying people what they are promised is the absolute bare minimum an employer is obligated to do. It may be easy for a small company to point fingers, but in my opinion these things scale. If you’re in trouble within weeks of a crisis, you’ve been consistently taking too many risks, no matter how big or small you are.

Move Forward

Several things aren’t great for the company. We have just hired a new junior, who’s awesome by the way, but who would now need to find a project in a more challenging market. I’ve not been on a project for three months and one of the teammembers told me to get a project to help out with the financial situation. I love the fact that he felt empowered enough to tell his employer to step up his game. I applaud him for it. (If you have need for an experienced remote working Quality Coach/Product Owner or a junior Tester/Front-end Developer, get in touch!)
On top of this, we’re organising three events for ITMatters.pl this year which face uncertainty whether they’ll happen in the first place. Sponsorship is harder to come by, speakers are more anxious to sign up for new gigs, not to mention finding participants. Finding business is harder, but let’s not let that stop us.

After explaining the team our financially stable situation, that they will keep getting their montly wages and their focus now is on their physical and mental health, the last message to them is to be brave. Adapt if necessary, but keep your projects going forward.

Aline & Geert trudging muddled waters.

Aline & Geert trudging muddled waters.

My Learnings

Deliberate exploring leads to new insights. I see this whole new situation as a chance to understand myself a bit better, what I want to stand for and what I want my company to be. I’m looking for vocabulary to put under words the ideology that is behind Isle of IT, but I haven’t found anything academic or helpful yet.

So in my own words:
I imagine a company of 6 people in total, not more. People who’s responsibility is the sustainability of the company and their own selffulfillment. A place that is fully transparent, fair, open-minded and progressive. Where people listen to each other, more than they speak. Where everyone’s peculiarities, skills, quirks and special powers are valued and openly appreciated. If you still think this is too fluffy and not competitive business-wise, I’m happy to have a chat with you.

I personally think this is the future. That more people will become fed up with the powerlust, greed and fear that governs many big companies and that they’ll build their own micro-businesses that feel more like a family than a machine.

It certainly is a future I’m building for my own and those who want to be part of my family.

Things don't always go as planned.

Things don’t always go as planned.

Releasing? No big deal.

Experience Reports

I’m jogging around in the park when my music suddenly stops and my phone vibrates.

– “Hi, I’m a bit… out of breath, how… can I help?”.

— “We have an issue in production. Our new release is eating away all the server   resources of the server, interfering with another product.”.

– “Ok. What can we do about that?”

— “We need to shut it down.”

– “Fine, shut it down.”

20190804_134955

Biking around the Mt. Blanc

There was a bit more to this conversation, as I wanted to know whether anyone had noticed our product’s malfunction and whether they’d notice if we would shut it down. Plus I wanted to know what would happen with the sending part of the system once we shut down the receiving part. It was a very short conversation though, where I made a quick and straightforward decision.

If this isn’t DevOps…

Why was this so easy? Why wasn’t I concerned/mad/fearful/…?
I was fine, because I understood the situation. 

I continued my run and after some time sent an email to the stakeholders explaining the situation. I started with an apology for the inconvenience, a congratulation for the great teamwork and communication and ended with the sentence
‘if this isn’t DevOps, I don’t know what is.’

The team had told me that the architecture had some possible malfunctions, that it might not scale well. But we had to learn exactly how badly it would be.
We decided to test this in Production. 

20190706_163416

Cat is not impressed.

Some context

We’re using the strangling pattern on already existing functionality. This means that we’re making a quasi-duplication of already existing systems, have them run in parallel and monitor the outcomes. When the outcomes are the same, or better, over a period of time, we know we have successfully replaced the old code. Then we can shut down the old legacy system and have our new one running as a cheaper, faster, better, more maintainable and future-proof system.

The first several releases are all about learning. ‘How do people react to a new, albeit badly, UI?’, ‘How much load does a production-like environment produce?’, ‘Can we integrate with the security partner’s software?’, ‘Can we display our new UI within the old UI without issues?’,…

Minimal Viable Experiments

We’ve learned a ton by experimenting with adding minimal changes and small valuable updates. We engineered the situation where this is possible. We have a management structure that supports this, yet is currently still a bit suspicious. We have the people who can make this happen.

We have the conversations, the vision, the strategy and the shared understanding.
I draw ugly pictures like this:

DWSB.png

What our next release strategy looks like. Simplified.

These ugly drawings don’t make sense when you look at them, but if you were part of the conversation, this is like a vacation picture where you fondly remember the moment and the outcome.

We don’t just talk about finishing User Stories. We talk about making an impact. Saving costs, making money, learning something new that will enable us to make the next move.

During our Blameless Post-Mortem we figured out that the architecture needs a drastic change. This change has been done now, which raises the question: ‘How shall we test this?’.
Remember the ‘sending part of our system’, that didn’t have a receiving end anymore? It amassed a big set of data over this past time and… well,… we could just point that to our new system and see what happens.

This is one of the parts of my job I really love. Strategising, discussing and thinking outside of the box to do a good job, doing it stress-free and doing it with people you enjoy working with.

20190602_173228

Complex structures: Monorail in Wuppertal

We have principles such as:
Bulkhead: Where you have different systems run on separate resources, so that they don’t interfere with each other. The only other impacted product was also an experimenting one.
Feature toggles: Virtually, this is a switch you flip to turn a system, or piece of a system on and off, much like a light switch. *click*, now you see it. *click*, now you don’t.
Dark Launches: We use pilot users, whom we can monitor, talk to, gather feedback from and learn, before we launch to the rest of Production.
Strangler Pattern: Explained above, this helps mitigate much of the risks of developing something new into the old.
Shadowing: Running our new software in Production, but completely invisible for our users. It helps us analyse load, investigate the outputs and evaluating its value.

But also: Eventual consistency, Distributed systems, Logging, Monitoring, Alerting,…

Releasing doesn’t have to be a big deal,…

  1. If you carry them as a team.
  2. If you’re smart about them.
  3. If you create a shared understanding.

 

 

Why my User Stories suck

Experience Reports, Software Testing

I keep on hearing how Testers must make excellent PO’s, because they’re so awesome at specifying acceptance criteria. People tell me how tester-now-POs can mold their user stories in such a way that they must be perfectly understandable and unambiguous.

I’m sad to break it to you, but my user stories are nothing of the sort. I know full well that when I feel ‘done’ with them, they still suck.

Possibly equally surprising, testers with a lot more product knowledge than me were unable to lay bare where my stories, acceptance criteria,… were lacking.

20190401_170005

The hills of Brighton – Devil’s Dyke

How can you live with yourself?

I accept various degrees of uncertainty. I don’t know everything, and neither does anyone else. Typically, at least in my experience, a concept has to go through several phases and through different hands to improve, to grow, to become something valuable.

This is also why the distinction between a User Story and Requirement is made:

  • A Requirement is something unambiguous, 100% clear and never changes. (Reality often proves to be different)
  • A User Story is a placeholder for a lower level of detail, often a discussion between people of different roles.


The examples you often read in blog posts or books that say: ‘As a user, I want to be able to filter on “name” so that I can easily find the product I need’ are relatively easy and make up very little of the actual work. In real projects, user stories are seldom as straightforward.

Most of my backlog is filled with stories that cover learning, investigating, building a proof of concept,… for quality aspects outside of the purely ‘functional’.
Before you can start building a filter, you must first have a minimum amount of security, stability, performance, reliability, observability, user experience… especially if you want to go live frequently and get feedback as soon as possible.

 

Most of my backlog is filled with stories that cover learning, investigating, building a proof of concept,… for quality aspects outside of the purely ‘functional’.

My hands are usually not the first ones our concepts go through. I get them by discussing problems and ideas with stakeholders. This could be a customer, a team member, a different team, anyone who might need our help to achieve something.

The concepts can be in a variety of different states: from very detailed and exactly described so that it’s hard to think about them differently,… to so vague that they hardly make sense.

 

My hands are also definitely not the last ones our concepts go through. As I pass my concepts on to the team, an 8-headed monster tears it apart with their questions, remarks, ideas, alternatives, examples, negative uses,… Which usually results in a stronger, clearer and all-round better view of the goal. Several additional tasks and potentially stories are created with this new information.

Then it gets built, tested, released, used, …

At any of these stages a concept can fall apart, need to be rethought, redefined, holes exposed, unexpected dependencies identified but also opportunities, ideas for innovation, strengthening, or additional business value found.

You have to start over so many times?

It can be frustrating, but this is exactly the strength a User Story has over requirements. They get better over time, they invite discussion and controversy and they result in better software.
From a PO perspective, it can be quite frustrating to get the feeling of having to ‘start over’. I’ve frequently thought ‘Why haven’t they thought of this SOONER?’, ‘why didn’t I think of this?!’.

We all learn new things over time. This is a core principle in agile software development. If we want to build better, we need to allow ourselves and the people around us to gain more and better insights over time.

Stories seldom end. Sometimes they are the beginning of something new, other times they have several spin-offs. The interesting ones, those that bring the most value, often sprout from several stories coming together.

They are not straightforward and that’s perfectly OK.

20190424_174703-1.jpg

Painting of a shipwreck in Church of Piedigrotta

What advantages does a previous tester have?

 

As a PO, I’m grateful for my previous experiences as a tester. Not because of my awesome acceptance criteria specification nor my powers of unambiguously writing down what a feature should do.
Instead, I’m grateful that during my tester years, I learned that:

  • Good software & software creators need time and several feedback-loops to be great.
  • Value is created by intellectual and creative people working together on a problem, not by following instructions to the letter.
  • My input should trigger discussion and controversy, rather than dismiss it.
  • Being able to hear solutions and problems from different people and asking the right questions.
  • Gathering and communicating information in a structured and understandable way to people with different backgrounds and expectations.

Combining these skills and knowledge with a vision & a strategy is how I enjoy being valuable as a PO.

20190420_154252-effects

Monastary in Swietokrzyskie, Poland