One of the earlier topics we went over in this course was Semantic Versioning and how many companies or groups will use it to keep track of their development. Sometimes shortened to “SemVer,” Semantic Versioning describes a versioning structure that will better communicate “implications of new versions, such as breaking changes, new features, or bug fixes” (Victor Pierre). It allows developers to have some comfort in knowing what changes will be made or have been made and whether there is some level of risk in moving to a new version. This risk lies mostly in software that have some sort of dependency, such as libraries or frameworks as updates to those can lead to dependent softwares having to update some part or most of their work, and the software not working otherwise. 

Semantic Versioning employs a three-part version number in the format, MAJOR.MINOR.PATCH, with each part signifying a different impact of the release.

• MAJOR: Incremented when making incompatible changes or introducing breaking API changes.
• MINOR: Incremented when adding new features or functionality in a backward-compatible manner.
• PATCH: Incremented for backward-compatible bug fixes or patches.

This is the basic structure for Semantic Versioning but there are many more rules to follow and other cases that will slightly change how the format will look (Victor Pierre). More details can be found on the official Semantic Versioning site (https://semver.org). 

When this topic was first introduced, I recognized it and was quite excited because it’s something I’ve seen quite often in the games I play or in other things related to games. The very first thing that came to mind was modding, especially in Bethesda Games. The Elder Scrolls Series and the Fallout Series are some of the most modded games ever, one of the reasons for this is the fact that Bethesda, some time after the release of a game, will implement modding support and tools. I connected Semantic Versioning to how Bethesda will rarely release a major update to Skyrim or Fallout 4, two of the most modded games ever despite how old they are now. These rare updates will cause the modding community to blow up as nearly every modder will have to update their mods in order to be compatible with the new version. After 10 or so years of these rare but destructive updates, many modders have simply stopped updating their mods, moving on to better things or just not caring enough to do so. It’s come to the point in which people have come together to make “downgraders” to play on an older version of the game to have access to a wider variety of working mods. 

That was a bit of a long story but overall, I think Semantic Versioning is simple but intriguing and most of all, extremely useful. I look forward to seeing changes, patches, updates for games and other software that I use and having access to an easy-to-follow log of just further cements my liking for Semantic Versioning. I’m not so familiar with other ways to keep track of development but this seems like a staple for developers and companies, and one that won’t be replaced so easily.

https://victorpierre.dev/blog/beginners-guide-semantic-versioning/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

In the past few weeks, we’ve been learning and working with REST and how it ties into the larger picture of software architecture. I found this section confusing at times but mainly interesting thanks to the connection to personal experience. Once I realized that this is essentially the behind-the-scenes of those HTTP errors I’ve seen all my life, I was excited to learn more. 

Web services that adhere to REST are called RESTful APIs or REST APIs for short. REST API is a UI (uniform interface) “that is used to make data, content, algorithms, media, and other digital resources available through web URLs” (Postman). They are defined by three main aspects: a base url, a media type for any data to be sent to the server, and standard HTTP methods. There are four HTTP methods that are generally used in REST APIs:

• GET: This method allows for the server to find the data you requested and sends it back to you.
• PUT: If you perform the ‘PUT’ request, then the server will update an entry in the database.
• POST: This method permits the server to create a new entry in the database.
• DELETE: This method allows the server to delete an entry in the database.

These methods will have different effects depending on whether it is used to address a collection or an element (Postman). 

The part of REST that I found most interesting and that I’ve seen before were the HTTP response codes. In the case that one tries to go to a website and all they are met with is a white screen with black text stating “404: Error” followed by some details, that is a response code. Response codes will slightly differ depending on the HTTP methods used but most common ones include: 

• 200 OK
• 404 Not Found
• 400 Bad Request
• 500 Internal Server Error

I found this topic to be pretty interesting and honestly necessary in the case that one works with the web. Knowing the internet and my luck, I’m sure to encounter many of these errors for the foreseeable future and it’ll serve as a reminder to what I’ve learned about REST.

Side Note: Just the other day, when I was trying to log into Blackboard, I was met with a 404 error. I thought I could just reload the page or open a new tab and get into Blackboard but I was still getting the error. It took about five minutes before I could actually log in. I realized that knowing the details of these HTTP responses doesn’t make them any less annoying.

Source: https://blog.postman.com/rest-api-examples/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

Earlier in this course, I learned about UML diagrams, how to read them, how to make them, and so on. This section of the class stuck with me as I thought it was pretty interesting how we use these diagrams to “visualize” our code. I thought I’d gain some more insight on UML diagrams and possibly more on how they are used in the real world.

For those who aren’t so familiar with UML diagrams, let me give you some background. UML stands for “Unified Modeling Language” and is “a way to visually represent the architecture, design, and implementation of complex software systems” (Lucidchart). These diagrams can be generally divided into two types, structural and behavioral. Both types of UML diagrams are pretty self-explanatory but structural UML diagrams display the various pieces of a system and how they are related while behavioral UML diagrams show how the system “interacts with itself and with users, other systems, and other entities” (Lucidchart).

In this blogpost from Lucidchart, one of the first things that caught my eye was under the section “Why should you use UML diagrams?” Of the four bullet points, three of them had me nodding my head in agreement, these were:

• Bring new team members or developers switching teams up to speed quickly.
• Plan out new features before any programming takes place.
• Communicate with technical and non-technical audiences more easily.

To me, these points make perfect sense. I’m not very familiar with how development teams work in the real world but I assume that there are plenty of developers and others that may come and go in companies, groups, and such. It may sound like a simple switch or change but that new person may have no idea what they will be working on or how it will be worked on. UML diagrams could help them adjust more quickly and help them understand their role, team, and work better. As for planning, simply adding a new piece to the diagram to indicate a new piece of the system could help display the relationships to what they already have. And finally, UML diagrams are much easier to digest than multiple files, classes, blocks of code, and such, especially for those who are not developers. A customer may want some update or insight into what they are spending their money on, and so, teams can simply show them a UML diagram and point out where they are and where they plan to go.

Blogpost: https://www.lucidchart.com/blog/types-of-UML-diagrams

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

When I was in the process of learning how to build a PC as well as planning out what parts to choose, I had to weigh my options on the scales of price and performance. Some time after building it and using it almost daily, I was confident that my shiny new PC could handle nearly everything that I was using it for. I have yet to run into any major performance issues despite how my last sentence sounded but the fear of that still lingers in my mind when I try or want to try pushing my machine a bit. To prevent these worries, performance testing is done on software applications. 

Performance testing “is a type of software testing that ensures software applications perform properly under their expected workload.” It is meant to test and measure a system’s performance “in terms of sensitivity, reactivity, and stability,” using metrics such as response time, scalability, and resource usage (GeeksforGeeks). Doing so ensures that a system can handle the expected workload efficiently and effectively. 

Performance testing can be done on multiple levels such as on the application itself, the system running the application, and other levels that go a bit out of my knowledge.

There are many types of performance testing but the three that seemed most common and simple were load testing, stress testing, and endurance testing. Load testing involves testing the product’s performance under expected loads. This could include simulating user experiences through testing with different tiers of hardware, using the application for a certain amount of time, and doing things that a user may do. This ensures that the application is accessible to as many people as possible as hardware limits and mild activity will not do anything to the application nor the system. Stress testing involves putting the application under extreme loads, pushing to and even beyond its limits. This helps to identify the point in which the product breaks or affects the system, and gives an idea of what to optimize or fix in order to avoid breaking as much as possible. Endurance testing involves putting the application under stress for extended periods of time. Simply running the application over the course of a few hours, days, and possible weeks helps to identify memory leaks and how it handles a different type of load. 

Performance testing is really interesting to me as, on my PC building journey, I was very much interested in the performance of computers and how some applications require better and faster components to enjoy it at its true maximum. I, though not on the level of actual performance testing, have tested my own machine to see its limits, how it handles the maximum of certain applications, and how well it handles my use. Luckily, I’ve had very few crashing of applications, freezing, or other issues. 

https://www.geeksforgeeks.org/performance-testing-software-testing

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

In a previous blog post, I had talked about Test Driven Development, or TDD. Today, I’m going to introduce a different approach that aims to almost rectify the potential shortcomings of TDD, that approach being Behavior Driven Development, or BDD for short.

BDD can be described  as “a collaborative approach to software development that aims to bridge the communication gap between business and technical teams” with the core idea of creating a “shared understanding of the software’s intended behavior using concrete examples” (Test Guild).

“The process revolves around writing scenarios using the Given-When-Then format, which describes the preconditions (Given), the action or event (When), and the expected outcome (Then).” This is a format that can be easily understood regardless of what people specialize in. TDD involved writing test cases and coding based on those test cases which mainly involved the developers, testers, and those that are closely linked to the programming and technical development. BDD, on the other hand, can involve the non-technical, such as stakeholders and those from other departments on top of the developers and testers. It can be simply put as, “compared to test-driven development (TDD) which is developer-centric, BDD is a team-wide practice” (Test Guild).

The Given-When-Then format allows for less misunderstanding when it comes to what is required of the software. Developers may use names that are short and to the point to describe something but it doesn’t match the behavior that is desired. The same developer or others that have just started working on the code may simply go along with it not realizing that what is desired of the code is something more or something else entirely. By using this format along with full sentences describing exactly what the code should do, there will be less room for error, misunderstanding, and time wasted fixing the code down the line.

One of the difficulties that seems to arise with the implementation of BDD is the inclusion of implementation details in scenarios. This is because scenarios are meant to focus solely on behavior. Including implementation details is basically attempting to set something in stone; scenarios describe what is desired of the code and how developers achieve that can change many times. It ends up adding more work every time that detail has to be met or changed.

BDD is an interesting topic, it seems to be a direct upgrade from TDD but that isn’t always the case. Take a classroom environment for example, it’s a bit odd as we (the students) could be considered developers but what about the other roles in the process? Would the professor act or technically be a stakeholder? It’s a process that can be learned at any point but it seems it can be only truly put into practice in a real world environment. We can certainly take aspects of BDD into mind, the Given-When-Then format and basing development around desired behaviors seems to have little to no downsides for any situation. 

Source: https://testguild.com/what-is-bdd/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

As we transition into a time in which technology is an integral and nearly essential part of daily life, the necessity of security in the technology we use becomes ever so important. Apps, devices, websites, and everything in between may have access to your personal information. You may have entered passwords, names, bank information, card details, and much more when using these things and possibly even allowed them to save that information. You may have confidence that your information will not be leaked or stolen but even with the biggest, most trusted companies, it is not impossible. 

To combat the potentially massive amount of information from getting into the wrong hands, we perform what is known as security testing. Security testing is an “aspect of software testing focused on identifying and addressing security vulnerabilities in a software application… and… it aims to ensure that the software is secure from malicious attacks, unauthorized access, and data breaches” (hackerone). It ensures that users have their privacy, the system is safe and secure, and that the software meets regulations. 

Security testing involves identifying vulnerabilities in the software through means of scanning, hacking, and evaluating it. Hacking is a method that seems to stand out compared to the other likely due to how it’s unique to security. Hacking falls under what is known as Penetration Testing which involves simulating real-world attacks on the software in order to expose vulnerabilities. Hacking, by definition, is the gaining of unauthorized access to data in a system or computer, but in this case this form of testing falls under ethical hacking. Ethical hacking is essentially hacking but with legal authorisation and is intended solely for security reasons. Overall, security testing is the perfecting of a software’s security through means of identifying and exposing weaknesses and remediating them.

I’ve actually had my debit card info taken in the past and my money used to purchase things without my knowledge. Thankfully, I got all my money back as well as a new card but, at the time, I was extremely anxious and worried. I was desperately searching for what could have taken my information and to this day, I still have no clue. It was likely my fault for putting my information in some shady place but there’s a chance that a site or app I had my info in and trusted was breached. I believed that I was being very careful with what information I shared and where I shared it but that situation really shook me. Security testing is not a topic we went over in class but it is a good topic to learn about nonetheless. Although learning about the testing of security is not something that everyone is interested in, I believe that teaching people how to protect their information is becoming more and more important.

https://www.hackerone.com/knowledge-center/what-security-testing#:~:text=Security%20testing%20is%20an%20important,unauthorized%20access%2C%20and%20data%20breaches.

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

Although I wasn’t present for the class in which code reviewing was introduced, it seems like a pretty simple topic to understand. It consists of… well, reviewing code; the only thing is, it can’t be done alone. Code review’s core and effectiveness lies in cooperation with others, where two or more people are required to even attempt code review. Of course, you can literally “code review,” as in, you review your own code but this refers to something more. 

What does it mean to review when it comes to code? Well, everyone is human, for the most part, and humans are prone to mistakes; and in the case of developers, these end up as bugs, errors, and everything in between. Code review allows others to look through one’s code to find these mishaps that the original developers may have missed or overlooked. I am also human and have had many cases in which I get stuck and have to ask a friend to look through my code just for them to point out something so simple and easy to spot yet I managed to miss. 

Code reviews encompass not only the spotting of mistakes but also the improvement of overall code, so as to have a better, more-refined end product before merging and such. This improvement of overall code includes but is not limited to structure, cohesion, cleanliness, and readability. Clean code is something that I hadn’t heard of until somewhat recently, so that aspect of my code from the past and even now can be improved upon heavily and would be greatly appreciated. 

Code reviews are usually chances for the one being reviewed to correct their mistakes and improve their code but there is also an opportunity for the reviewer to learn. The reviewer may encounter new techniques, solutions, and perspectives through this process, ultimately benefiting both reviewer and reviewee. 

One of the major downsides to code review is that the length and content of them depends entirely on the length of the code; and code can get to some very large sizes. The time spent reviewing especially large code could potentially be put into the current project, workflow, or what have you. 

As someone who is not so confident in their coding skill and proficiency, I believe that code reviews are great opportunities to learn and improve, which will in turn improve my confidence in my skill. There is much to be gained with code review and the downsides seem to only apply to much larger projects; so as a student and novice developer, they will be great to implement to my learning.

https://medium.com/@priyanthinisivasubramaniyam/everything-to-know-about-code-review-as-a-beginner-2a360cdd89ca

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

It’s certainly been a while since my last post. I’ve been slacking way too hard, especially with break, but now it’s time to lock in and focus on my work. 

For this blog post, I’ll be talking about Test Driven Development, or TDD for short. TDD is a “software development practice that focuses on creating unit test cases before developing the actual code.” It attempts to avoid or solve the issues that arise in “traditional testing.” TDD, rather than testing one big system, tests small chunks of code at a time. It also “follows an iterative process, where small chunks of code are developed, tested, and refined until they pass all tests.” This allows for errors to be found, debugged, and fixed as early as possible in the development process (BrowserStack).

In Kent Beck’s blogpost, “Canon TDD,” he lists the steps to properly adhering to TDD:

1. Write a list of the test scenarios you want to cover
2. Turn exactly one item on the list into an actual, concrete, runnable test
3. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)
4. Optionally refactor to improve the implementation design
5. Until the list is empty, go back to #2

