My Look into QA Testing

Hello, Debug Ducker here and this time I got interested into learning about QA testing. This sudden feeling of wanted to know more about this field came from my time spent watching online entertainment. In a lazy afternoon I decide to watch a gaming podcast, and found out that one of the host of the podcast was QA tester and worked on several games. His stories about his time in the business intrigued me a lot and made me do further research on what the job of being a QA tester requires. What I found is very interesting and hope you find it interesting too.

Let’s start off with what QA testers exactly do. QA testers is to make sure a product meets quality and legal standards and how they go about it is by using automated test with the purpose of making the program malfunction of break. This helps development teams as they find the issues that need to be address while still focus on the development of the product.

What I found interesting is that QA testing is that they perform a method of testing known as black box testing. They can’t see the code but still test its functionality. In my time studying software testing I was thinking of the possible reasons on to why would I test something that I can’t see. I realize now that if you can’t see the code you don’t have any preconceived notions on how it should function. If you had someone else, like a QA tester test it they would attempt to break things easily as they don’t ahve the idea of what the code base looks like. They are the unbiased viewer. Which can help a lot. I remember when testing for software there would be this one thing I didn’t account for based on my own assumptions and my code. Which lead to many annoyance and headaches.

QA testing is a very important aspect of software development. It helps find issues that can be missed and can keep a project manageable and focus when there is an entire team focus on testing. QA testing can save a lot of time too which can be very important for a project.

Maybe one day I can tell you more about the podcaster and his foray into QA testing as he has a lot of interesting stories to tell.

Thank you for your time have a great day.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Test-Driven Development

Hello! Welcome back to my next blog post. This post is about Test Driven Development, also known as TDD. I used this article to do some research on it: Test driven development: What it is and the benefits of using it

I chose this article because it goes into further detail about what we already learnt about in class. I chose this topic because we just went over it in class recently, and we also had a homework assignment on it. At first, I was very confused on what to do in the assignment, and I had no idea what I was supposed to put in the testlog file. But by the end of the homework assignment, I kind of understood everything more, and realized that the testlog file was just meant to help me organize my test backlog, and make all of my commits with notes left behind. It took me a lot of time to come to these realizations, but once I did it helped me a lot.

This article talks about something we briefly went over in class, called the “red-green-refactor development cycle.” What this means is that first you want to write a test, which you already know is going to fail – This is the red part. Then, you want to write very simple code; Just enough to make sure the test you wrote passes – This is the green part. Finally, you want to refactor your code, and make sure not only the first test passes, but also all of the previous ones as well. Refactoring is probably the most difficult part of the process, since the other two are sort of bare minimum procedures.

I was instructed to do this in the homework assignment, but with Test Driven Development, you are supposed to only do one test at a time. I think this is smart because sometimes you can get ahead of yourself or get lost while you are trying to make multiple tests pass at the same time. Sometimes with coding I feel like you can make more mistakes trying to be fast, which ultimately slows you down. While if you take it step by step, it actually could end up being quicker than if you are rushing and not being careful.

Overall, TDD is a very interesting topic, and it was helpful that we not only went over it during class time, but also had a way to practice this with the Kata homework.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

How Test-Driven Development Changed My View on Coding

The article I selected is titled What is Test-Driven Development? It explores TDD, which stands for Test-Driven Development. A software development methodology where tests are written before writing the actual code. At first, this idea sounded very backward to me, especially as a student still learning how to code. Originally introduced by Kent Beck in the 1990s, TDD follows a specific cycle: first, you write a failing test for a small piece of functionality. Next, you write the minimal amount of code needed to make that test pass. Finally, you refactor the code while continuing to pass all the tests. This method aims to create reliable and well-structured code from the very beginning.

I chose this article because while working on the TDD assignment for class, I found myself very confused about why the process was designed this way. It felt unnatural to write tests before even having code to test. After reading a few articles, including this one, I learned that the main purpose of TDD is to reduce the amount of time spent debugging and to automate testing early. It helps ensure that the code behaves correctly as new features are added, reducing bugs and saving time later.

