Our class discussed many code-driven testing methods, including Test Driven Development and Unit Testing. I thought it would be interesting to research what goes into performance testing, which doesn’t need coding to test but is still important to determine if there are any bottlenecks in your code. Many errors in our code go beyond whether it provides the correct output. If our software cannot function quickly and with many users, it doesn’t matter if our code functions if it doesn’t work in practice. The article “Performance testing, best practices, metrics & more” by Tricentis is a comprehensive look into how performance testing works and its role in software development. 

This article mainly provides the fundamentals of performance testing. It discusses why it’s important, the tests involved, what is measured, and a step-by-step process for ensuring your code functions correctly. It also discusses whether coding is necessary, when to conduct performance testing, and clears up performance and load-testing misconceptions. 

Reading the section on why performance testing is important had me finding a parallel to behavior-driven development because both focus on the user’s experience. If BDD provides an understanding of how the user is supposed to interact with the software during development, then performance testing is how users will interact with it when completed. If the users are stuck waiting for their application to load, find that it crashes often, or are unable to access it, then user experience will fall. That negative experience could lower revenue or reputation for the application’s company.

The section describing the testing methods highlighted how many ways you could poke and prod a system until it breaks. When I think of performance testing, I usually think of testing speed and user capacity, so seeing the other methods was enlightening. As I have not dabbled in performance testing, seeing the sequential steps to ensure speed and stability in our code was informative. It is vague enough for those new to performance testing to use it as a guideline. It was also interesting to learn that with agile methodologies at the forefront of software development, companies are looking for automation when doing performance tests to keep up with faster software development.

Overall, this article covered many aspects of performance testing, and those interested in learning would find it helpful. I plan to use performance testing to ensure users have a better experience, expose bottlenecks, and find where my code’s stability is weakest. 

The Article: https://www.tricentis.com/learn/performance-testing

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

In last week’s class, we were tasked with creating an activity related to our course material. Our group decided on behavior-driven development (BDD) since it is related to test-driven development, which we discussed in class. BDD’s approach is user-focused and prioritizes understanding between the development team and users, but it has yet to be discussed in class. Since the post was well-organized and informative, focusing on aspects that could help developers improve their code, I decided to talk about BDD for my blog post this week. 

The blog post “Behavior-driven development principles and practices,” by Philip Rogers outlines the basics of BDD, detailing its history, principles, and practices. Phillip explains that BDD is centered around three principles: what the software could do, what the software should do, and what the software does.

1. What the Software Could Do: This principle involves understanding what the customer wants from the software. They use discovery workshops to outline what the developers should prioritize and resolve any confusion between the users behaviors and the team.
2. What the Software Should Do: This principle focuses on creating documentation in a human and computer readable format. This includes the given-when-then format that describes the user’s behaviors and how the software should respond. 
3. What the Software Does: This principle focuses on using the documentation or scenarios to create automated tests and improving the code until it aligns with the customer’s requirements and the team’s goals.

The blog post also discusses Gherkin, a language used in BDD to bridge the gap between human and computer understanding. The syntax used in Gherkin helps capture user scenarios and articulate how the automated tests should work to align with those scenarios. Philip also explains the benefits of BDD, such as improved collaboration and reduced rework, and the cons, including high level of business engagement and the lack of compatibility with traditional software development. 

After reading this blog post, I better understood the BDD process and why these principles are in place. It highlighted why there would be a need to deviate from or expand test-driven development. There should be a focus on how users interact with the system using communicative language to reduce the creation of faulty features.  

In the future, I plan on being mindful of the user’s experience and creating software with my team to meet the users and, in turn, the team’s expectations. I will also look into a Gherkin and try to understand the syntax better to produce better tests and end products. 

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

