Give your testers a break! Discover how our test automation solution can help your business.
We believe automation should deliver not only better applications, but also be cost-effective and get your new products and features to market quicker. Why not pick our brains about how we do this for our customers?
The entire premise of continuous delivery is speed and accuracy in execution. Both of these elements cannot be achieved using traditional testing tools and techniques.
The Qsome Technology Platform is built to improve quality at speed. The combination of technology and bespoke services allows you to achieve your continuous delivery goals.
Performance optimisation is a dynamic exercise that requires multiple iterations. Its importance is magnified in a digital context where users expect, rather than desire, responsiveness.
The Qsome Technology Platform allows users to execute load tests using functional test scripts. No extra investment is needed.
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.
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.
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.
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:
Shrink, obfuscate and pre-verify code using a tool like ProGuard.
Move critical code to the server and serve it using APIs.
Write critical code in C/C++ instead of Java, because Java is easier to decompile.
Hide API keys.
Use SHA-2-compliant hashing algorithm.
Utilise database encryption.
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 guide to the 121 Critical Cybersecurity Tests you must conduct before shipping your web and mobile applications. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.
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:
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.
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.
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.
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.
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.
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.
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:
Look to start your DevOps journey on a project or with a team where your pain is most visible; and
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.
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.
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.
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:
Create new monitoring and alerting capabilities that overlap and require lots of maintenance; and
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.
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.
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.
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.
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:
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.
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?
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:
All test automation tools are the same; and
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.
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.
The quora hack proves that no company with web or mobile applications is safe from being hacked. Don't these words, uttered some years ago, sound so ironic and prophetic in this day and age:
There are only 2 types of companies: those that have been hacked and those that will be hacked.
Don't just disregard that line of thought because you think it is too dramatic or unlikely. The most recent stats about today's cybersecurity environment paints a bleak picture, especially for small and medium companies that don't have the financial firepower to spend millions on cybersecurity protection:
61% of breach victims in 2017 were businesses with under 1,000 employees
It takes on average 50 days to recover from a cybersecurity attack
Large companies spend an average of $3.7 million annually to defend against cyber attacks
But, it's not only hackers that are interested in your cybersecurity resilience (or lack thereof). A study by IBM Security found that cybersecurity resilience is now the second most important factor that tech buyers consider during their buying journey.
So answer this now: can you really afford to keep putting off taking action on your application's cybersecurity resilience?
If you agree that you need to take action to improve your cybersecurity resilience today, here are 4 actionable ideas you can start implementing right away:
1. Conduct vulnerability scans before every release
Black-box vulnerability scans are a bare-necessity before you ship every release of your web and mobile applications. This is because vulnerability scans will give you a great ROI when you compare the outcomes and certainty you will get versus the time and expense to execute them.
Vulnerability scans won't identify all security flaws in your application and cloud infrastructure, but they will likely identify the most glaring ones, especially if your scans test for the vulnerabilities listed in the OWASP Top 10.
2. Conduct a full penetration test if it's been more than 6 months
A full penetration test is designed to follow a rigorous testing regime to examine every nook and cranny of your applications and network infrastructure to detect security vulnerabilities.
If a vulnerability scan is like topping up the engine oil of your car, a penetration test is like a full engine rebuild. Our 121 Critical Cybersecurity Testing Guide lists many of the tests that our security testers execute during a penetration test.
While the tests in our guide will appear exhaustive to you, a really effective penetration test requires a security tester to follow more than just a pre-defined testing framework. That's why it is vitally important that your penetration testing plan is customised to the needs of your application and cloud infrastructure.
Without this customised testing plan many security vulnerabilities within your application and infrastructure may be left undiscovered.
Assuming that you are conducting regular vulnerability scans, we recommend that you conduct a full penetration test every 6 months or when 20% or more of your code base has been modified - whichever comes sooner.
By no means is this is a fool-proof plan that will guarantee that you never get breached. However, this system of cybersecurity testing represents the best balance between time, cost, effectiveness and ROI.
3. Inject security compliance checks into your software design & development process
We find this to be the most overlooked part of our customers' software development process. Most dev teams will take care of the finest technical details, but will never consider the cybersecurity impact of their decisions and actions. If this sounds familiar, I implore you to act now.
Download our 121 Critical Cybersecurity Testing Guide and share it with your team. There are a number of questions within this guide that should be asked by your application architects and development team starting from the design phase and continuing during development.
Best practice in this area is to include cybersecurity validations within the official design and development approval process. By asking the right 10 questions before a line of code is written, you will be able to minimise the number of security vulnerabilities shipped with each release.
Prevention is always better than cure. Even in cybersecurity. Who would've thought, huh?
4. Remember: culture eats strategy for breakfast
Answer this for me: why do new airlines have more crashes per thousand flights than airlines that have been around for 50 years? It's because older airlines have a CULTURE of safety. A know-how and manner of operating that kneels at the alter the ultimate truth in the airline business: dead passengers don't buy air tickets.
Unfortunately for you and your team, you don't have 50 years to build a culture of security around your networks and your applications. You must play catch up and you must do it every day.
Building a culture of any type requires top-down action. And cultures are built on making sure everyone is doing the 1-percenters right all day, every day. If you need to be "pedantic" (or even draconian) for a while to ensure that your team understands why you're building an enhanced culture of security, then so be it.
Your reputation, your products and your entire team will be thankful that you instilled this new culture of security when they realise that you remain one of the few among your competitors that has never had to send that dreaded email to customers to tell them that they've been hacked.
Culture may take a long time to build and be the most difficult action item on this list, but it is that one intangible that comes closest to being that magic bullet that will keep your cybersecurity resilience at a higher level for longer.
If you need a fixed-fee penetration testing quote and a customised pen testing plan that delivers you tremendous value, speak to us understand why working with Audacix for your pen testing needs will be a decision that delivers an amazing ROI for you, your brand and your users.
At the very least, download our guide to the 121 Critical Cybersecurity Tests you must conduct before shipping your web and mobile applications. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.
There are an unending list of reasons that compel SaaS companies and digital teams to ship each release at greater speeds. Your customers demand more responsiveness, your business demands more revenue and your competition isn't slowing down so why should you? This need for speed often leads software delivery teams to take shortcuts and turn a blind eye to spot fires that, seemingly "from nowhere" turn into soul-sapping infernos. Know what I mean?
Don't kid yourself because this feeling isn't just a figment of your vivid imagination, nor is it merely anecdotal evidence. A study by Big Blue found that it can cost you up to 100x more to fix bugs after they've been shipped as compared to during the development phase! Close your eyes and take this in for a moment: up to 100x more to fix those bugs that you're allowing to leak through into production.
The kicker is that this is not a problem that affects your processes and your financials. The stress caused by the increased velocity of releases hitting production is just as crippling on your team, especially as DevOps uptake increases without a thorough understanding of what the framework actually requires:
So what's the opposite of stress? Certainty, right? And what comes from certainty? Spot on, it's peace of mind. Our customers have solved this vicious cycle of late releases, bug-infested releases and cost blowouts have told us that this peace of mind they achieve far surpasses any technical or procedural benefit to revamping and optimising their software quality programs. The one thing they really don't miss is the anxiety that used to attack them before and after every release.
How different could your life be if you didn't have to wonder "what's going to go wrong today" every time your web and mobile apps went live?
So how do you find & fix bugs in your application before shipping?
First, you must accept that there is no silver bullet. The good news is that it can be done and there are lots of examples and actionable techniques that you can implement to make this happen.
The solution to this problem is a confluence of the 3 P's:
People, including not just your functional software testers, but also your developers, architects and your security testing team; and
Processes, the systems and communication channels you employ to ensure that most, if not all, bugs are consistently found before going live; and
Products (or software test tools), that ensure your teams get real-time analytics and insights about the spot fires that need to be handled before releasing.
We've seen across industries that it's very easy to over-complicate this process. But to achieve real, sustainable and material results you need to make evidence-based decisions and keep it very simple so that you don't confuse your team during this process.
A framework you can follow to fix your web & mobile app testing program
This is probably what you really came here for, so here it is:
Optimise the way you document and communicate your tests across your team
Ensure consistency between your test environments
Optimise the data sets for every test
Automate test scope selection and test execution
There are 5 other rules that you will find in our Secret Toolbox, which you can implement straight away without hiring any external consultants!
Our Secret Toolbox is literally our playbook of strategies that we implement for every customer. It has been refined over the years to make it useful for all SaaS and digital teams, irrespective of the methodologies or structures they follow. By applying the action items in the Secret Toolbox, you won't fix all your headaches, but you will achieve this:
Slash your software testing time from weeks or days to hours.
Reduce the number bugs that leak into production.
Minimise the direct and indirect (eg. support tickets) cost of software quality.
Eliminate the anxiety and stress that accompanies each release.
If you think these outcomes could positively impact your company's bottom line, your customers' happiness and your peace of mind, start implementing the Secret Toolbox now:
Selecting a pen testing company will be one of the most important business decisions you will make. This decision will decide just how well protected your users and your brand is going to be from a cybersecurity perspective. Asking these 6 questions will help you ensure that you choose a penetration testing company that is best suited to helping you secure applications and network infrastructure.
The answers to these 6 questions will ensure that your outsourced pen testing project delivers tremendous value and is not one of those disappointing IT outsourcing situations that we often hear about:
Where do the responsibilities sit between you, the customer, and the external pen testing company?
What type of results has the pen testing company delivered for their other customers?
What results will I get from the pen testing project?
How will our teams communicate with each other?
What can you offer us that your competitors can not?
When can you start? Can you work weekends or after hours?
Remember, as with any technical or business discussion it is not enough to simply rely on the first answer. In order to truly assess capability and alignment with your goals and values, you must delve deeper into every answer that a prospective pen testing company gives you.
Advanced Step: assess commercial sense
Conducting pen tests on a web or mobile application and network infrastructure is like conducting an angiogram on a 60-year old man - you are bound to find something that is not right. However, your team probably doesn't have endless time to keep finding and resolving every security vulnerability under the sun.
That's why the best pen testing services providers employ ethical hackers who not only have great technical skill, but also possess sound commercial sense. This combination of attributes allows pen testing companies like ours to prioritise vulnerabilities by risk and help you objectively prioritise security vulnerability resolution.
This is not an easy characteristic to understand without working with a pen testing company on a real project. However, by talking through the examples of where a pen testing company has demonstrated such commercial sense will likely give you great insight into their capability to deliver you commercial value.
If you need a fixed-fee penetration testing quote and a customised pen testing plan that delivers you tremendous value, speak to us understand why working with Audacix for your pen testing needs will be a decision that delivers an amazing ROI for you, your brand and your users.
Far too often we receive mayday calls from prospects who have invested a lot of money, but more importantly time, into selecting and working with a outsourced test automation services provider, only to be rewarded with a never-ending tug of war that inflicts much damage to their professional reputations. At the root of these frustrating and poor outcomes is a test automation service provider who was either out of their depth, unwilling to own up to failure and probably did not fully understand the customer's desired future state.
In the case of outsourced test automation services, most customers are trying to prevent losses of the magnitude reported by Computer Weekly magazine from the UK:
One analyst, who follows the outsourced software testing space closely, believes:
Cost savings are a major driver and also the need to do testing in a more professional manner.
While he is definitely on the mark, it is obvious to us that the thirst for cost savings often drives a disproportionate share of decision-making when selecting outsourced software testing providers. This only serves to diminish the importance of and attention to actually conducting "testing in a more professional manner." In fact, as far back as 2007, Gartner predicted:
Although the statistic above related to the BPO industry, our experience tells us that this would also hold true for outsourced software testing engagements. Gartner research director Alexa Bona put that finding down to high staff attrition rates suffered by many outsourced service providers. If you think about it, there are no free lunches, right? If you pay peanuts, you get...
While some software testing outsourcing engagements fail because of technical reasons, it is our analysis and that of other storied industry veterans, that most fail because of misaligned priorities, inadequate discovery and the IT services industry's propensity to try and fit square blocks in round holes.
At Audacix, we ask a lot of questions. Especially at the start of an engagement, but also throughout each project. This process of understanding each another is critical to building confidence and setting up the relationship for mutual wins. Contrary to popular belief, we have evidence that this process must start before the agreements are signed. Starting it later down the line leaves too much room for miscommunication and misalignment.
We have seen that the following 6 questions are often not asked or only broached very superficially during the "courtship" phase between a customer and their software testing services provider. It's almost never as simple as answering these questions alone, but they are a great starting point to understand your software testing service provider's capability to help you achieve your goals and deliver on their promises.
The 6 hidden reasons below address critical knowledge gaps that are the primary causes of failure in outsourced software testing engagements. These 6 reasons are, in fact, a set of 6 questions that you should ask yourself before your outsource your software testing. Answering these questions for yourself even if the outsourcing service provider does not ask you these questions will help give any engagement a much higher chance of success.
1. What is the big picture?
As an outsourced software testing service provider, this helps us quickly prioritise wins for potential engagement. This prioritisation is not based on our goals, but those of our customer. Clarifying the priority of outcomes helps us understand if the customer is looking for fast and effective test automation services that really kick goals, or just an attempt to get some cost transferred elsewhere.
By no means is attempting to achieve cost savings an unworthy goal. However, if cost saving is the primary reason you want to outsource your software testing then you will do well to find other goals and benefits you want to realise from such an engagement. Financial and non-financial reasons together will help you form a lasting and mutually fruitful relationship with your software testing partner.
If your software testing outsourcing partner has not asked the overarching goals for engaging, then you should explain these goals and link any performance evaluation to the achievement of these goals. Mutual and detailed understanding of the desired future state is the bedrock on which your software quality will flourish.
The future state should define quantifiable and measurable metrics covering software quality, internal and external resourcing, timeliness and investment targets.
Want to see how our testing tools & services can cut your testing time from weeks to hours?
The desired future state you described above is only going to be achieved if the combined labour of you and your outsourcing service provider produces the desired results. Transferring all project responsibility and accountability to your software testing service provider is the fastest way to guarantee a failed engagement.
We ask this question to understand 2 things:
How involved do you want to be throughout the project in terms of time and thought leadership; and
How do you view our roles in the engagement changing over time?
The answers to this question also help to clear many misconceptions that are very common in outsourcing engagements. Such differences often lead to increasing distance and friction between both parties. You can minimise, if not eliminate, the "crossed wires" and "we thought you were taking care of that" moments by clearly outlining responsibilities before and consistently throughout the engagement.
This clarity can be a big boon in outsourcing projects where you want your outsourcing partner to develop a test practice for you, then leave you to run it. Constant, structured and unstructured, communication is just as important with an external party as it is between internal teams and colleagues.
3. What will achieving these goals do for you?
This answer really tells a story about your priorities. Are your non-financial priorities at least on par with your cost saving goals? Are you really serious about finding bugs before they get into production and shifting left with your software quality or are you more concerned about shifting risk?
Prioritising these goals before you begin the selection process will help you make a more informed decision about the outsourced testing provider who best suits your needs. Some outsourcing partners will be happy to simply help you achieve your cost targets, whereas others may decide that they would rather concentrate on projects where cost reduction is one element of a good outcome.
How do you ACTUALLY know if your software testing is working? You must have a dashboard to easily track key testing metrics.
Phone, email and Slack are all relevant and useful modes of communication. The trick is to be clear about which communication medium to use for different needs. Many stalwarts of this industry also produce very fancy looking PDF or Excel reports prior to every progress meeting. But, how do you really assess project progress?
To remove this information asymmetry we developed a real-time dashboard as part our Qsome automated software testing platform. This dashboard is not only the central source of truth for project progress, because our test engineers see exactly what our customers see, but it also helps our customers make highly objective decisions about if and when they release to production. We find that removing the information gap between both parties is a critical component of the trust-building exercise.
By eliminating any doubts about the veracity of the information being discussed, our customers really appreciate being empowered to concentrate on conducting more frequent and more productive discussions about how we can all achieve their desired future state even faster.
Ask yourself: how could objective and accurate real-time data exchange between you and your outsourced software testing partners improve the results that are delivered by your team for the organisation? Think about it.
5. Have we understood you properly?
The clincher! All the thinking and explaining and strategising you have done to date are of no value if you and your outsourced software testing partner are not on the same page.
A simple technique that we ask our team to practice during sales meetings and progress review meetings is to explain what they think they have understood in their own words back to the customer. Communication experts will tell you that nothing promotes clarity and consistency like repetition.
Any idea, plan, or purpose may be placed in the mind through repetition of thought.
This conversation quickly brings unrealistic expectations to the fore. By repeating your goals and expectations aloud back to you, we are able to quickly isolate communication gaps and address them.
If you picked up a strong whiff of communication being the central theme behind these questions, then you are on point. Good communication is an abstract and ambiguous concept to those who miss the forest for the trees. In fact, you know communication is completely absent if someone believes they have communicated well with their outsourced test automation partner because the "legal agreement is watertight!"
The brutal truth is that if any commercial relationship devolves into both parties quoting from the contract, you may as well close the door on achieving any goals. While this is an unfortunate fact of life, you can minimise the chances of suffering this fate if you and your software testing outsourcing partner understands both your financial and non-financial goals.
6. What happens when things fail?
Failure isn't fatal, but failure to change might be.
And therein lies the crux of the most common problems with most outsourced software testing service providers. The ability and willingness to acknowledge, analyse and learn from mistakes, both your own and those of others, is a very noble and productive human characteristic, but sadly and uncommon one.
We have a very clear and concise three-pronged system for communicating and addressing failure within our projects. The surprising thing is how few prospective customers actually ask us about this during the sales process. There are 2 reasons you must ask this question of all your external partners:
If the external partner gets uncomfortable and provides glib answers, you have to really wonder whether it is worthwhile continuing discussions; and
This answer allows you to assess whether the outsourcing partner's values align with those of your organisation.
I've found that the alignment of values is the most underrated and overlooked aspect of assessing potential outsourced software testing partners. Think about it, how many times has your assessment list for potential partners included something around "aligned valued"?
Every question we ask during the sales process for our engagements is aimed at taking our communication to the next level, but also at ensuring that our values (play with heart, stand out and lead a revolution and become a world champion) will complement and not grate with those of our prospective customers. How do your values align with those of your outsourced software testing partners?
If you need help in cutting testing time and finding more bugs before your customers find them, speak to us understand how we might be able to help you. Right now, we're offering a free strategy session to help set you on the right path to achieve your goals.
+61 3 7001 1430
