devopsy.kinsta.cloud

Tag: Behavior Driven Development

Real-Life BDD: Getting the Best Out of Dev Teams
If we want our software to have value, we need to improve it every day, rather than wait three months for the next release. If someone finds a bug and we know how to fix it, we want to deliver the fix that day. The challenge is deploying to production many times a day.

If the developer is coding right now, we want to see their work in production today. However, when you increase the speed of delivery, you need to be sure that the code you deploy works. To increase speed and quality at the same time, you need a safety net and a lot of automation.

Sometimes we need to change the mindset of developers. This affects interactions between the developers and product management. It also changes the way developers code and how they approach their work.

Break It Down

Behavior-driven development (BDD) helps all of my teams. My mature teams use the three stages of BDD: discovery, formulation and automation. To increase speed and quality in a team that isn’t as mature (not much test automation, a lot of manual testing), one of our challenges is to develop small pieces of code they can deliver.

When we groom an item in the backlog, the product owner (PO) explains what’s needed, but sometimes when the developers start working, they find other stories that may take two weeks each. With BDD discovery, the PO and developers can reach a shared understanding of what’s needed before coding starts. If the story is too large, example mapping helps them split it. They need to obtain stories that will take less than three days.

More Ideas, More Examples, More Agile

To simplify collaboration between the engineering and business units, the product team needs to understand the size of the ask for the developer. You can improve communication by showing all the different cases that exist for this feature and by using example mapping.

Here’s an example of how this works in practice: the product team asks for a feature and explains it in about 10 minutes. The developers say this will take two to three weeks. However, after the developers completed user story mapping and example mapping and began to split the big features into smaller stories with examples, they realized it would take much longer. There were simply too many things the product team hadn’t known about.

The product team had lots of ideas, but ideas take time to implement. Now that they had more examples, they could make better decisions about what was mandatory and what would be great but was not essential. Working in this way allows us to be more agile.

The particular aspect of BDD that helps here is discovery with example mapping. I like to use user story mapping to see different versions of the same feature to understand the value brought by the feature’s different potential iterations.

Whenever Possible, Push Live Code

I’ve transformed the way my team works to help them to release more often. The key is to add a continuous integration server with the first automated test and a staging environment where the code is deployed many times per day. This allows us to automate the process from the code, so when a developer pushes the code, we have the beginning of a safety net. When the safety net says everything is okay, deployment is triggered to a staging production environment. The production can be a staging production, but it’s better when it’s live. When it’s not possible to deploy directly in production, then you should at least deploy in a staging environment.

From the developer’s point of view, when they push the code, there’s an impact on production, even if it’s just within a staging production environment. For the next step, they need to create the first unit test each time they have to add code. In other words, every time you write code, you need to have an automated test at the same time. These tests should be run by the continuous integration server.

Once you have that, the next question is about the size of the code you push. If you wait a few days to push or use another branch, you won’t have the value to see the increment of the code you’ll push.

Developers Should Own Quality

Quality has traditionally been the responsibility of the QA team, but it should be owned by the developers. As a developer, you can’t wait for someone else to read your code and tell you it’s okay and then talk to the QA team to make sure you didn’t introduce a bug. If more unit tests are needed, you should write them and you should be using test-driven development (TDD) and BDD. You also need a lot of feedback. You need to be the owner of quality, and help your team achieve it.

To summarize, here are my top three tips:
- Automate the process of deployment with continuous integration/continuous delivery
- Create examples with all the stakeholders of the project together—product, development and testers
- Create small stories that you can deliver in less than three days
August 12, 2021
Behavior Driven Development

September 21, 2020
Quality Engineering Has DevOps and Agile in the Driving Seat
As opposed to the traditional software development lifecycle (aka waterfall), today’s Agile and DevOps-based software development process is more outcome-oriented. The unrelenting pace of the changing market landscape has made the hybrid, Agile plus DevOps way of software development absolutely critical in addressing customer demands and staying competitive.

The focus on Agile and DevOps is necessary due to the high failure rates of traditional software development methodologies. These failure rates are mainly attributed to the glitch-infested, low-quality applications churned out by following legacy methodologies.

