The Concrete Skills pattern emphasizes the importance of acquiring practical, demonstrable, concrete skills in the Software Development field. By possessing the ability to complete simple tasks such as building files and having a familiarity with popular frameworks, can allow for an immediate contribution to any team. Additionally, this pattern highlights the need to go beyond theoretical knowledge and focus on building skills that can immediately be applied from day one on any team.

As I navigate through my path in the software development field, this pattern resonated with me as it aligns with my belief in the value of hands-on experience and practical application. What I found particularly interesting was the challenges that new developers come across when trying to join a new team. I feel as if every new developer goes through this as new teams may be uncertain of what knowledge you possess and what skills you can particularly contribute to the team. These teams may not want to take a chance on someone who is new in the field and may lack certain abilities. Therefore, highlighting the need for new developers to essentially bridge this gap by having concrete skills. This approach can not only enhance employability, but can also create a sense of confidence and credibility within the industry.

After learning more about this pattern, it has reinforced my belief in the value of continuous learning and skill development. It has motivated me to identify what skills are in demand for my desired position on a team, build those skills, and then directly apply them. From this, I can learn what skills I may lack, enhance my knowledge, and then contribute to my team in a positive way. Instead of relying solely on academic credentials or generic experiences, I now understand the importance of creating a portfolio of achievements or accomplishments that can effectively showcase my capabilities to potential employers.

While I completely agree with the message of the pattern, I believe that we should balance concrete skills with other soft skills like communication and adaptability. With that being said, I believe by having an approach that encompasses both technical skills along with interpersonal soft skills can be key in our ever growing field.

In conclusion, the Concrete Skills pattern can serve as a guiding light for aspiring developers. By embracing this pattern, anyone can make powerful contributions to their teams as well as pave a pathway for success in the foreseeable future.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Black box vs. White box vs. Gray box Testing

Black box testing

Black box testing focuses on the behavior of the software on a surface level. This means the tester cannot see any technical details such as code or the structure. Testers are not concerned about the inner workings of the software, rather only on the inputs and outputs. Therefore black box testing comes from the perspective of the user which allows testers to uncover any bugs and/or design flaws that would directly affect the user’s experience.

Some black box testing procedures include boundary value analysis, equivalence partitioning, and decision table testing. Boundary value analysis tests whether the software results in the correct output when the input contains the lower or upper limit of the input range. Equivalence partitioning groups all possible inputs into categories, which can reduce the number of total test cases. Finally, decision table testing involves grouping inputs into a table and testing how the software behaves when those inputs are combined.

White box testing

White box testing is the opposite of black box, meaning testers are given the internals of the system such as the code, the structure, and how its implemented. White box testing allows testers to fully understand how the software is executed. Having access to the internals of the software can help testers find issues related to security vulnerabilities, broken data paths, etc. while black box testing could not focus on those type of issues.

White box testing can be completed with a few techniques. These techniques include statement, branch, and path coverage. Statement coverage ensures that every statement in the code is run and tested at least once. Branch coverage executes all possible branches (i.e. conditional branches) in the code to be tested. Path coverage uses test cases to cover all possible execution paths throughout the software.

Gray box testing

Gray box testing combines black and white box testing into one. Therefore testing can be done from the perspective of the user, while still having access to the software’s internal code. Gray box testing is helpful when identifying problems that may otherwise be hard to find with other types of testing.

A couple techniques that are used in gray box testing are Matrix and Regression testing. Matrix testing looks at all variables in the code and assesses its risk level. Doing this can identify unused/under-optimized variables. Regression testing checks that software changes or bug fixes do not create new errors.

Reflection

This article was chosen because it clearly described the different types of box testing, and what each does. While reading the material, I realized that what we have done in class (equivalence class, boundary value testing) are actually black box testing techniques. I enjoyed learning about the different techniques that are used, and the benefits of them. Although developers and testers are two different roles, developers sometimes play the role as the end user when black box testing, so having a basic understanding of the different types of box testing will be helpful in the future.

References:

https://www.shakebugs.com/blog/black-vs-white-vs-grey-box-testing

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

Exploring the Edges: A Deep Dive into Boundary Value Testing

