Category Archives: agile

Code Reviews for Quality Assurance

As we continue in CS443 – Software Quality Assurance and Testing, we’ve delved into the test strategy/skill of group code reviews for debugging. So, this week I chose to search for a blog about effective code reviews with a focus on good practices to extract the most value from participating in them and found a valuable article posted on Vates.com. This article is from August 2023, so it is modestly recent and applicable to our current learning materials and discusses best practices and habits.

Code review is a pivotal practice in software development, offering more than just bug detection. It serves as a collaborative process where developers meticulously inspect code changes before integration into the main codebase. By doing so, it not only identifies defects but also enhances code quality, ensures alignment with project requirements, and upholds coding standards. The process fosters collaboration among team members, facilitates knowledge sharing, and integrates multiple perspectives, ultimately leading to the creation of reliable, maintainable, and efficient software.

To maximize the benefits of code review, it’s essential to implement effective strategies. This begins with establishing clear objectives tailored to the project’s goals. By defining specific focuses, such as code quality improvements, security enhancements, or performance optimizations, teams can streamline the review process and prioritize areas of concern.

Moreover, involving the right team members is crucial. Senior developers, subject matter experts, and team leads contribute diverse viewpoints, enriching the review process and leading to better outcomes. Adhering to a comprehensive code style guide ensures consistency in coding practices, which is vital for long-term maintainability. Utilizing code review tools further enhances efficiency by automating checks, highlighting changes, and facilitating collaborative discussions.

Promoting a culture of constructive feedback is equally important. Emphasizing that reviews aim to enhance overall code quality rather than criticize individuals encourages open communication and continuous improvement. Balancing review speed with depth ensures timely feedback without compromising quality, fostering agility while maintaining code integrity.

Lastly, following up on review feedback is essential for iterative improvement. Addressing comments promptly, clarifying questions, and implementing necessary changes contribute to a learning culture within the team, leading to continuous enhancement of development practices.

Vates is a leading provider of IT and software services and the host of this blog. They provide tools and resources to enable teams to unlock the full potential of code review, IoT consulting, and software testing services. This collaboration empowers organizations to elevate their software development practices, delivering exceptional value to stakeholders through collaborative development and effective code review implementation.

Source:

https://www.vates.com/the-art-of-code-review-effective-strategies-for-collaborative-development

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.