Author Archives: jelbirt

CS448 – Sprint 3 Retrospective

Last Tuesday, we concluded our final of three sprints for CS448 – Software Development Capstone marking the end of the semester/course aside from our final presentations and the ‘capstone’ to my undergraduate Comp. Sci. degree. This sprint and throughout the semester, my team demonstrated exceptional cohesion and proficiency as we learned new skills and frameworks, tackled challenges, and grew together. At the end of last sprint, we still had a few issues with some of the configuration files in the frontend repo we’ve been focusing on: CheckoutGuestFrontend which were causing Pipeline failures. So, we began this sprint by focusing on getting the pipeline straightened out and then moved into strategizing front-end testing frameworks and implementation after having discussed these topics last sprint with

Team 2.

As a team, we managed to finish all of our tasks for this sprint and come to a tidy/clean close to the semester and Thea’s Pantry project. We split the four .vue files which we needed tests developed for up by person, but all helped each other get the first one/configurations sorted:

‘Fix Pipeline for Frontend’ – As mentioned, there were some issues with the pipeline from our additions and designing of the .vue frontend files for CheckoutGuestFrontend in merging our additions. So, we started off this sprint by focusing on this; we did a group code review sharing screen and we were able to work as a team to identify and resolve the problems, passing the pipeline when we finished. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/49

‘After discussing with Team: 01-02, strategize Front-end test implementation’ – After resolving the pipeline issues (and having met with Team 2 to discuss frontend testing), we came back together as a group to strategize how we will go about implementing tests for the various components of CheckoutGuestFrontend. This resulted in creation of four new issues for our board, each representing the task of coding and implementing tests for one of the four .vue files in our repo – planning for one to be addressed by each team member. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/93

‘Test Layout.vue (most cases)’ – The .vue file which I worked on from our repo was Layout.vue. This is arguably the largest/most complicated of our files containing code for most of the objects on the screen and as the name suggests, assigning their layout on-screen to be cohesive and according to specifications. This also translated to having many components requiring testing, so I assisted in strategizing tests for some of the other files with my teammates so I could be a bit more familiar when designing my tests.  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/52

Being a part of this team has been an amazing and enriching learning experience. My group was cohesive and helped each other out when they could, contributing to an enjoyable team environment. Through thorough analysis and collaborative problem-solving sessions, we unearthed and swiftly addressed the root causes of inefficiencies, ensuring a streamlined development process going forward. One of the most significant accomplishments of this sprint was our concerted effort to fortify our codebase with robust frontend tests. Recognizing the importance of software reliability, we dedicated time and resources to meticulously design and implement a suite of tests tailored to our repository’s specific needs. This proactive approach not only bolsters our confidence in the integrity of our code but also enhances our ability to catch and rectify potential issues early in the development cycle. As I look back on the sprint and semester, it’s clear that our team’s collective expertise and collaborative spirit were instrumental in achieving these milestones. By prioritizing quality and teamwork, we’ve not only overcome immediate challenges but also laid a solid groundwork for continued success in future endeavors.

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.

“Draw Your Own Map” Individual Apprenticeship Pattern

This week, I decided to focus on the “Draw Your Own Map” Individual Apprenticeship Pattern for CS448-Software Capstone. This is my final required apprenticeship pattern analysis post, and I chose this pattern because it feels applicable to me as I am about to graduate and enter the working environment, mapping out my intended career path from its starting point. 

The “Draw Your Own Map” individual apprenticeship pattern emphasizes the importance of taking control of one’s career development and learning journey. It encourages individuals to proactively chart their own course rather than relying solely on predefined paths or external guidance.

At its core, this pattern advocates for self-directed learning. It urges individuals to actively seek out opportunities to acquire new skills, knowledge, and experiences that align with their career aspirations. Setting personal goals is essential in this process, providing a roadmap for growth and development.

Identifying various learning opportunities, both formal and informal, is crucial for professional advancement. This could include attending workshops, pursuing certifications, participating in projects, or seeking mentorship. Adaptability and flexibility are also key, as career paths may require adaptation and adjustment over time.

Regular reflection on progress is encouraged to refine goals and adjust course as needed. By reflecting on past experiences and learning outcomes, individuals can iterate and improve their development strategies. Additionally, building a personal brand and reputation within the industry is essential for showcasing skills, expertise, and achievements.

In essence, the “Draw Your Own Map” pattern empowers individuals to navigate their professional journey with autonomy, self-reflection, and continuous learning. By embracing ownership of their career trajectories, individuals can pursue their long-term goals with purpose and resilience.

With such a competitive entry-level environment, it is possible that I may find myself (or at a later point in my career) choosing to take a position that may not fully align with my interests and career goals. Additionally, with all of the ongoing changes in the tech industry and world as a whole, what may have been a traditional and common career path is impractical today. So, it’s crucial that I can draw my own map to success and redraw it as necessary throughout my career. By following the strategies outlined in this apprenticeship pattern, it seems a lot more realistic to be able to take a starting position that may be less-than-ideal while still progressing toward my intended goal.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

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 2 Retrospective

Our second of three sprints for CS448 – Software Development Capstone concluded and was reviewed last Tuesday (4/7/2024). My team worked very well together this sprint and we helped each other as we stayed flexible and adaptable as changes were rolled out that affected our repo and issues. Additionally, most of our issues focused on FrontEnd tasks including the design, development,  and integration of a user interface for the CheckoutGuestFrontend repo. UI design and particularly implementing Vue.js framework was mostly unfamiliar for our group, so we learned a lot from what we accomplished this sprint.

While we didn’t quite finish all of our initially planned tasks, we did successfully reorganize issues into smaller/more manageable and defined issues mid-sprint and we completed all of our issues up to testing the front-end we built:

“Get in touch with Team: 01-2 and discuss Frontend Tests and their findings” – When we took on the task of developing the CheckoutGuestFrontend repo, we found Team 2 had already taken on some responsibilities and begun researching front-end testing. So our first order of business was holding a meeting with them to decide on a starting point for our group. Our notes from the meeting are recorded here.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/92

“Review GUI Mockup” – For this task, we all met as a group to go over a basic on-paper mockup of what we envisioned and had in mind for the CheckoutGuestFrontend GUI and break down the task of coding the GUI into smaller, more manageable and well-defined issues. In the issue, we document our hand-written mock-up as well as our meeting notes and the smaller issues we refactored to. The “Consider Interaction Boundaries” and “Modify/Improve GUI Framework” issues were encompassed in the preparation and execution of this Review task.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/45

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/44

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/42

Main issue:

“Coding UI to place components on the screen where we want them (“layout”)” – This task encompasses the overall processes of creating the Vue.js, integration, and other resource files and code to actually implement our mock-up. This was our first time working with Vue.js, and we are also less experienced with JavaScript as compared to other languages like Java and Python, so we hit some setbacks and delays as we explored and learned more about using these. There were also some minor steps involving communication protocols that were learning experiences.

Another obstacle we traversed involving this issue is the rollout of the new frontend model by Dr. Wurst. When we first tackled this problem, it was not yet released so we struggled to get a working baseline/framework to edit and build off of.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/43

“General – Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” – This was a task from last sprint which we did not quite complete. This sprint we finished it up by verifying the necessary components. Once the working model was rolled out, we managed to build ours out to a stable state with an attractive UI by holding several full-team code reviews. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12 

In review, our second sprint for CS448 – Software Development Capstone was driven by patience, teamwork and adaptability. Despite encountering challenges, particularly in navigating unfamiliar territory with UI design and Vue.js implementation, we emerged stronger and more knowledgeable. While we didn’t fully complete all initially planned tasks, our ability to reorganize issues mid-sprint into smaller, more manageable ones allowed us to focus on essential aspects. Key achievements included productive collaborations with Team 01-2 on frontend testing, thorough review and refinement of GUI mockups, and overcoming hurdles in coding the UI with Vue.js. We also successfully addressed pending tasks from the previous sprint, ensuring all projects within Thea’s Pantry ecosystem met required standards.

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.

Nurture Your Passion Individual Apprenticeship Pattern

This week, I chose to focus on the Nurture Your Passion individual apprenticeship pattern as I found it applicable to myself as I am looking for post-grad jobs and in one respect must find a job to support myself financially but also look to further myself as a software craftsmen and in my career in general. This pattern underscores the significance of fostering and sustaining enthusiasm for software development. It acknowledges the vastness and perpetual evolution of software engineering, urging developers to actively delve into their interests within the field.

To effectively nurture one’s passion, the pattern recommends the following strategies:

Explore Diverse Areas: Dedicate time to investigating various facets of software development, including web development, mobile app development, artificial intelligence, and game development. Experiment with different technologies, languages, and frameworks to discover personal resonances.

Engage in Personal Projects: Undertake personal projects aligned with individual interests and aspirations. Whether it involves crafting a mobile app, contributing to open-source software, or developing a game, personal projects offer valuable opportunities for skill application, learning, and portfolio enhancement.

Seek Mentorship and Guidance: Surround oneself with mentors, colleagues, and communities sharing similar passions, capable of providing guidance, support, and constructive feedback. Participation in forums, attendance at meetups and conferences, and networking within the software development community fosters idea exchange and shared experiences.

Continuous Learning: Embrace lifelong learning and professional development. Stay abreast of the latest industry trends, tools, and technologies through literature, online courses, workshops, and conferences. Continuously challenge oneself to refine and broaden skill sets.

Balance and Well-being: Strive for equilibrium between passion pursuit and well-being. Guard against burnout by establishing achievable goals, managing time effectively, and prioritizing self-care practices, such as physical activity, relaxation, and quality time with loved ones.

By nurturing a passion for software development, individuals can discover heightened fulfillment, creativity, and satisfaction in their work, ultimately leading to a more gratifying and successful career. I found this apprenticeship pattern to be particularly helpful and relatable as it also complements the Breakable Toys strategy which I covered in a previous post. Even if craftsmen find themselves in a position or situation where they struggle to pursue projects their passionate about, they should devote time to creating a breakable toy to enjoy and continue to learn and grow with.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

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.

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.

Learn How You Fail Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Learn How You Fail” Individual Apprenticeship Pattern, which jumped out to me as I have been considering and focusing on some of my weaknesses as I prepare to graduate and search for an entry-level position.

This pattern similarly focuses on embracing failure and weaknesses as a learning opportunity that is essential for personal and professional growth, and doing so is a crucial part of the journey of the software craftsman. Rather than looking at negatives and seeing them as a setback, “Learn How You Fail” encourages developers to confront their mistakes, analyze them/their origin, and derive valuable lessons that contribute to their ongoing growth.

By doing so in a calm, focused and organized manner, developers can really be thought of as simply taking the necessary steps to progress rather than being caught on a setback and needing to reconsider an approach (or similar). A large part of this pattern is simply mental – viewing failures as stepping stones toward mastery rather than indications of incompetence.

One of the key aspects of this pattern is the necessity of self-awareness. Developers must be able to critically reflect on their actions, decisions, and outcomes. By understanding their strengths and weaknesses, they can identify areas for improvement and take proactive steps to address them. This self-awareness also fosters humility, as developers recognize that no one is perfect and there is always room to learn and grow.

Finally, the “Learn How You Fail” pattern emphasizes the importance of perseverance. Failure can be discouraging, but it should not be a reason to give up. Instead, developers should use setbacks as motivation to keep pushing forward, armed with the knowledge and insights gained from their failures. With each failure comes an opportunity to iterate, improve, and ultimately succeed.

I particularly appreciate this pattern because I have implemented it several times successfully and have adopted it as a general approach to life. Everyone has imperfections and weaknesses, so it’s most important to acknowledge and be aware of these so we can aim to improve upon them over time and lessen their impact on our day-to-day, career, and every other aspect of our lives.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

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.

A Look at Test-Driven Development & Benefits

Since just before Spring Break, in CS443 – Software Quality Assurance and Testing we have transitioned on from boundary/equivalence class analysis and onto Test-Driven Development as a strategy as well as implementation. For me, this is a huge relief and joy to get back to working on actual code rather than theoretical comp. sci. work, though it also helped me recognize the importance of non-coding exercises. 

