Category Archives: Week 13

The Wisdom of the White Belt

The “White Belt” pattern resonates with me on a personal level, as it summarizes the mark of maintaining a beginner’s mindset, a quality that I believe is crucial for continuous growth and learning in any field, especially in the realm of software development.
One interesting aspect of this pattern is the acknowledgment that expertise and mastery can sometimes become a double-edged sword. While we try to have proficiency in our field, there is a risk of becoming proud or developing a fixed mindset, where we rely too heavily on our existing knowledge and fail to embrace new perspectives or paradigms.
The analogy of “wearing the white belt” serves as a sad reminder that true mastery is not in holding to what we already know but in building a mindset of humility and openness to learning. It challenges us to overlook our assumptions and approach new challenges with a fresh and curious mindset, to a beginner’s eagerness to explore and discover.
What particularly resonates with me is the idea of “unlearning what we have learned,” as emphasized in the quote from “The Empire Strikes Back.” (Favorite movie haha) This concept challenges the work that our knowledge is lively and pushes us to question our assumptions and be willing to adapt and evolve our thinking as we meet new contexts or technologies.
Furthermore, the pattern’s point on approaching new domains with respect and curiosity, rather than assuming expertise, is rather more of a debate. The reason I say so is because it reminds us that true understanding often comes from collaborating with others and acknowledging the unique perspectives and realities they bring to the table.
One interesting aspect I find compelling is the idea of questioning how veterans in the field approached coding in the past versus how we approach it now. While we may be tempted to dismiss older methodologies or technologies as outdated, there is value in understanding the historical context and the challenges that shaped those approaches. By adopting a beginner’s mindset, we can explore these historical perspectives with an open mind, potentially uncovering insights or principles that remain relevant today.
In spirit, the “White Belt” pattern encourages us to have a mindset of continuous learning, humility, and adaptability – qualities that are essential for being advanced in the landscape of software development. It reminds us that true mastery is not a destination but a lifelong journey of growth and exploration, where we must be willing to use our preconceptions and embrace the wisdom of a beginner’s mind.

May 5, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

The Power (and Curse) of Retreating into Competence

This week, I chose to read the “Retreat into Competence” pattern and found its overall message quite interesting since I see it as a helpful but potentially harmful one. It suggests that when faced with challenges that can leave me feeling overwhelmed or upon realization of my limitations, I should temporarily retreat into known territory to prepare myself to confront the unknown. Doing so will enable me to rebuild my confidence and be able to prepare myself to tackle any challenges that may lie waiting in my future career. While retreating can be helpful, it may end up being harmful and the pattern also highlights the importance of setting time limits for retreat to avoid it from becoming an issue. Setting time limits and asking for help from mentors will ensure if I feel that I must retreat into competence in the short term, it won’t lead to the stagnation of my development in the long term.

I believe that setting time limits for a retreat into competence is vastly important in keeping one’s journey into evolving from an apprentice on the proper path. It works toward preventing people from becoming complacent or stagnant when returning to their competencies. Placing limits encourages an environment where one can gather thoughts and pool together any necessary resources before returning to the thick of it promptly. Asking for help from mentors is also important in aiding to overcome obstacles. Even if something may seem overwhelming at first approach, with the guidance of others, such may appear a lot more manageable than it had before.

I think the pattern provides a good framework on how to deal with my limited knowledge due to my lack of practical experience. It’s common for anyone to feel overwhelmed by new things, especially in the early stages of learning or taking on new challenges upon transitioning from a learning environment into a professional environment.

I have to also mention that the notion of retreating into competence can be helpful but it also may be harmful if not done correctly. It may be helpful, but making a habit out of retreating may result in taking fewer risks even when establishing time limits. I feel as time goes on, the necessity of retreating may fade away, but if a habit of retreat is developed and relied upon too much, it may do more harm than good in the long run.

