Recently, I once again saw the well-known Venn-diagram that is often used by Context-Driven Testing School adepts (this time at presentation at QA Fest 2017. Ilari Henrik Aegerter. What is Context- Driven Testing?).
But I decided to improve it a bit.
Let me explain this a bit to those who has not attended parties with participation of Context-Driven testers.
Explicit Requirements are the whole corpus of documentation, from a sentence in an instant messaging or email to the law regulating the industry in the target market country. Since the Manifesto for Agile Software Development stated in 2001 we should value "customer collaboration over contract negotiation", the understanding spread out that one cannot document every aspect of the future software usage, but instead should constantly "talk to business". Thus now, in 2018 software development team starts their job with listening to the Product Owner (the business representative); and continues listening through the whole way of the Software Development Life Cycle. To sum up, every business guys' whisper that we can understand may be considered as an Explicit Requirement.
Areas 1 and 6 are Implicit Requirements. This may be thought about as unspoken expectations, something the requestor asumes to be so obvious that it does not worth mentioning. Although they are not spoken out loud, the implicit requirements may be even more important to the requesting people, as they may form the basis of the future business process.
Area 6 corresponds to a "shared understanding" or a "Tacit Knowledge", the common understanding of the problem and solution between customers and developers. This very area is growing more, the more intensive is the communication between business and the implementation team.
Area 1 is what the developers know nothing about. This also incorporates the changes of business values that happen in-process. And of course this are area is unlimited as nobody can have the same experience and know the market future.
Area 4 is customers' expectations the developers misunderstood.
For example, the line "The page should be secure." may be understood by developers as "HTTPS should be enabled." But the customer meant "We need a separate level of permissions here." And this is a part of the tester's work to search for such ambigouos points and ask the right questions. With this activity called Requirement Testing, software testers make the implicit requirements to be more explicit.
Areas 4 and 2 are written but not understood by the developers (and are missed by testers and analysts).
Furthermore, areas 2 and 5 are not understood by the customers either. This could happen if the part of the document is copied from another project, and when the area 5 is understood and implemented by the team, the area 2 could be silently considered as "out of scope" for now and just ignored.
What is written is always limited, so no infinite parts here.
Area 6 is implemented but not intentionally, just a coinsidence of customer and developer thoughts.
And the area 3 was out of control and understanding of customers. For example, programmers added a modern API support that allows an easy way of geolocation; or have designed the app to work without internets and to get synchronized when it comes on-line.
Also it includes the factors not even controlled by developers or operations. Such as a 3rd party dependent software and hardware, updates and support issues. The area 3 is also unlimited as no one can predict when some software gets updated or hardware breaks.
Hopefully, the diagram helps to understand the knowledge sharing issues to software testers and others involved.
But I decided to improve it a bit.
Areas 4 + 7 + 5 + 2 - Written Requirements
Areas 1 + 4 + 7 + 6 - Customers' Expectations
Areas 6 + 7 + 5 + 3 - Actual Product
Only growing areas 6 and 7 will add value to the project and satisfy the business needs.
Let me explain this a bit to those who has not attended parties with participation of Context-Driven testers.
Customers' Expectations
Areas 4 and 7 are a limited part of the expactations that is written and understood correctly by the developers. This part is reffered to in other models as Explicit Requirements.Explicit Requirements are the whole corpus of documentation, from a sentence in an instant messaging or email to the law regulating the industry in the target market country. Since the Manifesto for Agile Software Development stated in 2001 we should value "customer collaboration over contract negotiation", the understanding spread out that one cannot document every aspect of the future software usage, but instead should constantly "talk to business". Thus now, in 2018 software development team starts their job with listening to the Product Owner (the business representative); and continues listening through the whole way of the Software Development Life Cycle. To sum up, every business guys' whisper that we can understand may be considered as an Explicit Requirement.
Areas 1 and 6 are Implicit Requirements. This may be thought about as unspoken expectations, something the requestor asumes to be so obvious that it does not worth mentioning. Although they are not spoken out loud, the implicit requirements may be even more important to the requesting people, as they may form the basis of the future business process.
Area 6 corresponds to a "shared understanding" or a "Tacit Knowledge", the common understanding of the problem and solution between customers and developers. This very area is growing more, the more intensive is the communication between business and the implementation team.
Area 1 is what the developers know nothing about. This also incorporates the changes of business values that happen in-process. And of course this are area is unlimited as nobody can have the same experience and know the market future.
Area 4 is customers' expectations the developers misunderstood.
For example, the line "The page should be secure." may be understood by developers as "HTTPS should be enabled." But the customer meant "We need a separate level of permissions here." And this is a part of the tester's work to search for such ambigouos points and ask the right questions. With this activity called Requirement Testing, software testers make the implicit requirements to be more explicit.
Written Requirements
Why isn't the whole written documentation just implemented?Areas 4 and 2 are written but not understood by the developers (and are missed by testers and analysts).
Furthermore, areas 2 and 5 are not understood by the customers either. This could happen if the part of the document is copied from another project, and when the area 5 is understood and implemented by the team, the area 2 could be silently considered as "out of scope" for now and just ignored.
What is written is always limited, so no infinite parts here.
Actual Product
Areas 5 and 7 are intentionally implemented by developers.Area 6 is implemented but not intentionally, just a coinsidence of customer and developer thoughts.
And the area 3 was out of control and understanding of customers. For example, programmers added a modern API support that allows an easy way of geolocation; or have designed the app to work without internets and to get synchronized when it comes on-line.
Also it includes the factors not even controlled by developers or operations. Such as a 3rd party dependent software and hardware, updates and support issues. The area 3 is also unlimited as no one can predict when some software gets updated or hardware breaks.
Hopefully, the diagram helps to understand the knowledge sharing issues to software testers and others involved.
3 коментарі:
Hi Oleksii,
I really like Ian McCowatt's take on this. In fact, I like it so much, I stole the idea (and added horse jokes) for an article in my company newletter :)
Thanks James for such respectful links in this post!
The first time I saw this kind of diagram long ago but something was buzzing me all that time. And now I have realized what was that and implemented on the picture:
Both expectations and reality are infinite, but they intersect as a limited area.
And your jokes are fun indeed :-))
Дописати коментар