The curious connection between washing dishes, AppSec & growing enterprise sales for your SaaS

It’s a combination of habit, hygiene and ultimately, common sense. When you finish eating dinner at home, do you place those plates and cutlery back in the drawer or do you wash them?

To re-frame this for you, your plates are on a regular hygiene schedule where eating from them is the trigger for them to be cleaned.

Let me ask you: what triggers the security hygiene schedule to be undertaken for the SaaS application that your team builds?

Do you have a “dish washing” process to find and eliminate the security vulnerabilities in your SaaS app?

Think about this: if your plates and spoons were to become unusable, they can be easily replaced with a trip to your closest shopping mall. However, if your cloud software is infested with security holes, then you’ll agree that it would take many more $$$’s and even more upheaval for you to contain the damage.

But my SaaS app hasn’t been hacked yet

“Yet” is the critical word here. In fact, statistics from the 2019 Vulnerability Statistics Report shows that a vulnerability in web applications is exposed for an average of 69 days before it is discovered.

That means hackers have a 2-month head start on your development team. What they could’ve installed, downloaded, ripped off or stolen from your servers in the last 2 months is mind-boggling:

• Stolen your entire codebase (ie. your valuable IP)
• Downloaded your customers’ sensitive data that they entrusted with you
• Installed crypto mining software maxing out your server resources (have you had to add more capacity recently?)
• Stolen your customers’ payment details if billing is integrated into your SaaS application
• Accessed your secret keys and encryption keys to get back into your system at their leisure

You get the picture – the list really is endless.

But the thing is, the stat below is even more alarming. It says that it takes on average a further month for software development teams to fix the security vulnerabilities from the time that they are reported. That means your favourite criminal hacker's head start is now at least 3 months long!

But your SaaS app hasn’t been hacked yet, so you might forgive yourself for thinking...

…my SaaS app won't be hacked, so tell me something that will help me

You can take that risk if you want. After all we live in a (mostly) free world. But what if I gave you an upside to investing in your application security (AppSec) for your cloud software?

You see, IBM Security did a study of the purchasing habits of enterprise buyers. They found that the most important factor during a purchasing journey was the quality of the software. That is, the software should have no bugs.

The second most important aspect was security. That is, the cloud software should have no security vulnerabilities.

Now, as Tony Robbins reminds us, it’s not knowledge that is powerful, but the targeted application of that knowledge.

So, how can I apply this incredible insight to my benefit?

My company, Audacix, is a SaaS company. Many of the world’s biggest companies use our SaaS test automation software. So, like you, we were also keen to figure out how to exploit this information.

We knew that most of our competitors usually focus on pitching their product’s features and benefits throughout the sales process.

Differentiating our solution based on features and benefits was getting harder. After a while, in buyers’ minds, all the features start melding into one massive blob of sales speak.

To get ahead of the pack, we decided to focus on the data and show our prospects a part of us that our competitors were either trying to hide or neglecting altogether.

So, we turned our app’s security into a differentiator. From the start of a sales process.

Now, what consistently gets us through to the final stages (and beyond) of enterprise sales conversations is a clear understanding of our prospect’s priorities. You see, our SaaS app’s features are meaningless to large enterprises if there is even the slightest chance that your app will leak their sensitive data.

We literally show our prospects the lengths we travel to protect their data and their brand, ie. we literally show them our “dish washing” schedule and its results.

When you start a sales process based on trust, rather than features and benefits, you’re more likely to actually close the sale.

Don’t get me wrong, we don’t win deals because of our security resilience alone. But because we have hardcopy evidence to back up our security claims, our ability to prove our security resilience builds trust fast. This has huge benefits for the other aspects of our pitch.

When you start a sales process based on trust, rather than features and benefits, you’re more likely to actually close the sale.

Ok, what AppSec work can my team get started on by themselves?

There are definitely things your development team should do before engaging a AppSec company to do an exhaustive web application and API penetration test on your cloud software.

Here’s a quick list of must-do AppSec tasks that will cost you no extra to implement:

1. Apply all patches and updates to any open source modules or libraries used in your SaaS app.
2. Check for and close any ports that shouldn’t be open after each release.
3. Ensure directory permissions are not set to 777 for all folders.
4. Ensure your app’s HTTP security headers are appropriately configured – they can use the free Cyber Chief service to give them clear, actionable instructions.
5. Repeat the above steps for all your environments – dev, test, pre-prod, staging, prod, etc.

Once your team have done all the above for a few consecutive releases, then you’ll know that they’re starting to implement the dish washing schedule in your app development process.

You should accept that doing application security properly is more like scrubbing heavily soiled pots, as opposed to putting your breakfast bowls in the dishwasher – it will take many cleaning iterations.

If a) your team is handling the above steps well and you’re ready to take your AppSec to the next level where it helps your sales process, or b) you want a done-for-you AppSec solution talk to our team about whether we may be able to help you.

Talk To Our AppSec Team

Test Your Web App's Security

By: Ayush Trivedi

The best SaaS apps have these 7 crucial defences against hackers

Application security is seldom considered during the ideation phase of web application development - unless the development team has previously been hacked and survived to tell the tale. But it's also true that it's never too late to secure your cloud-based web app.

In fact, smart and fast-growing cloud software companies who outperform their peers usually share this common trait: they consistently grow sales and build their brand by turning their security standards into a key differentiator and selling point.

There are at least three things that these smart companies do to prove to their B2B customers that their web application is secure and can be trusted. How many of these three things do you offer your prospective customers?

Why is cloud application security important?

Great question. There are the most obvious and often quoted reasons for investing in robust application security standards and processes:

• It helps to protect your business.
• It helps to protect your customers' business.
• It helps to minimise your costs when you do eventually get hacked.
• Prevention is always better than cure.
• As a professional, it's your moral (and legal, in many countries) obligation to ensure that the solution you provide to your customers is as secure as possible.

However, you will most likely view this finding from an IBM Security study to be the most compelling data point when deciding if now is a good time to look at your web application's security standards:

Doesn't it then make complete sense to give your potential customers just what they're looking for? Combine the above overarching statistic with these 10 cybersecurity questions that enterprise clients consider when evaluating cloud service providers, you'll quickly realise that you've found the illuminated runway that leads to your cloud sales goals.

So, should I just get a web application penetration test done?

Penetration testing for web applications is one piece of the puzzle that is your overall application security posture. Pen testing is a big part of that puzzle, but it's only useful when it's performed with the right structure.

What do I mean? Consider this: when a nation's armed forces are trying to rid a city of terrorists, they don't just go in with the army, do they? They first call for drone surveillance, then the air force for targeted strikes, then advanced reconnaissance units are sent it, followed by heavy infantry and more soldiers. All of this is then supported by engineers and civilian support to rebuild that city.

Simply conducting an annual penetration test on your cloud application and nothing else is like sending battalions into a war zone without any idea of where the enemy is hiding. By conducting penetration tests alone, you will be wasting your money and diminishing your ROI.

A penetration test should be:

1. Preceded by meaningful cybersecurity assessments during the design phase (share this checklist with your development team to help them understand the security mechanisms that they should build into new and existing features in your cloud application).
2. Backed by automated scans of your code base to check for compromised code.
3. Fortified by (at least black box) vulnerability assessments of our web app and its infrastructure before you go live.
4. Reinforced with regular drills to help your team understand what they need to do in the event of an attack.

Watch this training video to understand how you can put this type of application security structure in place and learn about the benefits it could bring for you.

I’m not telling you cybersecurity is easy. I’m telling you that it is doable. I’m telling you that the first step is the hardest. Your team is unlikely to take the first step until you lead the way by showing them what to do.

But my web app is hosted on AWS/Azure/Google Cloud and they look after my security

You’re not completely wrong, because to an extent these hosting platforms do provide a level of security. But it’s a very minimal security layer that they offer (unless you have the budget to pay for their really effective security offerings).

These hosting platforms typically offer protections against large-scale DDOS attacks and the like. Such protections are almost useless if your developers often open random ports into your environments. Or if they don’t close SQL injection vulnerabilities that allows an attacker to download your entire database without any valid login credentials. Or if they forget to apply security patches for the open source libraries that your cloud application uses.

The vulnerabilities leave you and your application wide open to a myriad of attack vectors. Only a deliberate and methodical AppSec structure like the one described above will help your developers find and fix these security vulnerabilities before it’s too late.

So, what is the first step in enhancing my SaaS application’s security?

Contrary to popular belief, application security does not have to be an expensive, time-consuming and anxiety-inducing exercise. In fact, properly configuring your web app’s first line of defence against attackers should be a reasonably quick exercise for most competent developers.

The first step to making it difficult for hackers to hack your web app or exploit it for other nefarious motives, is to configure 7 security-focused HTTP headers. These HTTP headers tell the browser how users can interact with your application and infrastructure.

More, importantly, these security headers instruct browsers about what users SHOULD not be able to do when loading and interacting with your application.

The good news is that there are really only seven security-focused HTTP headers that your developers need to configure. Here’s a quick rundown of what the seven HTTP security headers that your web application needs:

1. X-Frame-Options - helps you combat clickjacking attacks by controlling whether browsers can render your web app in frames.
2. Strict-Transport-Security - strengthens your app’s ability to enforce TLS encryption of data in transit by forcing the use of the secure HTTPS protocol.
3. X-Content-Type-Options - helps to counter MIME Confusion attacks and unauthorised hotlinking attacks.
4. Feature-Policy - allows you to selectively enable, disable, and modify the behaviour of APIs and features in the browser.
5. Set-Cookie - implementing the right directives makes it difficult for hackers to exploit cross-site scripting (XSS) vulnerabilities and hijack the authenticated user sessions.
6. Referrer-Policy - helps you control if and how much information your application submits to external websites that your users are clicking through to.
7. Content-Security-Policy - allows you to explicitly define the sources from which a browser can load components when rendering your application. It supersedes previously recommended headers like X-WebKit-CSP and X-Content-Security-Policy.

What's the easiest & quickest way I can check my HTTP security headers?

You want easy AND quick? You don't ask for much do you! ;-P

The easiest and quickest way to check how many of these seven HTTP headers your web application uses adequately is by using the CyberChief.co free HTTP header analysis service. Simply enter your web app’s login page and in less than 2 seconds you will be will have a complete analysis of the HTTP headers that are already configured properly, and those that need more work.

The best part is that Cyber Chief’s recommendations spell out in detail where your developers can configure these HTTP headers in your application. It will also explain what directives and keywords should be used maximise the security that each HTTP header can offer.

At this stage, it would be remiss of me to not point out that this header optimisation process is pointless unless you are serving your web application over HTTPS and ensuring that all HTTP traffic is automatically redirected to the more secure HTTPS protocol.

There are usually zero compelling reasons to pay hundreds or even thousands of dollars fancy SSL certificates from brand-name SSL certificate vendors. A free SSL certificate from services like LetsEncrypt or Cloudflare will be more than adequate for most cloud applications.

Remember that this HTTP header configuration process is only the first step in your journey to securing your web application and its infrastructure. The speed at which you’re able to build the remaining structure will determine a) how far ahead of attackers you can get, and b) how quickly you can turn your new cybersecurity resilience into a selling point to grow sales convert faster.

Download our Cheat Sheet For Building Unhackable Apps to understand the minimum security controls your SaaS application must have. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.

It probably will also help you land your next (or first) big enterprise customer for your SaaS.

Get AppSec Cheat Sheet

Test My Web App's Security

Or call us on +61 3 7001 1430 or +44 20 3411 4974 if you're in the UK, or email solutions[at]audacix.com

By: Ayush Trivedi