In my last post, I highlighted a blog that gives an overview of unit testing and how we can use it to increase the quality and efficiency of our testing or debugging processes. The point of unit testing is to test “units” or isolated methods, classes, or modules of our code to determine if there are any issues. Writing code with unit testing in mind makes it simpler for developers to debug their code. I felt this next blog, “TDD: Writing Testable Code,” by Eric Elliott, would help further readers’ understanding of writing this kind of code and the benefits that come from it.

Elliott’s blog discusses many aspects of writing testable code, including tight coupling, test-driven development, separation of concerns, and an overview of different data management strategies. He describes how tight coupling limits testability and provides strategies to reduce it, including TDD. He also discusses the benefits of testing first vs. testing after, with test-first being the main focus of test-driven development. He goes on to describe data management strategies.

Reading this post brought my attention to an important aspect of software development, which is influencing a specific type of developer culture that improves the quality of our software as a whole. Writing with testability in mind makes it easier for the users, increases the adaptability of our code, and allows us to fix issues without revamping the whole system. 

The breakdown of tight coupling and the different forms they can take was comprehensive, giving me a straightforward explanation of what I should consider when writing code. Elliott gave 11 forms and causes of tight coupling, including parent class dependencies, temporal coupling, and event chains. TDD was something I was already aware of, but the benefits of using and detriments of not using TDD were still insightful for how we should be taking our development step by step, failure by failure until we have testable code. The separations of concerns were interesting. He says we should isolate our code by concerns, including business and state logic, user interface, and I/O & effects. Separating these into separate modules allows us to test and understand each independently. 

I plan to consider all of these strategies when developing projects in the future. I will use test-driven development to limit the tight coupling of my modules, classes, methods, etc., to ensure that my code is readable and testable and that each of its concerns are independent from each other. 

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Unit testing is an important method that hammers out bugs in our code and verifies its behavior. Every line of code is critical to keep our projects functioning, so we must understand the benefits and best practices for unit testing to maintain our code correctly. As the title suggests, this blog post, “Unit Testing | What it is, How it Works, Types & Top Benefits”, lays out the principles of unit testing, the different types, and the benefits for software development.

 Diane Wong’s blog is a concise guide to unit testing and its benefits. It covers the types, techniques, advantages/disadvantages, and best practices of unit testing, giving an overview for newcomers to coding and those well-versed in it. I chose this resource due to its simplistic coverage of many essentials to unit testing. The blog is organized with a table of contents that leads those seeking information on a particular aspect of unit testing. It was a good start for my understanding of unit testing, and those new to the method would benefit from the blog.

I found the information concise and direct when reflecting on the blog post. This isn’t a blog that will delve into specifics on any technique or method of testing but will give you a general overview, which is what I wanted. We discussed many aspects of unit testing in class, including testing techniques like Black Box, White Box, Gray Box, Mocking, and Stubs, so some information was a refresher. The main benefit I got from this blog is a better understanding of the advantages unit testing brings, best practices, and why we use it. It lowers overall costs, allows for automation, makes debugging more manageable, and increases the team’s efficiency. The best practices were short but something to remember when conducting unit testing, like focusing on one module at a time or using conventional naming practices. The blog recommended unit testing tools besides JUnit, like Jasmine, TestNG, PHPUnit, and Mocha, which I may look into if they have better features than JUnit. Overall, the blog filled in gaps in my knowledge, and it was something I could quickly go back to or recommend to people new to the concept.

 I intend to use that knowledge for future software development projects and teach those who are unaware so we can effectively build and debug our code. Before using unit testing in practice, developers must understand the fundamentals, best practices, and advantages so they can develop good habits from the beginning. 

Link to the blog: https://testsigma.com/blog/unit-testing/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Earlier in the semester, we discussed licenses and copyright in regards to our code and documentation. I’ve wanted to write a post on licenses, but finding a post that did more than describe the definitions and uses of licenses was difficult. Luckily, I have found a blog that describes software license management, the best practices, and some drawbacks when managing licenses. From those sections, I want to highlight the parts that felt the most important. The blog is called, “Seven Best Practices for Managing Software Licenses” by Ibrahim Ogunbiyi, a data scientist and IT support specialist.