Being introduced to a process that differs so much from the “norm” and is also quite efficient and thorough is both refreshing and exciting to learn about. When this topic was first introduced in class, I was very lost but I picked it up not long after; but then again, the example we followed was a very simple one. Once we moved onto a more advanced one to work on within our groups, I was lost again. I understand the concept of Test Driven Development but putting it into practice, at least for now, seems pretty hard. It also seems like a skill that is easy to pick up but hard to master as some tests can be more beneficial than others when it comes to coverage or time management. 

I feel as though there are little downsides to TDD and when it comes to those downsides, they mostly lie in the capability of the individual. Forgetting to run tests, writing too many tests, writing too much for a test, and writing tests that are impractical are just some of the issues that may arise when using this practice. 

Overall, Test Driven Development is a practice that individuals and teams may want to use to try something new or to test if it’s more effective than their current one. It‘s a very different approach to the development processes that I’m familiar with but that’s not always a bad thing; and in this case, TDD seems like a great practice.

Sources Used:

https://www.browserstack.com/guide/what-is-test-driven-development

https://tidyfirst.substack.com/p/canon-tdd

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

Among various testing techniques, equivalence class testing stands out as an efficient method for cutting down the number of test cases required while maintaining thorough test coverage. 

Equivalence class testing is based on the principle that inputs can be grouped into equivalence classes that exhibit similar behavior. By selecting representative test cases from these classes, testers can efficiently cover various scenarios without testing every possible input value individually. This technique is the best of both worlds, optimizing test case selection all while maintaining thorough test coverage; as those from ProfessionalQA.com put it, both the quality of test cases as well as testing as a whole is enhanced “by removing the vast amount of redundancy and gaps that appear in the boundary value testing.”

Equivalence class testing has four variations, each of which have their own benefits, downsides, and uses. They are determined using the combinations of two factors, the number of test cases and whether only valid values are tested or both valid and invalid are tested Thus, in terms of equivalence classes, we have weak-normal, strong-normal, weak-robust, and strong-robust. Weak-normal has few but effective tests and only covers the valid equivalence classes, strong-normal covers every valid equivalence class, weak-robust is like weak-normal but includes an invalid equivalence class(es) as well, and strong-robust covers every valid and invalid equivalence class. One thing to note about strong-robust equivalence class testing is that there is some redundancy when it comes to testing the invalid equivalence classes.

Equivalence class testing was a bit hard to pick up initially but it really clicked thanks to some visual aid, that being the graphs of the variations of equivalence class testing. With this visual, I was able to understand how effective equivalence class testing is and why some will want to use it. It allows testers to “focus on smaller data sets, which increases the probability to uncovering more defects in the software product” and may reduce the possibility of error on the tester’s part. With other testing techniques that are more difficult or time-consuming when it comes to larger data sets, equivalence class testing is a great alternative.

https://www.professionalqa.com/equivalence-class-testing

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.