The main message is that there needs to be validation of the product idea up front, rather than getting the product idea wrong and potentially killing a start-up one or two years down the road. This is not prototyping which can be considered verifying that the underlying technologies should work together but a stage prior to this, using "arts and crafts"-type materials rather than hardware/software.
The secondary message is that calling yourself a tester, even an automation tester, or "quality assurance person" is detrimental to one's career as these skills are thought of as commodities. That is, the person is interchangeable with an offshore resource. Rather QA people should take the role of "righters" or people that make a project "right". I argue that everyone on a project should be responsible for making a project "right", but from past experience, getting your voice heard can be challenging, especially on more hierarchical teams. Also inertia is a hard thing to fight.
Labels
.net
(1)
*nix
(1)
administration
(1)
Android
(2)
Axis2
(2)
best practice
(5)
big-data
(1)
business-analysis
(1)
code re-use
(1)
continuous-integration
(1)
Cordova-PhoneGap
(1)
database
(2)
defect
(1)
design
(3)
Eclipse
(7)
education
(1)
groovy
(2)
https
(2)
Hudson
(4)
Java
(1)
JAX-RS
(2)
Jersey
(3)
Jetty
(1)
localization
(1)
m2eclipse
(2)
MapForce
(1)
Maven
(12)
MySQL
(1)
Nexus
(4)
notes
(4)
OO
(1)
Oracle
(4)
performance
(1)
Perl
(1)
PL/SQL
(1)
podcast
(1)
PostgreSQL
(1)
requirement
(1)
scripting
(1)
serialization
(1)
shell
(1)
SoapUI
(1)
SQL
(1)
SSH
(2)
stored procedure
(1)
STS
(2)
Subclipse
(1)
Subversion
(3)
TOAD
(3)
Tomcat
(4)
UML
(2)
unit-testing
(2)
WAMP
(1)
WAS
(3)
Windows
(3)
WP8
(2)
WTP
(2)
XML
(4)
XSLT
(1)
Thursday, April 25, 2013
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment