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.

I’ve always wondered what other roles exist in the tech industry besides software engineers or developers. Then I discovered QA testers, and I wanted to know exactly what they do. I chose to reflect on the article What is QA Testing? because it provides a comprehensive introduction to Quality Assurance (QA) testing. This is a topic we’ve explored in our Software Quality Assurance course. I found this resource particularly useful because it clearly explained the entire QA testing process, from requirement analysis to test execution and verification, while also explaining why QA is essential in software development.

The article defines QA testing as a process used to ensure that a software product meets customer requirements and functions correctly before it is released. Traditionally, QA testing happened at the end of the development cycle. However, modern practices now include QA throughout the entire process. This shift helps QA teams detect and resolve issues earlier, leading to improved efficiency and better teamwork.

The article outlines the QA process in six major stages: analyzing requirements, planning, test case development, test execution, verification, and documentation. Each step is explained in detail, showing how important it is to follow a structured and thoughtful approach to maintain high software quality. The article also introduces best practices such as combining manual and automated testing, using crowdtesting, adopting DevOps workflows, and applying predictive analytics. These practices help teams maintain high standards without slowing down delivery.

I chose this article because I’ve always been curious about how software is tested before it is released. After taking this course, I now understand that QA testing is more than just finding bugs. It involves improving user experience, ensuring reliability, and supporting the development team in delivering better products. This article helped me better understand those ideas and the important role QA plays in every project.

What stood out to me the most was the idea that QA should be an ongoing part of development rather than something saved for the end. This supports what we’ve learned in class, that early testing saves time, money, and effort in the long run. I also learned about tools like bug trackers and test scenario checklists, which help organize the QA process and make it more efficient.

After reading this article, I feel encouraged to explore QA roles further. Even if I am not working as a developer, I now see how I can still make meaningful contributions to a tech team. I’ve learned that skills like analytical thinking, attention to detail, and strong documentation are essential in QA, and these are skills I am actively working to improve. In the future, I plan to apply what I’ve learned by incorporating test planning and QA thinking into every project I work on.

Reference:
Team, The Upwork. “QA Testing: Beginner’s Guide to Quality Assurance.” Upwork.com, Upwork, 6 Sept. 2022, http://www.upwork.com/resources/what-is-qa-testing.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

This week, I read a blog post called “Netflix App Testing at Scale” which is based on an interview with Ken Yee, a Senior Engineer at Netflix. It takes a look at how Netflix tests their Android app, which is one of the most widely used streaming apps in the world. With over a million lines of code, 400+ modules, and support for all kinds of devices (including foldables and Android Go phones), testing at Netflix isn’t just about making sure the app works—it’s about making sure it works everywhere. I chose this article because we’ve been covering testing frameworks and strategies in class, and this felt like the real-world version of everything we’ve been learning. I also use Netflix a lot,  it is interesting to learn how they keep it running smoothly through so many updates and features. This blog helped me connect the theory from class to an actual large-scale product.

Netflix used to have a separate team of SDETs (Software Development Engineers in Test), but now every feature team handles their own testing. That includes unit tests, screenshot tests, and end-to-end tests. They still have two SDETs who help across teams, but quality is everyone’s job now. I thought that was cool—it encourages developers to think about testing earlier and more often, rather than just tossing it over to QA at the end. They also go into the frameworks they use. For unit tests, they use tools like Strikt (for fluent assertions), Turbine (to help with Kotlin Flows), and Mockito (for mocks). They also use Hilt for dependency injection and Robolectric when they need to test Android-specific logic. What stood out to me was how conscious they are of performance—each layer of test framework (plain unit → Hilt → Robolectric → device tests) adds more time, so they encourage developers to keep tests as fast and simple as possible. That’s a great tip I’ll definitely remember for my own projects. I also learned a lot from their section on flakiness. I hadn’t realized how much those little issues could mess up tests—and how fixing them makes everything more reliable. Finally, Netflix uses screenshot testing heavily. They use Paparazzi for Jetpack Compose UI, localization testing for checking designs across different languages, and even visual accessibility checks. It is interesting to find out that they care about accessibility and localization.

This blog gave me a better understanding of how layered and thoughtful good testing needs to be—especially at scale. I’ll definitely use what I learned about speed, flakiness, and strategy in my future development work.

From the blog cameronbaron.wordpress.com by cameronbaron and used with permission of the author. All other rights reserved by the author.

