In a nutshell, “The White Belt” encourages us to embrace our ignorance and adopt a beginner’s mindset. It’s like entering a martial arts dojo for the first time – a white belt symbolizes a blank canvas, ready to absorb the knowledge and skills the journey offers.

Summary of The White Belt:

1. Ignorance is Okay: The pattern emphasizes that it’s perfectly fine not to know everything. Acknowledging our ignorance is the first step towards real learning.
2. Focus on Learning: Instead of trying to be a jack-of-all-trades, the pattern advises us to focus on learning one thing well. Mastering a single concept or technology sets the foundation for broader expertise.
3. Practice, Practice, Practice: Hands-on experience is key. Whether it’s coding exercises or real-world applications, practice is the bridge between theory and mastery.
4. Seek Feedback: Actively seek feedback from experienced developers. Constructive criticism is the secret sauce for improvement.
5. Expose Your Ignorance: Don’t be afraid to admit what you don’t know. Being open about your limitations opens the door to learning from others.

My Reaction:

What struck me most about “The White Belt” is its emphasis on humility and curiosity. In a world where the pressure to know everything can be overwhelming, this pattern grants permission to be a novice. It made me reflect on how, as a student entering the vast field of software development, it’s okay not to have all the answers.

The call to focus on learning one thing well was a game-changer for me. In a world filled with shiny new technologies, I now appreciate the value of depth over breadth. It’s like building a strong foundation before constructing the skyscraper of knowledge.

This pattern has reshaped my perspective on learning. It’s not just about accumulating information but immersing oneself in the process. Admitting my ignorance, seeking feedback, and practicing relentlessly are now my guiding principles.

In conclusion, “The White Belt” is not just a pattern; it’s a mindset. It has ignited a spark within me, encouraging me to embrace the journey of learning with open arms and a white belt.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

After getting through a couple weeks of my classes, and looking through blogs online about testing, I found the stickyminds blog. In my first week I was given setup tasks for CS-443 Software Quality Assurance and Testing, and one of those tasks was to discover blogs and podcasts related to the course content. I used this blog for my setup tasks, and found it a useful compendium of resources. While searching through stickyminds, I focused on the area around ‘new to testing’, and found a specific article about how to improve your skills as a performance tester quite interesting. The article’s title is How to Become a Better Performance Tester 101 by Jun Zhuang.

The blog begins with a small piece of advice based on segmenting code for testing. While some people might argue that you should test and optimize after large portions of the code are complete, this blog argues instead for doing performance testing while it is still incomplete. It is also advised to learn performance testing under someone who is very experienced in the topic, as many performance testers don’t understand or know which questions they should be asking. This is why shadowing is very important, as it allows a new performance tester to pick things up quicker, and gather an understanding of the tools used more effectively. Jun Zhuang discusses Agile software development teams that are commonly used in industry. He describes them as being used to handle performance testing responsibilities. These teams use strategies such as getting developers involved in capturing performance issues early, communication between teams and testers, and holding critical team meetings more frequently. They still face occasional struggles to meet deadlines when performance issues arise, but these teams are overall described as efficient and useful. The latter half of the blog explains the importance of performance testing, and why you should put this effort into doing it. By exploring these components like applications, or databases testers can better design tests and diagnose issues. The blog also shares some personal accounts of testers utilizing their knowledge in programming to speed up testing processes, by writing stubs and generating test data. It stresses the importance that individuals with diverse technological backgrounds, even if less experienced in performance testing, can bring valuable insights and problem-solving skills to the role.

I chose this blog because I am very interested in improving my skills at all times. When I discovered the Stickyminds blog, I was excited by the amount of information it presented. This blog on performance testing I discovered in the new to testing section, which has a lot of very useful articles to help you improve your skills. Even small pieces of advice and tactics can make the difference when it comes to coding and testing especially. A personal weakness with testing in my own projects I had, was that I was worried my code was not optimized enough, and what I learned through this blog is something I will apply to improving optimization, especially seeking out someone experienced to work with and improve my skills. 

Source:

https://www.stickyminds.com/article/how-become-better-performance-tester-101

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Essentially, be willing to admit that you have gaps in your knowledge when you do, and be able to ask those around you for help when you really need it. The authors make a point to mention that this is relatively difficult for many people because of the self-imposed expectation of being omni-competent (that is, always competent) and when you aren’t competent, considering it a failure. This is definitely a difficult mindset to get past, but it is necessary for growth. Otherwise you remain stagnant in the things that you know and never challenge yourself.

