Like my previous blogs about performance and AI tools, I wanted to discuss another area of software testing that covers a specific development aspect. I chose security testing because while performance and functionality are essential, we must ensure our applications are safe for their users. This blog post, “Security Testing: Types, Tools, and Best Practices,” by Oliver Moradov, will outline various aspects of security testing, its importance, and its methodologies.

Oliver’s blog starts by defining security testing, listing its main goals and principles, and providing an index for many other aspects of security testing. It stresses that security testing is a non-functional testing process that determines the resiliency of software from cyber-attacks and data breaches. Non-functional testing focuses on how the system works rather than if it works. The primary goals are identifying assets, threats, vulnerabilities, and risks and performing remediation. 

The blog then discusses the types of security testing, including penetration testing, application security testing, API security testing, and vulnerability management. It also covers security test cases, and security testing approaches such as black box, white box, and grey box testing. The blog finishes by discussing best practices in security testing, such as shifting security testing left, testing internal interfaces, and automating tests.  

 I felt the distinction between functional and non-functional testing was important to discuss. Knowing how our data or the company’s data is handled is much more important for security than making sure the software functions correctly. It could function perfectly within the development team’s parameters but still fail to protect the company’s and users assets. 

I found it interesting that black box, white box, and grey box testing are applied differently than how they’re typically used in unit testing. The fundamental uses are the same, limiting and granting information, but there is much more to be gained when using this method in security testing. Testing what a malicious hacker could do with limited or abundant details on the software would be critical to protecting our assets. It also highlights the difference between non-functional and functional because developers use box testing to determine how to make errors occur within the system. In contrast, security tests would use the system functionality itself to create a breach in security. 

The sections detailing what security vulnerabilities they look for were enlightening. The authentication, input validation, and application logic sections highlighted what scenarios the security tests may encounter to validate system safety. I’m glad the blog discussed tools for developers to ensure their code can’t be exploited. Overall, this blog gave plenty of rudimentary information on security testing, and I urge those interested to check it out. In the future, I plan on using the tools and testing techniques to ensure that my code is safe for its users and owners. 

Blog: https://brightsec.com/blog/security-testing/

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

With artificial intelligence increasing computational power and variability in usage, I wondered what advances were being made with AI. The tedious and repetitive aspect of test-driven development can sometimes leave the development process stagnating, so I was interested in how AI is changing the software testing process. This blog post, AI for Unit Testing: Revolutionizing Developer Productivity, by Philip Riecks, expands on how AI is improving the quality of our code and the productivity of our developers. 

The article highlights AI’s revolutionary steps in software testing and development. It discusses tools like IDE plugins that act as digital coding assistants and surveys from GitLab that show a significant increase in AI usage and demand for AI testing solutions. Philip explains the benefits of AI, which include streamlining test creation, boosting developer productivity, reducing developer fatigue, and many more. The article addresses why developers hate unit testing, highlighting the importance of it despite its tedious nature. It then gives an assortment of those tools with a small explanation of their specialization.

I found this article very enlightening, especially regarding the impressive abilities of AI-driven tools. My first thought when thinking of AI is to fear for developers’ jobs or worry about copyright infringement. It is nice to see that the focus of AI tools based on this article is to help developers by removing tedious tasks and allowing them to focus on improving the code. One of the sections mention AI’s ability to use user stories to generate test cases automatically. This was particularly interesting to me because a big part of behavioral-driven development involves using user scenarios when developing tests. Having AI take the workload off those using the BDD method would significantly increase productivity.

While reading, I still worry about the experience of those who use AI. If AI predicts defect areas, creates tests, and assists you every step of the way, how will that affect your ability to do those tasks? I also wonder if it matters if our abilities are lowered if we always have the tool at our disposal anyway. I imagine it would end up the same way we use calculators. We learn and can do calculations, but use the tool for convenience. Overall, I’m cautiously excited about AI, the stress taken off developers’ shoulders, and the increased time they will receive to focus on enhancing their projects.  

In the future, I will endeavor to learn more about AI, focusing on current and upcoming tools. When I use these tools, I will use them as an assistant and not as a crutch. 

The Article:https://www.diffblue.com/resources/ai-for-unit-testing-revolutionizing-developer-productivity/

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

JUnit is a popular Java testing framework that makes unit testing, test-driven development, and code writing more efficient for the development team. We discussed JUnit extensively in class. I wanted to discuss an article that provides a comprehensive guide to JUnit so those new to it can understand its fundamentals and importance to software development. This article, JUnit: A Complete Guide, by Shinji Kanaiis, is a valuable resource for beginners to JUnit and those who want a brief refresher. 

The article starts by highlighting the importance of reducing the number of defects early in the development process and how JUnit facilitates that through specific and efficient testing. It explains that JUnit can do this because its testing framework allows developers to write tests that target the functionalities of individual pieces of code. Without summarizing the article completely, I’ll briefly list its talking points. The rest of the article describes several aspects of JUnit, the most important being how it works, the benefits of using JUnit, how to install JUnit, JUnit assertions, and a step-by-step guide on making JUnit projects and tests. 

This article gave me an excellent refresher on what makes Unit Testing and, in turn, JUnit necessary. It is a modular type of testing that does not limit you to testing the entirety of your software but allows you to test individual classes and methods. It enables developers to fine-tune their testing process to find bugs efficiently. I also better understood its effectiveness when combined with test-driven development. Test-driven development focuses on testing first and developing code second. JUnit allows for better test-driven development because developers can efficiently test each case, method, and class until their code functions correctly before moving on to development. The article also talks about the vast resources and tutorials that JUnit has due to its popularity and ease of use. This aspect of JUnit reinforced my choice to write about it because it can be an excellent starting point for those new to Unit testing or software development. The explanation of assertions we discussed in class was enlightening, and there were some assertions that I was unaware of. This article was a great refresher on JUnit’s place in the development cycle and what makes it an excellent resource for software developers. 

I plan to use JUnit in future projects and make my code as modular, adaptable, and bug-free as possible. I will also point those new to JUnit towards this article or other resources so they can better understand how to get started.

The article: https://www.headspin.io/blog/junit-a-complete-guide

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

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.