Overall, I think the “Retreat into Competence” pattern sets a solid framework for new apprentices to follow by destigmatizing the fear of the unknown. It shows retreating when faced with a challenge can be beneficial if used correctly.

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

CS-448 Week 13 Nurture Your Passion

The pattern “Nurture Your Passion” is compelling to me as a software developer who is learning the importance of maintaining enthusiasm and dedication in a challenging work environment. It acknowledges the common struggle many developers face when their passion for the craft is interrupted by factors such as corporate hierarchies, project pressures, or negative workplace dynamics.

What I find compelling about this pattern is its emphasis on taking the right steps to protect and grow one’s passion for software craftsmanship despite adversity getting in the way. It also addresses that while external factors may be discouraging, there are still actions individuals can take to sustain their enthusiasm and commitment to their craft.

I have personally experienced times when my passion for software development wavered due to demanding project deadlines, different obstacles, and lack of recognition. However, this pattern reminds me that while it may seem tough at times, my passion is worth preserving and that I have the tools to nurture it.

One of the aspects this pattern provides that resonates with me is the importance of setting boundaries between work and personal life. Prioritizing self-care and making time for out-of-work activities that help rejuvenate my passion allows me to maintain a healthy balance and prevent burnout.

The pattern also underscores the significance of continuous learning and seeking out like-minded peers for support. Professional development opportunities as well as connecting with colleagues who share my enthusiasm for software development can provide me with valuable inspiration and encouragement.

Reflecting on this pattern has reinforced my belief in the adaptability and resilience of software developers. It has reminded me that while external factors can influence the work environment, I have the power to carve my own experience and continue my passion for the craft.

If anything, this pattern has confirmed my intended profession and pursuing a career in software development. There have been times that I considered trying a different career path, but reflecting on this pattern has showed me that my belief and dedication are essential qualities for success in this field, and that overcoming challenges can lead to personal growth and fulfillment.

Overall, I agree with the principles outlined in this pattern. It serves as a reminder that passion is not something that is given, but rather it is something that should be nurtured and protected, especially when facing adversity. By embracing this mindset and taking the right steps to maintain my passion, I am confident that I can thrive as a software developer despite any obstacles I may encounter.

