Creating a test plan for digital advertising can be a daunting task that forces the tester to ask a lot of questions. But that’s the point. As a tester, you need to ask these questions because you need to know everything. What are you testing? Should this be compatible with non-traditional devices (smartphones, tablets, etc.)? Where are you testing? When should you start testing? How many test cycles are there? These are some essential questions, and exploring them in depth can help set you on the right path.

What are you testing?

This is the beginning. The client comes to you with a request – it may be to build a new website, a landing page, an email, a Facebook tab, etc. This is when you define the test plan. The first step is to understand the requirements; for example, what are the front end or user interface requirements? What are the back end or user data requirements? Are both of these even required? Are there forms? Should you be testing to see if it fails properly? What about form validation? Most important, this is when you define the functional requirements – does the development match up against the client’s design and specifications?

Should this be compatible with non-traditional devices (smartphones, tablets, etc.)?

Now it’s time to define the compatibility requirements. Is this a web-based project? What is the browser support? Do you have to support particular, less common browsers like Internet Explorer 6 or 7? What is the operating system support? Is it mobile compatible? Tablet compatible? Or if it’s an email, what email clients should support it? Does the email need to render properly in a mobile device?

Where are you testing?

When the testing begins, you should have at least two, and usually three, different environments. You have the development environment – where you do all the development work and where the initial test cycle takes place. Then you have the staging environment – this is separate from the dev environment and allows you to move work to a different server while continuing to code. The staging server is a replica of the live environment.

Lastly, you have the live production environment. This is the public-facing, live environment. You should test in all three environments during the test cycle.

When should you start testing?

This is perhaps the easiest question to answer. The testing process begins once the client’s request is received. It is, in fact, vital that the testing team be included from the very beginning stages. Most testers believe in the “Rule of Three,” which states that all conversations regarding the development of the client’s request include a member of development, testing and the account service/project management team. It’s in these initial conversations that you can gather a complete understanding of the project’s scope and tailor the test plan to meet the client’s expectations.

How many test cycles should you have?

As many as you need. The number of test cycles can range from one to infinity. The key here is for the testing to begin when the development cycle ends. Why? Because any small change made to code can adversely affect the project and will necessitate retesting. Once the dev cycle ends, the testing begins.

When the testing has been successfully completed, it’s time to move on to the staging environment, where testing begins all over again. At this point, you’ll need to do a walk-through of staging to be sure that every change, fix and update made the migration. After this round of testing passes QA, it’s time for acceptance testing. This is the client’s opportunity to review the code to make sure it meets their expectations.

After that, it’s finally time to roll the project out to the public…and test again! A post-launch QA walk-through is essential for every release. So head back to the test plan, and start again on the live production site.

When it comes to testing, it’s about asking questions – user flow, experience, form validation, tracking, etc. Testing requires knowledge, and you acquire that knowledge by asking questions. Lots of questions. So if you are having trouble getting started, don’t worry. Just start asking questions and the test plan will write itself.