I cannot stress how crucial it is for a Tester to have an understanding of the architectures and underlying cohesiveness of the system and this can be understood from Project Documentation.
Test Strategy and Scripts have a very strong dependency on Project Documentation, so when this is poorly executed you could have poor testing.
As you may have guessed it’s important to be able to assess document quality and demand for better quality where needed.
One way to assess this quality is to use the 5Ws (Rudyard Kipling)
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
So far I have come across some documents that say what they do but not why they do it.
“Why” is important than just the “what” you do, as it makes the what relevant and in context and provides connectivity.
I have built an application and this is what I did to make it work.... why? To do calculations
Applying where (location) and when (time) constraints highlights any important issues that might get overlooked.
The next thing is How. How is essential for actions to be taken by the reader/circulation list
How do you implement this? What are the prerequisites needed to do this.
Create separate paragraphs for the How defining usage of what was created and why it was created
Mixing what’s and how’s together without separating and you may lose emphasis on "hot soup" areas.
Using the 5Ws helps define, contextualise, highlight and activate you into action ensuring Test Strategy and Scripts serve their purpose and dont gather dust.