Home › Forums › Software Testing Discussions › Disruptive Testing
- This topic has 10 replies, 3 voices, and was last updated 10 years, 6 months ago by Anne-Marie.
-
AuthorPosts
-
May 22, 2014 at 11:42 am #1781
Got a question that will disrupt? Place it below.
You can view the webinar and slides Here
May 22, 2014 at 1:31 pm #1784Test case prediction from user requirements is precisely an area in which I frequently get into conflict with some colleagues, because they expect that if requirements are very well stated, driving test cases should be straightforward. They get angry when I say that I don’t know any way to have this assurance. This is still a job for someone with experience and system/process knowledge. Do you have any better answer? Thank you, Paulo Marques
May 22, 2014 at 1:48 pm #1785Do you have any advice for additional interesting literature on exploratory testing (book or web)?
May 22, 2014 at 2:01 pm #1786Q Test case prediction from user requirements is precisely an area in which I frequently get into conflict with some colleagues, because they expect that if requirements are very well stated, driving test cases should be straightforward. They get angry when I say that I don’t know any way to have this assurance. This is still a job for someone with experience and system/process knowledge. Do you have any better answer? Thank you, Paulo Marques
A: Wow, lots of stuff in there Paulo. Thanks for the question. I think its worth while acknowledging the effort that your colleagues are putting into writing the requirements. Perhaps its worth looking at the bugs that are found. Are they found within the test cases or external to them? That might be an indicator that regardless of how you try, you will never be able to have perfect requirements. For me, its about understanding that all models are flawed to some point. Its one person view of the problem, and its fallible. Perhaps its time to have a conversation on what they understand software testing to be? Is it to test that a problem is solved or is it to confirm requirements?
May 22, 2014 at 2:03 pm #1787Great presentation Anne-Marie 🙂
Here is a question from one of the attendees:
Do Black Swans only impact waterfall projects, what about agile?
May 22, 2014 at 2:03 pm #1788Q:Do you have any advice for additional interesting literature on exploratory testing (book or web)?
A: I know Elizabeth Hendrikson has written a book on Exploratory Testing that many like. Personally I’m a big fan of James Bach’s and Michael Bolton’s sites where they have many articles on Exploratory Testing. Cem Kaner too has significant detail on Exploratory Testing.
May 22, 2014 at 2:06 pm #1790A: Do Black Swans only impact waterfall projects, what about agile?
Q: Yes, black swans still exist in agile. The benefit to agile is that the impact to an extent is lessened. This is because agile iterative approach accommodates change.
May 22, 2014 at 2:07 pm #1791Please continue to post your questions on disruption here. I’ll respond to these shortly
May 22, 2014 at 3:34 pm #1808Q: Project Managers often ask me for deterministic plans. I send them packing but they return a few days later using manipulative tactics such as their manager needs the figures, or someone I’ll never meet from the business must have some dates/costs by tomorrow etc. At this point I tend to play along and produce crystal-ball gazing plans with loads of caveats because these people pay my invoices and love sacking trouble-makers! What’s your advice to test managers who find themselves in this situation?
A: Hi Declan, I’m always hesitant to give advice to particular scenarios, but here’s a few thoughts and tactics I’ve used in the past. Often, when people ask for estimated, its often the case (in my experience) that they have some fixed idea in their head. You can always ask them for this. So instead of offering a figure you ask them, “how much time do I have?, I’ll test to that.
Another option is to offer a range. It’s not quite as effective as in my experience people just hear the shortest timeframe.
I did hear a talk by James Bach on estimates where he suggests using a tiered system (if I recall right) so he offers a platinum estimate, a silver estimate and a bronze estimate, and ask the project manager to decide which one he wants. Its all dependant on the amount of information offered. The point is to demonstrate how varied an estimate can be. It’s probably on his website if you want to look it up.
My preference is the first one.
May 22, 2014 at 3:54 pm #1811It is a difficult topic, and one i suspect that isn’t going to come to us in a nicely wrapped parcel with a red ribbon. I think though that its people like you that are going to make the difference.
I suspect a combination of education and persistence is the way to go. Also adopting an exploratory testing approach makes it hard for project managers to easily ‘count’. Instead its a time measurement. Perhaps instead of facing the *test case estimate* issue head on, it might be worthwhile trailing an ET approach, perhaps in a pilot to see ‘explore’ the possibilities? Its hard to know – each organisation is so different isn’t it!
But regardless, I’d encourage to write and develop what works for you. Be vocal and encourage other testers around you to be vocal. I believe over time we will straddle this hurdle but I suspect the solution is going to come for testers such as you – working at the coal face.
May 22, 2014 at 7:46 pm #1813Declan, here’s a great link by Jerry Weinberg on requirements I think you might enjoy http://secretsofconsulting.blogspot.co.uk/2014/05/methodologies-arent-enough.html
-
AuthorPosts
- You must be logged in to reply to this topic.