This pattern is good. It’s true that in order to learn things, we often have to turn to those who have more experience and learn from them. It also gives a good way of asking productive questions rather than the common (and not very useful at all) “how do I make this work?” I find that in order to really understand what’s going on, you have to go to the root of the thing you’re having an issue with and work up from there. Otherwise, for example, you’re just writing code and you don’t even know what it really does, just that it works. This is one of the main reasons I get bothered whenever anyone has asked me to just show them my code in the past, not only does it not really help them learn anything most of them time, there’s a good chance the code I wrote ends up being copied directly. I don’t really care about getting credit for the stuff I wrote all that much, but it’s moreso about the precedent it sets.

Another interesting thing about this pattern is the idea of being willing to step out of your comfort zone to other fields and technology to better your versatiliy. I think this is truly important, especially when working in the tech sphere. Things change very quickly, and to not adapt means to remain with legacy components which are less efficient and less secure as a whole. This stagnation spreads to everything in the ‘system’ so to speak, and the results affect everyone who holds a stake in what your group does.

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

  The introduction chapter for the Apprenticeship patterns book gives a definition and understanding of not only the term ‘software craftsmanship’ but it also explains the stages of ones development within the software development career path. These stages can be attributed too many other careers but the apprenticeship patterns contained in this text are meant to help guide an apprentice software engineer to become a journeyman and later a master.

  Chapter Two ‘Emptying the Cup’ contains apprenticeship patterns which are meant to help when initially taking on an apprenticeship and the learning curve you will face when having to “relearn” how to do a task that you may already do in one way in order to learn another way to complete the task. This is very important as you must be open to learning different ways to do things even if a different way may be less efficient.

  Chapter Three ‘Walking The long Road’ refers to the everlasting cycle of learning that is ahead of an apprentice and the importance of learning new techniques and strategies continuously in order to increase your skill and understanding which will remain important even after exiting the apprentice ‘phase’ of your career.

  Chapter Four ‘Accurate Self-Assessment’ is meant to make you realize that you have not finished your “walk on the long road” and encourage you to realize and learn from flaws in your own work or seek mentorship from your more experienced counterparts.

  Chapter Five ‘Perpetual Learning’ contains patterns that you are meant to use for your entire career regarding both learning an communication but they are vital to success early in your journey due to the emphasis on expanding upon your own abilities and your knowledge in order to expand your career.

  Chapter Six ‘Construct Your Curriculum’ refers to the necessity of continued learning once again and the need for an apprentice to be responsible and dedicate some of their own time to the expansion of knowledge even though the reading and research required will not be ‘assigned’ but it is still important and necessary when it comes to your own development and success.

  All Six of the chapters included in the Apprenticeship Patterns book are very important for your own development and the development of your career. Many of these patterns are things that can be disregarded by people while learning but it is important to remember you started somewhere and it is up to you to ensure you develop well professionally and you utilize your counterparts as mentors and examples.

  My thoughts on the reading are that I believe many people including myself forget the significance of looking as different perspectives. The different patterns in this reading provide a whole new perspective in which I agree with the majority of the content and find it rather though provoking. In my opinion chapters four and six would be the most important because truly nobody can assess you more accurately than yourself in order too better yourself and constructing a curriculum is something that can in a sense guarantee your continued learning throughout your life as you assign things to yourself and hold yourself accountable.

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

The Deep End pattern is about growing your skills and boosting your confidence. It’s also about challenging yourself with bigger things. Growth is significant, it’s about taking big risks and doing things you don’t usually reach out for. Taking risks may be scary but playing it safe doesn’t help you improve or leave you unsatisfied. The Deep End pattern means that people should take on big projects or high-profile roles even when they don’t feel ready to. The importance of finding mentors, building feedback loops, and seeking help when needed. People should want to take on challenges, even if there’s a chance of failure, can open up doors and opportunities that playing it safe never will.That pattern knows that there are risks involved but those risks can cause growth by being in a scary situation and getting passed your comfort zone.