10 security questions enterprise customers have about SaaS/cloud software (but won't ask you)

As enterprises increasingly become more open to introducing cloud software to their environments, you as a cloud provider must proactively anticipate their concerns and address them. Without doing both, you will lose high paying and reliable enterprise customers to competitors who use their cloud software security standards as a differentiating factor to grow sales.

By acting on this trend early you will be able to turn your SaaS security prowess from just a differentiator into a barrier to entry for lucrative enterprise sales in your industry. This is because enterprise buyers are still in the infancy of cloud software adoption and this gives you the first mover advantage of setting the bar high so that only the best among your competitors actually have a chance to compete with you.

Despite statistics like that above, the really interesting piece of anecdotal evidence is that many enterprise cloud buyers still are still not bringing up all their security questions during the sales process. But they are considering all of them after your sales meetings have ended.

The only solution to this is to get your cloud software security in a position where you lead the security discussion during sales calls, rather than let it hang as another one of those proverbial elephants in the room.

Why are enterprise buyers' concerned about cloud software security?

You might be forgiven for thinking that enterprise buyers' extra emphasis on the security of their cloud vendors is just part of their standard buying journey. While that is true to an extent, statistics like this are alarming enterprise decision makers into thinking long and hard before committing to cloud software solutions:

Think about just how many open source technologies your cloud solution uses and you will understand the magnitude of the problem above. Enterprise buyers' apprehension also stems from how their cloud vendors respond to security vulnerabilities when they are found:

How are your team's response times when security vulnerabilities are found? The upside to the introspection that you're doing now is that you will have an target list of security processes that your team needs to fix.

What security questions stop enterprise buyers from buying your cloud software?

Some of the cybersecurity vulnerabilities may seem trivial to you, but we find them in almost every web application penetration test that we conduct for our clients. It will be worth your while to pay attention to these vulnerabilities in your own cloud software (as reported in the Top Threats to Cloud Computing: Egregious Eleven report):

Q1. How is my data protected?

The report notes that "data is becoming the main target of cyber attacks," which is quite different to ransomware attacks that take over an application and allow hackers to demand a princely ransom. Buyers are increasingly questioning who has access to their data and where it is stored - a question that you may already be familiar with if you sell to enterprise or government customers.

Interestingly, the report notes that "encryption techniques can help protect data, but negatively impacts system performance while making applications less user-friendly." This is not a view that we've encountered ourselves for our cloud-based continuous software testing software. This statement is also curious because the secure encryption technologies that our AppSec experts ninjas recommend to our clients have negligible impact on your cloud software's performance.

Q2. How are you managing changes to your environment?

Hackers these days wait for small windows where your cloud environment may be ripe for hacking. These windows usually present themselves when your teams ship new versions to your production environments. This is why it's so important to have robust change management processes that include regular vulnerability assessments and penetration testing.

The traditional model of conducting an annual vulnerability assessment or penetration test and just using it as a "tick-box" exercise is outdated. You need to implement a continuous vulnerability assessment and penetration testing protocol that gives your cloud software regular protection. If you don't have this expertise within your team and your external penetration testing partner doesn't offer it, talk to us about our subscription-based Cloud Warrior continuous application security plans.

Q3. Do you have a security architecture strategy?

Most SaaS/cloud software companies that we talk to only think about security after a product or new version has been built. This report makes it clear that this is no longer acceptable practice in the minds of enterprise decision-makers.

You're right, it's not easy to re-architect your software. But, it is a lot easier to help your team think about security from the design stages of new feature builds, rather than trying to retrofit security controls once the new features have gone live.

If your team has never undertaken a security review, it's worth doing it now, instead of after you get hacked.

Q4. How does your app protect my data beyond a password?

If you didn't already know, password-only authentication systems have proven easy fodder for even novice hackers over the years:

The common behaviour with enterprise users is to assume that all their data is sensitive. Whether it is or not is not worth arguing. The point is you have to prove to them that you understand their concern by providing them with not only 2-factor authentication (2FA), but multi-factor authentication (MFA).

It really is a non-negotiable in this day and age. If your application has already been penetration tested then your external penetration testing partner should have already pointed this out to you.

Q5. How do you prevent account hijacking?

In short, how many layers of security do you have in place to slow, frustrate and hopefully stop hackers? In cybersecurity terms account hijacking is best prevented through defence-in-depth measures. Defence-in-depth was a strategy used by smart military leaders to slow their enemy and to give them time to launch a counter-attack.

Playing offence in cybersecurity is a dangerous, and potentially illegal, business. But you should use these mechanisms to slow down and eventually halt hackers when they breach your system:

• Firewalls to control and monitor incoming and outgoing network traffic
• Web application firewall (WAF) to minimise the chances of hackers exploiting unknown vulnerabilities in your application
• Security information and event management (SIEM) systems to identify anomalies across multiple systems
• Identity and access management (IAM) solutions for authentication and user management to make sure only the right individuals get access to the right applications and services and nothing else.

Q6. How do keep my data safe from your internal teams?

Great question and one that most SaaS teams would just assume happens automatically. "We only hire trustworthy people, so why would anyone from our team want to access your data?" Right?

Wrong!

These statistics are the source of enterprises' worries about your team. The only way to convince them that you have mitigated this insider threat is to show them your information security and security incident management policies and procedures.

Don't stop there though. You should prove that your staff are trained to follow them too.

Q7. How secure are your APIs?

It's not enough to simply answer this question with a glib, "our APIs are pen tested regularly." In our interconnected digital world, APIs are proliferating faster than the speed at which a seahorse pops out its offspring. This has many advantages, particularly for minimising complexity and convenience, but also creates a security headache.

How many of our APIs are tested for security vulnerabilities before they are shipped to important (and demanding) customers? How does your team ensure that every one of your APIs has been catalogued and tested for security vulnerabilities?

You should consider managing this risk by employing standard and open API frameworks like the Open Cloud Computing Interface (OCCI) and Cloud Infrastructure Management Interface (CIMI).

Q8. What are your decision-making criteria when selecting cloud partners?

Enterprises realise that your cloud software probably doesn't work in an independent and unconnected silo. You probably host it on AWS/Google Cloud/Azure - brands that are well known for prioritising your and their own security.

But what about the other cloud services that you integrate with to deliver your solution? If you use APIs to offload some of your app's workload, how do you know the API provider follows best-practice security protocols?

Enterprise buyers want to understand how you select and verify your cloud partners' security posture? The best way of demonstrating this is to list the external services you integrate with and to list the security controls that they have demonstrated to you before you integrated their service into your cloud application.

Q9. What controls do you have to ensure my team doesn't misuse the data collected by your cloud software?

This is the flip-side of question 6. When we first ask this question of our clients the most common answer is, "we have different user roles to solve this."

While that's not the wrong answer, it is an incomplete answer that makes you look like an amateur. Here's the right way of answering this question:

1. We design all user roles to follow least privilege principles;
2. We ensure that all activities, no matter how seemingly inconsequential, are logged.
3. These logs are available for download to users who need them for security, audit and operational purposes.
4. Our external penetration testing partner thoroughly investigates our user access controls to ensure that role traversal is not possible.

It should go without saying that you should ideally put the above four answers into practice before trotting them out!

Q10. Will you do our security analysis for us?

This is not a question that a customer will ask you and it DEFINITELY shouldn't be a question that you ask your customers and prospects - no matter how tempting the financial saving might be for you.

Why, you ask? Well, would you invite your family and friends to your wedding and ask them to pay for their meals and drinks?

I didn't think so!

Download our Cheat Sheet For Building Unhackable Apps to understand the minimum security controls that SaaS applications must have. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.

It probably will also help your SaaS land your next (or first) big enterprise customer.

Get AppSec Cheat Sheet

Test My Web App's Security

Or call us on +61 3 7001 1430 or +44 20 3411 4974 if you're in the UK, or email solutions[at]audacix.com

By: Donna Abao

3 simple security questions to ask before buying (or geting a free trial) of a SaaS subscription

In years gone (and even for some niches today) the "freemium" model was the favoured one of SaaS platforms that were trying to attract new startup or SME customers. Now even enterprises are willing to use "free trial" offers from new SaaS providers in an effort to secure a winning edge on the cheap.

While freemium offers are great for slashing the cost of evaluating a new marketing platform, have you considered the cybersecurity risks that these free trial offers pose to your IP, your data and your business?

Why should you care about cybersecurity risks in someone else's SaaS?

It's easy to get caught up in simply trying to achieve your marketing objectives without stopping to consider what might actually be at risk for your organisation.

Given that most of our systems are connected, either with direct integrations using APIs or through external services like Zapier, you can be sure that a security breach in one service could open up your crown jewels to the internet's underbelly.

As a marketer you can’t possibly be expected to understand how all your company’s CRM, ERP and digital systems are connected. But it is definitely your responsibility to ensure that any external services you use do not increase the risk of a security breach or corporate espionage.

While no business wants to be hacked, you might be surprised to learn that very few SaaS businesses take all the necessary steps to protect their users. Worryingly, Trustwave found as far back as 2016 that "fewer than one in four organisations consider themselves to be "very proactive" in the context of security testing."

In our world of interconnected everything applications, these stats from Norton should have you concerned:

• The global average cost of recovering from a cybersecurity breach is US$3.86 million, which is money that would otherwise have been invested in growth projects. 
• On average it takes 196 days to find a security breach, which is an alarming amount of time that hackers have to rummage around in your network, applications and databases.

So what should I do before accepting a free trial of a SaaS product?

It is not uncommon to be excited at discovering a new product that you think might save you an inordinate amount of time or help you finally achieve those seemingly unreachable targets that your boss sets for you.

But you should remember that time is your friend. And knowing the right questions to ask of the SaaS provider is your secret weapon:

Question 1: Does the SaaS vendor have publicly published security policies?

Publicly published security controls may not give you hard data about the efficacy of the security policies, but they represent a level of maturity. Such policies signal that that SaaS company is taking proactive steps to protect your data, their IP and ultimately the think that their relationship with you and their other customers is valuable enough to protect.

All popular cloud services that you probably use, think Dropbox, Slack, AWS, Gmail, etc, have such pages that spell out their security practices. Look them up.

What you want to understand by reading these security policies are some of the following pieces of information:

1. Is application security a part of the vendor's application design process or is it just an afterthought?
2. In which geographic location will the SaaS vendor store your data?
3. Which third parties does your vendor contract with to deliver their SaaS solution?
4. How often do they generally perform vulnerability assessments and penetration testing on their applications?
5. Which other entities, related or not, potentially have access to your data (often referred to as sub-processors)?
6. What are their backup and disaster recovery processes?

The first point in the list above is a very important one, because if security is not considered and designed into an application right form its inception, then whatever security processes are implemented later are probably too little too late:

Question 2: Does the SaaS vendor have any information security accreditations? 

Have you ever seen companies claiming to ISO9001 or ISO4008 or ISOxyz accredited? Well, there is an ISO accreditation that for information security: ISO27001 and you should look for it, or something similar like SOC2, when you're evaluating your next marketing SaaS vendor.

These accreditations are not an ironclad guarantees that the accredited vendor's SaaS product is ACTUALLY free of security vulnerabilities. But such accreditations do signal that they have the policies and processes in place and if their teams actually follow those processes then their applications should be pretty secure.

The processes enforced by ISO27001 in particular generally serve to reduce the time between when security vulnerabilities are found and when they are fixed. After all, wouldn't you want your SaaS vendors to fix security vulnerabilities ASAP? If so, you'd be forgiven shifting uncomfortably in your chair when you discover that:

Question 3: When did the vendor last conduct penetration testing on their application and infrastructure?

Interestingly an HP Enterprise study found that 72% of web applications have at least one security vulnerability that allow hackers to gain access to things only admins should be able to see. The only way to be sure that the application you want to use isn't riddled by such security holes is to look at the vendor's penetration testing report.

Most smart SaaS companies regularly use reputed web application penetration testing services to find and patch security vulnerabilities before they ship a new version of their app. And if you ask them for the latest version of such a report, they will be more than happy to provide it to you - as long as you're a serious buyer, of course.

Conducting penetration testing through specialist and qualified penetration testing service providers like Audacix is a critical step on the road to finding and patching web and mobile application security vulnerabilties. A penetration test is more comprehensive and robust than a simple vulnerability scan and helps to uncover and bring issues like this to the app developers' attention:

Is this a foolproof way to guarantee that the SaaS app I want to evaluate is secure?

Unfortunately...no. There is no "foolproof" or "ironclad" way to ensure that a SaaS vendor has mitigated all cybersecurity risks. But there are proven ways to ensure that your prospective SaaS vendor has minimised the likelihood of a serious security breach.

Ask these questions before you accept your next free trial and satisfy yourself that your company's sensitive information doesn't fall in the hands of the type of people who shouldn't have it.

Download our Cheat Sheet For Building Unhackable Apps to understand the minimum security controls that SaaS applications must have. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.

Get AppSec Cheat Sheet

Test Your Web App's Security

By: Ayush Trivedi

This is why Accenture couldn't build a responsive ecommerce web app for Hertz

This story is newsworthy and even amusing because of the big sum involved - $32 million. But imagine, if you were in Hertz's shoes and the amount was only $3.2 million, or even $320,000 - would it still hurt if this happened to you?

You bet it would! And that is why it is crucial to take apart this case study in modern web app development failure and learn the crucial two principles that were disobeyed on the path to this colossal cock-up. Laughing at someone else's misfortune can be cathartic, only because we know it could well have been you. Maybe it was you, in a previous life or project.

This is what happened, according to Hertz's lawsuit

• Accenture was hired by Hertz to build a responsive ecommerce web app that could be used across its global operations
• Accenture couldn't deliver a working ecommerce web app, leave alone a responsive one, even after two lengthy delays
• By the time Hertz aborted the project, it had already paid Accenture $32 million
• To top it off, Accenture wanted another $10 million to deliver the original requirements
• "Accenture’s developers wrote the code for the customer-facing ecommerce website in a way that created serious security vulnerabilities and performance problems," it says before noting that "the defects in the front end development code were so pervasive that all of Accenture’s work on that component had to be scrapped."
• To compound its woes Accenture told Hertz it would have to use RAPID to fulfil the original requirements.
• But it is claimed that Accenture had little experience with implementing RAPID and spent much of its time on firefighting this integration

So how is it that a global powerhouse that hires the best and the brightest could deliver an ecommerce web app in $32 million, when most smart and efficient web development companies could've done it in 1/100th of that cost?

But first, why is this case study important for you

Because the statistics paint a very bleak picture. This study from 2018 says that you will have more unsuccessful IT projects than you will have successful ones:

So is it worth your time if learning two principles that can drastically reduce the chances of your software projects ending up in the "failure" column?

You see, the two principles below aren't just specific to the Hertz and Accenture story, they are the bedrocks of all successful, or at least productive, agile software projects.

You will benefit even more if you your team has managed to take the leap into DevOps. These two principles must be part of your DevOps strategy and every decision should be assessed against these principles.

So here's what prevented Accenture from delivering a functional ecommerce web app even after raking in $32 million from Hertz and these are also the two principles you need to apply to supercharge the performance of your software projects:

A lack of empowerment

It all starts with the right leadership. Leadership that allows others to feel empowered to make the right decisions based on fact and evidence, not just hunches. What type of leader are you for your team?

Leaders instil in their people a hope for success and a belief in themselves. Positive leaders empower people to accomplish their goals.

Unknown

Be careful here because the myth about empowerment is that it's just about delegation. It is not.

Real empowerment gives your team a structure or framework to make the right decisions more often AND to find and resolve potential issues before they become a source of frustration, embarrassment or even a lawsuit.

Effective empowerment in this situation would have allowed Accenture's team to plan the project in a way that allowed them to ensure that the house they were building actually looked like what was drawn on the plans.

Effective empowerment will ensure that the right sets of tools and people found and resolved weaknesses so that end-users don't become frustrated and angry at not being heard, when seemingly everything was written in a plain English in a requirements document.

Effective empowerment also helps you "shift left" by giving your team the space and responsibility to undertake activities (like real software testing) early and often during the project. In an agile development setting like the one within your team, the old approach of people simply doing their job role and only their job role will lead to more of your projects ending up in the 19% category in the infographic above.

Last but not least, effective empowerment will help you take care of attitudes in which developers are the only people that matter and everyone else is just an extra. Team cohesion is a critical part of your agile software development practice and there is no cohesion if one group of people think of themselves as a higher class of species.

Empowering each member of your team will enable you to build transparent checks and balances to ensure that only bug-free and secure applications are deployed to production. Your checks and balances should come in the form of clearly articulated processes where decisions are made based on objective metrics, not just someone's gut feel.

Take a moment to think about how you empower your team at the moment? You do empower them, don't you?

An absence of discipline

You see, software development is really a creative exercise. It's the creation of something out of literally nothing or at best the manifestation of someone's dreams into a sellable product. Most creatives will tell you that discipline isn't their dominant personality trait, but the successful ones all say this:

Creativity is a combination of discipline and childlike spirit.

Unknown

Would you agree then, that your role as a leader of software development teams is to coach, cajole and, even, coerce your team to inject a dollop of discipline to their daily activities?

At this stage you might be asking, "but how?" It's actually easier than you think, as long as you put in place the right structures where discipline is in the very fabric of the activity, rather than a conscious choice to be made (or not made).

Let me put it to you another way: the reason buggy releases make their way into production is not because your team is full of unprofessional sods, it's because YOU haven't created the structure that cajoles (and compels) them to find and fix every bug before they commit a new version to production.

This lack of structure is leaving a lot of teams, probably even yours, overwhelmed and stressed, which can only lead to more lapses in discipline, more mistakes and more bugs in production:

Instead of thinking of discipline from a carrot and stick angle, think of it as a set of processes that help your teams focus on the areas that need their attention. Trust me when I say that this mindset shift will transform your culture from middling to high performance.

A great example of this is automated software testing, which is often evaluated only in terms of dollars and time saved. What you might not have realised is that a successful implementation of test automation actually helps to uplift your testing team from glorified data entry operators to expert software delivery managers and trusted liaisons between business and IT teams.

These transformations are not science fiction, but provable realities. What could it do for your business?

If you need help in solving these challenges, or in cutting software testing time and finding more bugs before your application's users find them, speak to us understand how we will be able to help you. Download our Secret Toolbox and then book in your test automation mastermind session to help set you on the right path to achieve your goals.

Get Our Secret Toolbox

Schedule My Demo

By: Ayush Trivedi

How to make your mobile app completely unappealing to hackers

The inconvenient truth about developing a mobile app today is that hackers will find and exploit vulnerabilities in your app to steal data, demand ransoms, ruin your reputation and even destroy your business.

The good news for you is that we know the most common vulnerabilities that hackers will target to compromise your mobile app. Because we know their methods of attack, your developers can code best-practice security mechanisms into your app to reduce the likelihood of a successful breach.

Top Attack Vectors Hackers Will Exploit To Hack Your Mobile App

In order of significance and interest to hackers, and therefore your mobile app development team:

• Insecure user authorisation and authentication 
• Weak server-side controls 
• Lack of binary protections 
• Insecure data storage on the device 
• Ineffective data transport protection 
• Unintended data leakage 
• Execution of malicious code on the mobile device 
• Exploitation of insecure parameters 
• Insecure session handling 

The second inconvenient truth about mobile app security is that each of these security vulnerabilities can be reintroduced into the mobile app in any given release, despite not being present in earlier releases.

So you will understand why it is not enough to just trust your app developers to be vigilant every time they type new lines of code. You need to implement proper processes to ensure that the following security mechanisms are validated before new releases of your mobile app go live.

Global best-practice also dictates that all major releases of your mobile app that have significant additions to changes should also be penetration tested by a specialist mobile app penetration testing company.

Mobile App Security Tip 1: Token-Based Authentication To Access APIs

Many mobile apps use ineffective and insecure authentication methods. This leads to data leaks that allow hackers to discover sensitive user, transaction or app-related data.

Using tokens is the currently accepted global best practice to securely allow your mobile app to access APIs or other external resources. A precise tokenisation system is a critical cog in securing your mobile app.

Token-based authentication makes sure that the entity requesting the API call is authenticated fully and properly before any data is served.

Mobile App Security Tip 2: Use iOS & Android Keychain For Sensitive Data Storage

Both Apple & Google have recognised that insecure storage of sensitive data is a serious issue that keeps persisting. To make it easier for app developers to code secure apps, "Keychains" were created to give app developers a secure location to house sensitive data.

OS-based keychains are recognised as the most secure method currently available for sensitive mobile app data storage. Keychains are far safer than p-list files or NSUserDefaults.

The added benefit to using iOS and Android Keychains is that users can use universal login protocols already saved on their devices. This seamless authentication mechanism promotes a better user experience, which I'm guessing, is a major goal for you and your app development team.

Mobile App Security Tip 3: https Is No Longer A Nice-To-Have

All your apps communications must be over secure, encrypted transport protocols, like HTTPS. Encrypted connections require the use of strong SSL certificates.

Similar to websites and web apps that have SSL encryption, mobile apps and their backends that always use encrypted data transport mechanisms make it extremely difficult for hackers to interfere, compromise or steal any data.

A word of caution: while SSL certificates come in many price ranges, they are not all created equal. Be sure to check the underlying encryption standards to ensure that the SSL certificate you choose will ACTUALLY protect you and your users.

Mobile App Security Tip 4: Use Fingerprint or FaceID Authentication...

...instead of usernames and passwords. Research shows that biometric authentication mechanisms may be up to 5 times more secure than username and password combinations. It makes sense then, that even banks allow us to use TouchID and Android's fingerprint authentication to login to our netbanking apps, right?

It costs you nothing extra to use this functionality that is already built into iOS and Android, but it will give your users an amazing amount of confidence in your mobile app and a more friction-less UX.

Mobile App Security Tip 5: Make Reverse Engineering Difficult For Hackers

Reverse engineering vulnerabilities are more relevant for Android apps than they are for iOS apps. Using reverse engineering on your mobile app, hackers can disable advertising, can even detach it from various verification services and may be able to reproduce special functionality that your developers could have spent many months building.

There are a few solutions to implement anti-reverse engineering attacks:

1. Shrink, obfuscate and pre-verify code using a tool like ProGuard. 
2. Move critical code to the server and serve it using APIs. 
3. Write critical code in C/C++ instead of Java, because Java is easier to decompile. 
4. Hide API keys. 
5. Use SHA-2-compliant hashing algorithm. 
6. Utilise database encryption. 
7. Don't store information on external storage.

Mobile App Security Tip 6: Encrypt Data Stored On The Device

You might have picked up a common theme throughout our 6 tips: appropriate encryption can make it completely futile for a hacker to give your mobile app anything more than a passing glance. By encrypting the data stored on users' mobile devices by your mobile app, you will make it very difficult for hackers to access that data with any ease.

This is because the process of decrypting encrypted data is tedious and difficult, if not impossible at times. Successful decryption requires the hacker to find the right password and / or a secret key.

Unfortunately, I find that cybersecurity is an afterthought for most app developers. The real key to building a secure mobile app is to focus on security from the design phase, backed by a proper penetration testing program performed by a specialist penetration testing company, prior to release.

Download our Cheat Sheet For Building Unhackable Software to understand the security controls your apps must have before they're shipped into production. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.

Get AppSec Cheat Sheet

Test Your Web App's Security

By: Donna Abao

10 sureshot practices to supercharge your DevOps effectiveness

Whether you're about to implement DevOps or for ways to optimise it within your team, you must remember that DevOps is all about discipline and is definitely no magic bullet to doing it right from the outset or to fixing your perceived issues in one fell swoop. But you're in luck, because successful DevOps practitioners leave clues and patterns that you can start implementing today to supercharge the value from your DevOps program.

You can start implementing these 10 DevOps best-practices with your team from today:

1. There is a pattern to DevOps success

Like most patterns, you will either fall in line or you will try and take shortcuts. Taking shortcuts diminishes you and your teams ability to truly understand, harness and exploit the DevOps' potential to supercharge your business results.

If you still want to take shortcuts, keep scrolling. Otherwise:

1. Build solid foundations: identify the processes, people and products that you will use to establish your DevOps practice. Then, agree on how they will communicate and share information and learnings to transform your culture to one that aligns to DevOps principles.
2. Rationalise your tech stack: reign in your teams' propensity to collect the latest and greatest tools and ask them to decide on those components of their technology stack that are absolutely critical to delivering measurable business outcomes. This is your chance to minimise your tech footprint by refactoring applications to work on common environments and reducing the number of moving parts.
3. Standardise & share learnings: as individual teams begin to understand how to minimise their tech footprints most effectively, you'll find that they will have built a knowledge base of what works and what doesn't. This is a great time to share these learnings across team and functional boundaries.
4. Evangelise more key stakeholders: simply by doing the above your teams should be able to commit more to production environments than ever before. This supercharged pace of advancement will some of your testing and security teams feel like they're losing control and drowning, because of which they will create roadblocks. Bring such people into the DevOps fold, share learnings and build trust. This is where you start eliminating every superfluous manual intervention in your delivery process.
5. Remove infrastructure bottlenecks: you do this by ensuring that your infrastructure configuration and management doesn't become a bottleneck to developer productivity. This is achieved by starting to promote a self-service culture, first by automating infrastructure delivery.
6. Full automation & self-service: you should now be seeing material benefits in terms of productivity and noticeable improvement in trust, both intra-team and inter-team. Your teams should have self-service system that allow them to continually grow productivity levels and automation that removes bottlenecks.

You can simply rinse and repeat this template across teams, across divisions and across any functional borders. Follow this pattern and you'll find that your likelihood of achieving the DevOps promised land is boosted because everyone now has a recipe for success.

A word of caution: be very deliberate when turning manual tasks into automated workflows and build feedback loops to ensure that anything of significance is caught before its absence starts to damage on multiple fronts. Not only is this sound business practice, but also a great way to increase knowledge sharing and collaboration between, otherwise highly protective, stakeholders.

2. Cross-team sharing is key to scaling DevOps effectiveness

Do you have sharing, caring team members?

We discovered that the foundational practices — the practices with the most significant impact across the entire DevOps evolutionary journey — are dependent on sharing, one of the key pillars of DevOps.

State Of DevOps Report 2018

Communication is the key to solving most business challenges. The same goes for IT challenges. So it will not surprise you to learn that sharing and communication is a "key pillar" of DevOps.

If your teams communicate well internally and externally, then adapting your communication to facilitate cross-team and cross-functional sharing while implementing DevOps will be an easier exercise. You can start with the usual channels for knowledge transfer - ops manuals, mastermind sessions, lunch presentations, etc. The trick is to continue what is working and change that which needs improvement.

If you know your teams' communication is your Achilles heel, then you could either decide that DevOps is not for you. Or you could your DevOps implementation as a catalyst for fixing this area of your business or department.

You must buy into the idea that DevOps is just another buzzword, unless you apply it to change the fundamental components of your team and those changes deliver measurable business benefits. Without your complete buy-in, your teams will unable to exploit the non-technical aspects of DevOps to deliver anything other than utter frustration and confusion.

3. Start closest to reality & work backwards

In this instance, "reality" means two things:

1. Look to start your DevOps journey on a project or with a team where your pain is most visible; and
2. Also, implement DevOps principles as close to your production environment as possible.

By doing this you are building DevOps muscles based on reality, not assumption-riddled scenarios that create too much room for doubts and will require modification when you want to use them on production environment. Experience tells us that this is the fastest way to spread the DevOps culture throughout your teams.

You will know that there is no magic spells to fix culture. But you can start by improving collaboration (and results) from the areas that need this improvement the most. These internal case studies will be key to convincing the remainder of your teams to grow and flex their own DevOps muscles.

4. Change your mindset about security

You have to believe it before you see it.

Unknown

Changing your mindset is not an easy task, yet it is the key to success. Think about this: you're on this DevOps journey because at some point in the recent past you decided and / or agreed that DevOps could really transform the way your team and your business operates. And here you are.

You now need this same empowering belief to change your mindset about the importance and place of security within your DevOps practice. You need to believe that its is not only important, but also commercially beneficial to transform the cybersecurity of your applications from an afterthought to a competitive advantage.

Achieving this is not easy, because it first requires you to facilitate constant and consistent communication between your ops and security teams. You need to progress mindsets where security is about resolving immediate pain to one where it is a key strategic focus.

Move away from the school of thought that pigeon-holes application security as a tick-box audit exercise and towards one where cybersecurity actively contributes to maximising your bottom line.

5. Automate functional testing

DevOps without automated software testing is like racing a Ferrari with the handbrake engaged. After interacting with many new DevOps teams, my sense is that many of them are hamstrung by the imagination and risk appetites of their senior leaders, in a classic case of you don't know what you don't know.

If you don't like my Ferrari analogy, here's a more seasoned that will hopefully help you understand why your mindset around test automation needs to change if you really want to supercharge your DevOps environment:

A ship in the harbour is safe, but that is not what ships are built for.

John A. Shedd

You've gone down the DevOps fork in the road because you wanted speed and effectiveness. You wanted a competitive edge. Right?

By sticking to your old software quality habits you are only minimising your ability to achieve all these lofty goals. In short, you're attracting DevOps failure.

The good news for you is that there are lots of automated software testing tools and testing methodologies that work hand in glove with DevOps teams' needs and desires. It's up to you to select the right testing tool for your organisation and eschew the rabbit-in-headlights approach of simply gravitating to the big brands that are top-of-mind.

Get our Ultimate Guide To Test Automation for a comparison of the most popular, modern software testing tools and test automation engines.

6. Talk to the people at the coalface

Senior leadership in large and small organisations often fails to comprehend the nature and scale of the challenges and frustrations faced by those at the coalface. Like many other methodologies, think Agile, Kanban, Scrum, etc, decision-makers are often believe and promote a prettier picture that is reality.

This disconnect between IT decision makers and their minions is a chilling illustration of the disconnect between senior leadership and their people at the coalface:

While this is human nature and hard to change, mistaking fallacies for the truth will lead to systemic issues that will blow up in your face at the most inopportune times. It also leads to undeniable stress and misery for your team, which I'm guessing you REALLY want to avoid:

The question before you is quite simple: do you just want a good story to promote or do you want DevOps to drive real growth and profits in your business. The best way to do the latter is to talk to the people implementing your grand plans to identify and resolve the real issues behind the bottlenecks and inconsistencies that lead to frustrations, resentment and inefficiencies.

7. Make it continuous...

...both in terms of deployments, testing and security. You MUST have highly (although not "fully") automated pipelines where real people are not required to sit in front a screen to make something happen.

Without this level of automation you will not achieve the benefits that you visualised when you set out on your DevOps journey. Without this level of automation you are introducing room for failure that will be filled, not because your people are inept, but because as humans we revert to the comfortable and the unknown - even if it produces sub-standard results.

Be wary of recognising perceptions as reality, because what you perceive as a decision-maker is likely to be very different to what is reality:

For this to become reality your teams need to adopt continuous delivery pipelines that run your delivery processes where APIs act as puppet strings. This means that your infrastructure needs to be configured for automated deployments; that your software testing tools must be able to be controlled by APIs; and that your security testing tools must have two-way operation and communication through APIs.

This functionality set in software delivery tools is not a pipe-dream. It's available now. Your job is to find the combination of processes, products and people which allows you to achieve your results.

You've probably already worked out that the first step to achieving this requires the standardisation of your technology stack. This means that you have to force a culture where tools are used because they deliver a real and measurable benefit, not just because they are the lastest fad that someone found on ProductHunt.

8. Make alerting and monitoring automated & configurable

I know what you're thinking: "here's that A word again!" If you haven't got the picture yet, sit down and make a list of all the manual reporting and monitoring tasks that your teams are still performing. Then work out the low-hanging fruit in terms of what can be automated now and what must be automated later.

But the "configurable" part of this best-practice is just as important. Without the flexibility to customise monitoring and alerting activities your teams will engage in 2 flights of fancy that will definitely having you pulling your hair out:

1. Create new monitoring and alerting capabilities that overlap and require lots of maintenance; and
2. Revert to manual, which will break the system entirely!

Doing this will help you transition your team from building and relying on someone else to monitor and manage what they've built (in case you haven't already heard, a central team to run DevOps "ops" is bad form!). Amazon's tech innovation czar (and CTO) put it best as early as 2006, when he said:

