Testing is the cause of poor quality software

I'm going out on a bit of a tangent for this one but I think that's its got some merit.

Recently I was part of a conversation about all of the issues we'd discovered during a testing cycle. The back story is earlier this year a new test environment was built and we tested it. We tested the environment in-line with our current practices which is to run a suite of tests that tests all of the major components and system flows. This test suite can be completed in roughly 4 hours. If we were to run our complete system test it takes about 3 weeks and so taking a risk based approach we opted for the quick test cycle. This decision was predicated on the fact that this environment would be build using tested and approved build instructions which have previously delivered a stable and complete environment.

Fast forward to the conversation mentioned earlier. It went something like they said "Didn't you test it properly?" I said "Yes, we followed our standard process and ran the quick cycle tests" they said "well that's why all the defects, we need you to test it to make sure it done right." I said, well nothing... Pondering the conversation has lead me to believe the testing is the cause of poor quality software. Why, well because the folks who build the software rely on testers for quality control rather than focus on quality assurance themselves; With timelines never being long enough to build a proper solution of course there isn't enough time to test it before it goes into test. But that is ok, that's why we have testers, they test and they'll caught the bugs before they go into production.

So tonight, my thoughts are along the lines of if we get rid of the testers, then the folks who build the software will have to build and test; therefore the quality of software will increase and shift away from the compliancy of the testers will catch it! After all those testers take so long to test anything...

Are we asking the right question?

I'm part way through reading Freakonomics by Steven D Levitt & Stephen J Dubner (Gr8 read just quitely!). In the opening "economics is a science with excellent tools for gaining answers but a serious shortage of interesting questions..." and this starting me wondering are we asking the right questions in software testing? I mean every day I get asked how's our defect count, how close are we to finishing testing, how many tests have you run, how many are left, were is the test report. All of these are valid but really uninteresting questions (I think!) rather blah and binary, and really do the answers to these questions really tell us much? There's a line in one of the Disney movies (Shrek I think) in which one of the characters supporting characters said "blah, blah blah" and then the main character said "yes he's talking, but is he saying anything?" Which is kind of the way I feel about answering the daily questions. I give the answers, but without understanding the meaning behind the numbers or tends am I really saying anything? Shouldn't we be being asked about business processes or risks or impact on revenue? These are much more interesting but I think based on the freakonomics outlook something like ... help help me to find an interesting question!  

more to come...

Are we testing the right things?

Recently on a plane back from Adelaide I read an article in the QANTAS in-flight magazine the Australian Way (as you do!) the article was written through the eyes of a traveller who was visiting somewhere in either Canada or North America. The bits of the article I found most thought provoking was the quotes of the tour guide who said something like 'focus on what you can see, stop and admire all that is around you; don't lament the that you didn't see a bear, be thankful you have seen over 100 different types of plants and animals.' The guide went on to say 'all too often tourists visit these parts and rush from place to place to see this and that, taking only photos of things, not creating a memory by experiencing being there'. This made perfect sense too me the phase "Stop and smell the roses" came to mind. By chance tonight I saw the tagline of another article Look Beyond the Lens on the Sydney Morning Herald's website and after only reading the tagline I pondered.... As testers, in testing do we sometimes focus too much on proving that a requirements have been implemented or that defects have been found as a result of our efforts - to prove we were there? Do we focus on finding the bear in the woods because it's big, scary and easy to see or not see, all the while missing the wondrous smaller wildlife, flowers and trees that are necessary parts of the ecosystem for the bear to survive or equally perish?

My initial thoughts were along the lines of do we focus too much on finding bugs and satisfying requirements (taking pictures - see it is there, I saw it) only to forsake to the things that our users actually need from the system to do there job or improve their efficiencies? And if this is the case, then how do we change our plans to allow us to stop for a while and just "be there"...  Somehow I think the need to take pictures and wiz off to the next location is a result of time constrains and a desire to see as much as possible in a given period of time. Equally in testing, time or lack of time is a huge factor. But it is time that maybe the ultimate measure for a picture only lasts for as long as the media is around and often fades over time (remember when they used to print pictures!) while a memory can live forever being pasted from one generation to another! It's time to choose which we value more, pictures or memories...  
  

The Missing Link, found sort of!

Dude, where's my link? would also have been an appropriate title for this blog entry! I came across this little gem over the weekend - it's a beauty a double fail, firstly the link colour has been set to 'white' when not active and yellow when active. Neither of these two colours work at all well and makes it easy to see why blue link text is the default. Given the location of this particular link (within a tender site) I suspect that its a section of a document that has been copy and pasted in and relies on a style sheet thats not present in the destination website - but that's no excuse for not proof reading!!!

