Testing strategy document - how many? public or private?
I am working with development of my company's testing strategy. In my world a company only has one testing strategy document. In this document several areas could be covered, like testing for Wordpress, testing Sharepoint, testing EpiServer, automatic testing, functional testing and so on and so on. A colleague of mine said to me that she wanted one testing strategy for each platform, but that seems messy to me with one document for EpiServrer, another one for Sharepoint etc. Several times you perform the same tests on each platform and then you have around 5 documents to update if you change the testing process in some way. I always want to avoid the same information on different places/documents.
My colleague also wanted to send our testing strategy to a customer, but I said I do not prefer her sending that document to the customer, since the customer might get the idea that we always test according to the whole document. Also, perhaps there are company "secrets" in the strategy you do not want to send to customers.
Now, my questions:
- How is the testing strategy disposed? One or more documents?
- Is the testing strategy a public document to be sent to a customer? Or do you have one internal testing strategy and one external?
Here is my thought:
1. Have a single common test strategy document which is common across all platforms. For example, this document will cover all the test strategy which can be adapted in all the platforms.
2. Platform specific test strategy document should also be there. If you get a Sharepoint project, you will refer the common strategy document and Sharepoint specific strategy document.
Coming to your 2nd question, definitely test strategy should be a public document . The reason is it acts like your acceptance criteria and better to be shred with clients and get a sign off.
Originally Posted by AwesomeUserName
Testing Transaction Assertions During an Audit
During your audit, you need to test management financial statement assertions for fixed and intangible asset transactions. The six assertions that you must attend to when auditing — occurrence, ownership, completeness, authorization, accuracy, and cutoff — are outlined here
Occurrence: Occurrence tests whether the fixed-asset transactions actually took place. To test the occurrence of fixed-asset additions, you should take a sample of fixed-asset additions and vouch them to supporting documents such as vendor invoices, purchase agreements, and titles.
Ownership: The ownership assertion tests whether your audit client actually has a lawful claim to the fixed asset on its balance sheet. You test this assertion by examining title documents or deeds for proof of ownership.
Completeness: Completeness evaluates the management assertion opposite to occurrence. This means all the fixed and intangible assets your client owns show up on the balance sheet; none are missing.
Authorization: The authorization step addresses whether your client’s management and staff follow proper internal control or other company authorization procedures when approving the purchase or disposal of fixed assets.
I agree with Irsath that in this situation it makes sense to have a universal test approach document and then project/product specific test strategy documents (mix and match the term for the document depending on what's in it). This shouldn't always be the case, but it makes sense when you want a standard testing approach across multiple products but they have individual differences.
As for sharing a testing strategy document with a client, that really depends on you and your company's relationship with your client(s). Even if you can't or won't share the full document though, there is usually no harm in putting together a client friendly version that can be distributed.