Category Archives: Blog

Data Flow Testing

Source: https://www.testbytes.net/blog/data-flow-testing/

Data Flow Testing, viewed as a nuanced approach in software testing, is the process of examining data variables and their values through the use of the control flow graph. Data Flow Testing is an example of white box and structural testing. By targeting gaps that become prevalent within path and branch testing, data flow testing aims to locate bugs from the misuse of data variables/values. 

Data flow testing is used on both static and dynamic levels. In static levels, data flow testing involves the analysis of source code without actually running the application. The control flow graph in this instance represents execution paths of the code from the application. Errors that can be found on the static level include, definition-use anomalies (a variable is defined but is never used), redundant definitions (variable is defined multiple times before it’s used), and uninitialized use (a variable is used before a value has been assigned). 

On the dynamic level, the application is executed, and the flow of data values/variables is analyzed. Issues that can be found on this level include, data corruption (value of a variable is modified in an unexpected way, leading to undesirable behaviors), memory leaks (unnecessary memory allocations, memory consumption becomes uncontrolled), and invalid data manipulation (data is manipulation in an unpredicted way, causing many outputs).

The steps of data flow testing include identifying the variables, constructing a control flow graph, analyzing the flow of data, identifying anomalies in the data, dynamic testing, designing test cases and executing them, resolving anomalies, and documentation. I decided to read about data flow testing because I thought it’d be valuable to learn about how this type of testing allows for early bug detection and overall improved code quality and maintainability. The obvious downsides however are that not every possible anomaly can be caught, the process can be time consuming, and other testing techniques should also be used.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Static vs Dynamic Testing

Source:
https://www.browserstack.com/guide/static-testing-vs-dynamic-testing#:~:text=Static%20testing%20focuses%20on%20reviewing,to%20find%20bugs%20during%20runtime.&text=It%20is%20performed%20at%20the%20later%20stage%20of%20the%20software%20development.

This article is titled “Static vs Dynamic Testing” and explains the differences between them and how they allow for the development of quality software. Static testing is testing where the application isn’t being actively used. Code is manually read through to search for errors. As a result, a computer is not necessarily required for this form of testing as design documents containing the code can be reviewed. This kind of testing is done before the code is executed and early in the development process. The benefits to static testing are that defects are able to be found earlier in the process, it’s usually more cost-effective than other testing techniques, leads to more maintainable code, and encourages collaboration between team members. However some disadvantages of static testing are that not all of the issues could be found until the program/application actually runs, it depends on the experience of the reviewers for it to be effective, and it usually has to be done alongside dynamic testing to uncover other potential issues.

Dynamic testing involves giving an application input and analyzing the output. Code is being compiled in a run-time environment. This form of testing also relies on the expertise of the reviewers as deep knowledge of the system is required to understand how and why a system reacts based on the input. The advantages of dynamic testing are that runtime errors, memory leaks, and other issues that only come to fruition during code execution are revealed, helps verify that the software is working as intended by the developers, and ensures that all parts of the system work together appropriately. However some disadvantages of dynamic testing are that it can be time-consuming, may not cover all possible scenarios, and may be difficult to test uncommon instances in the program. 

Overall it is important to realize that static and dynamic testing are both important in their own ways and emphasize the importance of performing various kinds of testing methods to ensure an application works as intended. I chose this article because we discussed these topics in class and figured learning more about them would be beneficial. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Gitlab activity:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/37

This was my first task I worked on during sprint 1. I updated AddInventoryPage.vue to match the design elements of Main.vue from CheckOutGuestFrontend to foster consistency in design layout.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/38

This merge request involved the refactoring of a few files so AddInventoryFrontend was able to load on port 5173 in the browser and connect to InventoryBackend, I submitted this merge request as an update on my work before the sprint 1 review, as complete implementation wasn’t done yet, the adjusted total weight of the inventory wasn’t working in this request.

These next two merge requests fix the issue of the previous one (adjusted total weight of the inventory is now being returned):
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/59
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/39
There was an issue in InventoryBackend’s updateInventory.js file where the value was being returned incorrectly, so this was fixed and allowed the adjusted total weight of the inventory to be displayed in backend calls and in AddInventoryFrontend.

What worked really well in this sprint was the communication between all of the teammates. I acted as scrum master and there was no push back for getting work done. Everyone was able to work on their tasks independently and utilize teammates for help during class sessions. Discord was a big help in terms of ensuring we were keeping track of each other’s progress outside of class and was a good place to pose questions or ask for help. What didn’t work that well was the way in which we established goals for the sprint. This is our first one so it was to be expected, but going forward with sprints 2 and 3 we are aiming to establish more focused issues to work on. The goals of sprint 1 were too broad and made it feel as though not much progress was made even though we worked diligently.