Go where?

Here?

The Law of Gravity

Have you ever sat and thought about something so random as this...

I've had this reoccurring thought recently and I have no idea why, but as we were driving to Sydney over Easter I thought to myself - "How important is gravity to our modern societies concept of law?". So over the past few weeks I have continued to ponder this thought. I seem to recall a car on the side of the road and thinking something like "once we have cars that can fly or vertical cities like the ones in star wars and other such fantasy worlds will we have to change the laws we have now? At the moment if you own a car, you can park it in your driveway or garage and people know its your because its on your property and its our friend gravity that is keeping where you parked it. But imagine with no gravity, you bounce or float out of your car, close the door and make your way inside, only to notice sometime later your car floating by your window, with your neighbours with it - just floating around. I'm sure there won't be too much of an issue in the local area but what about if you visit a friend in another part of town and you have to find your car - you could just claim another one? On reflection cars are not the best example, they have number plates etc so lets think about pot plants or other non-identified house hold items. We have heaps of pot plants around the outside of our house what if they just floated away and we had to fetch them? People know they are ours at the moment, because they are at our house. Not sure what you think, but I am sure that there is a strong link between the law of gravity and the law of common society and possession.

Thoughts provoked by the Information Age (ACS magazine)

There were several articles that tweaked my interested and awoken the sleeping grey matter from its weekend slumber! The first was one titled "Investing in careers with SFIA" which describes how Westpac has incorporated the Skills Framework for the Information Age (SFIA) as part of managing the 'whole employment life-cycle'. SFIA has been at the front of my mind recently as it's featured in many discussions I've had with clients and service providers alike. Initially I was drawn into reading this article because of the relevance to my current activities-discussions which centre around the implementation and benefits of the framework but two-thrids of the way through I found the paragraph circled in the picture below. My first thought was of all the skills in SFIA (there are 89 odd skill areas) the Westpac executive choose to highlight testing, not Development, Not BA's and not Project Managers but Testing. The article didn't explain why testing and not the others, but what I liked was that his person understands that testing is a Professional Skill, with a career path just like any other the skills in the Framework. At the recent Test Managers Forum there was lots of discussion surrounding professionalising testing and I am now seeing evidence we are heading in the right direction! My thought is that the next step will be to have the difference streams of testing (Performance, Automation, Functional) recognised as skills in there own right - more too follow on that one.

The article can be found on page 38-39 of the Information Age.

The next article that captured my attention was  'ICT's biggest money wasters' (pg 46-49). Unfortunately in the software testing game we all too often see evidence of the number 1 cited cause of waste: "Dusty Software Licenses". For the most part I've seen this occur in the niche areas of software testing Automation and Performance Testing and they are usually accompanied by/or caused in part by number 1's closest friend, number 6: "ICT projects gone wild". 

All to often I have seen organisations spend Thousands of dollars on tools to make the testing process more efficient and end up delivering far less than was originally specified. There are many reasons for this result, the least of which is that within IT we often attempt upgrades and process improvement activities internally and we don't apply the same level of rigour and governance that we do as when we are delivering project for an external stakeholders. We often put the tool subject matter expert or super user in charge of the project, on top of there other duties and expert that it'll just happen. The lesson here is that all internal projects (upgrades, automation and performance testing) should be run as projects with milestones, reporting, have established baselines and be constantly measured, with individuals held to account for the time & $$ invested. 

Teleworking is a subject that is close to my heart, as I Telework for one of my jobs :o) It works really well for me (and my employer I hope!). I enjoy the flexibility to do what needs to be done in and around the other things in my life (Family & my other job). The part of the article that made me smile, and then ponder was the part were the author said the 'non-productive time' of the Teleworker can be put towards doing the household chores like cleaning, doing the dishes or preparing dinner - the tasks that usually get done during personal time. This made me go hmmmmm..... Initially I was like, well, that's not cool and as an employer and supervisor I'm not sure I agree. But on reflection, and when considering the alternative proposed in the article (surfing the net or chatting) I'm now thinking that if that is the case, well it'll save us some $$ on bandwidth and download fees and potentially stop the disruption to the other employees and causing them to be unproductive so maybe on balance it's not such a outlandish statement. Though, Boss, if your reading this, this is my only 'unproductive time' ;-p     

A post about something.

It's been a while since I've blogged and it's not because I've not been inspired by many of the things I've heard and read. It's because there never seems to be enough hours in the day! Maybe tonight might be the night...

- Posted using BlogPress from my iPhone