I’ve also been really enjoying TDD as I find it aligns with my general coding habits and builds off them to help me identify new coding practices and strategies for addressing challenges. So I decided to look at some blog posts discussing it and how it’s impacted software projects versus other methods used. Test Driven Development Is the Best Thing to Happen to Software Design instantly jumped out to me.

The post discusses the significant influence of Test Driven Development (TDD) on software design. It explains TDD as an iterative approach shaping an idea into implementation through a cyclical process of ‘fail-pass-refactor’. The author illustrates the two approaches to writing code and tests: one driven by code and the other driven by tests, emphasizing the benefits of TDD in terms of mindset and code quality.

This post also considers TDD in real-world scenarios, highlighting its capacity to provide fast strategic approaches to software challenges that may seem to have no place to start (by creating tests). It addresses challenges in testing and offers solutions such as spying or mocking, managing variable test data, avoiding bloated setup, and preventing “Mocking Hell.”

Additionally, the post discusses the tendency to add unnecessary features in code and how TDD, by its nature, prevents such occurrences, thus aligning with the principle of “You Ain’t Gonna Need it” (YAGNI). This is definitely a fault that I fall victim to at times as I try to plan ahead too far in a project and add unnecessary code so I appreciate strategies to address it. Finally, it suggests that TDD not only aids in requirements meeting implementation but also serves as a technique for gathering feedback about software design, thereby advocating for Test Driven Design (TDD).

My typical strategy for developing code begins with creating a skeleton of basic components I expect to be easy to implement and then fill out the boundaries and remainders by developing minor unit tests (like print lines) to make sure it is working as intended. I sometimes do them at the same time, but I have been doing TDD sometimes without knowing it and am now better prepared to hone in on its benefits.

Source:

https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

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.

Decision Tables from a Template

Over the past few weeks in CS443 – Software Quality Assurance and Testing, we’ve been learning how to apply our boundary test classes to create Decision Tables and apply somewhat similar logic to create Program and DD-Path Graphs for code segments. Decision tables are visual tools used in software testing and analysis to specify actions based on given conditions. The strategy we learned in class of assessing all possibilities then systematically combining them based on the decision outcomes and particularly “Don’t care” scenarios seems like a useful and interesting way to map out test designs.

So, I decided to look into blogs discussing Decision Tables and their implementation in software testing and found a great post on ShiftAsia with abstract and specific examples alongside general discussion. This post is also quite recent – posted on January 9, 2024 – which is something I always appreciate as the software/tech world is constantly changing. It opens by describing how to create a Decision Table by representing it with the following matrix:

Condition Stub Condition Entries
Action Stub Action Entries

Condition stub: List of all conditions in consideration

Condition entries: Filled out with Y/N (or X) to cover all possible combinations of conditions

Action stub: List of all possible actions/output

Action Entries: Marked (generally with X or blank) to show outcome and an association between a condition and result.

This is then illustrated with an example of being able to register according to conditions of having a valid email, registered email, and valid password. I found this template and example helpful to better understand Decision Tables in general by comparing them to the steps we did in our In-Class Assignment 7. And, using the example of an altogether invalid email forcing all results to be “Invalid” makes sense logically for the column consolidation.

The process of combining columns and simplifying Decision Tables is reminiscent of CS254 – Computer Architecture and Organization concepts, particularly using K-Maps to calculate Sum of Products and Product of Sums. Based on similar responses to a variety of inputs, we are able to essentially combine and simplify the K-Map table and in turn the expression it produces. While K-Map logic works based on binary math laws rather than actual outcomes, there’s a clear correlation here as we represent outcomes with boolean values that can be easily represented in binary – as either a 0(false) or 1(true). My personal experience in CS254 wasn’t the best – I didn’t totally understand how many of the concept we learned are applicable in practical situations, so it’s cool and exciting to see it applied in software testing – an area I would’ve probably least expected it.

Sources:

https://blog.shiftasia.com/use-decision-table-in-software-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.

Breakable Toys Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Breakable Toys” Individual Apprenticeship Pattern; while I did not know it when I selected this pattern, it relates back to two other patterns I analyzed earlier in the semester: “The White Belt” and “Confront Your Ignorance”.

