Welcome back to my blog. If you didn’t know, my name is Kyler and this is where I’ll be occasionally making blog posts about topics that relate to software, computers, programming, and the like.
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.
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.
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:
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.
Boundary testing is a technique that “involves evaluating data based on boundary values… such as minimums and maximums.” It involves testing the lower and upper limits of a domain of inputs, as well as values just inside and outside those limits. This technique helps improve software quality by detecting defects early in the development process, which ultimately saves time and resources. This is due to the fact that “the number of defects at the boundaries of an input domain tends to be higher than in other areas of the domain.”
Going back to how it saves time and resources, it helps developers choose more efficient test cases, which cuts down on time and how much they have to do, especially with large sets of data and number of inputs to consider. Furthermore, this technique “allows for a lot of uniformity and the test cases are much smaller” meaning that it can be automated. This would save more time, possibly result in less errors than if a person were to write the test cases, and allow for developers to put their focus on other tests or somewhere else, resulting in increased productivity.
Boundary testing involves determining the input value range, which is whatever values the system accepts. Values inside that range are valid while those outside are invalid. Test cases are then created based on the values at the extreme ends, end values, and values just before and after the end values. For example, with a range of 0 to 100, we test values less than 0 (-50), greater than 100 (150), values around and at 0 and 100 (-1, 1, 99, 101).
Another example the article shares is one that allows users to create a password. The password has to be 5 digits meaning that the range is 10000 at minimum and 99999 at maximum. Any combination of numbers is valid as long as it is 5 digits long, meaning that 4 digit long and 6 digit long passwords are outside the range and are invalid.
Boundary testing seems like a very useful testing technique with very little downsides. It’s a black-box testing technique which usually means that testers don’t need extensive knowledge of coding, computer science, or the system at hand. It also seems very easy to do as long as all the necessary knowledge for testing is provided. Seeing as how it can also be easily automated, it may be more efficient to focus on more complex or time-consuming testing techniques while this test is running in the background or on the backburner.
https://www.indeed.com/career-advice/career-development/what-is-boundary-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.
Over the past few classes of the semester, we’ve gone over some of the terms as well as the methods used in software testing. Two of the methods that stood out to me were Black Box Testing and White Box Testing, mainly because I assumed they were methods that were closely related. We didn’t go in depth with these terms and methods but from what I researched and discussed with my group, my assumption was correct.
Black Box Testing is a method in which the software is tested without looking into how it works internally. Testers provide inputs then observe the outputs produced by the system. The goal is to evaluate how the system responds to “user actions that are both expected and unexpected.” This method can help identify defects, errors, and the like from a user’s perspective, as they usually have no knowledge of the inner workings of the software. This also means that testers don’t need a deep understanding of software testing or the particular code of the software; and as such, qualifications are not so important.
White Box Testing is a method in which the internals of the software are examined and tested. Testers examine everything within the software, such as the structure, logic, and code, and create test cases that assess that. This method is effective at uncovering issues with code quality and structure, bugs, and more that can’t be seen or evaluated with Black Box Testing. Like Black Box Testing, testers must ensure that the software meets specification. Unlike Black Box Testing, testers need a deep understanding of coding and software testing as well as that particular software being tested.
I believe that both will be very important in the software development process, although I do lean towards White Box Testing having more impact. Those with specialized knowledge and skills will likely sort things out faster looking at the internals of the code than those without looking at just the inputs and outputs. It’ll generally be more effective as well as tests are done on the code and thus developers can quickly fix and solve those issues; whereas with Black Box Testing, it’s more of a way to acknowledge that there is some issue. I can only imagine Black Box Testing to be a very tedious and monotonous process although I could be completely wrong. It may be most effective to implement White Box Testing first and Black Box Testing afterward, as a double check of sorts.
Source: https://www.ranorex.com/blog/black-box-vs-white-box-testing-understanding-the-differences/
From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.
My name is Kyler and I’ll be making quite a few blog posts over the course of this semester. I look forward to both my class as well as the future posts I’ll be making.
From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.