The failure rates had left many companies to bite the dust and brought the key role played by quality in ensuring customer satisfaction and ROI for the business into sharp focus. Also, the IT landscape is witnessing developments such as mergers and acquisitions, increased focus on risk and compliance, data and analytics, the fast rollout of apps and mobile commerce, among others. These have necessitated the software development process to become increasingly agile, streamlined, collaborative and flexible. The reshaping of customer expectations is letting organizations to go beyond shift-left testing or DevOps testing by transforming the QA process into one driven by quality engineering.

What Is Quality Engineering?

To meet the growing demand for quality software applications in double quick time, a mere tweaking of the software development process is not enough. What is needed is the adoption of software quality engineering process comprising optimal quality assurance, predictive analytics and monitoring of QA elements to reduce glitches to negligible levels. The process would involve a continuous cycle of feedback and quality improvement based on the same. The quality engineering process offers maximum test coverage in the shift-left scheme of things and ensures outcomes like functionality, security, accessibility, usability, performance and reliability of the software application. It complements Agile and DevOps methodologies and ensures their outcomes to remain consistent with the desired business objectives. Quality engineering, instead of identifying the inherent glitches in the SDLC, focuses more on preventing them altogether.

Shift Left and Strengthen Right

Quality engineering services cover the entire spectrum of the SDLC thereby yielding the maximum test coverage and delivering the best quality product. With DevOps testing shifting left, the quality determinants are incorporated right into the product build during the development phase. At the same time, DevOps-based QA focuses on the shift-right approach to ensure the last stage of the SDLC i.e., delivery goes on unhindered and customer feedback is taken in right way and worked upon. The ultimate aim of both shift-left and right is to create and deliver a glitch-free product that meets the requirements of the end-users. Here, since end-users are the ones who ultimately assess quality of a software product based on parameters such as usability, functionality and performance, among others, the feedback mechanism should be responsive enough to understand the issues faced by the end-users and remedy them at the earliest.

Quality Engineering as an Aid

Quality engineering (QE) helps to bridge the gap between development and deployment processes, which can arise due to the lack of agility. It harps on the successful strategy of “test early, test often,” to pre-empt challenges that businesses face when testing a software product. Quality engineering ensures the quality of a software application throughout the SDLC–right from the designing stage to its final delivery. QE can be incorporated into the development process by using methods such as Behavior-Driven Development (BDD), Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) respectively.

Let’s find out what these methods are all about:
- BDD: In this software development method, the behavior of both the software and business outcomes are taken into consideration. Here, the right sets of tests are automated, leading to an increased collaboration among developers, testers and other business stakeholders.
- TDD: In this software development process, the QA team writes unit level tests before the development stage. This results in getting an early feedback and helps the development team to refactor its requisites.
- ATDD: This software development process focuses on writing an acceptance test even before the development phase. This helps the software to meet the acceptance criteria beforehand.
Quality Engineering and DevOps

QE, being an end-to-end testing methodology, can offer optimum solutions to businesses struggling with their legacy IT infrastructure. The solutions in terms of continuous testing and integration as mandated by DevOps, can be arrived at by integrating the QA process with the DevOps pipeline. This results in executing processes such as build, test, deploy and deliver in a seamless manner. QE complements DevOps and Agile by detecting glitches right at the beginning of the development process.

Moreover, QE’s focus on end-to-end testing helps the product to be developed and tested simultaneously. This approach adds teeth to the DevOps’s requirement for continuous integration (CI) and continuous delivery (CD). No wonder, the successful implementation of quality engineering is underpinned on fulfilling the requirements of DevOps and Agile. It further consolidates the benefits achieved from implementing DevOps testing services and Agile testing services.

QE riding on DevOps and Agile can help businesses to scale up their operations without investing much resources and time. By implementing DevOps test automation and Agile test automation using a test automation software such as Selenium, Robitium etc., businesses can boost their SDLC. QE can help businesses to develop and deploy glitch-free software speedily and deliver enhanced customer experience.

Conclusion