3. Walking the Long Road | Apprenticeship Patterns (

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.

448- Blog Post

This week I have read the section called Construct Your Curriculum The text emphasizes the immense access to information in the modern era, fueled by technological advancements like the printing press and the internet. Despite the abundance of digital media, it stresses the enduring value of books, particularly those authored by experienced professionals like Jerry Weinberg and Fred Brooks. These books offer a extent of wisdom and insight that goes beyond what can be found in blogs or online resources.

To manage the overwhelming number of books one may wish to read, the article suggests implementing a Reading List—a  list of books to read and those already read. This list serves as a personal curriculum, allowing individuals to prioritize their learning and track their progress over time. By making this list public, others can benefit from suggestions and contribute their own recommendations, fostering a collaborative learning environment.

The article introduces the concept of “Reading Constantly,” advocating for a steady intake of programming books to deepen one’s understanding of the field. It advises against rushing through books and emphasizes the importance of timing—reading the right book at the right time can significantly enhance the learning experience.

Additionally, the article encourages exploration of classic literature in the field, alongside more contemporary resources. It suggests asking mentors for recommendations and seeking out long-lived books that offer timeless insights into software development.

Finally, the article points out the value of a balanced approach to learning, incorporating both classic and modern literature, and leveraging tools like Reading Lists to navigate the vast sea of available knowledge effectively. Through continuous reading, reflection, and interaction with mentors and peers, individuals can cultivate a deeper understanding of their craft and continually improve their skills on their journey as software developers.

This was a good read to mark the importance of the continuation of learning and reading even after graduation and starting the professional career. It opens up the eyes for readers so that they grow and learn more and not stay stagnant.

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

443- Blog Post

The article “Property-Based Testing: A Test Strategy for Modern Software” on Codemotion’s website explores into the concept and benefits of property-based testing (PBT) in the context of modern software development. PBT is a systematic approach to testing software by defining general properties that the program should satisfy, rather than focusing solely on specific input-output pairs.

The piece begins by highlighting the limitations of traditional example-based testing, which often fails to cover all possible edge cases and scenarios. This leads to the introduction of PBT as a more comprehensive testing methodology. Unlike example-based testing, where tests are explicitly defined, PBT generates test cases automatically based on the properties defined by the tester.

The article talks about the key components of PBT, including generators, properties, and test runners. Generators are used to create random inputs for testing, ensuring a wide range of scenarios are covered. Properties, on the other hand, represent the general rules or invariants that the software should adhere to. These properties are then used to validate the behavior of the software under test.

One of the main advantages of PBT highlighted in the article is its ability to uncover edge cases and bugs that may not be caught by traditional testing methods. By generating random inputs based on defined properties, PBT can uncover unexpected behaviors and corner cases, leading to more robust and reliable software.

The article also discusses the challenges associated with PBT, such as the need for careful property definition and the overhead of generating and executing a large number of tests. Yet, it argues that the benefits of PBT outweigh these challenges, particularly in complex systems where traditional testing methods may fall short.

I really like this blog post because not only did it explain the theoretical aspects of PBT, the article provides practical examples and case studies to illustrate its effectiveness in real-world scenarios. It also showed like coding examples which really helped understand how it work instead of just trying to imagine how it could look like.

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

A Guide to Unit Testing

Unit testing is an important method that hammers out bugs in our code and verifies its behavior. Every line of code is critical to keep our projects functioning, so we must understand the benefits and best practices for unit testing to maintain our code correctly. As the title suggests, this blog post, “Unit Testing | What it is, How it Works, Types & Top Benefits”, lays out the principles of unit testing, the different types, and the benefits for software development.

 Diane Wong’s blog is a concise guide to unit testing and its benefits. It covers the types, techniques, advantages/disadvantages, and best practices of unit testing, giving an overview for newcomers to coding and those well-versed in it. I chose this resource due to its simplistic coverage of many essentials to unit testing. The blog is organized with a table of contents that leads those seeking information on a particular aspect of unit testing. It was a good start for my understanding of unit testing, and those new to the method would benefit from the blog.

I found the information concise and direct when reflecting on the blog post. This isn’t a blog that will delve into specifics on any technique or method of testing but will give you a general overview, which is what I wanted. We discussed many aspects of unit testing in class, including testing techniques like Black Box, White Box, Gray Box, Mocking, and Stubs, so some information was a refresher. The main benefit I got from this blog is a better understanding of the advantages unit testing brings, best practices, and why we use it. It lowers overall costs, allows for automation, makes debugging more manageable, and increases the team’s efficiency. The best practices were short but something to remember when conducting unit testing, like focusing on one module at a time or using conventional naming practices. The blog recommended unit testing tools besides JUnit, like Jasmine, TestNG, PHPUnit, and Mocha, which I may look into if they have better features than JUnit. Overall, the blog filled in gaps in my knowledge, and it was something I could quickly go back to or recommend to people new to the concept.

 I intend to use that knowledge for future software development projects and teach those who are unaware so we can effectively build and debug our code. Before using unit testing in practice, developers must understand the fundamentals, best practices, and advantages so they can develop good habits from the beginning. 

Link to the blog:

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

Week 13

The next classes will be about Software technical review it would be great to get a step ahead by delving into the concept. We only started with the review section of the code but fully understood it before the class could skip the barriers of never implementing this idea. Whenever doing something new there is always a barrier which can be difficult at first but with practical knowledge, it can be implemented with a greater effect.  

This article first talks about why there is a technical review. There are technical reviews for the company’s higher-ups who may not be fully aware of the coding process and the difficulties that come with it. They have to understand the developer’s importance to the business because they are spending a lot of money with ineffective results. Many times deliveries aren’t are time and come in fault states having several bugs. This is where a technical review comes in handy it’s a deep dive that provides a suitable perspective. Their definition of a technical review is a deep dive assessment of your software that provides findings and recommendations that be later adapted or discussed amongst your team. Common finds inside a technical review include slow or late deliveries which are just not meeting the due date, random or persistent bugs an example would be fixing the same thing over and over again, and sleepless nights because of worrying too much. These aren’t the end be it all every technical review is different and should be focussed on your team’s goals. The main discussion should be of pain points the things that keep you up at night to make the software complete. Process and team review is another key ingredient that makes sure everyone is working on the right task or if there are changes that need to be made plus an idea to every team member’s contribution to the project. The last thing the team should do is an effective summary that can be graded with a brief description. Detailed findings and recommendations that can be read by people not in depth with coding so they can get an idea of what is being done behind the scenes and can tell the team what needs to change.

Reading this article gave me an idea as to why we do technical reviews because when doing mine I was stuck trying to figure out problems in the code. I didn’t want to nitpick and find small issues that would seem redundant because at times it is better to keep it clean and simple. But understanding that this needs to be done to prove to people on the other side of the business that work is being done is a great insight. It makes a lot of sense that other people in a company would want to know what is happening on other sides of the department.

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

Week 13 Blog

This week’s blog post topic covers Pairwise and Combinatorial Testing. I chose this topic because we will soon cover it in class and having some background information prior to any activities involving this method will be useful to relate back to.

Pairwise Testing, also known as All-Pairs Testing, focuses on efficiency by testing every possible pair of input parameters, rather than every single combination. For instance, if you have a form with fields for name, email, and phone number, Pairwise Testing would cover combinations like name and email, name and phone number, and email and phone number. It’s a straightforward way to catch potential bugs without an overwhelming number of test cases. With Combinatorial Testing, it builds on Pairwise Testing by considering combinations of three or more parameters together. Using our form example, Combinatorial Testing would include triples like name, email, and phone number. This comprehensive approach aims to uncover bugs that might only appear with specific combinations of inputs. This testing method aims to optimize efficiency and coverage. Software testing can be time-consuming, especially with numerous parameters and scenarios. Pairwise and Combinatorial Testing streamline the process, allowing you to detect more bugs in less time.

The key benefits to this method is it helps in reducing the number of test cases needed to achieve “good” coverage. Instead of exhaustive testing, you’re strategically covering the most important combinations. Secondly, it helps in identifying interactions between parameters that might lead to unexpected behavior. By testing these combinations, you’re better prepared for real-world usage scenarios.

Of course, there are disadvantages to Pairwise and Combinatorial Testing. One, It can become tedious due to the large number of test cases required to cover all input combinations. Two, It relies on the interaction of pairs of parameters to determine outcomes, but this assumption may not always hold true, potentially missing bugs. And three, additional tests might be necessary to complement pairwise testing, adding extra time and effort to the testing process.

The main challenge when using this method is selecting the correct input parameters. The choice of relevant parameters impacts software behavior. Careful selection ensures thorough test coverage and defect detection. However, accurately determining parameter interactions is equally as difficult, because it could potentially result in the selection of incorrect combinations.

Some of the tools used by teams are PICT, IBM FoCuS, ACTS, Hexawise, Jenny, etc. These tools help automate the test case design process by generating a compact set of parameter value choices as the desired test cases. This is done by applying the all-pairs testing technique, which involves testing all possible combinations of two parameters.

Blog Post:

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Blog #2: In Defense of Dynamic Testing

While writing about static testing, I spoke about my positive disposition toward dynamic testing due to its ease of access. Over the time spent writing the last blog In Defense of Static Testing, I grew to understand the benefits of testing with that approach. Now I seek to learn why dynamic testing may not be as “easy” as I once understood it to be.

One lesson I learned from the previous reading on static testing was the idea of ‘time and place’. Both testing methods are to be used under certain circumstances, rather than interchangeably. The blog post, Dynamic Testing, written by Swati Twade brings up this very idea. Twade states that due to dynamic testing’s cost, it ought to be used in effective ways. Furthermore, she warns that if dynamic testing is not used enough during the early stages of development, then there will be much more costly issues down the line. Here a certain balance must be found. The development team must use dynamic testing sparingly to reduce costs, yet must use it frequently enough to prevent larger issues from forming during the final stages of production. In these situations, static testing may be appropriate, as between dynamic testing intervals the development team can review the code and documentation to ensure that all aspects of the program are meeting their specifications. Naturally, if the team was only focused on these two aspects, then static testing could help in minimizing the use of dynamic testing however, dynamic testing captures much more than the code. According to Twade’s definition of dynamic testing, it seeks to capture both errors during the program’s runtime and how the execution of the software affects the hardware. These two focuses of testing cannot be captured by static testing, and require resources to use dynamic testing.

Through this reading, I’ve slowly begun to understand why both dynamic and static tests must be used under certain circumstances. Before researching this topic, I thought the two could be used interchangeably, without considering the resources it takes to conduct each test. Furthermore, each test focuses on reviewing specific content. Dynamic testing places high priority how on the program behaves once executed, meanwhile static testing places its priority on both the source code and documentation. Using these tests interchangeably without first understanding the conditions they work most effectively under will yield less than successful findings. Ultimately between these two blog posts, I have reinforced my knowledge of the testing processes, and have learned under what circumstances each thrives in.


Link to Original Post:

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

Sharing Strategies for Effective Exploration!

As a student studying computer science and software testing, I found the blog post “Mushroom Picking and Testing” to be a fascinating and insightful exploration of the parallels between the art of mushroom foraging and the practice of software testing. The author, a seasoned mushroom picker from Estonia, skillfully draws connections between the two various activities, highlighting the similarities in the decision-making processes, risk assessment, and the development of observational skills.
The blog post begins by describing the author’s love for mushroom picking, a tradition rooted in their Estonian heritage. Interestingly, the author finds this activity to be a meditative and reflective experience, where one part of the mind focuses on the task at hand while the other have multiple thoughts and ideas. It is within this state that the author discovers the similarities between mushroom picking and software testing.
One of the key parallels drawn is the concept of “choice of location vs. product coverage.” Just as the author visits familiar forests to efficiently collect a good amount of mushrooms, software testers may focus on keep on testing the same areas of a product, limiting their vision and potentially missing new or exciting discoveries. The blog post encourages readers to pinpoint a balance between depth and breadth, considering the mission and objectives when deciding how to grant their time and resources.
Another comparison I found is the importance of making preparations before starting on either attempt. The author discusses the need to gather the necessary tools and equipment, as well as staying informed about environmental factors and recent changes that could impact the success of the task. Similarly, in software testing, it is crucial to have the right tools and knowledge about the product and its recent updates to make informed decisions and effectively approach the testing process.
I would say the most eye opening aspect of the blog post is the discussion around “knowing your oracles.” The author explains the importance of recognizing poisonous mushrooms, a skill passed down through generations. This concept directly translates to software testing, where testers must develop a deep understanding of the product’s characteristics and potential issues, rather than relying on a more questioning or searching.
As a software testing student, I found this blog post to be a refreshing and wise point of view on the craft of testing. The author’s ability to draw parallels between these two seemingly unrelated activities has provided me with a new lens through which to approach my studies and future practice. The emphasis on searching for more, risk-taking, and the development of observational skills are all elements that I will strive to plug into my testing methodology. This blog post has not only expanded my understanding of software testing but has also inspired me to continue the unexpected connections between the physical world and the digital realm.

April 14, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.