Continuous Testing at the Speed of the Agile Modern Business

Relying on automation to execute whole test on large deployment, doesn’t mean the role of the QA engineer is going away. Learn why?

With more companies of all sizes embracing the Agile and DevOps methodologies, the speed of the software development lifecycle continues to increase. This reflects a competitive business world which operates all over the globe on a 24-7 basis. The days of the biannual release cycle appear to be obsolete.

Continuous deployment and other offshoots of Agile strive to make software enhancements a quick and painless process, so it stands to reason this “need for speed” would influence quality assurance. Enter continuous testing. We’ve mentioned this concept in a previous post, but this time out we’ll take a closer look at this emerging QA trend.

Preventing QA from becoming a Bottleneck

Companies embracing continuous delivery leverage automation to make various aspects of the SDLC faster. This includes automating builds, migrations, and other related tasks. While a need for manual software testing still exists, especially when it comes to validating usability and interfaces, companies are taking advantage of automated tests as part of a continuous testing model.

Continuous testing requires extra effort to be spent on developing these automated tests. This concept applies when it comes to determining whether or not to deploy the software into production after the test run is complete. Business stakeholders need to work closely with QA engineers to determine the criteria for a go/no go decision; factoring in performance, reliability, and security issues.

Additionally, many continuous testing programs involve QA personnel at the beginning of the lifecycle, with the hopes of validating design work before development takes place — the extra cost of handling bugs later in the SDLC still matters in this scenario. The scope of testing includes automated API tests, unit tests, as well as system and integration tests. Security and performance testing is also performed when relevant.

Managing the Continuous Testing Process

Relying on automation to execute a whole range of tests as part of a larger build and deployment process doesn’t mean the role of the QA engineer is going away. We mentioned earlier about the importance in properly developing automated tests able to determine whether or not to deploy a release. It is also vital to involve QA personnel in the management of the entire automated testing process, including performance monitoring and defect analysis.

Many QA tools and applications now include support for continuous testing that goes beyond simply automation. These typically provide a robust mechanism for authoring tests in addition to the real-time defect reporting and performance features needed to truly take advantage of CT.

Resources for Learning more about Continuous Testing

A wide range of eBooks and other material covering continuous testing are available if you are interested in learning more about this topic. SOASTA, known for their performance analytics software, offers an eBook on Continuous Testing in an Agile World. IT managers interested in the subject need to check out Parasoft’s book aimed at technology leaders.

In short, continuous testing needs to be considered by any organization hoping to truly take advantage of Agile or DevOps.

Keep tuned to the Betica Blog for further dispatches from the wide world of QA and software development.

Using “Tribes” to successfully implement Agile

As the Agile software development methodology continues to mature, companies are beginning to leverage new and interesting strategies to implement the concept at their shops. Introducing something as revolutionary as Agile can be a difficult task with older, more entrenched IT teams. Even as the movement celebrates its 15th anniversary this year, it still seems foreign to development teams used to the Waterfall and other traditional methodologies.

Some shops are beginning to organize their development, QA, and business stakeholder teams into groups known as Squads, Tribes, Chapters, and Guilds to better facilitate the collaboration and communication vital for a successful Agile transition. Let’s take a look at this concept to see if it makes sense for your company.

Defining Agile Tribes and Squads

This new method for organizing teams in an Agile shop first evolved at the music streaming company, Spotify. The smallest group in their organizational structure is known as a Squad, led by a Product Owner. They tend to sit together; work closely on the same projects, and typically include developers, testers, and business analysts.

A Tribe is made up of a collection of Squads which share space in a common area. For example, a company’s mobile software development Tribe contains separate Squads responsible for iOS, Android, and other mobile platforms. The Tribe Leader facilitates an environment where each Squad is able to collaborate and share findings with each other, but they aren’t necessarily working on the same projects.

Chapters and Guilds help develop the Individual and the Organization

Chapters are independent entities within the overall structure that group employees based on their actual job duties. Many shops will have a Developer Chapter, QA Chapter, Business Analyst Chapter, and so on. A Chapter Lead essentially serves as the direct manager for everyone in their chapter when it comes to salary reviews, skills development, etc.

Guilds are another, less formal, structure inside the organization that are similar to chapters in that they include employees from different tribes, but are instead focused on specific areas of interest, like web development, Agile coaching, etc. The Guild Coordinator serves as the leader. They support the technical growth of the organization by researching new ideas while sharing found insights, code examples, best practices, and more.

There is a separate operations team for handling network and server administration at Spotify, but enterprises already embracing DevOps can easily include employees in that role into relevant Squads and Tribes. In that scenario, creating Chapters and Guilds specifically for those workers also makes perfect sense.

A Constantly Evolving Structure

Spotify uses quarterly surveys and regular dependency reviews to ensure their organizational structure is successfully meeting the needs of the business. This helps to mitigate any clashes and redundancies between individual Tribes and Squads. Additionally, the scope of daily Scrums is able to expand by including more Squads if required on larger products.

Ultimately, these innovative managerial efforts by Spotify and other firms illustrate how embracing the Agile methodology — albeit combined with the organizational changes more typical of DevOps — lets enterprises reach new heights by fostering a highly efficient software development process.

Come back to the Betica Blog for additional insights from the world of software development.

Transform your Organization with the Inverse Conway Maneuver

As the process of software development continues to mature in the modern business world, the organizational structures of companies engaged in application design struggle to keep up. This is largely due to the tendency of these firms to produce software architectures matching their current structure, which can lead to outdated and lower quality products, especially in this era of Agile and DevOps. This behavior is known as “Conway’s Law,” named for the computer scientist, Melvin Conway who first made the observation in 1968.

Tech pundits recently formulated a technique known as the Inverse Conway Maneuver, which involves restructuring a business organization to more closely match a desired software architecture. In an ideal case, business and technical teams become better aligned and ultimately produce higher quality work. Let’s take a closer look at the Inverse Conway Maneuver to see if makes sense at your company.

A Closer Look at Conway’s Law

Way back in the nascent computer age of the 1960s, Melvin Conway noted that committees tended to build systems that matched their business structure. His basic thesis for Conway’s Law is straightforward and was first made in the article How Do Committees Invent published in 1968 in Datamation Magazine.

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

Conway’s Law can be applied to a whole range of scenarios beyond software development as noted in the thesis. Its counterpoint, known as the Inverse Conway Maneuver, involves reengineering the structure of an organization based on a desired software design.

DevOps and the Inverse Conway Maneuver

In the modern development era, the DevOps methodology serves as a partial example of the Inverse Conway Maneuver with teams merging and evolving to reflect increased collaboration between the programming, QA, and network administration roles. Following a DevOps organizational structure is typically necessary for companies to be able to break down older, entrenched mindsets that won’t work at today’s speed of business.

Jason Bloomberg of Intellyx feels the rate of technology evolution in today’s business world is actually “reversing the Inverse Conway Maneuver.” Instead of companies making structural changes ahead of time in the hopes of reaching goals like DevOps or continuous deployment, the transformation is actually happening in the opposite direction.

“Technology change is driving changing customer preferences and behavior, which in turn are driving organizational change across increasingly software-driven enterprises. The causality question behind Conway’s Law, therefore, is less about how changing software organizations can lead to better software, but rather how companies can best leverage changing technology in order to transform their organizations,” says Bloomberg.

No matter what triggers this organizational transformation, there is no denying modern software businesses need to evolve to produce a better end-product lest they get left behind. The competition remains fierce. It is fascinating to note a “law” first formulated in the late 60s still holds so much weight in the software industry today.

Stay tuned to further installments from the Betica Blog as we dive deeper into the worlds of software development and QA.