Summary:

The pattern “Nurture Your Passion” addresses the struggle faced by software developers whose passion for their craft is hindered by the work environment. Often kept to “simple” tasks or faced with demoralizing conditions like corporate hierarchies or project death marches, developers find it difficult to maintain their enthusiasm. However, the pattern suggests several strategies to protect and grow this passion.

Reaction:

The pattern could be related to deeply with many software developers who have found themselves in similar situations. It highlights the importance of preserving one’s love for the craft amongst challenging circumstances. What’s really interesting is the acknowledgment that not everyone has the privilege to earn a living through their passion, making it important to safeguard and nurture it.

What’s Interesting and Useful:

The emphasis on working on tasks that align with personal interests stands out as a practical approach. By dedicating time to activities that spark joy, developers can reignite their passion and find fulfillment in their work. Additionally, the idea of seeking out like-minded individuals and immersing yourself in the classics of the field serves as a reminder of the rich heritage and community support available in software development.

Impact on Professional Outlook:

The pattern encourages a reevaluation of how someone approaches their career in software development. It makes individuals prioritize environments that support their growth and passion, even if it means diverging from conventional career paths. Setting clear boundaries and maintaining a sense of wonder about programming, as said by Paul Graham, becomes essential for long-term satisfaction and success in the field.

Disagreements and Reflections:

While the pattern offers valuable insights, some may find it challenging to implement certain suggestions, especially in highly demanding work environments. Setting boundaries and steering conversations towards positive topics require courage and confidence, which may not always be feasible depending on organizational culture and power dynamics. However, the underlying message about the importance of preserving one’s passion remains relevant.

In conclusion, “Nurture Your Passion” serves as a reminder that maintaining enthusiasm for software development is a deliberate effort, especially in the face of adversity. By embracing strategies outlined in the pattern and staying true to their passion, developers can navigate challenges and thrive in their careers.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Long Road” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about not being able to learn or grow more in my field, becoming stagnant because there is nothing else I can learn. Thankfully, this pattern dissuaded those fears of mine and inspired great confidence in my future endeavors.

The quote that this pattern opens with immediately puts much of my concerns about the limits of what I would be able to learn to rest. “‘How long will it take to master aikido?’ a prospective student asks. ‘How long do you expect to live?’ is the only respectable response.” In comparing computer science to Aikido, it implies that no one can possibly learn all that there is to know in computer science. Another quote from this section that makes me even more excited to be a part of this field mentions that for every step you make, the finish line is two steps further away. “For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.” While this may seem like a disappointing aspect of our field for many, the limitless opportunity for me to grow is why I love this field of knowledge.

I did not think it was possible, but further reading in this section made me even more excited and proud to be in computer science. “Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now, you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.” This quote had me thinking about incredible and outlandish possibilities in this field, which made me even more eager and excited to be in this field than I thought possible.

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.