Overall, as time goes on we continue to work better as a team. As a result, I don’t have many suggestions for improvement. However, establishing more focused goals as previously mentioned would improve our workflow, maintaining positive and consistent communication is obviously valued, and increasing how often we show each other what we’re working on are all things that can be considered. The biggest fault of our team is that sometimes teammates won’t really know what others are working on, even though they are contributing to the project. It’s important going forward to help visualize how everyone is contributing by ensuring there are consistent check-ins. Personally, since I’m still acting as scrum master, I should try to promote these check-ins myself instead of relying on teammates to initiate this. Having conversations going forward about who should be the scrum master, for how long, etc., is also something that I could mention. 

From Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, the most prevalent pattern for this sprint may be “Expose Your Ignorance,” just today we were shown the value of this pattern. One of our team members was able to solve two separate issues that were preventing merge requests from being made. The basic idea of exposing your ignorance is that you’re showing those around you that you don’t necessarily know everything, you’re open to receiving help, and you want to learn throughout this process. Instead of feeling the need to appear competent, you are fostering a learning environment for everybody. I selected this pattern to mention because if we as a team were consistently exposing our ignorance, we could have potentially accomplished a lot more. Yes, individual work is important, but the hours spent on your own trying to fix an issue to no avail is not always worth appearing competent to your peers. If this pattern was read during the sprint, more questions could have been asked and answered, and more contributions to the project could have been made. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Beginning the reading of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, I can say that I was expecting this book to be a lot more technical. However, the entirety of this reading was very thought-provoking. The idea of apprenticeship has always been interesting to me, and applying those principles in the modern era workforce of software development makes complete sense. Striving to continuously learn, receive guidance from your seniors, and actively indulge yourself in new technologies, will allow someone just starting their career to surely become the biggest fish in their pond, and ultimately cycle through the process of starting as the smallest fish and yet again becoming the biggest. This metaphor from the reading offers a vivid illustration of the importance of not becoming too complacent with your work and learning. Being the biggest fish in a small pond will not grant you any opportunity or growth, you have to surround yourself with individuals who are able to teach you something. Many people, including myself, have been led to believe that you should accept the highest paying job and quickly pursue roles in management. In reality the most meaningful aspect of the job is what you can learn from it, prioritizing this will pay off far greater than the short-term satisfaction of the high-paying job. The reading shifted my perspective from this cash grab mindset to a “knowledge grab” mindset. In regards to workflow on the job, the reading showcases the importance of utilizing your team to achieve a greater sense of productivity and insight into how methodologies and systems really work. Software development is a field of collaboration where everyone should be contributing to the pursuit of knowledge. There’s nothing in the reading that can really be disagreed with unless you are not truly meant for, or passionate, about the field of software development. The idea of creating your own curriculum might frustrate some people as it alludes to bringing your work home with you, however, in an ever-changing field such as this, self study is completely necessary. This is probably the most important chapter because it points to the idea that if you do not possess the inner motivation to study new material on your own terms, you may not be cut out for the job.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

CS-443 Intro Post

Hello, this is my first post for my Software Quality Assur & Test Course (CS-443). I’ll be making posts related to this course in the upcoming weeks.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

LFP Blog Post

One thing I found interesting from the LibreFoodPantry was found in the “Values” section and it was the link to FOSSisms. A FOSSism is a maxim for free and open source culture, and these are used to explain the benefits of open source values in computer science education. The article lists 16 of these. The most important FOSSism is the first one listed. It references “it’s all about community” and this is most definitely the entire point of open source software. Incorporating students with open source projects involves a lot more than simply working on a software project, it requires getting involved in a community of like-minded individuals who are all contributing to the project. These projects are mostly contributing to a greater social good. I chose to write about this because community is a huge part of the workforce and emphasizing this in open source projects is really important for effective collaboration.

One thing I found interesting from the Thea’s Pantry was the “Architecture” section. If we as students in this capstone class/project are going to be contributing to this software, it is definitely important to understand its architecture and all of its individual components. It was interesting to read that the client solution is composed of systems such as:

  • GuestInfoSystem
  • InventorySystem
  • ReportingSystem
  • IAMSystem (Third-party)
  • EventSystem (Third-party),

and that each of these systems has a multitude of features. The integration and deployment diagrams were a good piece of visualization to help understand the scope of the project. I chose to write about this because I recognized the importance of understanding the architecture of a project that one is working on.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Working as a Front end developer

Now that I have heard about people’s experiences working on the back end, I was curious about people’s experiences working on the front end. Reading personal experiences taught me a lot about working on the back end. You can learn a lot and avoid mistakes by seeing others take similar paths. Also, it can prepare you for problems that you may face in the future. Mistakes are inevitable but being able to adapt or being able to recognize it and fix it goes a long way. Working on projects especially those that have to do with coding errors is always a step away. You can try to get a step ahead on these problems by seeing other people work and implementing it on your stuff. That is why I found an article about working as a front-end developer. These articles are very engaging and always give me a new perspective.

This article is written by Selim Enes who has done freelance work in the past but is currently working as a developer. When he first started he was working on small things like CSS edits until he proved himself. One of his major projects was a blog project where he had to create the display of the UI. He was involved in all operations after 2 months. When he proved to the team that his code wouldn’t crash the project he gained access to the company’s main project. The company’s main project entailed a webinar application that used technologies like WebSocket. One thing that made him know he was going in the right direction was being able to develop features like push-to-talk by himself. There are some negatives to his work with his boss being very hasty on projects. He believes all tasks are urgent and make some work very stressful. Plus with the recent economic regression, he doesn’t believe he will be able to get a raise anytime soon. He has learned to have a full-stack blog project for himself and has an e-commerce project his about to start working on. He is working while also building his portfolio outside of work.

