Securing the smart and connected home

Billions of smart devices have at least one external connectivity interface which potentially becomes the entry point for cyber attackers to bring down the entire system.

Smart devices including mobile terminals, wearables and all kinds of sensors, smart nodes and platforms with connectivity and critical information processing capabilities are fast growing into billions of pieces. (File Photo)

Smart devices including mobile terminals, wearables and all kinds of sensors, smart nodes and platforms with connectivity and critical information processing capabilities are fast growing into billions of pieces. These billions of smart devices have at least one external connectivity interface which potentially becomes the entry point for attackers to bring down the entire system. Smart home is one such example of a connected system with intelligence.

To prevent attacks, a robust, market proven and certifiable hardware security solution becomes a key ingredient of such systems that communicate and process critical or sensitive information. Here we look into the various security threats in connected smart home devices and discuss the necessary security measures that should be utilised, in particular leveraging on the values of hardware trust anchors. We will also present specific use cases on Smart home environment as a good reference for the audience to gain a better understanding.

With the fast growth of IoT applications, our home network environment has changed dramatically in recent years. A typical home network setup five years ago consists of a wireless/wired router with ADSL/cable connection to the internet, and the devices are connected to the router are mainly desktop computers, laptops and smartphones. These devices have one commonality, which is that they are operated by human beings, and they are not powered up 24/7 in many cases except the smartphone.

Today, the home network setup is undergoing a complete revolution. A typical home network environment can be described as in below diagram:

Today, the home network setup is undergoing a complete revolution. (File Photo)

There are a few important new characteristics of a smart home network environment
First, there are more devices in the home today that are becoming smarter and connected. For instance, smart sensors like thermostats need to be connected to the internet for data logging and remote control. IP cameras need to be connected to internet for real time monitoring. Even door locks have evolved to include connectivity options to allow remote monitoring and to allow opening of the door remotely.

The dramatic increase of smart devices in the network increases the potential entry point of attacks from a security point of view. And all these smart devices have very minimal direct human operations. They all have built-in intelligence to collect data and information, make decisions based on the programmed algorithms and in many cases they need to have data communication capability with either the home gateway or the cloud server. End users mainly control or monitor these devices via external consoles or smart phones. Therefore in case of an occurrence of a security breach, end users have very minimum way to detect, prevent the issue and make corrective actions because these devices operate on their own.

Major security threats in smart home

We can broadly categorise security threats for smart home applications into 4 main categories. These security threats are identified and discussed as follows:

1.      Fake Identity of Devices: Most of the smart home devices possess some form of device identifiers as a unique ID or certificate. However, unique identifier without cryptographic protection can be easily cloned as soon as the attackers gain the knowledge of the generation process. Once the unique identifier can be cloned without authorization, the attacker is able to gain immediate access to the network via the cloned device, and from there subsequent attacks can be deployed. E.g. critical information can be stolen, bandwidth of the network can be misused, or malware and virus can be injected. On the other hand, validation of the server identity is equally important. If a home device is connected to a malicious server, critical user data can be stolen or in a very worst case, entire home network can be attacked.

2.      Eavesdropping of Data: Most of the communication interfaces used in smart home environment are based on wireless technologies, e.g. Bluetooth, ZigBee, Wi-Fi etc. Although most of the wireless technologies have some form of security protection mechanisms, they are not robust enough due to the constraints of the use cases. For instance, Bluetooth typically relies on simple passphrase to do pairing. It increases the risk of eavesdropping of the critical and sensitive user data over the communication interfaces. It is also common to employ encryption of the communication data using cryptographic keys to protect the confidentiality and integrity, however, the protection of the cryptographic keys against stealing and extraction are then of great importance.

As an illustration of a real life attack, three years ago, experts from Context Security demonstrated the security weaknesses of certain smart-bulbs. These LED bulbs were connected to a Wi-Fi___33 enabled circuit board and the experts found that when the bulbs “talked” to each other across a mesh network (6LoWPAN powered), the messages contained a username and password. As the underlying pre-shared key was never changed, all the white-hat guys had to do to gain access was to set up a similar circuit board simulating one of the smart bulbs asking to join the network. That allowed them to steal credentials and eventually gain control of all the lights on the network. They reported that a potential attacker could have easily gained access in private homes or businesses if they could have gotten as close as 30 meters to the bulbs. Even worse they note also that such a attack would have gone undetected by the owner of the network.