After practicing more during the assignment, I began to see the benefits firsthand. I enjoyed the process once I understood it better, even though there were moments when I had to refactor my code multiple times to make all the tests pass. One important takeaway from the article was how TDD encourages continuous improvement. As developers write more tests, their code quality naturally improves over time. I also learned that TDD plays an important role in Agile workflows, pushing developers to prioritize testing before writing large chunks of code. This mindset shift promotes creativity, collaboration between developers and QA testers, and reduces technical debt, making it easier to maintain and update code in the future.

This article and topic really changed how I view software development. It showed me that TDD can be both a creative and collaborative process rather than just a strict set of rules. I now plan to apply TDD practices in my future career. By writing tests first, I can better organize my development process, catch issues early, and build more reliable software. Exploring this topic helped me overcome my confusion during class and appreciate why Kent Beck created this approach in the first place.

Reference:
Moore, Paul. “What Is Test-Driven Development?” Scrumalliance.org, 2023, resources.scrumalliance.org/Article/test-driven-development.

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

Learning JUnit 

In the article I selected, the topic of JUnit, a popular Java testing framework, is introduced and explained. The article simplifies JUnit for beginners or those who have never used it before. It discusses key features such as assertions, test runners, test suites, and reporting tools. The article is divided into several sections, including an overview of what JUnit is, how it functions, the different types of testing it supports, and the key benefits of using it. It also provides a step-by-step guide on how to download and set up JUnit, making it an accessible resource for new learners.

Before taking this class, I barely knew anything about JUnit. As I read through the article, I learned that JUnit is part of the xUnit family of testing frameworks and is primarily used for automating unit tests in Java applications. It can also support other types of testing, such as functional and integration tests. One of the biggest takeaways for me was understanding the features that make JUnit so effective: assertions for verifying test results, test runners for executing tests, test suites for grouping tests together, and reporting tools for easily spotting problems. I also learned why using JUnit is important not only because it helps developers write more organized and readable code, but it also improves error detection and correction early in the development process. This ultimately boosts the efficiency of QA testers and software engineers.

I chose this article because we recently discussed JUnit in class, and I wanted to deepen my understanding beyond just what was covered in lectures. As someone studying to become a future software engineer, I realized that knowing how to write effective tests is just as important as writing code itself. Testing frameworks like JUnit ensure that applications behave as expected, making them more reliable and easier to maintain over time.

Reflecting on what I learned, I feel much more confident about incorporating unit testing into my future projects. Learning about assertions and test runners especially helped me see how testing can be integrated smoothly into the development process rather than being something added at the end. Going forward, I plan to apply this knowledge by writing unit tests alongside my code from the beginning, which I believe will make me a more efficient and thoughtful developer. Overall, this article not only expanded my technical skills but also shifted my mindset about the importance of testing in building quality software.

Reference:
Abhaya. “JUnit: A Complete Guide – Abhaya – Medium.” Medium, 9 Jan. 2024, medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce.

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

Test Driven Development

This past week we worked on test drive development which was very difficult for me do to me being used to working with only source code first then writing test code. This new approach in my head was fairly easy, but when I went to code it, I was struggling. I believe part of this struggle was due to me not thoroughly writing out my test cases and taking the time to fully understand what I was doing. I ended up doing better on the testing for the homework than the activity I believe because I took a step back to understand and read more in depth into the five steps provided. I decided to also read more on another website (sourced down below) about test driven development, which this website went into more of the process of it and how the cycle works. It explored the history of it as well as the advantages and disadvantages.

These advantages included how writing the tests first provided constant feedback to the developer as well as always meeting the requirements more in depth and not having unnecessary tests or codes. This helps developers decrease production time in some scenarios due to only having to write the tests than source code to only specially pass that one test and if needed down the road to refractor code the developer can do so as well, but they will know what went wrong and reach their conclusions much quicker. The disadvantages spoken about are increased code volume which can be a pain currently or down the line when the code is going to be refactored or maintenance. Also, a huge disadvantage that can lead to multiple issues is false security from tests which some developers will go in and assume since one test passed, they do not need to make more. I believe personally for larger applications test driven development is not the best idea due to ever growing projects which will require lots of testing and can only be written after the source code to ensure they all work together rather than individually because some methods rely heavily on other methods.