The fast-changing competitive business landscape of today requires organizations to streamline their operations, increase productivity and fast forward the delivery of glitch-free software applications. To achieve these objectives, they need to make quality engineering as part of their development and testing cycles. However, QE ends up complementing the Agile and DevOps approach by achieving outcomes such as CI and CD. Furthermore, it leads businesses to get high ROI, better productivity, reduced cost of operations and enhanced customer experience.

— Akshaya Choudhary
October 15, 2019
Watch Your Language: Behavior Driven Development

There are two basic design methodologies in the software development world: top down and bottom up. In bottom up, the goal is to piece functionality together to “build up” to the desired result. In top down, the goal is to break the problem into smaller and smaller parts until you have implementable pieces.

Both have strengths, and by correlation, both have weaknesses. Analysis and design phases in pre-agile days were almost ubiquitously top down. They would take business requirements, translate them into functional requirements, then break those down and assign the constituent pieces to developers. As the code was implemented, weaknesses in the design would be exposed, and feedback would go back up to the level of functional requirements—or, in really bad cases, to business requirements—and a mini-iteration would take place to resolve the problems.

When agile came along, this was all too slow a process. To be sure, it was (and is) still used and has produced some of the world’s best software, but an agile team can’t sit idle waiting for a long process of analysis. Kan-Ban and similar tools/processes were introduced to address this issue, making the pieces being designed smaller and thus speeding the process somewhat. But smaller pieces implies bottom up to some extent, and the waters got a bit muddied.

Test driven development (TDD) was designed to make sure the code written met the technical requirement by writing a test for the expected result before the actual code. This was one of the most fruitful things to go into/come out of agile development. While it has flaws—the most significant being the human factor—it does make more thought go into code being written and more rigor come out of code produced. The act of writing the test makes the developer think of ways to solve the problem that satisfy the test. But the source of those requirements still needed to come from some form of process.

Enter behavior driven development (BDD). It’s not really development, though the name is catchy. It would be better named behavioral design for TDD, but that’s a mouthful.

In short, the idea is that business owners and analysts speak in terms of the needs of a given role, while developers speak in terms of functionality or the results of a given test set. This creates a gap that causes misunderstandings. The goal of BDD is to get everyone speaking the same language. It tries to extend the spirit of TDD up the design/analysis stack—”shift it left,” in today’s parlance—so that the tests being developed are a hierarchy stretching from acceptance testing down to unit testing, and everyone is speaking the same language.

En vogue today for the language is Gherkin, a simple requirement specification language that writes requirements and test criteria with (relatively) strictly defined sentences. I say “relatively” because, the language is a bit loose from a unit test perspective. But from role-based specification, it is locking down options to make the environment and test cases clear.

I actually got to thinking about all of this while considering SmartBear’s recent acquisition of HipTest. SmartBear has made an investment in making its tools BDD-compatible, and HipTest is largely a BDD platform. The combination of the two should see some movement in the BDD space that will be interesting. I spoke briefly with SmartBear about the acquisition, and it seems the company really is merging the strengths of the two organizations, so it is worth watching over the next few months.

Thus far, the benefits of BDD that jump out are the ability for everyone to talk about an element of the product in common terminology, while the developer can think “down” to the code required to meet the requirement and the business analyst (or owner) can think “up” to determine how to market this cool new feature.

Tools are out there to generate TDD test classes/cases for a variety of languages—notably from my stable, Python and Java. This might be a huge step in the right direction also. Just the other day I was having a bit of a lighthearted conversation with a peer and said, “Get to the point where you can auto-generate tests at build time for us, so IT managers aren’t stuck deciding which lines of code are/aren’t worth maintaining test code for, and then we’ll talk.” Tools and frameworks such as Cucumber and JBehave actually take steps in that direction, though their approaches are different.

We are not currently using BDD on our in-lab test application (Android/web clients, Spring API server) at work, but will have to consider it moving forward as another bit of DevOps tooling and practice we can experiment with. The tools are there, and the process bridges that sticky part of analysis and design where top down meets functional.

After all, the end goal is giving users what they need. If BDD helps make that process smooth and faster, it is a fit for any DevOps environment.

— Don Macvittie

May 15, 2018