Posts

Sprint 3 Retrospective

In this post, I’ll be reflecting on our third and final sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 2, we had an almost-fully-functional proof of concept which integrated a mock frontend capable of calling out to Keycloak to require authentication, getting an access token, and passing that token to the backend for authentication and validation. Our goal for sprint 3 was to fully implement production microservices for Keycloak, the IAMBackend, and the IAMFrontend. These goals may not have been explicitly defined like that at the beginning of the sprint, but that ended up being our objective. We also wanted to have finalized documentation that explains our implementation and design choices. Some of my personal work towards that goal was as follows: GitLab Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, b...
Post a Comment
Read more

Sprint 2 Retrospective

In this post, I’ll be reflecting on our second sprint towards developing and implementing an Identity and Access Management system for Thea’s Pantry. Coming out of Sprint 1, we had a better idea of Keycloak in general, and we had some basic frameworks for a fake frontend and fake backend. Our sprint goal for Sprint 2 was to fully integrate these components, so that we could provide a proof of concept for the entire workflow, as opposed to just one component. We wanted to be able to force authentication on a frontend page via a Keycloak login page, and then we wanted to be able to store the resultant access token from that interaction so that we can perform authenticated actions without ever talking to Keycloak again. Some of my personal work towards that goal was as follows: GitLab Documenting our low-level issues in GitLab and assigning them accordingly. I put additional focus/effort this sprint into properly linking related issues, blockers, and tracking various key information in co...
Post a Comment
Read more

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems. Some of my personal work towards that goal was as follows: GitLab Documenting our low-level issues in GitLab and assigning them accordingly. Epic Backend Create API endpoint specification and schemas for role checking functionality. Endpoint , Schemas Create test calls with mock JWTs to test the endpoint. Test Call Implement backend JWT processing/decoding logic. CheckRole.js Implementation Frontend Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user...
Post a Comment
Read more

On Structuring and Managing Test Cases

  In this post, I’ll be discussing a recent article I came across on the TestRail website, which can be found here . The post interested me because it dives deep into the importance of organizing and managing test cases effectively, a topic that we have been covering closely in class. As someone who does a lot of tests in various stages, this article gave me some good notes about how proper test case management can streamline the testing process and reduce the risk of overlooked issues. One of the key takeaways from the article was the concept of structuring test cases with clear, concise steps and expected outcomes. This was notable because I’ve often seen situations where poorly written test cases lead to confusion or unnecessary delays. The article emphasized that each test case should be easily understandable, even for someone unfamiliar with the project, which makes a lot of sense. Clear test cases not only make the process smoother for current testers, but they also provide b...
Post a Comment
Read more

On CI/CD Pipelining

  In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “ An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers .” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times. One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in m...
Post a Comment
Read more

On Integrating Automated Testing

  In this post, I’ll be discussing my thoughts on a recent article I read from the Software Testing Help website, which can be found here . The piece really struck me because it reinforced many of the ideas I’ve come to believe about the role of testing in the software development lifecycle, particularly how automation can improve both speed and quality. I’ve always been a fan of automated testing, but this article helped me think more deeply about how it should fit into the broader testing strategy. One of the key points in the article was the idea of balancing automation with manual testing. While automation is critical for repetitive tasks and quick feedback, the author pointed out that certain aspects of testing—like user experience—cannot be fully captured by automated scripts. This really resonated with me, as I’ve encountered situations where automation was great for catching functional issues, but it missed some of the nuance that a manual tester might be able to identify o...
Post a Comment
Read more

Always Improving Software

In this post, I’ll be discussing my thoughts primarily on Chapter 1 of Apprenticeship Patterns , a book I had to read parts of for another class . I really like the idea of being a “Software Apprentice,” as I think it is a good representation of the attitude I have adopted over the years. I’ve always viewed myself as someone who is constantly learning and evolving in this field, and the apprenticeship model seems to align perfectly with that. It’s not about arriving at some endpoint but about growing, making mistakes, and improving. What stood out to me the most was the idea of viewing the development process as a journey, not a destination. Chapter 1 introduces the concept of “Software Craftsmanship” as more than just technical skill, but also as a mindset of continuous learning. This was particularly thought-provoking because I think there’s a tendency, especially early in our careers, to think of coding as a task to be completed or a skill to be mastered and then moved beyond while ...
Post a Comment
Read more