As my journey to becoming a full stack developer continues, I have begun to encounter the need for front-end testing. When finding an article, I realized that I did not have very much knowledge on what front-end testing entailed or how to implement it into my coding. I found the blog “Front End Testing: A Comprehensive Overview” by Kiruthika Devaraj (https://testsigma.com/blog/front-end-testing/) on my search for information on this topic.

The blog starts off by explaining that front-end testing is focused on the user’s experience. While past experiences have taught me that back-end testing specifically tests the functionality of the code, front-end, also known as the user-facing end of a website, testing has a higher focus on the user’s interactions. The author also delves into eight different types of front-end testing and the elements that make up these different types:

• Unit Testing is the analysis and testing of the individual components to ensure they each work as intended. 
• Acceptance Testing involves testing to ensure permissions, such as account accesses, are working properly. 
• Visual Regression Testing tests for visual changes in the front-end by comparing a reference picture to a baseline image. This can typically create brittle tests that can fail due to the slightest changes in an element’s location on a page.
• Performance Testing measures an applications stability and responsiveness under different levels of simulated stress and traffic.
• Accessibility Testing ensures that individuals with visual impairments or other additional needs can still use and access the application to the fullest of their capabilities.
• End-to-End (E2E) Testing involves testing the application from start to finish while testing all components and systems for how they work together.
• Integration Testing is when each individual module is tested to ensure it has been implemented correctly.
• Cross-Browser Testing tests that the application works correctly across multiple browsers and confirms compatibility.

Devarj also provides tips for better front-end testing, the first tip is to always use a testing framework. These frameworks, also called front-end tools, are what actually run the tests. Although countless front-end tools exist, the blog provides information to 3 popular options; Testsigma, Selenium, and Ranorex. Testsigma and Selenium are both open-source front-end testing frameworks that may be worth investigating further, while Ranorexis a commercial framework that may be more than what I am currently looking for. 

Front-End Testing Moving Forward

As I move to implement automated front-end testing into my projects, it is important to remember that the front-end testing is focused on ensuring the project is user-friendly, responsive, and visually appealing by testing the layout, design, and functionality across multiple browsers. Doing so will provide users with the best possible experience.

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

The ‘sustainable motivations’ pattern is all about development in the real world and how it can be very challenging as an apprentice to get used to the reality of software development. Development of your own technical skills is very important as you gain more experience working with customers and with a different variety of products. As it is described you may have a different reason which motivates you to continue in your programming job whether it be that you are motivated for the money, motivated to build reputation or motivated by your own enjoyment of programming. THis pattern is a part of the “long road” chapter which is characterized as being a part of the “long road” from apprentice to journeyman to master within the software development field.

The solution to this proposed problem is to not get “trapped by your motivations” and a way to do that is to write down things you are motivated by and be able to separate the things that motivate you from the things that are what others see or think. Motivation is something that is important in any career but software development requires a lot of motivation as times when developing is strenuous or when you have a long project ahead of you.

I find this pattern to be important as I feel that a lot of people struggle to maintain motivation in all careers worldwide, not just software development. So having a strategy to combat low levels of motivation and also try not to burn yourself out by being too motivated is very important. Many situations will present you with long projects where you need to be able to ‘sustain motivation’ this is especially important to software development as many times you will be faced with longer projects which will need your full attention throughout. Reading about this pattern makes me realize that it is ok to not always be fully motivated whether that is because of the length of a project or if it is due to your working environment, you shouldn’t expect to always be fully motivated but you need to be willing to persevere even when a project takes a lot out of you as it will further you within your craft.

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.

https://testsigma.com/blog/levels-of-testing/#:~:text=The%20most%20common%20types%20of,system%20testing%2C%20and%20acceptance%20testing.

Different levels of testing software is very important when it comes to quality assurance and each of the different levels is based on different combinations of things that help ensure the best conditions and functionality of your software. The four different levels of testing are as follows: “Unit Test” which tests an individual component, “Integration Test” which tests an integrated component, “system Test” which tests the entire system and “acceptance Test” which tests the final system otherwise known as the final product.

Unit Testing is used to outline the expectations of a program or outline its functionality which in essence makes sure that certain parts of the program function as intended. Integration testing allows you to test groups of functions to make sure that they interact properly with each other which is a step above unit testing. System testing is similar to integration testing as it tests a ‘group’ of functions but this group is now comprised of every part of the program/application. Acceptance testing then tests all functional and non functional aspects of the program in order to ensure proper functionality, security, etc.

I selected the levels of testing as a topic as it directly relates to the types of testing we have been doing in class. We have been testing functionality of different bodies of code so far during this semester and we have used different techniques including but not limited to equivalence class testing, edge case testing, worst case testing, boundary value testing, etc. I would say that most if not all of these testing types would fall under the unit testing level of software testing as we have for the most part testing individual system components being able to learn about the different levels of testing makes me excited to continue on through the levels of testing.

This source was very helpful when it came to learning about the other levels of testing we have not used during class yet and I would recommend this article to any of my fellow students although this article does not go extremely in depth when it comes to the different levels of testing it does give you a good general understanding of each level so that you can go on to learn more without getting confused between the different levels of testing. The diagrams and explanations of the software sequence are valuable resources for a software testing course.

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.

Boundary testing is a technique that “involves evaluating data based on boundary values… such as minimums and maximums.” It involves testing the lower and upper limits of a domain of inputs, as well as values just inside and outside those limits. This technique helps improve software quality by detecting defects early in the development process, which ultimately saves time and resources. This is due to the fact that “the number of defects at the boundaries of an input domain tends to be higher than in other areas of the domain.” 

Going back to how it saves time and resources, it helps developers choose more efficient test cases, which cuts down on time and how much they have to do, especially with large sets of data and number of inputs to consider. Furthermore, this technique “allows for a lot of uniformity and the test cases are much smaller” meaning that it can be automated. This would save more time, possibly result in less errors than if a person were to write the test cases, and allow for developers to put their focus on other tests or somewhere else, resulting in increased productivity. 

Boundary testing involves determining the input value range, which is whatever values the system accepts. Values inside that range are valid while those outside are invalid. Test cases are then created based on the values at the extreme ends, end values, and values just before and after the end values. For example, with a range of 0 to 100, we test values less than 0 (-50), greater than 100 (150), values around and at 0 and 100 (-1, 1, 99, 101). 

Another example the article shares is one that allows users to create a password. The password has to be 5 digits meaning that the range is 10000 at minimum and 99999 at maximum. Any combination of numbers is valid as long as it is 5 digits long, meaning that 4 digit long and 6 digit long passwords are outside the range and are invalid. 

Boundary testing seems like a very useful testing technique with very little downsides. It’s a black-box testing technique which usually means that testers don’t need extensive knowledge of coding, computer science, or the system at hand. It also seems very easy to do as long as all the necessary knowledge for testing is provided. Seeing as how it can also be easily automated, it may be more efficient to focus on more complex or time-consuming testing techniques while this test is running in the background or on the backburner.

https://www.indeed.com/career-advice/career-development/what-is-boundary-testing

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

Software testing is a crucial aspect of the software development lifecycle. Among various testing techniques, Boundary Value Testing and Equivalence Class Testing stand out for their effectiveness in identifying defects early in the development process. In this blog post, we delve into these two techniques and discuss their implementation using JUnit, a popular Java testing framework.

Boundary Value Testing: Boundary Value Testing focuses on testing the boundaries of input ranges. The rationale behind this technique is that bugs often lurk around the edges of acceptable input values. By testing values at the boundaries, we increase the likelihood of uncovering potential defects. For example, if a function accepts input within the range of 1 to 100, we would test values such as 0, 1, 100, and 101.

In JUnit, implementing Boundary Value Testing involves writing test cases that specifically target boundary values. By using assertions to verify the behavior of the function at these critical points, developers can gain confidence in the robustness of their code.

Equivalence Class Testing: Equivalence Class Testing aims to reduce redundancy in test cases by partitioning the input domain into equivalence classes. Each equivalence class represents a set of input values that should produce the same output when processed by the function under test. By selecting representative values from each equivalence class, testers can ensure adequate coverage without testing every possible input value.

In JUnit, implementing Equivalence Class Testing involves creating test cases that cover each equivalence class. Test inputs are chosen strategically to represent the entire range of possible inputs within each class. This approach not only improves test coverage but also makes test suites more manageable and maintainable.

Combining Boundary Value Testing and Equivalence Class Testing: While both techniques offer unique benefits, they are most effective when used together. By combining Boundary Value Testing to test the edges of input ranges and Equivalence Class Testing to cover representative values within each range, testers can achieve thorough test coverage with minimal redundancy.

Boundary Value Testing and Equivalence Class Testing are powerful techniques for improving the quality of software. By leveraging JUnit, developers can easily implement these techniques within their Java projects. By understanding the principles behind these testing strategies and applying them effectively, teams can build more robust and reliable software products.

Incorporating these testing techniques into your development workflow can help catch bugs early, reduce the risk of defects slipping into production, and ultimately enhance the overall quality of your software.

Link: JUnit 5 – User -guide/

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

While looking for more articles online involving testing, I came across SauceLabs. This website is another compendium of blogs, similar to stickyminds mentioned in my last blog. The layout and articles on this website were an excellent selection of resources dedicated to testing and quality assurance. While running through many bugs in my most recent projects and assignments, I was searching for an article dedicated to programming bugs. I found an article that fit my needs, dedicated to the differences between severity and priority of bugs, which is something I had not previously considered. The article’s title is Understanding Bug Severity vs. Priority: Key Differences and Best Practices by Chris Tozzi

The article provides (as the title indicates) a breakdown of bug severity and bug priority in software testing. It explains that bug severity is primarily concerned with the impact of a bug on the system’s functionality. Issues are categorized into the following levels of severity: critical, major, minor, and trivial. Each of these have a different level of impact on the system. For example, critical bugs may cause system crashes, while trivial bugs have a small functionality and performance impact. Bug priority focuses on the order in which bugs should be addressed, considering various factors that will impact the job as well as the program, such as deadlines, or bugs that are caused by higher priority bugs. Bugs with high priority require immediate attention, and those with low priority can be addressed later as the program develops and is tested further. It is an extremely important skill to be able to identify the severity and priority of bugs throughout the system and its development, so as to facilitate a smoother and more efficient development cycle. The article also provides some examples, such as a critical severity bug that causes data loss. This bug would ALSO have high priority because it is causing a lot of damage to the system’s structure.The article offers very useful recommendations for bug reports such as: establishing clear classification guidelines for bugs (priority/severity levels), communicating efficiently within teams, or reassessing bug statuses frequently.

I chose this blog because of my most recent experience in my assignments and projects. I had found that many bugs relied on each other, and I had never previously taken the initiative to learn more about bugs. When working with a team in industry, I will now have an understanding of how bugs are classified, as well as how to manage bug reports. This is something I had very little experience with prior to this article, and I will make sure to put extra effort into bug reports in my own projects with peers. I will continue to look into articles about bugs, testing, and QA to further improve my knowledge.

Source:
https://saucelabs.com/resources/blog/bug-severity-vs-priority

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.