Some good headlines about emerging industry trends came out of the recent World Quality Report produced by HP, Sogeti and Capgemini, but as I read deeper, some things started niggling at me, so much so that I decided they were worthy of a blog post.
‘Only 4% of IT professionals agree that their ALM investments are fully paying off, and only slightly more than a third said that half or more of their solutions have been fully implemented and are helping to improve application quality.’ (Pg.8)
HP and Sogeti state that ‘QA organizations need to focus on increasing the adoption rates of their purchased technologies’. This is of course great advice, but both companies have a vested interest in these users throwing more and more money at consultancy, training, and in HP’s case, overpriced and difficult to implement products, (that consequently need a lot of ‘services’ cash thrown at them).
In my opinion it would be more prudent to look in more detail at why these companies are not getting a return on their investments or managing to fully implement their products.
The answers seem to fall into three categories. Company issues, Resource issues and Technology issues, with technology resoundingly winning the prize for biggest stumbling block.
20% failed due to lack of an internal process or support from management. The question does beg to be asked – how on earth did they ever manage to purchase their ALM technologies without some form of internal support? To make ALM successful, it must touch more than just the QA team: support needs to be gained, processes mapped out and business goals and requirements defined way before you make decisions about what technology to buy. It’s really not surprising that these projects failed.
26% stated that not enough resources were invested into the adoption of the technologies. Now I could have classed this under company issues, but I think you really need to look deeper than just writing this off as a staffing issue. It could equally be a technology issue. Was it that not enough staff were trained? Was the project badly planned? Was the technology too complicated for users outside the dev/test team to adopt?
In terms of technology, a whopping 41% struggled because their ALM investment was the wrong choice of technology; it failed to integrate with other technologies or was too complicated and required specialist skills that were thin on the ground. I’ve lost count of the amount of times we hear stories like that when meeting companies across the globe. To truly embed a solution in your company, you need to empower all stakeholders. Unless everyone involved in the delivery of IT projects can collaborate using the solution, it’s just not going to work. When choosing a solution, you need to think about how easily management, business analysts, business users, developers, project managers and testers are able to get what they need out of the solution.
‘Companies prefer testers who have both strong technical skills and relevant domain and business knowledge’ (Pg.11)
Well the stats don’t really allude to that. The question that was asked was – When hiring testers which of the following skills are most important to you? Well obviously QA skills came out tops at 31%. Having a good grounding and understanding of the principles of Quality Assurance is key for testers, I’m actually more surprised that this figure wasn’t higher, but interestingly, the second largest desired skill is business knowledge (22%). This is something we come across time and time again with companies we talk to; so many of them utilise business users for the testing phase. Take SAP testing for example, business process is key. You really need to leverage the knowledge that the business users have about how the system is supposed to perform and exactly how they all use it. So many of the accounts we’ve been into have been literally banging their heads up against a brick wall trying to work out how to capture this knowledge or utilise these testers, knowing that it is impossible with their current toolset – HP is just too cumbersome to get non technical business users to adopt. Development skills 9% and scripting skills 10% are actually rated incredibly low when you consider that the market dominating tools actually force these prerequisites upon QA and make these skills imperative at sites where these traditional tools are embedded.
‘Nearly three quarters of respondents say that they do not follow [common test management methodologies]. Instead, their organisations develop and document their own best practices that are followed in the majority of development and testing projects. (Pg.10)
Different groups in the organisation may adopt their own ‘versions’ of the standard practices, and as a result, the company as a whole is not fully realizing the benefits of standardization, economies of scale, common metrics, unified reporting and asset reusability’
Not all companies are equal and each has different ways of doing business. One size DOES NOT fit all, so surely it is good for the industry that companies develop their own best practices? These companies are just using their brains and working out what best suits their own unique needs and circumstances.
Software vendors should be supporting this very obvious progression of development maturity. Why shouldn’t they be able to all work slightly differently, yet still enjoy the benefits of unified reporting, asset reusability, common metrics etc.? Perhaps the answer lies in the fact that HP hasn’t built its software to be this flexible? Maybe it’s time for the dominant market player in test automation and management to listen to what businesses need rather than telling them how they should be working!
This particular bone of contention was revealed earlier this year with a survey of Application Development Managers back in April 2010. The industry is really crying out for flexibility in the way that tools allow them to work, which is one of the reasons that Original Software developed Qualify, a process and methodology agnostic Application Quality Management solution. Qualify allows businesses to map their own processes, use standard methodology templates, tweak them to suit their own needs and even run multiple methodologies across different teams and projects, with – wait for it, all the added benefits of unified reporting, metrics, re-usability and economies of scale.
Go and check Qualify out.