Given a simple application diagram how would you test it or what will
be your test plan or test strategy.
The only answer to a question like this is: "There is no such thing as 'go there and test'". Testing is performing a risk investigation activity. Any investigation has goals and questions to be answered.
So, what type of testing one usually do in software systems with components of UI, Business Logic, and data storage?
UI -> Usability, accessibility, consistency, internationalization, etc;
Business Logic -> Error handling, boundary cases handling, code health, etc;
Data storage -> Scalability, reliability, chaos handling, etc;
System-level -> Comparison with competitors, inward and outward dependencies.
It may be important in your context to have fast feedback that we are building what we think we want to build. This is where automated checking comes into play: Unit testing, integration testing, acceptance testing, etc.
But these are the techniques to investigate some risks. To uncover these risks, you do risk analysis, with techniques such as Open Coding (extracting risk scenarios from the risk categories) and Backwards Coding (extracting risk categories from risk scenarios (in order to fuel a round of Open Coding)).
A test plan is a document showing who does what and when, and how things connect to each other to fulfil an investigative goal ("Which risks were we focused on and how did we investigate them?").
You can use Product Coverage Outlines and checklists to explain it.
In the end, your test plan and the test report should tell a story to your stakeholders:
A test strategy encompasses the framework under which your test plans for a product are created, detailing the context of develop of this product. One common example is the Heuristic Test Strategy Model