The great thing about test driven development though that I learned and enjoy is finding bugs much earlier on. It helps me quickly go back and refractor my code for the test to pass but as stated previously it has its advantages and disadvantages. Overall, I had a hard time with it because I have never heard of it until now, but reading more about it I understand the main concepts of it. The activities in class did help discussing with the team as well as the homework, but the thing that confused me about the homework was the log since I usually don’t write logs on how and what test I am going to do because I base it on the source code. Overall, it was a great experience, and I am glad I was exposed to it so I can try it more on my free time and see how it is used in the real world.

Source: What is Test Driven Development (TDD)? | GeeksforGeeks

From the blog Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.

Favor real dependencies for unit testing

URL: https://stackoverflow.blog/2022/01/03/favor-real-dependencies-for-unit-testing/

Mark Seeman brings us an interesting idea about which dependencies should be used during testing. In his article Favor real dependencies for unit testing, he explains that not every dependency necessarily helps you develop your tests. His main point concerns the use of dependencies that generate some kind of fake implementation of your methods in order to allow you to test them. One great example of this is Mockito, a widely used Java library where you can ask the tool to mock an entire class implementation. Although that sounds completely reasonable at first glance, what could be one issue that Mark is possibly missing in his argument? I would say that he is missing the reason why developers often rely on mocks and stubs in real-world development scenarios.

The main reason someone may choose to use mocks and stubs is more related to collaborative group work rather than projects handled by a single developer. In group settings, such as when working on a complex system like a hotel booking website, developers are usually assigned to different components or features of the system. For example, imagine a situation where you are working as a developer on such a project and are responsible for the Bookings class, while your teammate is assigned to the Suites class. Both of you have been making progress on your respective parts, and now you want to start writing tests to ensure everything functions as expected.

However, if any of your methods rely on a function that your teammate has not yet implemented, you could run into difficulties. Without the other function available, you might not be able to fully test your own code, even though your part is technically complete. This could lead to a development bottleneck, preventing you from moving forward until the rest of the system is ready.

To solve such a problem, one practical solution is to use libraries like Mockito. These tools allow you to create a mock version of your teammate’s class or method, enabling you to continue writing and running tests without delay. As explained earlier, Mockito generates fake implementations that simulate the behavior of the real components. This makes it possible to isolate and verify your own code independently.

Mark’s point is valid in scenarios where a developer is solely responsible for both the implementation and testing of all related methods. In such cases, using real dependencies like database fakes or stubs may be more effective. However, in collaborative environments, mocking libraries are essential tools that support parallel development.

This article surprised me with its perspective and application. As I’ve learned in class, the use of mocks allows developers to test features that haven’t been implemented yet adding a useful layer of abstraction. I believe that such libraries are not meant to stay in the codebase permanently but rather serve as temporary scaffolding—tools meant to be discarded once the full system is in place.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

During Sprint Two, my main task was troubleshooting an issue with sending data to MongoDB and its connection within Docker. Initially, a teammate had trouble sending the fake data from RabbitMQ to MongoDB. The data was reaching the RabbitMQ queue, but there were problems with the consumer. I suggested that we seed fake data directly into the database so we could work on calculating totals and building the report. When working on that, it soon became clear that the issue was not the consumer but the connection to MongoDB itself. Even with the database running and showing access to an empty database on the browser, we could not add the fake data from the queue. Further attempts to connect to the database did not work. At the end of the sprint, we decided to split the data transfer portion into another subproject for sprint three.

This was the main experience for half of the team, while the others worked on JSDoc, calculating report totals, and developing the frontend. We faced setbacks throughout the sprint but collaborated well and tackled the problem from different angles each week. Unfortunately, the troubleshooting process regarding the MongoDB connection bore no fruit. We misidentified the problem early on, which took some time, but this was mostly due to our inexperience with Docker. When comparing and implementing the guestinfobackend with our backend, I grew consistently confused about what was causing the issue and believed it had something to do with using the docker container we did not understand.

Moving the data transfer portion to a different subproject seemed like the best approach. It will move us around the roadblock we hit and give us an achievable goal for sprint three. Although we could not solve the issue, I still learned a lot about MongoDB, MongoDB Compass, how to seed fake data, the docker-compose, and how Docker can complicate connections between different services.

