Why we build prototype for application ?
Following are the purpose for building prototype for application
a) Prototypes enable developers and testers to see what is being constructed.
b) It enable to select most appropriate test environment.
c) It help in improve the requirements.
d) In case of Automation , it enable tester to select appropriate testing tools.
Is it a question or a discussion????
A - Generally this is done using High Def markup. Prototypes are harder to build than a UI designer photoshopping a set of screens together.
Originally Posted by Rishi.Gulati
B - What do you mean by this? This might be a case for version 0.1, when you're starting with nothing. But generally not the case when you have an existing build/test environments already in place.
C - Yes and No. Primary purpose of prototyping is to explore technical risks. Requirement risks will mostly be done through story boarding, customer mind maps, business plan canvas, and customer interviews. Requirements is mostly a business/marketing process. Prototyping may be used to explore how feasible it may be to implement it. But not the primary reason for doing prototying.
D - Yes it should be, but rarely isn't. Most automation engineers never even see the prototypes. It's really not that helpful since prototypes are generally not build using the same technologies as the real product. If I were prototyping things, I'll use rapid prototyping tools and more likely different frameworks than the platform used by the current app. This is mainly because I want to explore creating the technology quickly to prove it, and I wouldn't want to be encumbered with legacy code or security requirements. Security requirements will greatly affect automation capabilities.
To clarify to my previous comment. My view is slightly skewed towards larger enterprises that has a separate UX and Research divisions. So usually new feature ideas are being fed in via business with UX mocking them up. And research prototypes being done by a separate research team to prove the feature is possible before the main product teams tries to implement them. This allows the main product teams to focus solely on implementation and stability, and not have to bother with research and theoreticals.