I'm fairly new to this subject. Out of different literature I'm understanding what I show in the image below.
My understanding is first you have to create test plan, After test plan you have to create test cases, but this is dependent on the testing techniques that you are using, like you see in the image below.
This isn't how I approach testing but I suppose you could try it like this. Based on the diagram it seems very top down and doesn't represent how you might actually approach testing. In practice I do something like this:
Test Plan - contains the logistical information (delivery dates, who is on the team, etc etc) and the Test Strategy. This could be a written document or not.
Test Strategy - contains the test ideas (some call them test cases) and to a larger extent the test techniques I intend to use.
Test Techniques - ways to design, run and interpret the results of tests.
I will design my Test Strategy first based on what my information objective is and what product (or service) I am testing. My information objective (or my mission) will help me understand what risks were looking for and that will help me determine what approaches I take (black box, glass / white box) and what test techniques I use.
This information feeds back into my over-all Test Plan. I look to the test plan for help with understanding how much time I have to complete my testing but I typically won't spend more than 30 minutes on this document. It's really just a high-level overview.
I will choose the best test techniques for the job (and my skill comfort level), approach them in either a black box or glass box way and then design tests to hopefully reveal failures.
It's worth noting that some describe certain test techniques as "black box techniques" or "white box techniques". It's true that some make more sense to do with the internal knowledge of the code (glass / white box) and some make more sense to do without it (black box) but some test techniques can be applied in both ways. For example Boundary Value Analysis could be applied both with or without internal knowledge of the code. See my comment on this post for an example: Black box testing methods without knowledge.