Hiccupps

I messed up this week. And the week before. And the week before that, the one prior, most weeks last month, most months this year, most weeks in most months most years ... Basically all the time. And I do it on purpose because it puts me in a position to find bugs that I wouldn't otherwise come across. I'm not talking about deliberately entering junk content into applications, configurations, data and the like. I'm not talking about random clicking in a system under test or trying to engineer corner cases by artificially restricting disk space or RAM or some other resource or any other of those legitimate test vectors that benefit from experimenting with the available parameters. I'm talking about sympathetic testing - or even just plain usage - in an untidy way to try to increase my test coverage in passing. Here's some examples: If your application is in the cloud, maybe don't log out of it when you've finished your current task. Look for odd effe...

Since reading the  last issue of The Testing Planet  on leadership I seem to have come across more blogs than usual talking about how to be a great leader, manager, boss or whatever, for instance: Evaluate Character AND Performance 9 Leadership Tips Anyone Can Use Immediately 10 Things Really Amazing Bosses Do This is why you need to learn how to talk to developers I'm interested in improving as a manager, leader, boss and (especially) whatever and this kind of material can provide inspiration. I'm also keen on personal reflection and introspection as a way of identifying areas to work on and over the years I've come to realise that a couple of principles trump most other things for me: clear : I will do my best to be absolutely clear about what I think, what my response to any request is, what my motivation for any particular approach is, what I will commit to do (or not do) about some problem and so on. I will encourage and answer any question on any work-rel...

Rands recently wrote a great blog post on the way that companies project unrealistic expectations onto new employees, are disappointed when they don't achieve them and then then come to know the new hire further down the line. This trajectory is a familiar one and applies not just to employees but also to many aspects of software development including whole products and features within an application. When a feature description is still relatively broad, unexplored and underdeveloped it will naturally be understood in a variety of ways by different people. Equally naturally, the ways in which it is understood and the depth of the understanding will correspond largely to the particular interests of those people. The sharp end of those interests tend to be in issues that the idea can resolve and the feature can often look like Lilly the Pink  with respect to them. High-level apparent solutions to high-value problems inflate the attraction of the feature. As the feature move...

I had more or less the same conversation with  Michael Bolton and Pradeep Soundararajan recently and both started with a statement about tool use and automation: Pradeep : @testertested : I help testers re-think what they mean by automation. I help them see usage of any tool as automation @qahiccupps : any tool? A pen and paper is a testing tool.. @testertested: Yes, it does help you make notes, that you refer to for re-exploring the app. Do you see it that way? @qahiccupps: Yes, a tool but not automation which, for me, requires action w/o my participation. Another: I can use Excel manually (enter formula into every cell) or automated (macros). Tool != automation. @testertested: So, what about annotation pens and stuff ? @qahiccupps: Used directly it's manual. Without me (directly) controlling, automation. Not sure if we're missing each other's point? Michael : @michaelbolton : Test automation is any use of tools to support testing . @qahiccupps: pen and...