In the realm of software testing, Boundary Value Testing (BVT) emerges as a cornerstone, spotlighting the crucial junctures at the extremities of software modules. This method, celebrated for its strategic focus, eschews the intricacies of internal code to scrutinize the behavior at pivotal points: the minimum, maximum, and nominal value inputs. Its essence captures the high propensity for errors lurking at the fringes, thereby underscoring its indispensability, particularly for modules sprawling with vast input ranges.

BVT transcends mere error detection; it embodies efficiency. By tailoring test cases to boundary conditions — including the crucial spots just above and below the extremes — it ensures a comprehensive examination without the exhaustive effort of covering every conceivable input. This approach not only conserves resources but also sharpens the focus on those areas most likely to be fraught with defects.

The methodology behind BVT is meticulous yet straightforward. It commences with the creation of equivalence partitions, a critical step that segments input data into logically similar groups. Within this framework, the boundaries are meticulously identified, crafting a testing landscape where both valid and invalid inputs undergo rigorous scrutiny. The beauty of BVT lies in its precision — it’s a targeted strike on the software’s most vulnerable fronts.

However, the path of BVT is not devoid of obstacles. Its lens, sharply focused on boundaries, may overlook the vast terrain of non-boundary inputs, a limitation particularly pronounced in Boolean contexts where only two states exist. Moreover, its efficacy is inextricably linked to the adeptness in defining equivalence partitions — a misstep here can skew the entire testing trajectory, transforming a potential asset into a liability.

Yet, the allure of BVT remains undiminished. In the high-stakes arena of software development, it stands as a sentinel at the gates of functionality, guarding against the incursion of boundary-related errors. Its role is pivotal, especially when the clock ticks against the backdrop of tight deadlines and expansive test fields.

BVT is more than a testing technique; it’s a strategic imperative. As software landscapes continue to evolve, the demand for precision, efficiency, and effectiveness in testing methodologies will only escalate. BVT, with its focused approach and proven efficacy, is poised to meet this challenge, proving itself as an invaluable ally in the quest for flawless software. In the hands of skilled testers, armed with a deep understanding and meticulous execution, it transforms from a mere method into a beacon of quality assurance. Boundary Value Testing (BVT) is a key black box testing method targeting software’s extreme limits to identify errors without delving into internal code, focusing on boundary conditions for efficient and effective error detection. It requires meticulous planning and execution, especially in defining equivalence partitions, to ensure testing success.

I read the blog on this link:
https://testgrid.io/blog/boundary-value-testing-explained/

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

when it comes to the ever-evolving landscape of software development, i’d say it’s imperative to keep pace with methodologies that not In the ever-evolving landscape of software development, it’s imperative to keep pace with methodologies that not only foster innovation but also ensure efficiency and quality. Scrum, a natural evolution of Agile Management, emerges as a powerful ally in this quest. I wanted to try explore in this blog post some of the intricacies of Scrum, the roles it defines, its numerous benefits, and the heartbeat of the framework – Scrum ceremonies.only foster innovation but also ensure efficiency and quality. Scrum, a natural evolution of Agile Management, emerges as a powerful ally in this quest.

Our journey through Scrum begins with the understanding that it’s a flexible methodology firmly grounded in the 12 agile principles. It operates in time-bound blocks known as Sprints, where the emphasis is on delivering tangible results efficiently. A critical element is the Product Owner, who ensures alignment with the project’s goals and client priorities.

I wanted to choose this due to its holistic approach to Scrum, covering both its foundational concepts and its profound impact on software development and beyond. It’s particularly relevant to our course as it provides insights into harnessing technology for project management.

The article underscores Scrum’s suitability for modern demands – the need for quality, fast delivery at lower costs. Its ability to adapt to changing requirements is an invaluable asset. Scrum’s emphasis on the most important functionalities first ensures swift client access and timely risk management. The definition of roles, especially the Product Owner and Scrum Master, is pivotal to maintaining a balance between business priorities and agile development.

This resource served as a reminder of Scrum’s pivotal role in the software development ecosystem. It reinforced my belief in the importance of flexibility, adaptability, and efficiency in project management. The incorporation of Scrum’s ceremonies ensures that every aspect of the project is aligned with the overarching goal, promoting collaboration, transparency, and improvement. I see myself applying this knowledge in future projects, advocating for scrum methodologies to achieve better results.

As we conclude our exploration of Scrum, it’s evident that its application extends beyond software development, seeping into various organizational models. The benefits of scalability, expectation compliance, flexibility, and risk reduction make Scrum a cornerstone in project management methodologies. The Scrum ceremonies, with their structured yet flexible approach, not only foster collaboration and transparency but also ensure timely progress and continuous improvement.

https://www.nimblework.com/agile/scrum-methodology/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

So what even is an anti-pattern? Well, anti-patterns are solutions to ineffective problems that eventually cause more problems than they solve them. They are often used because they seem to work very well but the long-term consequences are not usually thought of. Anti-patterns are just like a regular pattern but instead of a solution, they give a superficial solution but really isn’t one at all. Programming anti-patterns are known for common mistakes, they can lead to problems like maintainability. The spaghetti code is a good example of anti-pattern, it’s a code with no structure. There are random files scattered into random directories, the whole thing is difficult to follow and is tangled together. This usually happens when someone isn’t carefully thinking out their program and how smoothly it should be running before actually coding. It makes it basically impossible to add any new functionality, no matter how many changes you try to make and try to understand those changes you will still end up with countless issues with your code. Another example of anti-patterns is the boat anchor. The boat anchor happens when someone leaves a piece of code in the codebase because they believe that they will need it later but doing this actually can keep your project from moving forward, can cause your coding time to slow down, and mess up your codebase.

Avoid anti-patterns with better system management. You can avoid anti-patterns in your code by being more consistent with your system. By reviewing your code, looking through and making sure you have no typos and grammatical errors. These code reviews help improve the quality of your code and make it easier to find better solutions for any common problems your’re having. Always have someone else take a look at your code in case you did miss something that you didn’t see it’s always helpful to have a set of fresh eyes look at your code so it can help you tighten up your code. The process of engaging in code refactoring can also help make adjustments that will strengthen your code’s structure and framework without impacting the user experience. Refactoring is very helpful in simplifying your code construction.  It will make it easier for someone to take a look at your code and understand how you put the code together and be able to add any new functionality to the code as well. Making the code a visual can help give you as well as others a better understanding of the information presented to them. It can help you show the workflows, and analyze and brainstorm for any new improvements.

https://www.lucidchart.com/blog/what-are-software-anti-patterns

https://www.baeldung.com/cs/anti-patterns

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

This week in class we discussed the process of scrum. Scrum is an agile framework that can be applied to any project or product development effort. It promotes flexibility by encouraging openness, inspection, and adaptation. This loose framework allows teams to adopt it and make changes that benefit their team’s workflow. Unlike the waterfall development approach, where each step must be completed before moving to the next, a scrum team works in small increments over a smaller period. That period consist of the sprint, sprint planning, daily scrum, sprint review, and the sprint retrospective. The scrum event that piqued my interest after reviewing it in class was the daily scrum.

The blog, “Ten Tips for More Effective Daily Scrums” by Mike Cohn,  brought up some interesting and important points. The ten points that were mentioned were: (1) talk almost exclusively about the work of the current sprint, (2) limit discussion to what was and will be accomplished, (3) talk about impediments, not “blockers”, (4) give people something to say about their work not directed toward the sprint goal, (5) give team members a way to indicate when someone is rambling, (6) have people point to what they’re working on, (7) update the sprint backlog but don’t let numbers become the focus, (8) vary how the daily scrum is conducted, (9) keep everyone guessing as to who will speak next and (10) make it painful to ramble too long. 

During the summer, I had the chance to work on software for our university. It was my first time experiencing the scrum workflow. Our team implemented some of these tips during our daily meetings, mainly points 1, 2, 3, and 6 so it was interesting to hear the author’s perspective on what other methods make a daily standup more effective. The points that cater towards diminishing rambling were a fascinating read. While discussing methods to indicate when a member is rambling, examples of using buzzers, holding up rubber hats, and using dolls were mentioned. Although strange to me, those methods show that different teams use what’s best for them. Cohn’s ninth point about keeping everyone guessing as to who will speak next discussed more methods to make the meeting fun to help avoid tuning other members out while they are speaking. While working on software in the summer, I didn’t think about fun ways to improve daily scrum because it was all so new to me. It makes sense to implement something to make the meeting more engaging because, like he said, I did find myself zoning out at times. 

Because I have such little experience with a scrum team, I enjoyed reading about possible ways to improve a team’s process .It helped me realize just how different another team’s methods could be and what I could possibly implement in the future.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

