For this weeks’ log entry, I wanted to cover a topic that relates to the class but was not covered. I wanted to conduct some research of my own in regards to how AI is changing the ways in which people are testing code, as well as some of the new testing methods that are being used thanks to implementation of AI. When researching this topic, I came across a podcast titled, “The Role Of AI In Software Testing” by Test & Code on spotify. I also specifically chose this podcast because of both its popularity, as well as because of its recency, given that it was posted just over one week ago.

Over the past few years, AI has exploded in its popularity. Not only is AI able to process basic information with relatively high accuracy, but it is able to do so in such a manner as to allow that information to be processed automatically. One thing that AI is now being used to do within a software testing space is generate tests. In general, many people entering the software testing field or programming in general, do not have a very high level of comfort or practice with writing tests. AI in this case is beginning to be implemented to fill the gaps in knowledge that people have (writing tests in this case), allowing people to theoretically make more progress while working for the same amount of time with less debugging needed. AI technology has even developed far enough to the point where people are using it to completely replace the rest of their role in writing most coding and testing projects. At a point not too long ago, people were using AI to help write tests and code to meet a specification, but now things are much different. People are easily able to use AI to generate not only a specification for itself to write code for, but also write competent code to fulfill that specification that it gave itself, while also writing and running tests for it. AI has become scary good when it comes to being competent at writing almost all kinds of tests and code. For now, the code it writes is just competent. It is able to complete a task but often not in ways that we, as humans, would think to be a logical solution to the specification given, and also often not in the way that we intend. One way that AI is being quickly incorporated into the workplace is through tools and writing or describing how to write certain things for programmers or testers that may not have an expertises in a certain aspect of the job and need assistance with getting started. For those who are more informed in the field, looking at AI responses to questions that people are asking or answers generated, such as how to perform certain tasks, can be jarring and often return responses that are more than unsatisfactory, but in a weird way, when the person who is using the AI is also the person who is uninformed on how to compete a task, the only thing shown is satisfactory by the person who finished their testing earlier than they expected. 

From the blog CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

For this weeks’ log entry, I wanted to cover a topic that was a bit different from the post that I made last week. One topic that caught my eye as being a perfect option to learn more about was Behavior Driven, and potentially also Test-Driven, development of code. When researching this topic, I came across a podcast titled, “Behavior-Driven vs Test-Driven Development & Using Regex in Python” by The Real Python Podcast on spotify. One of the largest factors that drew me to choosing this podcast to learn from was the fact that it was made incredibly recently (only a few months ago).

TEST-DRIVEN DEVELOPMENT:

A process of developing code that revolves around writing automated tests for code before ever actually writing the code itself. The process starts with a programmer writing a test for some sort of new feature that they want added to their code or that they want their code to be able to solve. After this, they write the smallest amount of code that they possibly can in order for that test to pass, potentially refactoring after the test is passed if they feel a need to do so. TDD originated before and was used to heavily inspire the agile process and scrum methodology that we see used today. TDD can be a helpful process to follow for several reasons. First, it ensures that you have actually written good tests and helps to mitigate any sort of temptation to cut corners when working on a project. TDD also helps teams to work specifically within the realm of what is being asked of them, rather than “gold-plating” their work and adding other features to their code that may not have been asked of them. Overall, TDD is very structured and easily provides a path for workflow to follow without confusion.  

BEHAVIOR-DRIVEN DEVELOPMENT:

BDD for short, in a way it is an extension of TDD, only focusing on the highest levels of the testing pyramid and involves Acceptance Test Driven Development. Essentially, before you ever write the function that you would use to test in TDD, you first write tests about how you think the application is actually supposed to behave. It focuses on a feature behaving in a particular way as opposed to that same feature returning a particular response. First, you would identify things that your code would need to create some sort of list that can be used to define what needs to be done or whether or not that feature is properly working. After identifying the need, you would write high level tests to check this. Same as in TDD, you would essentially be writing the code in parts, running tests in between to ensure that the code being written is being done so with an immediate purpose and goal to achieve within the project.

From the blog CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Recently, I have been learning a lot about testing code, specifically methods such as static and dynamic testing of code. For this blog post, I wanted to research deeper into static and dynamic testing methods, as well as their applications, especially given my limited experience with using them up until now. As for researching this topic, I came across a well made podcast titled, “Static Testing vs Dynamic Testing: What is the Difference?” by CTSS Academy on spotify. I found this podcast to be a perfect choice to aid in my research for the software quality assurance and testing course I am taking this semester, especially because of the speakers prior experience in a very relevant workplace that focused on software testing, and the manner in which they address their video to an intended audience of prospect software testers. 

STATIC TESTING: 

This involves looking at software without ever running it in the first place, much like looking at a blueprint. Static testing has a heavy emphasis on preventing bugs from existing in the first place, much like proofreading instructions that you have been given before investing time and resources into the task that would be unrecoverable. Initial requirement documents are involved here, as well as all other outlines for how the project will go about being constructed in the first place. Source code can also be included here, as well as test cases and scripts needed to run when testing the software, really anything generated when developing the software, except running the code itself. The most basic form of static review could be considered “informal review” or something as simple as a coworker looking over another co-worker’s code and giving feedback. Technical review is more formal and is essentially a peer-review of the technical procedures or specifications taken. Static testing also includes “walkthroughs” or presentations of a project to peers, including step-by-step processes taken when creating the project. Static code review or white-box testing itself could include specifically looking at the code written and making sure that it follows the proper syntax of whatever language it is written in, as well as looking for any obvious security flaws.

DYNAMIC TESTING:

This involves executing a software or code and understanding how it processes information and behaves. Dynamic testing is all about executing code and tracking how it behaves and responds to certain situations, more specifically whether it is performing efficiently as it should, while also using the proper amount of data it should be. If static testing refers to whether or not we are building something the right way, dynamic testing refers to whether or not we are building the right thing. Unit testing is a basic place to start with dynamic testing, as it encompasses individual units of code apart from one another, using unit tests to make sure that one job of that part of the code is functioning properly. Integration testing is one step more complex than unit testing, involving multiple unit tests and the manners in which they interact with each other. System testing refers to testing the entire system of code and how it functions as a single machine, assessing whether it meets all criteria established. Security testing, performance testing, or any other form of testing that would require running the software to figure out are all considered to be dynamic testing as well.

From the blog CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

A few weeks ago, I learned about the necessity of publishing code under a license and now that I have had the chance to implement proper licensing into assignments that I have been tasked with, I wanted to take a second and closer look at the positives and negatives associated with publishing software as “Open Source” as opposed to under commercial licensing. Before writing this blog post, I did some research and came across a blog titled, “Open Source vs. Commercial Software License: What Do You Need?” by Frank Amissah, which does a good job comparing and differentiating open-source licensing from commercial licensing. 

OPEN SOURCE:

Open source code is source code that has been made available to the public for free, allowing for anyone to read, share, or modify it. Open software licensing is divided into two categories, these being “Permissive” and “Copyleft”. Permissive licensing is less restrictive, allowing people to do as they please with the code, often only requiring the original author to be credited. Copyleft licensing is more restrictive, requiring future redistribution of code under a copyleft license to also abide by the terms of the originally implemented copyleft license. Open source code is easily accessible and adaptable by a community. The ease of acquiring the code also allows for a large scale of quality improvements and innovation provided by the community to be officially implemented. This, however, comes as a downside being that there is very limited funding for the future development of the code and if its users lose interest, it will ultimately be abandoned entirely.

COMMERCIAL LICENSING:

Commercial licensed software is usually proprietary and is distributed with the intent of its developer making a profit. The terms of use of the software is identified directly by the developer, but in general, licenses for their use will exist in the forms of subscription services or one-time payments, either for one user or an entire team of users. Benefits of using a commercial license include establishing direct ownership of the software for its users, as well as constant funding for improvements through the purchasing of copies of the software. On the other hand, commercial licenses often cost a lot of money to their customers, have longer development cycles for implementing changes, and suffer highly from piracy of the software. 

This blog post effectively compared the similarities and differences of both open source and commercial licensed software, even going so far as to teach me that the choice for which license to implement will come down to the goals of the project, as well as its intended audience and cost of operation. It was also formatted in a very user-friendly way, using well-organized diagrams to prove its point. Going forward, I feel that I will be more inclined to take my time weighing my choices when it comes to choosing the right license for my projects, especially now that I have been made aware of the difference one can make.

Blog Referenced: Open Source vs. Commercial Software License: What Do You Need? | Turing 

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Recently, I have been made aware of a “Alex” linter, which is capable of analyzing the words used in a program and identifying ones that may be offensive or used in a harmful context. This got me interested in looking further into what other forms of software are being used to perform similar actions and where. 

In order to learn more on the topic, I have read a blog titled, “Microsoft claims its new tools make language models safer to use” by Kyle Wiggers. This article goes in depth about how Microsoft has been developing open-source tools to audit AI generated content and automatically test them for potential bugs, especially in a content moderation context, where “toxic speech” may be used. Microsoft has focused their efforts on two projects for this cause.

ToxiGen is a dataset that contains 274,000 examples of statements that may be considered “toxic” or “neutral”, acting as a massive hate speech dataset and functioning in a similar but much greater scale of what the “Alex” linter does. ToxiGen is being used by researchers on LLMs similar to ChatGPT to generate statements that are likely to be misidentified and aid in finding potential weaknesses in these generative tools. 

AdaTest is the second program Microsoft is focusing on developing and should help address larger issues with AI language modules. It functionally generates a large number of tests, steered by human guidance, and organizes them into similar groupings. It is run with the goal of adding diversity to test cases and enhancing the reliability of LLMs. 

From my perspective, generative AI does not possess cognitive function in a comparable manner to that of a human and until it does, AI will forever struggle at identifying speech that may be acceptable in one context or culture but viewed as very offensive in a separate culture or environment. I also believe that because these newly developed programs are being made in the same way that the “Alex” linter is (that being through someone providing a list of key words or phrases to be cross referenced) and is not able to generate its own list of potentially harmful or “toxic” terms without human oversight, the most these programs will likely be able to do is provide quality standards for LLMs through testing. 

Through my research, I became aware of programs being developed by Microsoft to help detect harmful speech in a similar way that the “Alex” linter does (that being through cross referencing with a dataset). I also became aware of the many forms of biases that exist even in generative AI as a result of information provided by biased human input. Moving forward, I plan on being more careful with the phrasings I give or artificially generated when working on projects. Given that AdaTest is an open-source software as well, I am interested in using it in the future to test for bias and offensive speech wherever I use generative AI.

Blog Referenced: Microsoft claims its new tools make language models safer to use | TechCrunch

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Not too long ago, I learned about the “Agile” methodology for the first time. I learned all about how following “Agile” allows for code that is always functional and that can be built off of in a much more proactive way than that of code produced through the waterfall approach. What I did not learn as much about, however, is the impact that following an agile methodology has on the customers, the vendors, and the project manners, as many of the lessons I took part in were developer-focused.  

In order to learn more about the impact of the Agile methodology project members, other than developers, I did some research and came across a blog post titled: “8 Benefits of the Agile Methodology” by Erin Aldridge. This blog post takes the approach of describing the benefits of using an agile process through the perspectives of people who would otherwise not be working directly with the code. 

CUSTOMER BENEFITS:

The article identifies the way in which incremental delivery of a project often results in higher levels of customer satisfaction, as well as provides greater customer involvement and input on what they are looking to receive as a final product. This higher level of customer satisfaction is also paired with a higher return on investment for the customer.

VENDOR BENEFITS:

From the perspective of a vendor, it becomes much easier to ensure a high-quality product, or a product that satisfies the customer when a new increment of the product is available at the end of each sprint. Increased level of transparency on the progress being made on any given project also allows for a vendor to more effectively work with a small-sized team and communicate in meaningful ways with the customer. 

PROJECT MANAGER:

While working with “Agile”, developers are able to get right to working on a project, cutting out much of the uncertainty that may be created as a project manager attempts to figure out all the parameters for the project. Project managers are also able to better select tasks to be prioritized first, and will find it much easier to keep track of project progress through the points emphasized during each daily scrum meeting. 

From what I have discovered, using “Agile” seems to be better for every member of the development process compared to other methods like the “Waterfall” process. I have also learned through this research that implementation of the agile methodology is more simple than often thought and improves nearly every aspect of the work process (as mentioned through points above). To add to this, I also now have a better understanding of the role everyone plays as described by someone who actively uses “Agile” in a real workspace. In fact, I now believe that the agile process is easy enough to implement that I will very likely recommend its use in future projects that I take part in. 

Blog Referenced: 8 Benefits of the Agile Methodology – Project Management Academy Resources

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

In many of the previous classes that I have taken throughout my college process, I have been tasked with writing code. However, in nearly all of the assignments I have received so far, instructions only require the code to be working or at most want there to be comments to go along with said code. After reflecting on this fact, I began to think more about how there must be some sort of standards for writing code; some sort of quality control when it came to preparing code for use in a professional environment. This is where the practices of writing “clean code” come in.

Recently, I have read a blog post called: “Writing clean code: best practices and tips for developers” by René Cadenas, in which the author went on to outline several key points to follow when improving the readability and cleanliness of code. I chose to read this article in order to develop a better understanding of the topic covered in class, as well as to create a better understanding of how I can implement the use of clean code practices in future workspaces.  “Clean code” is defined here as “code that is not only functional but also easy to read, understand, and maintain”. The author also wrote about why clean code matters, claiming that it leads to improved collaboration between developers, and that implementing defining features of clean code, like meaningful naming conventions, proper documentation, and reusable code blocks that don’t require other developers to repeat efforts and redundancy, will all lead to a final product that follows the principles of writing “clean code”. Other topics of emphasis in the blog post were: consistency of code, clarity of comments, and efficiency of the code written.

After having read this blog, and through our classes in which we had our own lessons of writing clean code, I now understand why it is such an important aspect of writing code. After reading the article, I learned about how much of a difference refactoring code can actually make when it comes to the readability of code, which I didn’t consider throughout our in class discussions. After seeing examples of refactored code alongside the same code in its non-refactored form, it really convinced me to try harder to implement these practices in my own writing of code. Moving forward from this point, I want to put a lot more thought into how I write my code and whether other people are clearly able to understand it in the same way that I view it. After all that I’ve seen on the topic, I think the best way to go about this is through practicing more on implementing these “clean code” practices in my own work. I think it might even be a good idea to use a separate “clean code” guide to double check code I write in the future before submitting it. 

Blog Referenced: https://blog.elaniin.com/writing-clean-code-tips-for-developers/ 

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.