# Testing Against Implicit Requirements with Nicola Lindgren **URL:** \ **Category:** đŸȘ TestBash\ **Tags:** collaboration, testbash-home, requirements\ **Created:** [14 June 2021 08:00 UTC](https://club.ministryoftesting.com/t/testing-against-implicit-requirements-with-nicola-lindgren/50826 "2021-06-14T08:00:55Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![mwinteringham](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/mwinteringham/32/9023_2.png) [@mwinteringham](https://club.ministryoftesting.com/u/mwinteringham)\ **Post date:** [14 June 2021 08:00 UTC](https://club.ministryoftesting.com/t/testing-against-implicit-requirements-with-nicola-lindgren/50826/1 "2021-06-14T08:00:55Z")
For our first talk of TestBash Home 2021, @deament takes to the stage to talk to us about testing against implicit requirements, how to spot them and what shapes them We’ll use this Club thread to share resources mentioned during the talk and answer any questions we don’t get to during the live session. ---
**Author:** ![antonella](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/antonella/32/13918_2.png) [@antonella](https://club.ministryoftesting.com/u/antonella)\ **Post date:** [17 June 2021 20:03 UTC](https://club.ministryoftesting.com/t/testing-against-implicit-requirements-with-nicola-lindgren/50826/2 "2021-06-17T20:03:12Z")
# Questions we didn’t get to 1. I find there are some people who are keen for QA to act as gatekeepers for a release. How do you find this works with reporting your findings without judgement? 2. I find there are some people who are keen for QA to act as gatekeepers for a release. How do you find this works with reporting your findings without judgement? 3. what would you suggest as a way to get testers or devs “to read between the lines” or think about the implicit requirements 4. What do you think are usually the telltale signs of implicit requirements still to be uncovered in a project? 5. Do you identify any metric / how we can measure testing effectiveness applying this to our development cycles? 6. Do you ever have disagreement between dev and product when you reveal an implicit requirement? 7. Do you think, the risks with implicit requirements is higher for “newly formed” teams vs teams, who work long time together? 8. Do you find implicit requirements are discovered/identified easier when pairing/mobbing on testing or getting your head down and focusing on the problem? 9. Where in the time line in a project lifecycle? do you take up the implicit requirements at project start up, SBE? sprint start? exploratory testing? 10. Is there a good way to handle clients (or management) when implicit/unexpected requirements appear? 11. Do you advise acquiring some domain knowledge or gain some understanding of similar projects, when the testers senses that the requirements are implicit? 12. Do you use example mapping and more team meeting to uncover more implicit requirements? How would you go about explaining implicit requirements to someone who is new to the project, who has not have been there from the beginning? 13. How early do you think we need to start implicit requirements testing in the testing life cycle? Do we convert every implicit requirement to explicit ? 14. How would you go about explaining implicit requirements to someone who is new to the project, who has not have been there from the beginning? # Resources mentioned Implicit requirements [What Are Implicit Requirements? Implicit Requirements Definition & FAQ](http://airfocus.com/glossary/what-are-implicit-requirement) Risk storming online [https://riskstormingonline.com/](https://riskstormingonline.com/) What’s a heuristic? [Heuristics: Definition, Examples, and How They Work](https://www.verywellmind.com/what-is-a-heuristic-2795235) Heuristics game from Ministry of Testing [Would Heu-Risk It? – Ministry of Testing Merch](https://store.ministryoftesting.com/collections/would-heu-risk-it) Useful Ministry of Testing article about heuristics > **[Software Testing Heuristics: Mind The Gap!](https://www.ministryoftesting.com/articles/software-testing-heuristics-mind-the-gap)** > > Discover how to apply heuristics effectively TestSphere Arena Expansion > **[Arena](https://www.ministryoftesting.com/testsphere/arena)** > > TestSphere Arena - An Expansion Of TestSphere European Accessibility Act details, it is a requirement in Europe [https://ec.europa.eu/social/main.jsp?catId=1202](https://ec.europa.eu/social/main.jsp?catId=1202) Maik Nog’s book recommendation on the topic of implit/explicit: [Amazon.com: Tacit and Explicit Knowledge: 9780226004211: Collins, Harry: Books](https://www.amazon.com/Tacit-Explicit-Knowledge-Harry-Collins/dp/022600421X) ---
**Author:** ![nicolalindgren](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/nicolalindgren/32/10262_2.png) [@nicolalindgren](https://club.ministryoftesting.com/u/nicolalindgren)\ **Post date:** [17 June 2021 21:04 UTC](https://club.ministryoftesting.com/t/testing-against-implicit-requirements-with-nicola-lindgren/50826/3 "2021-06-17T21:04:27Z")
**I’ll go through roughly half of the questions tonight, then the second half tomorrow** - I find there are some people who are keen for QA to act as gatekeepers for a release. How do you find this works with reporting your findings without judgement? _I find it can be tricky as you may be forced to give a judgement on behaviour being good or bad, even when you just want to present information on how it is. If backed into a corner, I will give my opinion on how risky something can be if we were to go live with something that could be very problematic for end users. But usually benchmarking my findings or just presenting what I find causes the product owner or the rest of the team to act as a gate keeper._ - what would you suggest as a way to get testers or devs “to read between the lines” or think about the implicit requirements \*I find starting discussions with some of your assumptions really helps (with how you, yourself, have read between the lines). Then this helps trigger other people to discuss other aspects - you may find you first discuss browser or device support, but the conversation will probably take you to other aspects of non-functional requirements etc. \* _I think it’s also good to have a go-to of things to start up discussions (HICCUPPS and the non-functional requirements I mentioned in my talk, tend to help me get things going)_ - What do you think are usually the telltale signs of implicit requirements still to be uncovered in a project? _Lack of written requirements (i.e. either they don’t exist or they are very minimum/bare)_ _In discussions about the features, finding people have different understandings of a few things, to me, then implies there could be more things people have different understandings of (so it opens a can of worms)_ - Do you identify any metric / how we can measure testing effectiveness applying this to our development cycles? _I can’t think of any good reliable, measurable metric (as people can act in such a way to make the metric show good results, but testing could still be done poorly)._ _This isn’t the easiest thing to measure, but I do find that when developers actively seek out the input of testers early and others in the team try to get testers more involved - then that is usually evidence that the tester has been recognised to be doing a great job (that’s not to say that if these things aren’t happening, the tester isn’t good - just that the team has recognised the value the tester adds)._ - Do you ever have disagreement between dev and product when you reveal an implicit requirement? _Yes. And that’s where the fun starts - we explain our viewpoints and then come to an agreement on what we think the website/app should do. I’m just happy that the disagreement was brought to our attention so we can address it_ _I’ve found it can be useful to have allies, in past cases the UX designer has been a good one for this, but ultimately I’m not trying to argue that I’m right - more than there could be an expectation for this implicit requirement we should investigate._ - Do you think, the risks with implicit requirements is higher for “newly formed” teams vs teams, who work long time together? _I think they are a higher risk for newly formed teams because they haven’t yet gained a massive understanding of what the product owner or business analyst expects/means when they say/write certain things. Over time, you can learn from past mistakes, and have past features etc, built together as a point of reference._ _There is definitely still a risk of implicit requirements for established teams, but I think having that shared history helps minimise the risk._ - Do you find implicit requirements are discovered/identified easier when pairing/mobbing on testing or getting your head down and focusing on the problem? _Pairing or mobbing._ _More specifically: having discussions with someone so you can trigger ideas off each other._ - Where in the time line in a project lifecycle? do you take up the implicit requirements at project start up, SBE? sprint start? exploratory testing? _You can find implicit requirements all the way from project start-up right up until exploratory testing the website/app in front of you._ [/quote] ---
**Author:** ![nicolalindgren](https://sea2.discourse-cdn.com/flex020/user_avatar/club.ministryoftesting.com/nicolalindgren/32/10262_2.png) [@nicolalindgren](https://club.ministryoftesting.com/u/nicolalindgren)\ **Post date:** [18 June 2021 07:22 UTC](https://club.ministryoftesting.com/t/testing-against-implicit-requirements-with-nicola-lindgren/50826/4 "2021-06-18T07:22:22Z")
**Here is my second half of answers:** > [@antonella](#): > > - Is there a good way to handle clients (or management) when implicit/unexpected requirements appear? > _I think it can be rather tricky as that depends a lot on whether the client thinks it should have been included/done in the first place, or if they understand that the implicit requirement wasn’t immediately obvious. It also depends on the pre-existing relationship you have with that client - if you’ve already established trust with them, then it’s easier - if your relationship with the client is fairly new: then not so much._ > _I’ve found explaining how we saw things at that point in time (try and explain our perspective), really helps - also to not get defensive: it’s hard to get angry at someone if they’re not trying to fight you back._ > _When it comes to money, then implicit requirements can result in scope creep: therefore I’ve found it’s important to try and be more explicit with things in the start. It’s not like you can’t do ANYTHING that isn’t mentioned in the pre-written requirements, but for everyone’s sanity - agreeing that the written requirements is (as it is written) what will be built is sometimes the best you can do._ > > - Do you advise acquiring some domain knowledge or gain some understanding of similar projects, when the testers senses that the requirements are implicit? > _It can help but it’s not necessary. Past experience on projects and knowing how to ask good questions (cue @christian 's talk on do you know how to ask a question) are also useful here when you sense there are implicit requirements._ > > - Do you use example mapping and more team meeting to uncover more implicit requirements? > How would you go about explaining implicit requirements to someone who is new to the project, who has not have been there from the beginning? > \*No I don’t use example mapping - I need to read more on that, thanks 🙂 \* > _But I do use examples extensively in discussions to make sure the team is on the same page_ > _I also book in a few extra team meetings to uncover implicit requirements._ > > - How early do you think we need to start implicit requirements testing in the testing life cycle? Do we convert every implicit requirement to explicit ? > _I think the earlier the better - even in feature discussion/kick-off._ > _It’s good to make known implicit requirements explicit. But I don’t think it’s possible to make every implicit requirement explicit, as that requires an awareness of every implicit requirement that exists - which is very hard to have._ > > - How would you go about explaining implicit requirements to someone who is new to the project, who has not have been there from the beginning? > _WIth new people, I ask about their background (i.e. what they have worked on in the past) and the level of requirements they had worked with - I then use this to frame some examples of implicit requirements that were (probably) there on those projects, that they themselves probably tested against, but weren’t necessarily conscious they were testing against. > From that point, I bring them to where we are on our project and the sort of implicit requirements we have now._