3.      Manipulation of Data: Besides the risk of eavesdropping, there is possibility of critical data being manipulated/changed by malicious attacks, therefore data integrity protection is another important aspect of security in Smart home environments. Critical information like billing information, sensitive configuration data or resource usage cannot be communicated and stored as manipulated value.

4.      Malware Infection: One typical attack after gaining access to the network is to install malware so that the affected device becomes the source of next level attack. The recent cases happened in some of the major telecommunication networks are typical examples of such attacks. Once the connected home devices are breached with malware installed, such devices could be added to a botnet and start issuing DDoS attack. As a result many smart home devices – not only computers – become potential source of DDoS attacks. The amount of such smart home devices (e.g. smart cameras, home routers etc.) is much more than the amount of computers connected to the net, therefore the scale and speed of damage due to botnet DDoS attack can be also much more significant.

Secondly, wireless connectivity solutions are not only limited to Wi-Fi in today’s smart home environment. Connectivity solutions, such as Bluetooth, ZigBee and Z-Wave have evolved and are adopted quickly. With the increase of the connected devices via different wireless connectivity solutions, the attack surfaces of smart home devices have greatly increased and the number of attacks has been rising steadily. Additional protection at system level is thus strongly needed.

Last but not least, most of these smart devices run on various microcontrollers with proprietary Real-Time Operating System (RTOS). The security level of such implementations can vary from vendor to vendor. Also, very often there is a need for field firmware upgrade for these devices which opens up another highly potential attacking entry point because malware can be injected during firmware upgrade without sufficient protection mechanisms in place. The recent distributed denial of service (DDoS) attack from connected devices in US and Germany are very good examples of the importance of firmware protection in connected home devices.

Basic Security Cornerstones
The above mentioned security threats in the smart home environment can be addressed by 3 basic security aspects: “Confidentiality” by encrypting the sensitive data; “Integrity” by protecting data with cryptographic Message Authentication Code function or digital signature; “Authenticity” by using strong cryptographic authentication schemes.
At the center of these 3 security cornerstones are the cryptographic keys which are used for the encryption/decryption, calculation of the CMACs and supporting the strong cryptographic authentication schemes. If an attacker manages to steal or clone these cryptographic keys, then these security cornerstones (“Confidentiality”, “Integrity” and “Authenticity”) can no longer be enforced since the attacker is now able to successfully eavesdrop and/or modify the communication data and fake itself as the real device. Therefore, it is of paramount importance to protect these cryptographic keys by using a tamper-resistant hardware trust anchors.

Hardware based trust anchors for Smart Home Security
Secured identities are established using secret keys and cryptographic processes that utilize secret keys. Secret keys are fundamental root of trust for the entire chain of security measures required to protect smart home systems. Hardware-based security solutions provide the robust levels of security required to protect secured identities and deliver a greater level of trust than pure software based implementation.

Software-only solutions often have common weaknesses such as software bugs or malware attack. Typically, it is also relatively simple to read and overwrite software, which, in turn, makes it easy for attackers to extract secret keys. In contrast, hardware based security solutions can be used to store access data and keys on the same level as a safe is used to store confidential documents.

Software-only solutions often have common weaknesses such as software bugs or malware attack. (File Photo)

There is no one-size-fits all solution when it comes to cyber-security and very often the effective approach is to adopt a defense-in-depth approach where the security countermeasures are built into various layers such as devices, software and application, processes and user education.
On the device and hardware level, the best-of-both-worlds can be achieved by adopting tamper-resistant hardware trust anchors to complement the software security implementations. The hardware trust anchors can be used to provide a secured storage of cryptographic keys and provide a strong level of trust to support the software implementations. By achieving the spatial separation of the software applications and cryptographic keys, this provides a cost-efficient and highly effective barrier against the leakage of the keys and certificates in the event of malware infections.

With the advent of the Internet of Things and Smart Home technology, more and more devices are becoming connected. (File Photo)

Conclusion
With the advent of the Internet of Things and Smart Home technology, more and more devices are becoming connected. Attacks are made possible as these smart devices are able to run source codes for applications and that they are mostly connected to the internet without any secured connection. These can potentially become entry points for malicious hackers to break into the system to steal, manipulate confidential information (e.g. passwords) or even to inject malware.

In most of these cases, the users are unaware of the vulnerabilities and potential security exposure (e.g. ref the DDOS attack) of the products they purchase. Hence it is imperative that device makers include security measures from the design of their products.