The post starts off with defining software license management as the process of controlling, tracking, auditing, and managing the use of software in an organization. They highlight the importance of using SLM in many ways, but the one that stood out to me was to ensure the software is secure and has no malicious code. If there is no liability in the rights listed by the license or the lack of one, I can imagine how it would be important to sift through each one to ensure the code is safe to use. Another one that felt important was keeping track of software due dates. Having your team or company rely on access to software only to have it pulled from you could be expensive and time wasting. If you fail to stop after your access is revoked, you could be held liable and sued.

The potential setbacks of SLM were the cost, complexity, and compliance risk. In an organization or large company dealing with a myriad of different license types and potentially using them in combination with each other, I can see how those issues could come up.

The best practices discussed in the post that I found most important were documentation and training. Any issues that arise when dealing with license issues would be incredibly hard to fix if you cannot find relevant information. Keep track of everything, within reason. I have worked in a company that had one person in our location who was fully trained to use the company’s software. She was berated with questions about how it worked without every employee getting a full understanding of the system. She was the linchpin. After she left, so many things fell through the cracks and I can only imagine how detrimental that could be when dealing with licenses. Making sure everyone is on the same page with a full understanding of how licenses work will save companies a lot of time and money.

After reading this post, I felt like this would be especially helpful for people starting their own company. Understanding the complexities and importance of software development can only help in the future. Although I do not feel like I will be making decisions on implementing a software management system anytime soon, I will still keep what I learned in mind when dealing with licenses.

The blog post: https://www.wrangle.io/post/seven-best-practices-for-managing-software-licenses

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Recently our class discussed inclusive language and delved into tools that are able to root out non-inclusive language. I tried to find an article or blog that gives a set of examples to watch out for. I found a blog post that gives guidelines, examples of non-inclusive language, and provides examples of how companies are adapting to make their language more inclusive. The blog post is called, “Inclusive Language in Technology” by Barathy Rangarajan, DreamWorks Animation.

            The blog post starts with giving a definition of inclusive language. It highlights the difficulty in changing language across repositories and identifying what is seen as non-inclusive language. Before diving into those offensive terms, they give four guidelines when writing code or documentation. These guidelines were: avoid using terms that have social history, avoid using idioms and jargons, write inclusive examples, and if you’re unsure, ask. I personally liked the inclusion of idioms and jargon being something to watch out for and how important it is to ask if you are unsure. Usually, idioms and jargon are just ingrained in the language we use based on where we are. Being aware of that when writing code or documentation for people who may not understand felt important. Understanding that these terms can be tricky to identify as non-inclusive, it’s important to ask those who might know more.

The post then gives a set of terms deemed non-inclusive, organized by different categories. These categories were, socially charged, gendered, ableist, ageist, and violent language.  I won’t get into detail about each, but I recommend you take a look to familiarize yourself with the terms and alternatives. There were some terms I was not aware of.  

The final portion of the article is the how companies have made changes to be more inclusive. They described how Autodesk, DreamWorks, and Sony pictures are addressing non-inclusive language. Some involve hiring based off race and gender, promoting resource groups, and setting a baseline initiative to produce inclusive code in the future and update older code. In one of my previous posts, I talked about setting ground rules that the team can agree on when conducting ourselves during development and discussions. I feel this is also relevant when it comes to inclusive language.

The blog post shed some light on the best practices and popular terms used when addressing inclusive language. In the future I will strive to be self-aware about how I write, ask question when I don’t know, and use what I’ve learned in day-to-day interactions along with writing code.

Link to the blog: https://www.aswf.io/blog/inclusive-language/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Similar to my last blog, I wanted to focus on how to implement certain aspects of Scrum in an effective way. While exploring articles related to sprint planning, I came across a crucial aspect not covered in our class, technical debt. The article “How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work” by Cate Lawrence, provides strategies for making sprint planning less overwhelming while also highlighting the importance of preventative measures for technical debt. In this blog, I will focus on the technical debt portion of the article. Technical debt is a term used to describe future complications, that are time and resource intensive, that arise from expediting development instead of properly completing the product. It is the tradeoff between immediate gains versus long term consequences.

The article provides three steps for incorporating technical debt into sprint planning. The steps are:

• Make technical debt visible

Recognizing potential issues and highlighting them for the team is important. Letting those issues accrue and not addressing them seemed like the opposite of the Scrum values. You should be adapting to unexpected issues or requests, not planning to have issues in the future.

• Determine the business impact of each debt item

I could see how it may be enticing to take shortcuts during a Sprint. Convincing the team or management to not take these shortcuts and to tackle these issues will only help development, but it may be hard to do. Instead of focusing on all the technical issues in front of them, highlighting how the debt will come calling in the future felt like the appropriate response.

•  Bring it to your sprint planning meeting

After visualizing the issues and showing why it would be best to deal with them now, including them in the next sprint plan is the final step.

Though not the main point of the article, it highlighted that technical debt was a neglected topic in sprint planning. I chose this article due to the steps, but also because it felt like something everyone should add to their Definition of Done. Even if everything “works” correctly with the code, knowing that there could be further problems due to the expedited nature of the sprint, the code should not be seen as done. It should not be ignored and should be addressed immediately or in the next sprint. Hopefully, these steps and the discussion on technical debt in the article will be helpful. In the future, I will try to address these types of issues using the steps, but also incorporate this into the team’s Definition of Done.

Link to the Article: https://stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

During our classes we discussed the definition, theory, values, team makeup, events, and artifacts of Scrum. I decided to focus on one of the events of Scrum within the Sprint called the Daily Scrum. The Daily Scrum was briefly described and we discussed how the Daily Scrum allows the team to inspect progress toward the Sprint Goal and to adapt the workload as necessary. What we didn’t do was discuss the best way to go about that. I wanted to understand the best practices for proper communication with team members in accordance with Scrum values. The blog “Ten Tips for More Effective Daily Scrums” by Mike Cohn helped with this by giving 10 helpful tips for how to conduct a Daily Scrum. Cohn specializes in agile processes and techniques and makes a living by helping companies build high performance teams.

After reading the tips, I could see that most of the points were prioritizing focus, one of the main values of Scrum. Most of the tips give solutions or show problems that arise that stop the Daily Scrum from focusing on the Sprint Goal. The problems it shows are what I assume to be problems that happen repeatedly for people new to Daily Scrums. They don’t talk about the current Sprint, talk about work done unrelated to the Sprint Goal, focus on unrelated details, and ramble. I liked how the author handled the issues. He pushes the idea that you should set ground rules or guidelines that everyone understands before conducting the Scrum. Having words or phrases that let the team know you might be rambling or for letting a person quickly explain that non-Sprint Goal work was done seemed like a very good way to professionally conduct a meeting. I would think it’s hard to tell someone that they are rambling more than they need to. To have a buzzer or code word established must help communication without hard feelings and allows everyone to be on the same page.

 I also appreciated prioritizing the use of certain words. Saying “impediments” instead of “blockers” or asking about what a person “accomplished” instead of what they “did”. I wouldn’t normally think to prioritize certain words while conducting a meeting, but his explanation on how it changes the team’s perspective on the work during the Sprint was enlightening.

This blog showed me that when communicating with your group, whether in a daily Scrum or not, there are simple ways to optimize communication. The tips given weren’t groundbreaking, but I can see various ways this could be used when communicating with others. Going forward, I plan on setting an outline of ground rules that the team agrees on so we can effectively communicate.

Link to “Ten Tips for More Effective Daily Scrums” by Mike Cohn – https://www.mountaingoatsoftware.com/blog/ten-tips-for-more-effective-daily-scrums#author

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.