In discussions of software #testing, people often say to me “In the real world, I have to…” just before they describe some way of faking.
— Michael Bolton (@michaelbolton) September 11, 2012
bit.ly/Qdv3o5 @jhunterj @salvius23 And instead of thinking “pass”, think “appeared to meet some requirement to some degree.” #testing
— Michael Bolton (@michaelbolton) September 12, 2012
@michaelbolton One answer: testing that ignores problems and value.
— George Dinwiddie (@gdinwiddie) September 12, 2012
bit.ly/RIEj5g User experience is also about responsiveness, compatibility, support, elegance, flow. Are you #testing for those?
— Michael Bolton (@michaelbolton) September 12, 2012
Bugs are bad, but confusion, misunderstanding, and disagreement are the nests where bugs develop. Give priority to reporting nests. #testing
— Michael Bolton (@michaelbolton) September 13, 2012
If you think #testing is the bottleneck, another problem is that there are things around the bottle that are poorly understood.
— Michael Bolton (@michaelbolton) September 13, 2012
@aquintian If you’re a tester, it’s very unlikely that you have control over schedule, budget, staffing, release date, product scope (1/2)
— Michael Bolton (@michaelbolton) September 13, 2012
@aquintian or source code. So the best you can possibly do is to provide information to those who DO have control over those things. (2/2)
— Michael Bolton (@michaelbolton) September 13, 2012
@aquintian So the question arises, then:on what, exactly, do they base a *demand* for you to deliver a high quality product?
— Michael Bolton (@michaelbolton) September 13, 2012
