2

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.

Am I understanding this correctly?

enter image description here

3 Answers 3

3

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:

Terminology:

  • 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.

My Approach:

  1. 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.
  2. 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.
  3. 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.

1

I hope this link provide perfect answer to you http://www.tutorialspoint.com/software_testing/software_testing_methods.htm

Here they have explained about Black, White and Grey Box testing.

White Box testers--> Testers, test the Code of the Project, were this is mostly done on Unit Testing

Black Box Testing--> Testers do not have the Knowledge of the code. they test the project by comparing the Requirement Document

0

Depending on what you are trying to achieve you might do both. Test cases are usually in an appendix because they change. Once a MTP is baselined it can be a chore to change it (thank you government).

Take a look at ISO/IEC/IEEE 29119-3:2013. Click the preview button to see what a test plan table of contents should look like. You can also google master test plan template 29119-3

Of course if your project is agile, don't bother.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.