S4E3 Nicola Lindgren – Implicit requirements

Nicola Lindgren is an experienced Senior Test Engineer, QA Lead, and Manager for ustwo. She's worked on projects in many different industries such as trade, education, and e-Commerce. She founded the Stockholm Software Testing Talks meet-up and co-founded the WeTest Auckland testing meet-up. She has also recently published her second book “How Can I Test This” which she will tell us about. We’ll talk about Implicit Requirements, where we should look for them, how to make them explicit, and much more.

Episode Highlights
Understanding path and current position in software testing
Tell me your story, and introduce yourself!
tell us about your books
How did you end up in software testing?

Topic: Preventing bugs / implicit requirements

What’s your definition of implicit requirements?
Can you share any examples from real projects?
Where should we look for implicit requirements?
What about these known as “non-functional requirements”? expectations on usability or basic security or performance or portability
How can we make them explicit? Should we? To what extent?
Have you ever had a discussion with a developer or a PO, regarding something you consider a bug because of an implicit requirement you don’t agree with your colleague? What should we do in that situation?
What’s the difference between implicit requirements and assumptions?
I see a relationship between them, because there are things that you cannot make explicit, that it’s more efficient to assume, otherwise it would make the process very expensive
Do you have some sort of working agreement with your team about what to do in order to manage implicit requirements?

Depending on the time

Is it possible to prevent bugs?
If we do so effectively, could we stop testing?
When did you change your perspective from the traditional view of finding bugs to preventing bugs? What happened?

Episode source