Technologies that software testers need to master in 2017 and beyond

Insight Main Image

The wide-spread adoption of agile software development methodologies and DevOps in the past few years is helping businesses become much more efficient at rolling out new products and services.  Big, centralized Test Centers of Excellence are going the way of the dodo bird, a trend Forrester Research first reported in 2013.  Agile processes are all about rapidly building and delivering high-quality software that meets business users' changing requirements.  On agile teams, excellence and quality are expected to be in the products and in the work everyone does.  This means testing is done by the whole team, not just designated testers or quality assurance professionals.

Since software testing is an integral part of development on agile teams, here are a couple of technologies that software engineers with a background in quality assurance should become familiar with in order to stay relevant in iterative, fast-paced DevOps environments:

1. Large-scale Agile Frameworks

The guiding principles of the agile development process are to keep code simple, test often, and deliver working pieces of an application as soon as they're ready.  This works well on small software projects with co-located teams of 8-10 members but can cause problems on larger, enterprise-wide projects that need to scale across a wide variety of locations, lines of business, platforms and technologies.  There are three major frameworks that currently have significant mindshare when it comes to scaling agile software projects for large enterprises: the Scaled Agile Framework (SAFe), the Disciplined Agile Delivery (DAD), and Large Scale Scrum (LeSS).  All three of the main scaling approaches offer multi-level training and certification, which make them attractive to enterprises wanting to expand a small agile group into an enterprise-wide practice and need formal guidance. 

Because all three scaled agile frameworks build upon techniques used by smaller team-oriented agile frameworks, it's important to have a basic grounding in the ideas, concepts and terminology of either Scrum or another team-oriented agile framework.  Scrum is one of the most popular frameworks for implementing agile processes and it's so ubiquitous that many people confuse it with the umbrella-term Agile.  As an Agile process framework, Scrum takes a time-boxed, incremental approach to software development and project management by advocating frequent interaction with the business during what are known as Sprints (which are called iterations in other frameworks). 

Basic Scrum knowledge can be achieved by taking a Certified ScrumMaster or a Professional ScrumMaster course, or by hands-on experience practicing Scrum. The more experience you have with Scrum and other lean and agile methodologies, the easier it will be to master one or more of the larger scaled agile frameworks.

Figure 1:  Schematic of the Scrum Agile Process Framework

Overview of the Scrum Agile Process Framework

Image Source: Dr ian mitchell

How the 3 Large-scale Agile Frameworks Differ

The SAFe framework defines group processes at the Team, Program, and Portfolio level.  SAFe Teams typically consist of 5-9 people who work in two-week scrums using XP (Extreme Programming) methods, pulling work from the Program backlog. The length of each team's scrum is synchronized with 5-10 other SAFe teams at the Program level (the next level up), as part of an "Agile Release Train" that includes the development teams and other stakeholders. The highest level of the SAFe framework, the Portfolio level, defines ways that executives and agile leaders can use lean processes like value streams to identify and prioritize features, which can then be broken down at the Program level and scheduled on Agile Release Trains.

The SAFe "Big Picture" 

Image Source: SAFe

Disciplined Agile Delivery, developed by Scott Ambler and Mark Lines, is similar to SAFe in that it is built on existing lean and agile techniques. The DAD framework is designed to work across three project phases: Inception, Construction, and Transition. DAD's strength is in providing more guidance in the areas of architecture and design, which occur at the inception phase earlier in a project's lifecycle. It's also strong at deployment (in the transition phase) since it has explicit DevOps practices and strategies built into the framework.

Large-scale Scrum (LeSS), created by Craig Larman and Bas Vodde, has two frameworks:  Framework-1, designed for smaller companies (up to 10 Scrum teams, with 7 members each), and Framework-2, also referred to as LeSS Huge, designed for up to a few thousand people on one product. LeSS expands on the basic team Scrum framework by organizing several feature teams under a single Product Owner (PO).  Framework-2 adds the notion of an Area PO (APO) to handle scaling in larger organizations.  Compared to SAFe and DAD, LeSS is a more flexible and non-proscriptive agile scaling framework, which may not make it the best choice for enterprises and large-scale development projects that need more structure.

Large-scale Agile Frameworks Training Courses and Certifications

There are plenty of training courses and certifications to help you get up to speed on a particular framework.  The Scaled Agile Academy has a half-dozen certifications that provide the knowledge and tools to be effective at the Team, Program and/or Portfolio levels of the Scaled Agile Framework. These range from two-day courses for managers and executives (SAFe Agilist), to courses for developers and testers (SAFe Practitioner), to an in-depth SAFe Program Consultant Trainer program. The Disciplined Agile Consortium, which oversees the DAD framework, promotes five different certifications that range from a beginner stage, represented by Disciplined Agilist and Certified Disciplined Agilist certifications, to a 'master' stage, represented by the Certified Disciplined Agile Coach certification. There are several ways to learn more about LeSS, including courses for Certified LeSS Practitioner and Certified LeSS for Executives.

2. Beyond Mobile Testing to the Internet of Things

IT research firm Gartner has estimated that there could be more than 26 billion devices connected to the Internet of Things (IoT) by 2020, which will generate revenue, mostly in services, exceeding $300 billion.  According to another HP study, 70 percent of devices in the Internet of Things are vulnerable to security problems, "including password security, encryption and general lack of granular user access permissions."  From TVs and thermostats to door locks, appliances and hubs for controlling multiple devices, the app ecosystem is rapidly moving beyond smartphones to just about every connected device imaginable.  Unlike smartphones and their apps that rely on human input, many IoT devices also receive their information from sensors or other smart devices and act on their own according to their programming. 

A good resource for QA testers looking to build expertise in IoT devices and applications is the Open Web Application Security Project (OWASP), which provides a set of 10 basic guidelines for testers to focus on to improve the security of an IoT product.  These include:


IoT Security Consideration

1: Insecure Web Interface

Ensure that any web interface coding is written to prevent the use of weak passwords …

2: Insufficient Authentication/Authorization

Ensure that applications are written to require strong passwords where authentication is needed …

3: Insecure Network Services

Ensure applications that use network services don't respond poorly to buffer overflow, fuzzing …

4: Lack of Transport Encryption

Ensure all applications are written to make use of encrypted communication between devices…

5: Privacy Concerns

Ensure only the minimal amount of personal information is collected from consumers …

6: Insecure Cloud Interface

Ensure all cloud interfaces are reviewed for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces) …

7: Insecure Mobile Interface

Ensure that any mobile application coding is written to disallows weak passwords …

8: Insufficient Security Configurability

Ensure applications are written to include password security options (e.g. Enabling 20 character passwords or enabling two-factor authentication)…

9: Insecure Software/Firmware

Ensure all applications are written to include update capability and can be updated quickly …

10: Poor Physical Security

Ensure applications are written to utilize a minimal number of physical external ports (e.g. USB ports) on the device…

Chart Source: OWASP Internet of Things Project

Effectively testing IoT apps and devices means having to deal with an almost overwhelming number of hardware platforms, operating systems, and programming languages--not to mention deployment and release tools.  Because IoT programs will be developed quickly and deployed widely, they will need to be tested by multiple teams as part of an agile and DevOps culture that emphasizes collaboration.   Scaled agile processes like those described above will play an important part in this culture since they are much more adaptive than traditional waterfall methodologies.  Multi-team, geographically distributed IoT projects also create a necessity for application lifecycle management tooling that can manage and monitor all aspects of the large-scale agile testing process, such as requirements, user story, test case and defect management.

IoT DevOps teams will also need to leverage best practices in agile software testing, continuous integration and test-driven development to accelerate their test QA processes and reduce cycle time.  This includes automating as many tests as possible, including GUI, API, integration, component and unit tests.

The Agile Test Automation Pyramid

Image Source: Cody Blog

ALM software can also help multiple IoT DevOps teams collaborate and be more productive at activities like manual exploratory tests, which are tests where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.  Exploratory testing will be important on many IoT projects since some physical events, such as running, jogging, or the beating of a heart, are difficult to simulate in a laboratory and are best tested  "in the wild," under real-world conditions.  

Exploratory testing is done in a more freestyle fashion than scripted automated testing, where test cases are designed in advance.  With modern ALM software, even the most circuitous test path taken by an exploratory tester during a testing session can be recorded and played back. This helps other agile team members recreate the defect and fix the bug.

As the Internet of Things continues to grow, software testers will need to master agile and DevOps processes, including large-scale agile frameworks, in order to stay relevant.  Effective IoT testing requires a collaborative DevOps culture and access to suitable test management tools.  The good news is that a background in IoT testing, especially in dealing with security issues like the ones outlined above,  will be an invaluable job skill as more and more organizations bring IoT devices on-line and look to thwart digital attacks.

Related Articles: