In both black box and white box testing, you are executing test cases and tracking whether they pass or fail. The difference between black box and white box testing is your knowledge of the system under test.
In black box testing, you don't have access to the code. You're writing test cases based on how you, as the user, think the application should behave. I've generally seen this type of testing on existing products that have little or no requirements coverage, or when integrating with 3rd parties whose technology isn't documented well.
In white box testing, you are able to inspect the application code and you have access to business rules and requirements. This is the case with most projects, especially when QA or testing is part of the projects from the beginning.
For a real world example, consider testing a login page:
- A black box test would be when someone gives you the login page without requirements, and asks you to test it. You don't know what the expected errors are, but you'd guess that you should only be able to log in with a valid username and password.
- A white box test would be when you get a user story or requirements that specify what makes for a valid username, what makes for a valid password, identifies any error messages, and may even specify what buttons and text are present on the screen.
In short, white box tests allow for more thorough and robust requirements-based testing, whereas with black box tests you're guessing and going off of your gut and past experiences.
One excellent use case for white box tests is in automation. You can automate black box tests, but when you automate a white box test you can check for specific wording, toasts, errors, etc.