The Times has an interesting article on investors’ attitudes to financial risk tolerance. Data suggest that investors’ perceived and actual risk tolerances can markedly differ, affecting the suitability of their investment portfolios.
So why’s this relevant? Well, as testers we always make risk-based calls on what to test and to what extent. We therefore need to understand how our perception of our own risk tolerance maps to that of the business so that these decisions are in line with what the delivery, and business, needs.
For a short while The Times has teamed up with finametrica.com who provide an online risk tolerance questionnaire. It’s obviously geared towards financial risk, but it’s well worth a look to see how your own risk tolerance maps to that of the adult population.
How does a website hosting a search for used cars already know my postcode?
I was a little confused about this, but the answer is obvious – yes I had used this search service before. In fact the basic search criteria could be easily pre-populated from data already persisted to my machine. The website in question utilizes Adobe Flash Player technology and a quick trip to their Settings Manager helped me understand what was going on. In my case the feature was quite convenient, but certainly behaviuor to be aware of if you are using a shared machine.
A few days ago, the network interface on my system ground to a halt. The arp and netstat commands suggested something strange might be going on, but I really needed to correlate the network connections with the system processes. I then discovered the -b flag for netstat (on Windows XP) which does exactly this, and helped me to isolate the problem.
We’ve been using a much more agile development process than in the past, continually tweaking our approach and trying out new development and test tooling. I’m really pleased to say that this investment has paid off: even as a hardened test cynic, I’m genuinely impressed by the quality.
I was on a conference call today and someone mentioned that C has regained its place as the industry’s most popular programming language. I couldn’t believe it, after all Java has ruled the #1 spot for the last four years.
A quick check on the TIOBE index showed this to be true:
The explanation they give is not that C is growing but that Java is declining. So what does this mean for the industry? Is Java dying? Is there another contender for the top spot gradually working its way up the ladder?
The one thing that stands out is that C is a good language to know. It’s been around a while and it’s not going anywhere in a hurry. I wonder if they’re still teaching it at college and university
If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying. Find new ways to instrument the software, and come up with more creative tests. The odds are that there are still bugs in the code, which may or may not be related to unintended acceleration. Until these bugs are identified, how can you be certain they are not related to sudden acceleration?
This brings us back, as ever, to the question of “when do you stop testing?”. How do you answer that question when safety is involved? At some point, you have to ship your product. With software, we are often afforded the luxury of updating it afterwards, but it isn’t always possible (problems with installation programs usually fit into this category, as do many embedded systems). We can never prove the absence of errors.
“The executive who decides whether or not you will be allowed to release your product, will not be looking at your product code to make that decision. They will be looking at your defect numbers and your test pass rates.”
This is how I started a conference call last week, as part of a session to encourage more focus on test.
In a truly Agile team there are no dedicated testers or developers. Everyone is a software engineer and everyone shares responsibility for the quality of what is produced.
In an ideal world everyone would harbour a deep desire to ensure testing has been done fully, before even considering the possibility of coding more features. Sadly, in reality it is all too tempting to charge ahead with the next feature on the list. Because it is so hard to know when you are ‘done’ testing and so easy to see the features you’ve not started yet.
So I find myself trying to raise the profile of the business of testing, why we do it, and how our process ties into it. Software engineers find it easy to understand all the features that need to be written to meet the requirements. What is needed is a gentle reminder that the gateway to release is controlled by someone who will not try the product, they will not read the code, or even the documentation. The measures that they use to determine fitness for release are defect trends and test passes. They look to see that the rate of high severity defects being raised has dropped off, and that the tests are, if not 100% passing, then very close to it.
In a traditional team, one or two key people needed to worry about that and direct their fixed teams accordingly. Part of being an Agile team is making sure that everyone understands these metrics and takes their share of responsibility to prioritise test in their planning.
Shortly after my conference call, one of the local component leads told me that another team had let him know they would not be developing the feature he wanted until the next sprint, because their plan was full with testing in the current sprint. What’s more, he understood and accepted that this took priority over his request. So, for the moment at least, the message is getting through.
Whilst we now take for granted the ability to enjoy our banking, shopping, socialising and entertainment online, back in the “early days” this future was by no means assured:
The proliferation of web applications and their increasing complexity pose huge challenges to us as testers. In this post we’ll take a *very high-level* tour of what to look out for, and how we might approach testing web applications.
I’ve been testing a tool that manipulates Java web application archives (WARs) – but it’s a challenge to ensure I’ve got a representative cross-section of real-life WARs to test against. So far, I’ve been hunting for samples and coding up my own WARs – convolving the Java specifications with common patterns I’ve seen recommended on developer forums. It’s a shame there doesn’t seem to be a repository out there of a broad range of samples for me to deploy to my application server and test the tool against.
