Scrum Product Owners, learn how to secure your mobile & web platform with this guide. Covers security requirements, risk assessment, & implementation
To stay relevant, software testers must focus on what makes manual testing essential to the software being tested: humanisation.
By Mario Matthee, COO at DVT Global Testing Centre
Software testing has evolved, along with the advent of highly efficient and progressive software development methodologies like agile and its derivatives.
Gone are the days when a software developer would ‘test' his own code and send it into production, where it would be subjected to further testing. Iterative development has eclipsed this antiquated form of manual software testing with automated alternatives, and the role of the software tester itself is shifting, with business analysts increasingly taking on testing responsibilities for their own projects.
Despite the fractures, I'm not calling ‘time of death' on manual testing anytime soon. In fact, manual testers will play an increasingly important – albeit far more specialised – role, as software development fragments into specific niches, from enterprise-scale mainframe to consumer-grade mobility.
The advances in test automation have taken the spotlight off the bare-knuckles world of manual testing, but automating for the sake of it can be counterproductive and costly. While automation is ideally suited to the fast-paced world of agile development, and is increasingly critical for regression testing, it falls short in two scenarios: new builds and human experience.
It can be prohibitively expensive to design test automation scripts for new products that are still in development – and therefore constantly changing. Keeping automation scripts current could end up costing more than the software is worth, so the only way to get the application stable enough for automation is through manual testing.
Secondly – and particularly in the mobile space, where new applications are a dime a dozen these days – there's no substitute for human experience when it comes to usability testing. Sure, once an app has been out in the wild long enough, it can be stated fairly confidently that test automation will keep its future iterations fresh and bug-free, but by that time most of the usability issues will have been ironed out, and software testers are testing for stability and legacy compatibility rather than usability.
Hammer blow
But, for new apps, or apps that have been completely redesigned, there's no automation scripts I know of that can see the ‘bigger picture' or predict with any degree of certainty how real humans will react to it. For business-critical applications, leaving usability decisions to a script is like polishing glass with a hammer – it can be done for a while, but ultimately, it's going to crack.
Another aspect of manual testing that's difficult to automate is field testing. This is true for many mobile applications, but more so with the growing popularity of app-driven wearables like watches and fitness devices. Stability is one thing, but automation can't possibly account for the diversity of human demographics these devices are designed for.
This brings me to an interesting crossroads. Manual testing, at least in the traditional sense, is clearly in decline, while automation is in the ascendancy, and the blurred lines between developers, project owners and business analysts are becoming even more so.
Automation is very much a work in progress. It's ideal for simple applications, or in cases where new features are added to older applications that have already been tested to death. Manual testing, on the other hand, is the old curmudgeon in the room; it's been there, done that, and has all the experience, but is rapidly being replaced by the younger, fitter, better-looking model.
As such, there's only one clear path for manual testers to travel to avoid extinction: specialisation. By that, I don't mean taking up abstract roles limited to exotic devices or industries, but rather focusing on what makes manual testing essential to the software being tested: humanisation.
Handmade
The human touch is synonymous with quality, and quality assurance ultimately requires the human touch. Automated tests are just that; they don't necessarily react to a design feature or usability cue as a human would. A manual tester will be using the software as it would work on launch, and therefore provides a real-time view of any human issues an automation script might miss. Any flaws that are only likely to be triggered by organic human use will likely also be found by manual testers.
Manual testing is the old curmudgeon in the room.
Of course, this is nothing new; history has shown up hundreds of examples of traditional roles that have been overtaken by progress, only to resurface in unexpected ways and in places the people that replaced them least expected them to. The shoemaker was replaced by the factory, but people are not going to send their shoes to the factory when the stitching comes loose, and there's a reason why the world's most coveted shoes are still lovingly made by hand.
Manual testing is also far more flexible than it is given credit for. When a developer (or client) has one of those ‘lightbulb moments' that fundamentally changes the course of an application or project, ideally, the change should take place (and be tested) immediately. Doing so without completely retooling the automation scripts and processes for the previous iteration of the software is almost impossible without significant cost and time delays. Not so with manual testing; just test and see the results right there, without delay.
Despite the benefits, manual testers are still an endangered species. Modern training and courseware tends to steer testing into the developer's domain, and manual testing is often considered an afterthought or consequence of inadequate development skills. More resources are also funnelled into sophisticated test automation, with major advances in artificial intelligence set to drive the wedge between automation and manual testing even wider.
For manual testing to survive these changes, it needs to adapt quickly and show its value where it matters most: in the hands of everyday users.
The more people depend on their smart devices to think and act for them, the more they need real people to build software applications in their own image. Likewise, the more they rely on autopilot to manage every aspect of their lives, the more manual testers are needed to ensure they're heading in the right direction.
By Karl Fischer
The business and technology world is undoubtedly undergoing an incredible journey. There is an avalanche of technology capabilities and opportunities that can seem overwhelming at first, but that wave of innovation is also one that is enabling success.
The traditional lines between "business" and "IT" have at the very least been blurred if not eliminated in organisations adopting the digital revolution. For these companies, IT is a business life-blood and business a heartbeat that drives demand for technology and requirements.
So how does IT become the Business Hero of today?
Having a roadmap (a "GPS" for millennials) to guide one would help, so here are the six advisory steps we utilise at DVT to assist our clients to understand digital and agile transformation context and become heroes to their business.
Step 1: Know where your business wants and needs to go.
Understand the opportunities and how they line up with what your business is trying to achieve.
For the digital (or digital aspirant) business, there are a few typical positions that you can identify and align with to provide the technology focus needed to enable achieving those goals. Consider Gartner's "Journey to Digital Business":
Knowing the goals and objectives of your business, then consider the maturity of your IT function and consequent ability to contribute.
KEY ACTION:
Know your business's key objectives and then align with and measure your IT activities toward achieving those goals. Develop your framework by positioning where IT is today for your business, and where it needs to be to make your business successful.
Step 2: Road trips are better with friends (Collaboration is the new normal)
In most established organisations, the IT function has evolved over time and is probably not identified alongside innovation and agility. If IT in your business is seen as the Innovator, then you are well ahead of the curve. But most departments will need to show a new dimension and practice conscious change management to reposition IT as a key enabler of the business.
A good anecdotal gauge is if there is a distinction between "business projects" and "IT projects". When there isn't, IT has "made it" into being just another key business contributor. Getting there often means bringing in "friends" with specialist skills and experience that can fast-track you into the technologies and processes that are enabling digital initiatives (Think cloud, social, mobile and analytics). More importantly, the nature of the engagement with your new best friends can well be different to consulting engagements of the past with the "experts", providing an expensive opinion as to what needs to be done. Ever had that experience where you were left wondering, "That's interesting, but HOW do we do this?"
At DVT, we look to establish a partnership with our clients that will see them function not just deliver on project objectives but gain the insight, skills and capability that will enable them to take the initiatives forward in the future. When our clients are better off, we've delivered on our partnership commitment. Our extended eco-system of partners with specialist skills ensures we are well positioned to provide a full-fledged solution. Digital is complex and extensive in scope. Bringing the right parties to an initiative, with the right attitude toward a common intent leads to better results.
KEY ACTION:
Find partners with the experience that compliments your team and where collaboration and knowledge transfer are part of the engagement.
Step 3: Get to know the roads (Ask someone who has been there before then review the options)
Leverage expertise both internally and externally to understand your tactical choices. Consider short little "trips" (experiments with the technology or process) that will give you a better idea of learning curves, ease of use and relevance to the key outcomes your business is looking to achieve.
Knowing there is more than one way to achieve an outcome (and continuing to look for options even after you have a favourite) immediately reduces risk about the investment you will recommend. It's important that IT has considered the alternatives and is providing an informed, business savvy opinion.
KEY ACTION:
Initiate "meet-ups" to talk digital and new ideas and open the invitation to both internal and external parties.
Step 4: Listen to the GPS. Guides are useful, but take the shortcuts
Expectations have changed significantly as to what is possible, what IT should be providing, and the speed at which solutions should be delivered. Fortunately, IT and technology have been innovating at a similarly dramatic pace. There is a multitude of technologies, methodologies and collaborations that can help IT shift its performance and rise to the challenge.
The Agile business may adopt a credo of "fail fast, succeed faster" but that's likely to create significant discomfort in the boardroom unless it's explained (and shown to be managed responsibly). Akin to looking for the shortcuts on the map and having the GPS recalculate the path to journey's end, the introduction of new processes, expertise and technologies can radically shorten the transformation of IT into a current and relevant digital business partner. There's no singular path to the outcome, so consider your options and start with small-scale initiatives on which you can build momentum and where success is probable.
KEY ACTION:
Look for short-term, manageable changes that can start to move your function toward the end goal state (effectively making change through bite-sized, right-sized initiatives).
Step 5: Look at the road, not the representation (Plan and then plan for change)
Expect to make changes and adjust your plans. Having a plan is great. Being responsive and prepared for a change in the journey needs to be standard practice (Agile in essence and action). All too often the adoption of Agile is used as the excuse for:
- lack of planning - "Agile is about doing, not planning" – False
- lack of documentation - "Agile doesn't use requirements documentation or value specifications or analysis" – False
- lack of outcomes - "Agile means we change to work on each and every new request" – False
In the context of the transformation of IT functions, management teams need to consciously manage the change being introduced into the function. Changes in methodology can be difficult to achieve if attempted as purely an IT change. Agile is manifestly NOT just an IT change in how projects are run.
As an organisation focused on Agile, both as a service to our clients and as to how we operate, we know that successful implementation of Agile is a journey best led by those who have been down the path (multiple times). It's why we offer Agile Transformation programmes to our clients and follow them ourselves, believing in an evolution driven by a shared Agile philosophy.
KEY ACTION:
Adopt a conscious programme of change management that intends to see the transformation of the organisation to an Agile entity. Note that just because methodologies like SCRUM have typically taken root in IT departments does not mean that everyone in your IT department (and certainly not across your organisation) understands Agile and is supportive of the change. Consider utilising a formal Agile transformation programme that has been implemented through other organisations and customise it accordingly.
Step 6: You don't need a car if you can Uber
There are key technology enablers that must be part of your thinking for enabling agility, speed of delivery and value delivery: Social, Mobile, Analytics and Cloud. Be aware of the platforms and capabilities that these digital enablers have provided and how you can leverage them for lower cost, rapid development (prototype evolutions) that can help quickly prove a business concept with minimal investment in infrastructure. These mediums lend themselves to collaboration with partners and customers which in turn can help you drive innovation and align with market needs.
KEY ACTION:
Look into the use of "multi-speed" IT (adopting different processes, team structures, and technologies to enable different IT supported areas such as "innovation" (what is wanted) versus "operational support" (what is in place). Service partners can then spin up short-term teams with essential skills to enable such initiatives and introduce fresh thinking.
As Dorothy famously said, "We're not in Kansas anymore", the landscape in technology continues to change dramatically and with it brings new dynamics that demand collaboration, innovation and agility to be successful. With IT being at the centre of this tornado, it's both a challenging and incredibly opportune time for leaders in this space.
The six steps discussed in this blog are how we at DVT open the conversation with some of our clients (collaborators) to ensure that investment in IT will secure both short-term and on-going success for their business.
Visualise the journey, choose your "friends" for the trip, and start your engines! Your business teams are already asking "Are we there yet?”
Sources and Recommended Reading
Gartner – Post Event Trip Report – Digital Maturity Benchmark Summary, 2014
Accenture "Driving an ambitious agenda to transform Accenture into a digital enterprise"
HBR "7 questions to ask before your next digital transformation", Barry Libert, Megan Beck, Yoram (Jerry) Wind, July 2016
How can you empower your customers with an omnichannel approach? Find out here, where we discuss how to improve customer experience.
Is there a middle ground when it comes to the developer-tester scenario?
When Internet software giant Google released a seminal book on how it tests its own software – aptly titled: "How Google Tests Software" – it set the cat among the proverbial pigeons of software developers and testers alike.
Until then, the two disciplines coexisted rather peacefully side-by-side, each knowing its place in the software development universe, and each quite comfortable with its own rules and responsibilities.
But, then (Google book co-author) James Whittaker blogged about his book thus: "Testing and development go hand in hand. Code a little and test what you built. Then code some more and test some more. Better yet, plan the tests while you code or even before. Test isn't a separate practice; it's part and parcel of the development process itself."
Picture thousands of developers and testers around the world exclaiming a collective: "Say what!?"
Testing 1, 2, 3
The truth is this testing conundrum has been brewing for a while, especially in SA, where both development and testing skills are in extremely short supply to begin with. So, asking developers to suddenly take on a tester's mind-set (and skillset), and vice versa, seems a stretch too far.
Much of this developer-tester thinking stems from a concerted effort by many large companies – not only software development companies and not only Google – to automate as much of the testing process as possible. To achieve this means testing while developing (as opposed to developing then testing then developing some more), so it follows that developers themselves would be doing most of the testing.
The net result of all this not-so-insignificant strategy shift was a bunch of big companies questioning the value they get from manual testing, which is all good and well, until they realise how difficult it is to actually find people with the skills they need to do both.
Again, this is particularly evident in SA (and other developing economies) where the skills base is already low. Local testers tend to be graduates and professionals who either didn't make the grade as developers, or didn't fancy development in the first place. At the same time, SA's developers tend to regard testing as something someone else does once they're done writing their code.
Scrambled or fried?
The mistake I see many companies make in trying to unscramble this developer-tester omelette is shifting test automation responsibilities onto manual testers. In other words, they're saying if developers that can test are impossible to find, they will get manual testers to add more value by automating.
This doesn't work. For all the romance of the perfect developer-tester ideal, manual testing remains a highly skilled and focused discipline, which will continue to play an important role in the software development life cycle, even if there is suddenly a glut of developer-tester skills flooding the market.
"Manual testing remains a highly skilled and focused discipline."
The same goes for test automation. An important factor often lost in the whole developer-tester debate is the value of regression testing. Because so many local companies outsource their development to offshore development centres in places like India and China, they're often left to deal with new code on a regular basis, which may or may not negatively impact their existing code.
This is where the real value of regression testing comes in, to ensure new code doesn't break old code. That said, companies can't expect their manual testers to work back through the legacy code to fix the features broken by the newly minted code.
Even if they could, with new code being updated almost daily in some cases – especially in the mobile application space – and companies increasingly favouring the agile model of frequent incremental updates, manual regression testing becomes as costly as it is impractical in most cases.
The answer lies somewhere in the middle. As always, it is beneficial to look for the best possible balance between what's possible today, what works, and what can be achieved in the shortest amount of time with the highest quality.
For example, it makes more sense for companies that outsource their development to also outsource their testing – but not all their testing, because that would be prohibitively expensive.
In environments like banking and insurance, where any breaks in existing software can lead to substantial downtime and lost revenue, the more fluent the testing, the lower the risk and cost. So, rather outsource the part of the company's testing that also carries the highest risk – regression testing – and stick with the tried, tested and trusted manual testing processes already in place.
That way, companies are not compromising on quality while reducing risk and managing costs. In the meantime, they can work towards a more modern and robust testing culture through the development and advancement of their existing skills and new hires, which benefits everyone in the long run.
Discover the crucial role Business Analysts play in bridging IT and business. Gain insights for success. Take action now for a competitive edge!