“You build it, you run it.

Werner Vogels, Amazon CTO

As your DevOps practice grows you will find manual alerting and monitoring tasks are often the bottlenecks that create the most frustrations and inefficiencies. Alerting and monitoring activities follow a linear growth trajectory alongside your building efforts and at some point they will become a burden on your team's time and your money.

If you like making data-driven decisions, then this fact should make this best-practice a no-brainer for you to implement:

9. Make data-driven decisions

You'll agree that this is one of the most abused buzz-phrases in the tech industry today. But, if this is not second nature to you then you need to take immediate steps to inculcate this into your personal and your team's decision-making process.

Unlike most other concepts you will read about this year, this is not a fad. Your organisation's performance could be explained by whether you make decisions based on data or pure instincts whims and fancies:

Transitioning to a data-driven decision making culture obviously requires accurate, consistent and timely data. Therefore, it becomes imperative that you and your team has access to relevant dashboards for every element of your DevOps practice. This should be a major consideration when you rationalise your technology stack.

Learn from the experts about how to transitioning to an evidence-based decision making culture.

10. Think, do, analyse, repeat

The way to get started is to quit talking and begin doing.

Walt Disney

Follow Mr Disney's advice and avoid the trap of safe and comfortable waterfall thinking. DevOps empowers you to embrace the fail fast motto. Why is this important? Because failure is the step before success.