The blog post “What Do You Fix When You Fix a Test?” by Joep Schuurckes explores the nuanced decisions developers and testers face when a test fails. The central question is whether the issue lies in the test itself, the code under test, or possibly even the expectations behind the test. Schuurckes starts with bringing up the topic of legacy tests, legacy test code that makes “more decisions about what and how things are tested than the team.” He encourages readers to reflect before blindly “fixing” a test by editing it to pass again. This is what he calls “tests-as-code” where the developer is trying to change the code of the test so that it passes rather than treating it with the mindset of “tests-as-code”. “Tests-as-code” would be where the developer looks at a failing test as an information dump where each test returns some kind of data and thus any changes must preserve that data return. Part of keeping tests as code is keeping to a naming scheme so that each test is obvious in what you are expecting as a return which is the exact same thing I was taught in class, but now I understand the reasoning a bit more.

This post made me rethink what it means to “fix a test.” I’ve been guilty of tweaking test code just to get everything green in the test runner again, without stopping to think whether the test was telling me something important. Joep’s approach feels like a call for discipline and care in testing—treating tests as important resources in the codebase rather than disposable tools. The idea that tests should be maintained with this way of thinking resonated with me, especially since I’ve seen how neglected or misleading tests can erode trust in automated test suites.

Going forward, I want to adopt a more mindful approach when a test fails. Instead of rushing to “fix” it, I’ll start by asking why it failed. Is the requirement outdated? Is the test too brittle? Has the functionality truly changed? Also, I want to be more deliberate in writing tests—designing them to clearly document behavior and to be resilient against irrelevant changes. This is especially relevant for integration tests, which are often more vulnerable to external factors and instability. By treating each failed test as an opportunity to learn, not just a checklist item to resolve, I hope to contribute to codebases that are easier to maintain and trust.

source :
https://smallsheds.garden/blog/2024/what-do-you-fix-when-you-fix-a-test/

From the blog Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

The article “The Difference in Perspective of Testers and Developers” by Vijay provides a comparison of how software testers and developers approach software QA and testing. Developers are often focused on building features that work as intended, with an optimistic mindset geared toward implementation. Testers, on the other hand, adopt a critical mindset, aiming to uncover flaws, edge cases, and unintended consequences. The article explains that while developers ensure that the software does what it’s supposed to do, testers ensure it doesn’t do what it’s not supposed to do. This difference in thought processes is not a conflict but a complement to creating robust, reliable software. The article encourages improved collaboration, mutual respect, and open communication between these roles to produce higher-quality software.

Reading this article gave me a better understanding of how vital both roles are in the software development lifecycle. As a CS student who has done more programming than testing, I’ve often written code with the assumption that if it runs without errors and produces the expected result, it’s good to go. But throughout my QA and Testing class, through reading different blogs, I now see how much that perspective misses. I haven’t always taken the time to think about how a user might unintentionally (or maliciously) use the software, or how fragile assumptions can be unless they’re tested thoroughly. It’s easy to feel like bugs are personal flaws, but this article helped me appreciate the tester’s role and the stark difference in mindsets because I truly saw testing as just another tool in the developer toolkit and not as the fully fleshed-out role it is.

This new understanding is something I plan to apply in future group projects. I want to make a conscious effort to invite feedback from teammates who are testing my code, and more importantly, not take that feedback defensively. I also want to improve my own testing practices by thinking like a tester during development. That means writing unit tests that go beyond the “happy path” and trying to break my own code before someone else does. In larger projects, I now see the importance of collaboration between testers and developers early in the development process, rather than waiting until the end to start thinking about quality. Encouraging open communication can lead to better designs and fewer bugs downstream.

source:
https://www.softwaretestinghelp.com/the-difference-in-perspective-of-testers-and-developers/

From the blog Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

As a computer science student getting more into the details of software development, I’ve started to realize how much goes into making sure software actually works the way it’s supposed to. I recently read the article “13 QA Testing Best Practices For 2024” from Testlio, and one part that stood out to me was the idea of risk based testing.
(testlio.com)

Risk based testing is all about using your time and effort wisely. Instead of trying to test every single feature equally, it focuses on the stuff that matters most. You look at what parts of the app are most likely to break or cause problems for users if they fail. Then you make sure those are tested thoroughly before anything else.

The article explains that identifying risky areas early helps teams put their energy in the right place. If you’ve only got so many people and so much time, this method helps avoid wasting those resources. It also means the most important features are solid by the time the app goes live.

This reminded me of a group project I worked on where we made a class management web app. We spent way too much time testing features like color themes and user bios. But when it came to the assignment submission tool, which was probably the most important part, we barely tested it. Sure enough, after we deployed it, users had issues uploading their files. If we had used risk based testing, we probably would’ve caught that.

Now that I know about this approach, I’m going to start using it in future projects. I’ll take time up front to figure out which features are most essential or most likely to go wrong, and make sure we focus testing there first. It’s a simple idea, but it makes a big difference.