This week in our Software Process Management, we delved into the world of Scrum, an agile project management framework that’s been gaining a lot of attention in the software development industry. Scrum is all about fostering collaboration, flexibility, and adaptability in a project, and we explored the crucial roles that customers and developers play in planning and completing each sprint.

Let’s start with a quick overview of Scrum. It’s a framework that emphasizes incremental and iterative progress. Instead of a lengthy and rigid project plan, Scrum divides the work into smaller, manageable pieces called sprints. Each sprint typically lasts around two to four weeks, during which a specific set of features or tasks is tackled. This approach allows teams to be more responsive to changing requirements and deliver valuable software faster.

Now, onto the roles:

1. Product Owner: In Scrum, the customer’s voice is represented by the Product Owner. This role is pivotal in ensuring that the team is working on the right things. The Product Owner collaborates closely with stakeholders to define the product’s vision, prioritize features, and create a backlog of tasks. They act as the bridge between the customer and the development team, answering questions and providing feedback.
2. Scrum Master: The Scrum Master is like the team’s guide, facilitating the Scrum process. They ensure that everyone understands and follows the Scrum framework, including the roles, events, and artifacts. Scrum Masters remove any obstacles or distractions that might hinder the team’s progress.
3. Development Team: As a computer science student, this is where you come in. The Development Team consists of professionals who do the actual work of creating the product. This can include software developers, designers, and testers. The team is self-organizing and cross-functional, which means they work together to complete the tasks committed to during the sprint planning. They are responsible for delivering a potentially shippable product increment at the end of each sprint.

In Scrum, collaboration is key. Customers and developers regularly interact during various ceremonies like sprint planning, daily stand-up meetings, sprint review, and sprint retrospective. This close collaboration helps to ensure that the product being developed aligns with the customer’s needs and expectations.

The sprint planning meeting is where the Product Owner presents the prioritized backlog items, and the Development Team discusses what can be accomplished in the upcoming sprint. This collaboration ensures that the team commits to a realistic amount of work and that the customer’s priorities are respected.

During the sprint, the Development Team is focused on delivering high-quality work. The daily stand-up meetings keep everyone in sync, and any impediments are addressed quickly.

At the end of the sprint, the team and the customer come together for the sprint review to demonstrate the work done. This provides an opportunity for feedback and adjustments based on the customer’s input.

Finally, the sprint retrospective is where the team reflects on their processes and identifies areas for improvement, making each subsequent sprint better than the last.

In conclusion, Scrum is an exciting and collaborative approach to software development that empowers both customers and developers. It ensures that the product remains aligned with customer needs while fostering a dynamic and adaptable working environment. As computer science students, this framework equips us with valuable skills for future software development projects. So, embrace Scrum, work closely with your team, and be prepared for a dynamic and rewarding journey in the world of software development.

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.

With the constant updates that software can endure, there have been schemes that help track each update. Software versioning is the process of assigning either unique version names or numbers to unique states of computer software. This allows programmers to know when changes have been made and track them. There are several different types of versioning schemes, including name versioning, basic versioning, and internal and external versioning.

Name based versioning identifies software with words and labels rather than a numerical value. This is usually less structured than some of the numerical versioning systems. A basic versioning scheme uses simple, numeric values to track changes. While it is simple and easy to understand, it may not provide detailed information about the nature of the changes with previous versions. Internal versioning, also known as internal build numbers, is used within an organization or for internal purposes to track and manage different iterations. This is separate from external versioning, which is used to communicate with users. The versioning scheme we have started to learn about in class has been semantic versioning. This is a format that I have seen before, but personally did not know much about how exactly the scheme works.

Semantic versioning, also referred to as SemVer, is a versioning system that has the ability to provide a universal way of versioning software development. It is represented by a 3-component number (X.Y.Z) to represent the three different software releases. The Z value indicates the releases for bug fixes, with no functionality changes coming in these updates. Y shows a minor version update where a new functionality is introduced. When increasing the Y value after an update, you must reset the Z value back to 0. The X value denotes a major version, which breaks the current API. It is helpful to split up the different updates that the software endures in this manner so that the user knows the importance of each change.

There are advantages that SemVer brings to software development. It is a fairly simple scheme which provides the ability to track every transaction and help manage dependencies. This also helps the user to identify the risk of taking on the updated packages. It is a very valuable option for version management, especially when it relates to open-source and collaborative development environments.

