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.