In the end, risk based testing is about being smart with your time and making sure what matters most actually works. If you’re also learning software testing, this is a great thing to start thinking about. I definitely recommend checking out the full article if you’re curious:
13 QA Testing Best Practices For 2024

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Manual and automated testing are the two ways to run tests. One involves human touch while the other needs very little from a third party to work. While one would think automated testing is better in almost every case. That’s not necessarily true. To start, in most cases automated tests are just better. They are more efficient and save people a lot of time. They can be run over and over again. And can be run every time code is pushed, instead of having to be manually runned. Oftentimes the only times manual testing is useful is when things are tested for use by humans. Meaning things like testing how an app feels to use or how the functions in practice. These areas require testing things that are hard for a computer or code to test.

Manual testing can be more cost effective depending on the circumstances. But manual testing is also subject to more error due to the nature of human involvement. Tests are more adaptable because they can be changed more easily. While automated tests being changed might take more time to change to make sure they work with the code. Automated testing offers more coverage since they can be made small and can cover various areas of coding. Automated tests can also handle larger test cases that span over a large area. While manual testing struggles to handle something so large. Overall I’d say that automated tests seem better to use in general. Aside from things like testing for human feel, automated tests seem to handle most things better.

https://www.testrail.com/blog/manual-vs-automated-testing/

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Security testing is a major area of testing that is very important. In today’s world, security is imperative to a softwares effectiveness. Without security software will be targeted and used against people. The cost of data breaches result in humongous money loss. Some of the goals in security testing is to find weakness in code, finding the impact of security breaches, report findings, and eliminating risks. Some of the principles of security testing is having realistic tests that test real world applications. Tests that are through and wide spanning. Continuous testing because the nature of security and attacks is always changing. Testing should be a collaboration of all parties involved in the software development process.

We always hear on the news about data breaches for some company that cost billions of dollars. It’s hard to put into perspective how much money that is and how that actually affects people. The security of software has real world consequences on people. It’s not something to take lightly. We have to protect software in order to protect the people using it. It’s just as important as testing to make sure the software works. In the blog it said that negligence in security breaches leads to a higher fine. Which makes sense since if you willingly ignore security breaches you’re putting peoples livelihoods at stake, not just at the company. There are many different areas to security testing. API testing, HTTPS, Cloud, basically any area that requires communication is subject to hackers. 

https://fluidattacks.com/blog/security-testing-fundamentals/

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

While doing an activity related to Software Quality Assurance concepts in class, I came across an article that clearly explained two crucial black-box testing techniques: Equivalence Partitioning (EP) and Boundary Value Analysis (BVA). The article, “Equivalence Partitioning and Boundary Value Analysis” by Alan Liew, stood out to me because of its simple examples and approachable language. I appreciated how it used realistic scenarios like age and email validation to make the concepts easier to understand.

In summary, the article defines Equivalence Partitioning as a technique that divides input data into partitions or sets that are treated similarly by the system. Inputs from the same partition are expected to behave the same way. For example, if users are allowed to register only when their age is between 1 and 21, then that range is a valid partition, while any value outside it is considered invalid. The article also introduces the idea that only valid partitions should be combined in testing, whereas invalid ones should be tested individually to catch specific error messages or bugs.

Boundary Value Analysis builds on this by emphasizing that input values at the edge of partitions, like 1 and 21 in the age example are more likely to uncover boundary-related bugs. It explains the 2-value and 3-value BVA methods. A 2-value BVA tests the boundary and its neighbor (e.g., 0, 1, 21, 22), while a 3-value BVA goes even further (e.g., -1, 0, 1, 2, 20, 21, 22, 23). This distinction is important for thorough testing and to avoid letting bugs slip by due to limited test coverage.

I chose this topic because it was one of the activities during class that initially confused me. I struggled to understand its purpose and how it applied in real testing scenarios. I wanted to learn more about why this technique matters and how it fits into the bigger picture of software quality assurance.

From the article, I learned that testing isn’t just about checking if a system works, it’s about designing the right test cases to catch errors early. Testing with both valid and invalid inputs, along with carefully chosen boundary values, helps ensure robust software. I also realized how combining invalid inputs in one test can lead to overlooked issues because one error may hide another.

Moving forward, I plan to use these strategies in future development and testing projects, especially where user input validation is involved. I hope to explore more QA topics like this to gain deeper insight into the role of a software tester.

Reference:
Liew, A. (2024, July 14). Equivalence partitioning and boundary value analysis. Medium. https://alanliew.medium.com/equivalence-partitioning-and-boundary-value-analysis-c940a0c120f5 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.