Reading this article was very insightful. It made sense that when you first start working for a company they won’t give you the keys to everything just yet. They ease you up into it until you have gained their trust. Working on his portfolio outside of work motivated me to do the same too. You can sometimes become complacent at your job because you have a living but you shouldn’t. You should always try to improve and hope to find better opportunities elsewhere

View at Medium.com
https://medium.com/@sellimenes/1-year-experience-as-a-junior-front-end-developer-39766fad5c34

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

Code Review

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

This article is titled “What is a code review?” As clearly stated by the title, the article explains the processes of code reviewing. “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Code reviews help in the identification of bugs, increase the overall quality of code, and enhance understanding of the source code. Code review, as suggested in the name, happens after a software developer has finished coding. Code needs to be checked before it is merged into an upstream branch for bugs or conflicts. A code reviewer “can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, two experts should review the code.” Adhering to a solid code review process allows for continuous improvement of code and aims to ensure that faulty code isn’t being implemented for customers/users to see and use. This process isn’t just important for the code itself, but also for all of the team members of a software development project. Whilst reviewing the code, meaningful knowledge of the source code is shared between team members to ensure that it is being implemented properly. The main benefits of the code review process are: the sharing of knowledge, discovering bugs earlier, maintaining compliance, enhancing security, increasing collaboration, and improving code quality. Code reviews allow for maintaining compliance because different developers have different backgrounds and thus different personal processes when they are developing. Code reviews allow these people to get together and maintain a standard coding style. Security is enhanced because “security team members can review code for vulnerabilities and alert developers to the threat. Code reviews are a great complement to automated scans and tests that detect security vulnerabilities.” There are many benefits to code review, but there are some disadvantages, including: longer time to ship, focuses being pulled from other tasks, and large reviews mean longer review times. These can be described as necessary evils due to the sheer amount of positives that code reviews offer in software development.

I chose this article because it was published by GitLab, a software that we are heavily using in class for version control, and I thought that it would be interesting to read this specific topic from the syllabus. Version control softwares such as GitLab allow code reviews to happen, so diving deeper into the topic in an article published by this popular software company was tempting. Before reading this article I understood that code reviews were important to pinpoint any bugs or difficulties before merging code into the upstream, but I never really thought about the implications of security or different development styles. I’ll definitely keep this information in mind during future code reviews on the job to remind myself that bugs aren’t the only important thing during a code review.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Software Maintenance

Source: https://www.geeksforgeeks.org/software-engineering-software-maintenance/

This article is titled “Software Maintenance – Software Engineering.” Software maintenance “refers to the process of modifying and updating a software system after it has been delivered to the customer.” There are many different aspects involved in this including: fixing bugs, adding new features, and keeping up with new hardware and software requirements. Maintenance is very important for ensuring that software is able to last long. This process can be expensive and complex, so these factors must be taken into account during the planning of a software development project. The important tasks in regard to software maintenance are: bug fixing, enhancements, performance optimization, porting and migration, re-engineering, and documentation. Summarizing these tasks, it is important to find and fix errors quickly, add new features/improve existing ones, improve the performance of the software, adapt the software to run on different hardware, improve the design, and maintain accurate documentation of all of these processes. There are quite a few different types of software maintenance, but they can be categorized into proactive and reactive types. “Proactive maintenance involves taking preventive measures to avoid problems from occurring, while reactive maintenance involves addressing problems that have already occurred.” Maintenance can be done by stakeholders, the development team, a third-party, and they can be both planned or unplanned. Planned maintenance can be described as regular maintenance (bug fixes) while unplanned maintenance can be described as reactive maintenance that occurs when something unexpected happens. Maintenance can fall into these different categories: corrective maintenance, adaptive maintenance,  perfective maintenance, and preventive maintenance. Corrective refers to fixing bugs and enhancing performance of the system. Adaptive refers to modifications being made when a customer needs the software to run on a different system. Perfective refers to the adaption of the software when a customer has a demand. Lastly, preventive maintenance refers to modifications that focus on the prevention of future issues with the software. Software maintenance is important but there are some things to consider: the cost, complexity, possibility of new bugs, users not updating the software, compatibility, technical debt, and end-of-life (where maintenance isn’t possible anymore or cost-effective).

I chose this article because I found it in the syllabus and thought the topic to be interesting. We are always learning about the development of software, but the idea of maintaining it over the long term isn’t as heavily considered. A large part of the work of a software development team is to obviously develop software but it is also important to learn about how it can maintain a sense of longevity free from error and customer complaints. I will keep the information I learned from this article in mind in future projects and when I’m working with a team to ensure that I’m developing software all the while keeping maintenance in mind. If it is considered during the development process, the maintenance process will be much easier.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.