Our team did not initially understand the extent of the problem, and in hindsight, we should have had all teammates working on the issue earlier. We assumed the roadblock would be resolved quickly, but we should have brought the rest of the team in after week two. Our communication in and out of class has been fine, but while we were stuck on the database, I believe similar roadblocks on the frontend side were being downplayed. Since we are no longer stuck on the database, I will focus on helping with the frontend during sprint three.

Individually, I need to deepen my understanding of Docker containers networking and ports. None of the attempts produced functional or testable changes, and we actively discussed what we tried each week, so it was disheartening not having anything to commit. I was scrapping entire changes and trying different approaches constantly to no avail.

The apprenticeship pattern reflecting my experience for this sprint would be “Learn How You Fail.” This pattern emphasizes analyzing the reason for your failures and not dwelling on them. Understanding what led to the failure, like incorrect conclusions, gaps in knowledge, or missed details, can turn something frustrating into a learning opportunity. I chose this pattern because the sprint was full of failed attempts. Despite researching and testing each week, we could not solve the problem. Initially, it was frustrating, but seeing it as part of the process makes more sense when stuck. Our group talked about our lack of experience in Docker, and it helped us to know what we needed to work on and that I was not the only one confused. If I had read this pattern earlier, I may have worked on the issue with less frustration and more patience.

While I did not make any commits this sprint due to the unresolved database issue, I was consistently involved in troubleshooting the MongoDB connection issue alongside my team, as shown in the weekly reports.

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Top javaScript testing frameworks

Jest:

Developed by Facebook, Jest is one of the most beginner friendly frameworks, especially for those working with React. It comes pre-configured and includes a test runner, mocking, and assertion libraries. Its snapshot testing and excellent documentation make it a favorite among React developers. However, debugging can be tricky in some IDEs, and large snapshot files can be hard to maintain.

Mocha:

Mocha is a flexible framework ideal for Node.js applications. Its simplicity and long-standing presence in the testing world make it reliable. With support for async testing and various plugins like Chai and Sinon, it offers solid control. That said, it requires more configuration than Jest and lacks some built-in features.

Jasmine:
Jasmine supports asynchronous testing and integrates well with external libraries. It’s loved for its flexibility and extensive community support. The trade-off is more setup complexity, especially if you need additional libraries for mocking or assertions.

Nightwatch
Nightwatch is great for E2E testing with Selenium WebDriver. It’s particularly useful if your team has a Java background, thanks to its object-oriented syntax. However, its syntax can be less readable, and logging failures can be cumbersome without detailed error messages.

Playwright
A rising star from Microsoft, Playwright allows you to automate Chromium, Firefox, and WebKit using one API. It’s fast, supports modern web features, and works well with headless browsers. Being newer, it still lacks the depth of resources available for older frameworks.

Puppeteer
Built by Google, Puppeteer is tailored for Chrome/Chromium automation. It’s fast, developer-friendly, and ideal for tasks like form submission or page scraping. Its main limitation is the lack of cross-browser support.

Selenium
The veteran of test automation, Selenium remains the go-to for cross-browser testing. While powerful, it often requires additional setup and can struggle with scalability unless paired with tools like Selenium Grid or LambdaTest.

Karma
Karma offers real-time feedback and runs tests across devices and browsers. It supports popular frameworks like Mocha and Jasmine. It’s highly flexible, though less commonly used in newer projects today.

Cypress
Cypress is designed for modern JavaScript apps and offers unique features like time-travel debugging and real-time reloads. It runs directly in the browser but is limited to a few supported browsers and doesn’t allow multi-tab or remote execution.

Final Thoughts
Your ideal framework depends on your project’s size, tech stack, and testing goals. Whether you’re working with React, Node.js, or need robust cross-browser support, there’s a JavaScript testing framework tailored to your needs. Test smart, and happy coding!

Reference: https://www.lambdatest.com/blog/top-javascript-testing-frameworks/

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog

My task in Sprint 2 was to modify all endpoints to accept access tokens that will determine the system whether the request is from an authorized individual making that request. The goal is that these tokens will let the system know if the requester is authorized. But this can only happen after the IAM team figures out how the tokens will work. In this sprint, I collaborated very closely with my partner Sean Kirwin.