The “Breakable Toys” pattern encourages craftsmen working in high-risk environments intolerant of failure to create personal projects, referred to as ‘Breakable Toys’. These projects are typically smaller in scope but similar in toolset to work systems, providing a safe space for experimentation and learning through failure. The pattern advises building tools like wikis, calendars, or address books, which may be overengineered but allow for trying new ideas without significant consequences. Given the book’s original publishing in 2009 and the progression and advancement of technology/platforms since then, other tools and platforms may be more applicable and resources like Git make tracking and controlling versions easy.

The focus is on personal growth, skill development, and enjoying the learning process, ultimately fostering a deeper understanding of tools and encouraging continuous improvement. In this way, this pattern is similar to “The White Belt” and “Confront Your Ignorance”, but focuses on building off of prior knowledge in a low-stress environment rather than ignoring it.

I really enjoyed reading about this pattern and its benefits as it is one of my favorites to implement – actually, while reading it I realized how many skills I have picked up using this method. As an individual, when I learn new skills/tools I naturally want to practice them and their non-instructed limitations as well as just generally play around. While a lot of what I learn may not be directly related to my initial task, I usually pick up a few things that are unbelievably useful later on and give me an advantage in addressing challenges.

The clearest example of this which comes to mind immediately is learning Apache POI and PDFBox early in my Computer Science degree/education. I had a lot of experience with basic Microsoft Office applications and was beginning to understand the power of OOP through my Java learning, so the summer after my first semester I decided to learn how to connect the two. By the end of my project, I was confident in reading/manipulating data from Excel, generating new files or report generation, format text and images in PDF documents, and more. All of this was possible because I took it upon myself to research and create my own “breakable toy” environment to learn in.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

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.

Another Look at Boundary Value Analysis and Equivalence Class Partitioning

Recently in CS443 – Software Quality Assurance and Testing we’ve been learning some of the conceptual aspects of code testing that are required to identify the relevant points of programs to test as likely break points. We’ve primarily learned about Boundary Value and Equivalence Class testing strategies, so I decided to find a blog to learn more about each of these from a third-party perspective. I landed upon a (relatively) recent blog on TestSigma – a (automatic) testing platform – from June 2023.

The post discusses the overall importance of software testing in ensuring functionality and reliability of software products focusing on the defining aspects of the two methods we’ve been learning: ‘Bound. Value Analysis’ (BVA) and ‘Equiv. Class Partitioning’ (ECP). BVA concentrates on testing the boundaries of a system to identify vulnerabilities, while ECP groups similar items into equivalence classes, helping testers target specific areas with a higher likelihood of containing bugs.

Benefits of applying BVA and ECP in software testing include improved understanding of the system, simplified test design, better test coverage, prioritization, and risk management. The applications of these techniques extend to various scenarios, such as database testing, network testing, hardware testing, time-based functionality, and UI testing. An interesting point that the article emphasizes is that BVA and ECP are often used together, providing an example of testing a form that accepts age as a number. It suggests partitioning the age range into groups for more effective testing while also considering likely break points.

Common challenges discussed to avoid when using BVA and ECP include restricting testing to input values alone, making assumptions about limits and classes, ignoring user behavior, over-relying on these techniques, and neglecting edge cases. The post concludes by comparing BVA and ECP, highlighting their differences in testing approaches and summarizing them as thought processes that enhance testers’ understanding of the system, leading to improved test coverage and strategy.

Test automation for BVA and ECP using tools like TestSigma (or other softwares) is also discussed, highlighting the potential benefits of saving time, ensuring accuracy, and achieving better test coverage. However, the decision to automate tests should be made considering the cost and benefit of automation and set-up.

Overall, this post taught me some interesting differences between BVA and ECP as well as reinforcing the benefits and basics we learned in class. One interesting aspect of this blog that I noticed in review is that it was written by author Apoorva Ram, a non-white woman in the computer science and specifically software engineering industry. This demographic represents a sparse minority in the computer science field and worth recognizing alongside their contribution with this and other blogs.

Sources:

https://testsigma.com/blog/boundary-value-analysis-and-equivalence-class-partitioning

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.