In addition to other security measures in the operating system or software, a hardware trust anchor provides the secured basis for the system. By relying on such a specialized device, the manufacturers of embedded devices can reduce their efforts for creating a secured basis while still getting a strongly secured system.

Source : indianexpress

Read More

How To Make Developers More Efficient: Software Development in the Cloud

The software development cycle is changing. The traditional cycle of software development ranged from tasks like requirements gathering, analysis, implementation, QA, build-fix-build iterations and then, finally, application deployment. From start to finish, software development typically took many months or even years. Those individual tasks aren’t going away, but the development cycle is changing.  It is shortening

Agile development, for one, has had a tremendous influence on the development cycle. The morphing of long development cycles into frequent loops of development and redeployment followed by feedback from customers, end users and other stakeholders has enabled more frequent updates and more targeted releases.

The packaging of software as apps that can access collections of microservices and as containers also means that it’s now possible to introduce updates more easily and frequently by swapping out newer versions of self-contained services.

But, above all, the cloud-first development philosophy has become a part of almost all new software is affecting how software is created.

Some of the reasons why software development is done more efficiently in the cloud include:

1. Typically software developers are already using the cloud for some part of their current process.

2. Software developers want to work with new technologies, most of which are cloud centric.

3. New software development tools, like for DevOps and Continuous Delivery, are based on cloud services.

Source: Formtek

Read More

Infrastructure as code: The agile approach to testing

The purpose of testing is to help us to get our work done quickly, however, in many organisations, testing is seen as something that slows work down.

There is a common misconception that quality and delivery speed are opposing forces that must be traded off against each other, with this mind-set leading to the idea that automation can speed up the delivery process by making the act of testing a system go faster. These misconceptions can easily lead to expensive, failed test automation initiatives.

Quality is an enabler of delivery speed, with the goal of automated testing being to help teams focus on keeping the quality of their system high, through fast feedback. When combined with a good team culture and a discipline that prioritises quality, automated tooling can help to find quality issues fast, meaning the team can respond and fix them quickly.

In turn, this keeps the system in a state where changes can be made quickly, easily and confidently, proving that faster delivery speed is a side effect of focusing on quality and automated test tooling is an aid to keeping quality at the forefront of the team’s mind.
Shortening the feedback loop

Agile processes encourage teams to integrate testing with implementation, in order to shorten the feedback loop. Testing takes place continuously, with ongoing changes being made by testers and developers working closely together, combined with automated testing.

The most useful goal for test automation isn’t to make a test phase run faster, but to enable testing and fixing activities as a core part of the workflow. As someone works on changes to the system, whether that is to an application code or infrastructure definitions, they are continuously testing. People test so they can fix each problem as it is discovered, while they’re still working on their changes and everything is fresh in their mind. When the scope of changes are very small, the problems are quick to find and easy to fix.
Automating tests for fast feedback

Teams whose testing process is based around separate implementation and test phases often attempt to adopt automation by automating their test phase. This is often a project owned by the QA team, which aims to create a comprehensive regression test suite. In my experience, automated test suites built by a separate testing team tend to focus on high level testing, but the outcome can sometimes result in an unbalanced test suite.

The key to designing and implementing a well-balanced automated test suite is for the entire team, especially the implementers, to be involved in its planning, design and implementation. Big bang test automation initiatives often bite off more than they can chew, and struggle to keep up with ongoing development. The system is a constantly moving and changing target, and before the massive test suite is complete, the system has changed and shifted multiple times. Assuming the test suite can be completed, the system will change again immediately, meaning tests tend to be constantly broken, and the nirvana of a complete test suite is never achieved.

It is rarely effective to aim for the goal of a complete, finished test suite; the goal of an automation initiative should be to embed the habit of continuously writing tests as part of routine changes and implementation work. The outcome of an automated testing initiative is not a completed test suite, but a set of working habits and routines. When automated testing has been successfully adopted by a team, tests are written or updated whenever a change is made to the system. CI and CD regimes run the relevant tests for every change continuously, and the team responds immediately by fixing failing tests.
Organically building a test suite

The best way to start an initiative that results in embedding these kinds of testing habits is to write tests for each new change as it comes up. When a bug is found, write a test that exposes that bug, and then fix it. When a new feature or capability is needed, begin implementing tests as you go, possibly even using TDD. Building the test suite organically as a part of making routine changes forces everyone to learn the habits and skills of sustainable, continuous testing.

The outcome to aim for is not a “finished” test suite, but the routine of testing each change, and a comprehensive test suite will emerge from this approach. Interestingly, the test suite that emerges will be focused on the areas of the system that need tests more urgently and the ones which change and/or break the most.
Implementing automated infrastructure testing

There is a variety of tooling available to implement automated infrastructure testing, and in many cases, tools designed for software testing can be directly adopted and applied to infrastructure. Some of these tools have been extended to add infrastructure specific functionality; Serverspec, for example, extends the RSpec Ruby-based testing tool with features for checking server configuration. It’s important to avoid getting hung up on the tooling, however, and you should avoid choosing a tool and basing your entire testing strategy around it.

Instead, analyse the systems and components at hand to decide how you need to approach testing them, and then find tools to carry out your approach. As with any part of your infrastructure, you should assume that you will continuously change parts of your test tooling over time.
Roles and workflow for testing

Infrastructure teams tend to find testing a challenge, with the typical systems administrator’s QA process being: 1) make a change, 2) do some ad-hoc testing (if there’s time), 3) keep an eye on it for a little while afterwards. On the flip side, some testers don’t understand infrastructure very well, and as a result, most testing in IT operations tends to be at a fairly high level. One of the big wins of agile software development is the breaking down of silos between developers and testers, and rather than making quality the responsibility of a separate team, developers and testers share ownership. Similarly, rather than allocating a large block of time to test the system when it’s almost done, agile teams begin testing when they start coding.

There is still some disagreement over what the role of a QA (Quality Analyst) or tester should entail, even within an agile team, with some teams deciding that, since developers write their own automated tests, there is no need for a separate role. Personally, I find that even within a highly functioning team, QAs bring a valuable perspective and level of expertise for discovering the gaps and holes in what I build.
Conclusion

Automated testing is arguably the most challenging aspect of infrastructure as code, whilst also being the most important for supporting a reliable and adaptable infrastructure.

Teams should build the aforementioned habits and processes to routinely incorporate testing as a core part of their infrastructure, but should recognise that this will require the highest degree of openness to change.

Source: http://www.itproportal.com/2016/04/24/infrastructure-as-code-the-agile-approach-to-testing/

Read More

Software Testing Myths and Realities

Many companies see software testing at in a different way that depend on web applications for business operations in today’s rapidly transforming technology. These companies think software testing as a mysterious thing which has factors that are difficult to understand. Things like why and when they need to have pool of expert test engineers, next-generation testing tools with modern infrastructure and a key thing is that difficulty in finding the priorities of testing. The most common myths are that testing is time-consuming, it is too costly, it requires a lot of effort, testers are responsible for the inadequate quality of application, testing in agile environment is purely ad-hoc etc.

Companies that looking out for testing their applications or the companies that looking out to outsourcing testing activities would face a lot of factors which keep hitting their minds. Companies that are not aware of capability of software testing would be completely puzzled. It is not easy to have all the right things in place at the right time.

Some people think it is too boring at times when the need of being creative in work is very limited. It could happen when the software project is very small with only few functions and user input fields here and there. Of course it will not last long, but it’s not very exciting either. However, if a project is a large one with a lot functions and features, it would be very interesting and challenging to test. It needs applying a lot of creativity to be productive.

Some software testing stories that could really confuse one with certain misconceptions like some; people think that testing is too costly, but for the reality it is something like you pay less for testing during software development or pay more for identifying issues later. Introducing software testing at the early stages would help in reducing both time and cost. Some companies think that testing is time-consuming, but for the reality when it is introduced during the development life cycle, it is never a time-consuming activity. Testing and identifying bugs throughout SDLC is always very productive.
Some companies think that tester’s only job is to find bugs, if bugs are not identified, they would be responsible for quality of application. But the reality is that, there cannot be anything like that an application is defect-free even through when it is tested through the specialist team. With an advent of Automation Testing, people started thinking that it can be used anywhere during SDLC. But the reality is that, it can help only in reducing the repetitive tests.

Another thought is that automation can eliminate the need for manual testing. Doubtlessly, there is no replacement for manual testing, whereas automation testing is relied on manual test plans only. Generally, automation is deployed only when tests are repetitive and time-consuming. A better test coverage can be reaped using the combination of manual and automated testing. Some myths around Testing in Agile environment like, since agile development methodologies have been focused point for many companies, testing in agile environments has become important.

Some myths are; Testing in Agile is ad hoc, less documentation, and it does not have strategies. For the reality, an agile environment involves planning sprints, budget and resources ahead of time. It brings testers and developers together helps to improve quality, achieve faster time to market at reduced costs. However, the testing has moved on. Testing cannot be ignored. We should be focusing at increasing complexity of applications and how can we test them to identify all defects.

Source: https://www.clictest.com/

Read More

The Top 5 Skills for Future Software Testers

The software field grows every year, and so do all of the individual facets it contains. We can personally attest that software testing companies are expanding, looking for talented folks interested in pursuing a career in testing and QA. That’s why we just published a QA jobs website , to help guide those who are interested in joining us here at the US’s largest software testing company. Careers in this industry are satisfying and fast-paced, but they aren’t for everyone; here on the QualiTest Blog we decided to look at the top 5 skills for future software testers today.

A software tester’s biggest job is to mentally get inside a system, figure out what makes it work, and come up with interesting ways to “break” it.

1. Logic and analytics – any career in the tech field will need this one; figuring out how things work correctly and independently is a godsend to software-related teamwork, as it means you’re likely to come to the right conclusions with little to no handholding.
2. Communication – It’s by far the most important skill for software testers old and new, as without it, testers have no idea what they’re supposed to be doing, and stakeholders have no idea what’s going on with their project.
3. Creativity/ability to think outside the box – a software tester’s biggest job is to mentally get inside a system, figure out what makes it work, and come up with interesting ways to “break” it.
4. Understanding of business processes – similar to the above, this skill allows you to better understand a system, and how can you test the functionality of a system you don’t understand?
5. Some amount of technical understanding – your employer won’t expect you to be their new IT admin, but you should have some basic understanding of how the program you’re testing works, and how the hardware you’re using to do so works as well.

If you have these five skills, congratulations! You’ll probably be an awesome software tester (and you’d also be great at a bunch of other careers in IT/technology). If you don’t, you’ll definitely be at a slight disadvantage, but most of them can be picked up with a bit of hard work. The best thing about these skills is that they don’t necessarily require prior hands-on experience in software development or testing; sure, the only real way to learn to test is by actually testing, but the above skills can be sharped from just about anything – college schoolwork, part time jobs, or experimenting with technology in your own free time. Software testing is great like that.

Source: http://www.qualitestgroup.com/blog/test-methodologies-and-philosophies/top-5-skills-future-software-testers/

Read More

How to Write Test Documents

When beginning a Software Testing project, several documents must be prepared as part of the process. These documents include a Test Plan, Test Scenarios and Test Cases.
It can be difficult to start these documents from scratch each time that you begin a new software testing project. Knowing where to begin is one of the greatest challenges in writing these plans. Using a template that has a detailed outline of required information can assist in this process.

Share to download our Test Documentation Templates:

Use one of the buttons below to share and start downloading:
Test Plan template
Test Scenario template
Test Case template

Download

Download

Download

Download

inShare42

Creating a Test Plan

A Software Test Plan (STP) documents the requirements that will be used to verify that a product or system meets its design specifications and other requirements.
The STP prescribes the objectives, approach, resources and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan. The Test Plan should also discuss any deliverables for testing, including references to test scenarios.
A test plan is usually prepared by a team lead or test engineer, with significant input from developers.
For an example of a Test Plan template that has been assembled by QualiTest, please refer to the link above.

Creating a Test Scenario

A Scenario, also known as a Test Condition or Test Possibility, identifies the functionality to be tested. A Scenario includes a set of test cases to ensure that the business process flows are tested from end to end. They may be independent tests, or a series of succeeding tests, each dependent on the output of the previous one. Any connection to the test plan should be referenced in the test scenario.
For an example of a Test Scenario template that has been assembled by QualiTest, please refer to the link above.

Creating a Test Case

A test case is a set of conditions or variables from which a software tester will determine whether an application, software system or a feature is working as it was intended. It may take many test cases to determine that a software program or system has been sufficiently scrutinized before released. Test cases are often referred to as test scripts after being written and collected into test suites.
The characteristics of a good test case are:

• Accurate: Expressly articulates the purpose.
• Economical: No unnecessary steps or words.
• Traceable: Capable of being traced to requirements.
• Repeatable: Can be used to perform the test as many times as necessary.
• Reusable: Can be reused if necessary.
• Independent: Each test case should be executable in any order, without any dependency on other test cases.
• Concise: The description of a test case should be simple and clear. A tester should be able to understand it by reading it once.

For an example of a Test Case template that has been assembled by QualiTest, please refer to the link above.

Tips For Templates

• Before writing any test cases, one should concentrate on the various scenarios which the product will face at a customer’s site.
• Because plans, scenarios and cases form the base for future test cases and testing, you should designate sufficient writing time, followed by a thorough review process.
• Scenarios should be brief and succinct. The purpose of a test scenario is not to provide details, but to convey a specific idea about testing a particular case.

Source: http://www.qualitestgroup.com/blog/testing-tools/write-test-documents/

Read More

Visual Testing: A Necessary Component to DevOps

As we all know, continuous integration and agile methodologies are on the rise, meaning that companies are releasing tons of software releases – not just in a month, not just in a week, but on a daily basis. With this increase in releases, it can be extremely difficult to ensure that you are thoroughly testing every webpage, every visual element, every User Interface (UI), with every release, and knowing with certainty that any new code hasn’t broken the appearance and layout of your application.

So what is the answer to this conundrum?

That’s exactly the question that our friends at Applitools are trying to answer, and they may have cracked the code with their foray into Visual Software Testing.

Visual Software Testing is the process of validating the visual aspects of an application’s UI. Visual Testing focuses on validating the layout and appearance of each visual element of the UI and of the UI as a whole, as well as ensuring that the correct content is displayed. Layout correctness means that each visual element of the UI is properly positioned on the screen, that it is of the right shape and size, and that it does not overlap or hide other visual elements. Appearance correctness means that the visual elements are of the correct font, color, or image.

Adam Carmi, one of Applitools’ Co-Founders, conducted research of image processing algorithms that can imitate a human tester’s eyes and brain and has come up with a set of algorithms that finally did the work! Based on those algorithms, they built their tool around the premise that it must inspect the application’s UI just like a human does. This means processing entire UI screen images rather than isolated image fragments or opaque UI objects within the application. Advanced image analysis is required to reduce false defect detection and to pinpoint the root cause of detected changes. For example, the tool automatically categorizes the difference as a content, layout or appearance defect, and pinpoints the specific UI elements that caused the defect. Another aspect of a successful visual testing tool is ensuring that the tool is smart enough to highlight and resolve each detected change only once – even if it appears in multiple screens of the application.

The motivation for performing visual testing has grown dramatically in recent years. Software vendors invest huge amounts of effort, time and money to design and develop user interfaces that stand out from the crowd and meet ever increasing customer expectations. Vendors must verify that their UI correctly displays on an ever-growing variety of web-browsers, screen resolutions, devices, and form-factors, as even the smallest UI corruption can result in loss of business. To keep up with the stresses and agility of continuous integration environments, software vendors are either going to have to keep performing the drudgery of manual testing, or move on to the thrills of visual testing!

Source: http://www.qualitestgroup.com/blog/testing-tools/visual-testing-a-necessary-component-to-devops/

Read More

Tech trends that have changed the way we test software

We are witnessing the rapid influx of new technologies and a continuously evolving industry which is always moving forward. Year on year, we are seeing new trends in technology such as ‘cloud computing’, ‘enterprise mobility’ and the ‘IoT’ that have changed the way we test software.








*The graphs show the popularity trends vs other search terms. The numbers that appear show total searches for a term relative to the total number of searches done on Google over time. A line trending downward means that a search term’s relative popularity is decreasing. But that doesn’t necessarily mean the total number of searches for that term is decreasing. It just means its popularity is decreasing compared to other searches.

In 2015 Big Data, the Internet of Things, Cloud Computing and 3D printing appear to be current trends that dominate the IT industry. While the popularity of “information technology” has declined, we see a rise in many specific technologies. As reflected in the graph above, as the diversity of technology continues, people are moving from the general search term to more specific ones. For example, living in this connected world, we can see a growth in “internet of things” which is likely to continue. Cisco predicts there will be 25 billion connected devices, which will double to 50 billion by 2020 (Information Age).
With these new trends in technology, companies are required to adopt new ways of development, essentially requiring new methods for testing. Therefore, we can presume that testing trends consistently follow those of development.

Using Google trends can inform us of numerous details about the various up/down trends that are occurring, as well as the predicted forecast for the near future. Google trends delivers both timely and accurate information which can educate us in regards to the current testing space. For this particular article we have focused on the rise of Agile Software Development and DevOps which has led to the demand for Test Automation and the attractiveness of open source vs paid test tools.

Agile Software Development

Test teams are having to keep up with the pace of current development trends. With that said, we see more and more enterprises breaking away from traditional approaches to development as they need to remain competitive. With high pressure to reduce the time-to-market, where projects are being driven by fast paced and responsive testing solutions, organisations are moving towards being integrated in agile development methods.




The above Google Trends graph identifies that the term “agile software development” is trending upward in search popularity with some small dips over the years. The worldwide interest over time increased by 28.95% in August 2015 compared with August 2010. Agile will continue its progressive journey and will receive increased worldwide interest, leading us to assume that more organisations will continue to apply agile to their test process.

Additionally, with the ability to develop faster and the more recent emergence of cloud computing, we are seeing a cultural shift towards DevOps. With benefits including continuous delivery, cloud providers and technology companies are adopting DevOps culture into their organisations. Google Trends reveals that the term “DevOps” has been growing since 2011, seeing its greatest growth in the past two years. DevOps average search popularity has increased by 50% in 2015 from 2014. According to Gartner, in 2016 about 25% of 2000 global IT companies will adopt DevOps.

In this Agile and DevOps driven environment with the demand for shorter timeframes, there is a greater emphasis on test teams to embrace test automation wherever possible to reduce times, costs and improve efficiency. The role of test automation is considered fundamentally important to the continuous integration and continuous delivery of a project and is more important than ever before. As a result, the trend for test automation has also increased over the years as automation is a critical component to maintaining agility.

According to the World Quality Report 2015-2016 the average percentage of test case automation has increased from 28% to 45% in the last year. Furthermore, as suggested in InfoQ, we can agree that the complexity of testing will increase with IoT, having a vast impact on the testing community and with this there is likely to be a strong push to more automation.

Open Source vs Paid Tools

Suppliers are now offering more tools and services and the availability of a variety of tools is driving the increased adoption of automation across the development cycle. For automation to be successful, selecting the right tool is important. You must critically assess your own need and choose a tool accordingly, whether choosing to adopt a commercial or open source tool.

There appears to have been significant adoption of open source tools over the years compared with commercial tool investment. Open source tools enable early code driven tests and continuous integration mechanisms, which are key to the success of agile projects. In addition, 45% of organisations cite a lack of supplier dependency as a reason for choosing open-source software (InformationAge 2015). Gartner has identified that the most widely used open source tools include Geb, Selenium, SoapUI, Sahi, Watir, Bugzilla and JMeter.



*Selenium and QTP/UFT interest over 5 years
Vendor tools like HP’s test tool suite (QTP/UFT) have been on a downhill path and we are not sure that vendor-based tools will necessarily make a comeback anytime soon. There is no doubt that Selenium is the winner here, as it has advanced and is rapidly growing as one of the most widely used test automation tools, having almost doubled in search popularity in 2010 compared with 2015.



Open source tool SoapUI has risen in search popularity and interestingly, more recently has become even more popular than Smartbear’s TestComplete. TestComplete has received the least number of searches in comparison to the other tools and its forecast has little/no data to show its estimated popularity for 2016. However, more test tool vendors are beginning to embrace open-source tools like Selenium e.g. Smartbear’s TestComplete can now run a Selenium test (Smartbear 2015). So here we can see that open source tools are continuing to make progress as they are practical alternatives to these commercial applications.

Considering the above statistics and projections, we can validate that as technological innovations continue to grow and with the emergence of new trends in the technology space, the trends in testing continue to be influenced.

Over the last decade the software industry has evolved considerably. We can see how the demand for faster time to market has seen the rise in popularity of agile development and the cultural shift towards DevOps, which in turn has stressed emphasis on businesses to embrace automation to reduce costs and improve efficiency. As test automation is continually adopted, we can realise first-hand the shift from commercial test tools as the search for cost effective solutions has encouraged enterprises to seek open source solutions and to date they have become an integral part of testing. Going forward we can continue to use google trends to inform us of how various software testing trends have altered over the years as well as helping us to predict the future of testing.

Source: http://www.qualitestgroup.com/blog/testing-as-a-lifestyle/tech-trends-that-have-changed-the-way-we-test-software/

Read More

Automation Testing: image

Read More