| || |
I am setting up a proof of concept (POC) with a tools vendor and would like to get some feed back from the forum.
I have never headed a POC, or even seen one done before. I have asked some of the people from my group that are going to be involved in the POC and they have never been involved in one either.
Our plans are to take two stable apps, one Java app running on WebLogic and iPlanet and another PHP app (we don't have an app that is using both languages at this point), so we can see the tools running against both languages. We are then going to introduce some bugs (exactly what we have not determined) and move some of the objects around.
When the vendor comes in we plan to have them run the tools against the unchanged versions of the app and then run them against the altered versions.
Now my question (finally): Is there anything else that we should do? How have you managed a POC in the past? Is this the right track or am I in a different world than I should be?
Any help would be greatly appreciated, even if it is as simple as you are a complete idiot and should let someone else in your group handle it.
Sorry for the long winded post.
Sr. QA Lead
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by e-tester:
Sorry for the long winded post. <HR></BLOCKQUOTE>
Geez, if you consider your post long-winded it is no wonder that so many people dislike when I post. Anyway, I will try to keep this short:
A formal POC usually details the following sections:
Just keep in mind that proof-of-concept evaluation (or testing, if you prefer) is the process of determining whether a product or solution meets all of the specifications, advertised features, and promises that have been made about it, particularly any specific SLAs given by the vendor.
Proof-of-concept testing is also a method of determining whether a product or solution, even if it does meet the specifications, successfully fits and functions in your environment, which is what it sounds like you are detailing somewhat.
The basic proof-of-concept evaluations that I have done basically involve determining the environment for which the solution is proposed (and that includes any problems that the solution is supposed to address). That you have to define based on your needs. The second part is setting up a testing environment capable of emulating the real environment to the necessary degree, which it sounds like you are in the process of doing.
The third part is, of course, introducing the proposed solution into the emulated environment and then putting it through a series of pre-defined tests designed to find the weaknesses and problems, particularly SLA violations. Again, this sounds like what you are doing.
So I think you are approaching this just right.
Thanks for the input. I just wanted to make sure I wasn't approaching this wrong.
Sr. QA Lead
[This message has been edited by e-tester (edited 11-19-2001).]