In this post, we will discuss Proof of Concept done before selecting an automation tool.
Proof of Concept
Proof of Concept( w.r.t Automation Framework) is a research and study done before selecting an automation tool. The study checks the tool to satisfy the evaluation criteria. Often while conducting the study, it is necessary to try the tool for a few test scenarios and use cases. The engineer picks the vendor evaluation copy of the tool for this purpose for a limited period of time. It is sufficient to use the evaluation version for the PoC, instead of spending money on the tool.
Scenarios to Pick
The scenarios should be chosen in such a way that the scenarios cover important aspects and some key features present in the tool. The scenarios chosen for PoC are very important. For example, if you are looking for parallel tests in the framework, there is no point in checking a single test in a thread in the PoC.
The key objective of you is to prove that the tool can work for automation.
PoC should install confidence in the tool. Otherwise, it would be a throw-away.
It should cover sample automated cases to give the confidence that automation using the tool will be successful.
It should be time-boxed and fit in a small iteration if the methodology is Agile. I often notice spill over’s for the Spike effort.
PoC should be small. Don’t waste big chunks of time on it.
Although it’s not necessary for a demo, it’s good to have a demo for DoD( Definition of Done )