This mindset is important if you are going to successfully implement the pattern of success I gave you above. The biggest mistake that I see even experienced professionals making during their transition to DevOps is the propensity to over-engineer their every decision and process.

Don’t worry about failure; you only have to be right once.

Drew Houston

Instead run smaller proof-of-value experiments and ingrain this culture of succeeding by failing fast into your team. This is the secret that helps successful leaders scale their outcomes.

Talk to one of our consultants if you need help supercharging your DevOps practice or book a Mastermind session to get your automated software testing and cybersecurity testing purring.

Test Your Web App's Security

Talk To DevOps Consultant

Or call us on +61 3 7001 1430 or +44 20 3411 4974 if you're in the UK, or email solutions[at]audacix.com

By: Ayush Trivedi

How to slash software testing costs with these 6 proven ideas

In chatting with CEOs of SaaS companies, one topic keeps coming up over and over again: how do we cut our software testing costs? Or, if we can't reduce them, how do we tame the growth in our software testing spend? What's just as surprising is that IT leaders in large enterprises ask the same question!

While everyone is looking for a silver bullet, let me be the voice of reason for you: software testing costs will only keep rising unless you do the 6 things mentioned below. But more importantly, be brave and implement the 10 strategies from our Secret Toolbox for a more lasting and effective outcome.