What was best for me in Sprint 2 was to work with Sean and continue to work on the backend. I was working on an issue that I am comfortable with again. I was also able to continue a task that was in progress from the previous sprint.

As a team, we still managed to get along. Communication from my teammates was really the best. Every individual could complain about what issues they were facing, why they were late to class or missing class, and was helpful whenever someone needed help from a teammate. Every week, my teammates were always there to offer helpful criticism, and I appreciated their help when I needed it. They also answered my questions about how to proceed with my assignment. I know that there is always room for improvement. However, I think that my team did very well in this sprint and we did not have any major issues during this sprint.

Relying on another team was somewhat challenging for me. We were not able to accomplish as much as needed because we were waiting to see how the tokens will be, as it is the IAM team’s decision to make that. Although we keep communicating with them on Discord, in my opinion, we should have sat down and spoken face-to-face or on Zoom so that we can better understand each other’s views. I sort of felt like both teams were getting a bit mixed up with each other’s arguments. The pattern I associated with from the Apprenticeship Patterns book was “Create Feedback Loops”. Here in this chapter, it highlights the importance of constant, actionable feedback in speeding up learning and improvement in the journey of an apprentice towards mastery. Feedback loops facilitate the discovery of weaknesses, confirm progress, and hone skills. They are imperative to move from apprentice to journeyman and later to master because they enable self-awareness and incremental improvement.

I chose this pattern because it is so closely related to what was happening in the sprint. Although it is stated not to move/work on tasks from the previous sprint, I managed to do so because I had the time available to complete a small mistake that was executed in sprint 1 in order to wait for feedback from the other group so that I could work on my task in sprint 2. I was able to learn the feedback from my other team members and rectify the small mistakes done during sprint 1. The “Create Feedback Loops” pattern helped me to step back, hear the feedback from my peers, and strategize on how to improve.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/141

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospect

In sprint 2 my team and I actually got the project functioning as we had intended. We now have a webpage with a scanner that can read UPC codes off any product we can find. A fetch script that takes that UPC code and uses an FDA API to give us data on the product. This data includes brand, brand owner, product category and a description. This data is then merged into our back end and stored with a quantity that gets manually entered. 

While demoing the webpage our customer seemed very interested in it and how user friendly we had made it. They seemed concerned about having to scan every individual product until they saw that you only needed to edit the quantities after scanning one single time. There is only one issue we have in that regard. We are not able to find absolutely any products data in that FDA API. However we are in the process of creating manual entries that will be saved, so it will only be a problem the first time that item is scanned. Attempting to keep our theme of user friendliness.

It has been cool and very rewarding for the team to actually see our project function this way. We’ve all done projects where things don’t really get to the point of looking and functioning like a completed product. This is a first for a few of us.

Our communication with each other during the weeks has stayed pretty consistent throughout this entire semester. I would say that is the strongest characteristic of this team. We all hold each other accountable by just being visible and seeing the others working hard to get this done.

Relating our team with a chapter from the book apprenticeship patterns, a good one would be – be the worst. With our strong communication and the fact we are putting the different parts of our project together into one product. We all noticed the strengths each member has to offer. All though this does not perfectly match the example of the book by surrounding yourself with a full team that is better than you. I think we have all done a good job at noticing each other’s strengths and understanding of each portion. This sprint showed how much we really started to learn and grow as a team. 

After sprint one I wanted to make it clearer for everyone to understand what each part of the team was doing and where they were at. This sprint actually managed to do a lot of this for me. While putting the pieces together everyone really started to see the full picture and there was points when you could see the excitement across everyone’s face when things started to shape up and start working. This also proved to create a more cohesive team as the pairs that had been working in a more broken off system were having to explain what they did in order to get certain parts to function properly. Now that everyone’s working in the same directories we all witness the fast pace of progress we have had the whole time, that I believe I was the only one really witnessing.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend

-this is the current state of our project. It has a working webpage, back end and fetch script that works between them.

Start up:

  • start the backend using bin/rebuild.sh
  • Install the live server extension on vscode
  • Right click scanner.html and open with webpage
  • Start scanning items =]

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.