Semantic versioning and impact of breaking changes in the Maven repository – ScienceDirect

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing some of what I learned about the DRY design principle from the article “The DRY Principle: Benefits and Costs with Examples” written by The Valuable Dev. I initially chose this particular article because it perfectly aligns with the DRY design principle topic within the syllabus. This article discusses what DRY is, as well as why you shouldn’t always use DRY. I personally found the author’s use of humor to be very refreshing. I feel many of the blogs I have read so far have seemed to be robotic in how they are written.

The article says that DRY is primarily about a repetition of knowledge first and foremost. “Therefore, the logic of this shipment should only appear once in the application. Why? Imagine that you need to send shipments to a warehouse. You need to trigger this behavior in 76 different places in your application. No problem: you repeat the logic 76 times. After a while, your boss comes to you and asks you to change this behavior. Instead of sending shipments to one warehouse, you need to send them to three different ones. The result? You’ll spend a lot of time on your shipment logic since you’ll have to change it in 76 different places! This is a waste of time and a good way to produce bugs to piss your boss off.” The author suggests instead of repeating the logic that you are using, and it would be better to use abstraction to prevent the kind of issues that the example given causes. This would not only allow for changes to be made faster but also minimize the risk of bugs being created because you are only changing code in one area instead of 76 different places.

The author also discusses a situation where DRY doesn’t apply. In this example, the author is working on software for a VOD (video on demand) platform that both filmmakers and content teams would use regularly. The author was considering creating abstract classes to use instead of the current implementation that was being used due to many classes being almost copy-pasted, as well as seemingly having similar utility for both filmmakers and content teams. “In many cases, we knew that the interface would evolve differently in the future. We would have created a lot of conditionals in the controllers’ actions if we had created one set of controllers for both applications. Nobody wants a forest of if statements; the resulting code would have been way more complex. Additionally, the controllers shouldn’t contain any business logic. If you recall the definition of the DRY principle, it’s this knowledge and business logic that should not be duplicated.” As both classes would become more developed in the future, they would differ significantly. If they were made into an abstraction, the code needed for them to work for filmmakers and content creators would have been messy and complicated to manage.

Article: https://thevaluable.dev/dry-principle-cost-benefit-example/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

This week in class, we went over the process of Scrum. Essentially, it is a loose framework on how a team should be working if they want the greatest potential from that work. I say ‘loose’ because it is loose, other than providing how the process should go, it allows teams to not only follow this framework, but adapt it and make it unique for their team and their work. I like this methodology for this reason. 

Scrum states that a team consists of developers, a product owner and a scrum master. Each has their own roles and responsibilities in the process. The process has five parts. The main event is the Sprint, which is a one month process where everyone is working in order to achieve a goal. Before this can happen, there is the Sprint planning, which is planning the Sprint and figuring out what needs to be done. Everyday before people start working, there is the Daily Scrum, a short meeting about what needs to be done that day. At the end of the Sprint, there is the Sprint review, going over the results and progress of the Sprint, and the Sprint retrospective, reflecting on the Sprint, as a whole and on individual parts, so that the next Sprint is better. Each part, and the roles, are described in detail in the Scrum guide.

In this blog post, Gregory Crown and Robert Pieper talk about how Scrum could be used outside the realm of software development, like marketing. I chose this particular post because not only does it connect to what we’re learning in class, it talks about how Scrum can be used outside of software development. In the post, they specifically talk about how marketing can use the framework of Scrum, and how it benefits from it. Pieper says that if it is a complex activity or problem, Scrum can help. He describes complex as something requiring a lot of opinions. He uses a water bottle as an example, saying one stakeholder may not like the color, another may ask what the purpose of the rubber thing at the bottom of it is, etc. Essentially, if you show the benefits of something, and there are a lot of different opinions on it, you can benefit from Scrum. He describes it in a very nice way, saying, “if you’re in a subjective environment where you’re getting a lot of opinions, use Scrum.” He says that if what you’re working on is something that just meets requirements, and then moves on, you don’t need Scrum. 

Personally, I agree with what he says. On paper, Scrum is an excellent framework for a lot of things. It has the layout on how to do things, but allows people to fill in the rest, however necessary for things to be done. It is a clean way of doing things, strict yet flexible. This shouldn’t just be a computer science thing either, if others can benefit from this, do it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.