Create a Testing Plan:
So, you’ve built your portal, migrated some content into your pilot test sites, configured the basic functionality that was to be delivered in Phase I. Now, it’s time to see how your pilot group reacts to the portal.
This testing phase is going to be where you’ll identify many “little” issues that need to be, as well as any major “misses” that may have, inadvertently, skipped by you tweaked (it’s great to get fresh pairs of eyes on the project after you’ve stared at it from every angle). To do this, you must create a solid Test Plan.
The Test Plan can be as simple or as complex as you want to make it. You could do a very thorough use case analysis, if that’s what you prefer. There are great resources out there for creating use cases.
Microsoft provides a great resource on this topic. Personally, I would use their version as a general guide, since this resource is not specifically designed for Portals.
Of course, I like a more simple approach – but without sacrificing doing it “right”. So, I’m going to show you my way of creating a simple Test Plan that is flexible, scalable, but super easy to create. Because we did some great work in previous phases, most of the heavy-lifting has already been done. For starters, go find your Requirements Traceability Matrix. You’ll need it to build your use cases.
What should my Test Plan include?
The following is a basic run-down of what should be included in your test plan. The SharePoint Dude Sample Test Plan format is very simple, which makes it easy to fill out. However, it’s also very scalable, so if you want to conduct complex and/or thorough use case analysis, feel free to get as detailed as you wish!
This is a very basic (but effective) form of use case analysis. You can view my sample and run with it if you wish. The information below is how I went about creating the sample.
You should include an objective statement (or paragraph, or section), detailing exactly what you’re intentions are. In this case, we’ll be testing our new portal solution, so we want to state our main objectives in testing this solution. Some of your objectives could include (loosely worded for now):
- Ensure that business requirements have been met
- Ensure that functional requirements have been met
- Ensure that graphics/branding renders correctly
- Evaluate system performance
- Determine users’ level of satisfaction
In my sample, we will write out the above bullets in paragraph form.
Include a brief section (maybe a table or something) that details the following:
- Who will be testing?
- What will the Test?
- When will they test it?
- How long will they spend testing it?
Specifically who will do what?
- Who determines what to test?
- Who will write the test cases?
- Who will execute each test case?
- Who will verify results?
- Who will collect feedback?
Define User / Tester Types:
Define user/tester types: I kept this very simple.
Admins – People who own the portal, manage security, content, design, maintenance, etc. Also users and navigators of the site.
Content Stewards – People who will administrate sites at the departmental level, also users and navigators of the site.
Users – people who will read, navigate, and/or contribute content to the portal.
Outline use cases
Create a table in a document with the following columns:
- User Type
- Test Description (Intention)
- Steps to test
- Result (System Response)
To make this super easy, just bust out your Requirements Traceability Matrix and make sure you test for success on each requirement documented (business, functional, and technical).
Focus on use cases that will directly address the goals your Portal Committee outlined in Phase 1 & 2. You want to be able to show people that your objectives were met and well-received. (Documented Success!)
Make sure that you meet all of the objectives that you set out for this phase/project. Additionally, find out from the testers what their first impressions were. Did they like it? Dislike it? Find it useful or confusing? Get that feedback early, while you can still do something about it!