I found the pattern useful because it’s supposed to not only build your skills but also build your confidence. Boosting your confidence is a skill that some people don’t think is necessary but it can open up so many opportunities. Just by being brave, taking risks, and learning from failures taking those experiences can help people shape a successful future. I would say that pattern has changed my way of working because usually, I want to take the safe side and not take any risks doing that would just keep me from fulfilling my full potential. Challenging my self will only better myself and the way I work. I don’t disagree with The Deep End pattern because it has the right idea of doing something risky so you can grow instead of being comfortable with where you are now. This pattern is about bettering yourself, learn from any failures you had in the past, and grow from them. Don’t let anything hold you back from shaping your future keep trying to succeed. This is a pattern I will use moving forward so it can not only help me become more successful by taking risks but also build my confidence so i’m not scared to take any opportunities ahead of me.

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.

For this week’s blog post, I have chosen to discuss the blog “An Overview of Unit Testing” by Kayode Adeniyi; this article discusses the importance of unit testing, what it is, the stages of the unit testing process, as well as discusses some differences between automated and manual unit testing. I chose this topic for this week’s blog post because unit testing fits well within the issues we are discussing in this class; I also like how the author discusses the differences between manual and automatic testing.

The first topic the blog discusses is what unit testing is. “Unit testing is a testing method in software development where each individual part (unit) of an application is tested to analyze its proper working. This approach is pretty common and used by most development teams to verify the accuracy of each software component.” In my opinion, understanding what unit testing is is imperative, especially understanding that each test tests a part of a system, not the whole system.

The blog then mentions some key aspects of unit testing, which are, in part, why they are so helpful for developers in all fields of software development. The key aspects mentioned are debugging errors from the root, having reliable testing procedures, repeatability at every stage, and simplicity over complexity. The article also mentions that separating each part of a program makes it much easier to find and correct errors that appear as you are working on a project. The blog also discusses the steps in developing unit tests.

The first step of the test development process is planning the test. The blog describes this first step as “… [T]he developer defines the objective and scope of the testing. Once the unit of application is identified, the developer also defines the criteria for testing it. Critical thinking and effective planning is needed at this stage to ensure focused testing.” Due to this step’s importance in determining the functionality of the final test, it is one of the most essential parts of the test development process.

The next phase of creating unit tests is the creation of test cases. The blog describes test cases as scenarios where the units’ functionality is being tested. The blog also discusses edge cases or scenarios in which an unlikely event is to occur but still needs to be tested in the event where this unlikely event happens. The article defines an edge case as “… an occurrence of an extreme scenario during the normal expected working of any software. They are often the rare events that can happen when a user uses the software application.” While these events are unlikely to occur, if your project will be used by many people over a long enough period of time, these edge cases are an inevitability.

Blog: https://blog.logrocket.com/product-management/unit-testing-guide/

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.

Over the past few classes of the semester, we’ve gone over some of the terms as well as the methods used in software testing. Two of the methods that stood out to me were Black Box Testing and White Box Testing, mainly because I assumed they were methods that were closely related. We didn’t go in depth with these terms and methods but from what I researched and discussed with my group, my assumption was correct.

Black Box Testing is a method in which the software is tested without looking into how it works internally. Testers provide inputs then observe the outputs produced by the system. The goal is to evaluate how the system responds to “user actions that are both expected and unexpected.” This method can help identify defects, errors, and the like from a user’s perspective, as they usually have no knowledge of the inner workings of the software. This also means that testers don’t need a deep understanding of software testing or the particular code of the software; and as such, qualifications are not so important.

White Box Testing is a method in which the internals of the software are examined and tested. Testers examine everything within the software, such as the structure, logic, and code, and create test cases that assess that. This method is effective at uncovering issues with code quality and structure, bugs, and more that can’t be seen or evaluated with Black Box Testing. Like Black Box Testing, testers must ensure that the software meets specification. Unlike Black Box Testing, testers need a deep understanding of coding and software testing as well as that particular software being tested. 

I believe that both will be very important in the software development process, although I do lean towards White Box Testing having more impact. Those with specialized knowledge and skills will likely sort things out faster looking at the internals of the code than those without looking at just the inputs and outputs. It’ll generally be more effective as well as tests are done on the code and thus developers can quickly fix and solve those issues; whereas with Black Box Testing, it’s more of a way to acknowledge that there is some issue. I can only imagine Black Box Testing to be a very tedious and monotonous process although I could be completely wrong. It may be most effective to implement White Box Testing first and Black Box Testing afterward, as a double check of sorts.

Source: https://www.ranorex.com/blog/black-box-vs-white-box-testing-understanding-the-differences/

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