Newsletter Subject

Software Quality and Developer Experience: Why testers should care about it

From

ministryoftesting.com

Email Address

hello@ministryoftesting.com

Sent On

Wed, Jul 17, 2024 10:59 AM

Email Preheader Text

Understand how improving the developer experience can easily and efficiently contribute to creating

Understand how improving the developer experience can easily and efficiently contribute to creating high-quality software [View this email in your browser]( [An image of one of our mascots holding a browser in their hands with stars on each side of them.]( by Fernando Teixeira | [Read online at Ministry of Testing]( What is Developer Experience? Developer experience, also known as DX, is a quite trending topic in the IT industry right now. However, it is not something new. The first mentions are from the early 2010s and it has gained more attention in the software development community over the last few years. Developer experience is related to how easy or difficult it is for a developer to perform essential tasks needed during the development process. A positive developer experience means that these tasks are relatively easy for the team to execute because we have the proper systems, technology, processes, and culture to support the development process. In short, a good DX is important because it enables developers to build with more confidence, drive greater impact, and have improved productivity with less effort. When we say “developer” here, but that includes any engineer involved in the development process, including Quality Assurance (QA) engineers and software testers working with software quality and any other tech-related role also part of the same process. Some companies have entire departments responsible for finding ways to improve the developer experience. Big Tech companies like Spotify have even built dedicated tools to help improve their internal developer experience, like [Backstage]( which helps create developer portals to centralize all the engineering organization's tools, resources, and documentation. This article will also show how those improvements in developer experience are directly connected to software quality, which is another reason why it could be a topic of interest for QAs and testers. 👋 TestBash is our annual conference happening in September in Brighton, UK. As we like to say, our network is your network, we'd love for you to join us. We will have 2 days of learning and community as testing professionals share what they know about testing, AI and more! [Explore the TestBash Experience]( Examples of Developer experience To better illustrate what it is, here are some practical examples of good development experience practices: Automated tests that can verify the correctness of introduced changes Developers can easily run different levels of existing automated tests (unit, integration, E2E, etc.) to validate the functionality and reliability of the introduced changes. When a pull request is opened, the automated tests configured in CI/CD are automatically triggered to validate the correctness of the application's behaviour and ensure that it is safe to merge and deploy the changes. The tests are executed in a short period of time, so then the developers have a short feedback loop. Make new deployments in an easy, safe, and fast fashion Continuous deployment practices have a proven relationship with better developer experience. [The DevOps Research and Assessment (DORA)]( studies have shown that teams that ship consistently are more motivated, ship higher-quality code, have less deployment pain and burnout, with higher levels of job satisfaction. Shorter developer wait times and no interruptions Developers are not forced to stop their workflow due to long-running local builds, test runs, or pipelines. Also, they have time to concentrate on their work without the interruption of multiple meetings during their working day. Assertive application monitoring Developers quickly get alerts when something goes wrong in the application and have aggregated logs that help them to detect the root cause of issues. This helps them save time that would have otherwise been spent investigating the problem, allowing them to take immediate corrective action. Easy rollback and incident recovery process in place There is an automated rollback process in place where developers can easily revert changes introduced into the production environment to remediate any error or incident. Easy to find documentation and getting-started guides Developers can easily find answers in a centralized place to set up and run a project, such as, "What are the technology requirements?" and “How is the deployment process of this application?” How is DX related to Software Quality? The Quality Assurance process aims to help teams produce high-quality products with as few bugs as possible, that provide value to the end-user or customer. That's a challenging goal, and it will require completing several tasks to achieve it. But have you ever considered how bugs and poor-quality software are created? We could try to list some reasons, including: - There are no tests to validate software behaviour - Bad software specification with no clear descriptions - Long time to deploy and validate changes resulting from slow / flaky pipelines - Long feedback loop to find out if the introduced changes have any problems or break any tests - No code review practices in place - No software observability to monitor the application after deployment and detect downtimes and other issues - Developers spend so much time on the problems mentioned above and need to deliver new features in a hurry without the proper quality and tests Now, I can ask you: What do all those things have in common? The answer is that they are all related to the developer experience. They can directly impact how the whole team develops and delivers the software. With good DX processes in place, the development team will spend less time waiting for pipelines, looking for information that no one knows where to find, and analyzing false-positive results from the test executions. Instead, they will focus on what really matters: delivering high-quality software and value to your end customer. Once you understand it, you can think of smarter ways to prevent defects and contribute to the quality of the product software by helping your team have a better development experience. The QA role is constantly evolving, and that could be an important new topic that QA engineers should start to learn about. How can I start to improve the DX of my team? Many things can be done to start improving your team's DX. In some situations, it can be very complicated since some improvements can require changes in the whole company, for example, having a culture more centred on documentation and knowledge sharing with peers to make easier access to information. The first step is to evaluate where your team currently stands. Does your team consider itself to have had a good development experience? Do developers feel constantly blocked or unhappy with the current working circumstances? What are the main things affecting your team's DX at the moment? After this analysis, your team can start prioritizing what is more relevant to be solved first and then start improving step by step. You can periodically reassess the progress and how the improvements are impacting your team. You can even use metrics to analyze how the DX improvements are directly helping your team improve quantitatively. Regarding the metrics, you can use internal surveys to rate the development experience for the whole team and DORA metrics to demonstrate how the development and delivery process is impacted by the development experience improvements. Developer experience and quality experience. Two sides of the same coin? Developer experience covers the quality experience aspects of software development so can be seen as two sides of the same coin. Areas like productivity, collaboration, processes, culture, etc. can be equated to both terms. It is difficult to simply break down some practices that are only developer experience, since many of them contribute to more than one point from the areas mentioned above. From my point of view, Testers are / should be part of the software development process as much as any other professional, like developers, DevOps engineers, Product Owner’s, etc. That's why for me, developer experience should not be treated as something just for developers and quality experience should not just be something for Testers. It is just like software quality that some years ago was seen as a topic for only testers and later, we (testers) tried to bring back this topic for the whole team as a quality culture to share the responsibility with the whole team. If we start to define quality experience as something only for testers, later on, we can go through the same problem and see that what is really beneficial is to have something shared by the whole team, like the developer experience. Conclusion Improving the developer experience is essential and requires contributions from many individuals with diverse skill sets. Many companies are heavily investing in it since they have already noticed the big benefits and improvements it can bring to their organizations. As this article discussed, good development experience can directly contribute to an efficient process of creating high-quality software, which is why it can also be a topic of interest for QA professionals. In the end, you can find smarter ways to improve software quality by simply understanding what contributes to creating better and more reliable software. Some improvements can take effort and time to implement, but you don't need to do it alone. Like software quality should be a whole team's responsibility, investing in ways to improve the developer experience can also be something you can work on together with your whole team. "I found a community in the Ministry of Testing, a form of belonging which helped me grow personally and in my career." — Kim Knup [Upgrade your software testing career with Ministry of Testing]( [Website]( [LinkedIn]( [YouTube]( [Twitter]( [Instagram]( Copyright © 2024 Ministry of Testing, All rights reserved. You have opted to join this email list. Our mailing address is: Ministry of Testing 19 New RoadBrighton, East Sussex BN1 1UF United Kingdom [Add us to your address book]( Want to change how you receive these emails? You can [update your preferences]( or [unsubscribe from this list](.

Marketing emails from ministryoftesting.com

View More
Sent On

25/09/2024

Sent On

23/09/2024

Sent On

19/09/2024

Sent On

18/09/2024

Sent On

10/09/2024

Sent On

09/09/2024

Email Content Statistics

Subscribe Now

Subject Line Length

Data shows that subject lines with 6 to 10 words generated 21 percent higher open rate.

Subscribe Now

Average in this category

Subscribe Now

Number of Words

The more words in the content, the more time the user will need to spend reading. Get straight to the point with catchy short phrases and interesting photos and graphics.

Subscribe Now

Average in this category

Subscribe Now

Number of Images

More images or large images might cause the email to load slower. Aim for a balance of words and images.

Subscribe Now

Average in this category

Subscribe Now

Time to Read

Longer reading time requires more attention and patience from users. Aim for short phrases and catchy keywords.

Subscribe Now

Average in this category

Subscribe Now

Predicted open rate

Subscribe Now

Spam Score

Spam score is determined by a large number of checks performed on the content of the email. For the best delivery results, it is advised to lower your spam score as much as possible.

Subscribe Now

Flesch reading score

Flesch reading score measures how complex a text is. The lower the score, the more difficult the text is to read. The Flesch readability score uses the average length of your sentences (measured by the number of words) and the average number of syllables per word in an equation to calculate the reading ease. Text with a very high Flesch reading ease score (about 100) is straightforward and easy to read, with short sentences and no words of more than two syllables. Usually, a reading ease score of 60-70 is considered acceptable/normal for web copy.

Subscribe Now

Technologies

What powers this email? Every email we receive is parsed to determine the sending ESP and any additional email technologies used.

Subscribe Now

Email Size (not include images)

Font Used

No. Font Name
Subscribe Now

Copyright © 2019–2024 SimilarMail.