After all, this statistic from a survey conducted by IBM security, clearly illustrates that the last thing you want to achieve by cutting software testing cost is lowering the quality of your applications:

1. Shift left - don't leave testing until the end

Don't lie to yourself, because you know this is true: software testing is always the last task performed when shipping a new application. This is the case with waterfall as well as agile. It's not a problem of methodology, it's human nature - because we are wired to, encouraged to and applauded for releasing applications that make for great PR announcements.

Unfortunately, software testing ALWAYS seems to fall victim to the need to meet release deadlines and customer demands.

I say "unfortunately", not only because this manner of software delivery leads to frustrated users and high churn, but also because costs balloon and you end up scratching your head, having to read articles like this one.

Think of it this way: software testing is to a great user experience, what software design is to software development. Get this order wrong and you end up in a whole world of hurt, not just financially, but also in terms of the hit that you take to your reputation for not being able to deliver bug-free applications, on time.

By "shifting left" and ensuring that software testing is conducted from the outset of and throughout the development process you create the necessary space that empowers your team to find and squash bugs before they ship a release.

It's not rocket science, but it is just as powerful (in terms of delivering bug-free software).

2. Start test automation early...

...not after you've finished developing your application as is the (unfortunate) prevailing opinion. There are two primary reasons you automation should soon after your application's first stable releases are ready:

1. You will be able to gain greater test coverage during every sprint from an earlier stage, because your manual testers' workload will be much reduced, or at the very least, better managed. Naturally, greater test coverage equates to a better user experience, less user frustration, less churn and therefore a healthier bottom line.
2. Your automated testing suite keeps pace with your development so that you don't have to over-invest later to bring your automated regression suite to a level where automated tests represent 90%+ of complete test coverage.

If you well understand the mental aspects of high performing software teams, you will already have realised that what you need is a mindset shift. Shift yourself from a place where test automation is a nice-to-have, to a reality where a lack of test automation is like trying to make progress with your handbrake on.

3. Collect good people, not just lots of them

Most software teams I know are short of people, especially testing people. This leads to a situation where non-IT team members are drafted in help test every release. Or worse still, you have to resort to using your customers as an outsourced testing team.

If this seems like normal service for you, consider this: the former sucks the productivity out of your broader business and the latter results in frustrated customers who feel abused. These customers are usually the first to churn, leaving you trying to top up a forever leaky revenue bucket.

So what's the answer? You might be surprised to learn that it's not "more testers." The often forgotten advantage of test automation is that it allows you the time and money to reduce the size of your software quality team AND fill it with passionate team members of the highest calibre.

Just in case you haven't caught on: high calibre software quality types don't take roles that offer them "lots of manual testing." The guns that you should be hiring want a role in an organisation that wants to progress by helping its people reach new heights.

So let your automated tests handle the repetitive and the mundane, and empower your software testers to take your user experience to the next level.

Are you only conducting manual software testing at the moment? Do you use non-IT people from the business to help with software testing? Do you want to change to a more cost-effective structure?

Book Mastermind Session

4. Prioritise your tests based on risk

I'm often asked, "can we do smoke tests with your Qsome cloud testing tools?" I've come to learn that what this really means is: can we run just a few tests that we think might be important, because in the past we've never had enough time to test everything?!

If you share this mindset then you've not grasped the power of test automation. The number 1 advantage of test automation is that it allows you to test early and often during a sprint. When implemented effectively, you will not be able to use your previous manual testing data as benchmarks, because the numbers produced by your automated testing program will seem unreal.

For large and complex applications, however, where even automated regression tests can still take some days to complete, risk-prioritised tests are the new smoke tests. Good software testing tools are able to priorities your tests based on technical and business risk factors and give your team an option to run an objective subset of tests under certain circumstances.

This frees your team and managers from making difficult decisions that have potentially disastrous consequences, in the blind.

5. Select a test automation tool that is fit for you

A mindset change of the order that I'm recommending here will allow you to dispel the following two myths from your psyche, that:

1. All test automation tools are the same; and
2. Your software testing needs are so special that you need a custom built test automation tool or framework!

First, there are test automation tools that were built many moons ago, but you shouldn't be wasting your time with them. Importantly for you, there are cloud-based test automation tools that will enable you to conduct continuous testing on your web and mobile apps. Get our Ultimate Guide To Test Automation for a comparison of the most popular, modern software testing tools and test automation engines.

There may also be certain elements in your ear espousing the benefits of a "custom-built test automation framework." Why, you ask? Because our software is so special that there's not been a testing tool invented that we can use for automated tests, they answer.

Call BS on such flights of fancy before they irrevocably drain your budget, your energy and your professional credibility. Unless you're testing autonomous vehicles or software to land odd-shaped crafts on Mars, you can choose from a veritable smorgasbord of automated software testing tools that will cover at least 80%+ of your test automation needs.

By buying off the shelf, you save yourself the enormous cost and headaches of having to manage a team to develop, test and maintain a software testing tool. Why would you bother?

6. Outsource to a specialist test automation services company

When you find there is a lack of progress within your software quality program stretching over a year or more or your in-house strategies and decisions are not delivering the desired outcomes, look outwards for the answer.

When outsourcing your test automation be careful to select a turnkey solution where the automation can begin from the day dot. Never accept a solution where your test automation partner will first build you a custom framework (refer to paragraphs above) and then begin automating your tests, unless you want to implement a sure-shot recipe for missed deadlines, ineffective tests and test automation that has zero ROI.

Check out the 6 success factors you must consider when selecting an outsourced test automation company.

If you need help in solving these challenges, or in cutting software testing time and finding more bugs before your application's users find them, speak to us understand how we will be able to help you. Download our Secret Toolbox and then book in your test automation mastermind session to help set you on the right path to achieve your goals.

Get Our Secret Toolbox

Book Mastermind Session

Or call us on +61 3 7001 1430 or +44 20 3411 4974 if you're in the UK, or email solutions[at]audacix.com

By: Ayush Trivedi