Apprenticeship Patterns Chapter 1 and Chapters 2-6 Introductions

After reading the introductions to Chapter 1 and Chapters 2-6 of Apprenticeship Patterns, my desire to be in the software development field drastically increased. It is more than a field of just constant repetition. Instead it is an ever changing field where there is always something new to learn, questions to ask, individuals to interact with, and skills to eventually master. The introduction of chapter one instills the fact that when first starting in the field, we may be nervous or not really know what we should do and question software development as a career. It encourages us to reflect on our career journey, what we have accomplished, what we still need to learn, and how we can overcome different challenges we may face to eventually reach a mastery level.

What interested me most was learning about the differences between an apprentice, a journeyman, and a master. An apprentice is typically an individual who is trying to find a way to complete tasks in a more efficient, faster, smarter way, and in a role with few responsibilities and continuous learning. The journeyman retains the attributes learned as an apprentice to continue to grow in the field. In this case, the journeyman’s next focus is to create connections between practitioners, different communication channels, and masters. After adding this, the journeyman begins building a portfolio to demonstrate their understanding in the field. Lastly, the master encompasses all the roles of both the apprentice and the journeyman as well as focuses on moving the industry forward. I found this interesting because no matter what we all start as an apprentice. Some skills may be easier to learn and understand than others, but overtime with constant training and learning, we can become masters in any aspect of the growing field.

In regards to Chapters 2-6, the book covers topics revolving around being committed to your work, continuous learning, mentoring, and constant practice. I am personally interested in reading Chapter 3, Walking The Long Road. The introduction of this chapter refers to viewing software development as more of a journey rather than just a field or destination and that there is always something new to learn, challenges to face, and things to master. Additionally, this chapter drives into setting meaningful goals and how to overcome challenges in your learning journey.

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

Software Testing Terms – Can you list them all?

link to blog at the end:

Have you ever heard a word or phrase that you feel like you should understand but you just don’t? It’s happened to many people, and I’m sure it is not uncommon in the software industry. Certain software terms are either confusing or unknown, which is perfectly understandable!

Chris Kenst’s blog post relates to what we studied in class this past week, as it correlates with and even mentions some of the terms we learned, such as black box testing. It will hopefully help the definitions we previously learned stick in my head as the weeks go by.

This blog post is all about lingo. It aims to better prepare students and software-testing newbies for the confusing jargon coming out of their coworkers’ mouths. It is in a simple glossary format, which is easy to understand and refer back to from time to time. There are 50 terms listed as well, so there may be some left out, but the ones listed are what you are most likely to hear in the workplace or in communication. Kenst also mentions at the end of the post that an increased mutual understanding of such terms can lead to increased productivity and collaboration.

I chose to cover this blog post because it is easy to get lost in all the mumbo jumbo tech buzzwords flying around the internet. It is like being a parent and learning what your kids’ slang means; except the kids are your coworkers and the slang is important keywords for your profession. I would not want to be the one guy at a meeting who does not understand “black-box testing” or what “domain testing” is. Jokes aside, this is a great resource for my fellow students to refer back to, especially as we are just beginning our software testing journey. These terms are important to know, because otherwise you might fall behind as new terms and testing variations are created. 

I personally believe this is a great starting point for those new to software testing (like me) and those who might need a refresher every now and then whenever their coworker says something unfamiliar. I learned how “high volume automated testing” involves auto generation, execution, and evaluation of multiple tests that may be weaker and not as thorough on their own, but together expose bugs and weaknesses. I will continue to learn more testing variations and other terms from this list to strengthen my confidence as a software tester and engineer. I hope to apply this knowledge in the future whether it be at a job interview or in a working environment, proving to my coworkers that I understand the language they are speaking and can keep up with their discussions.

Blog: 50 Software Testing Terms Defined – Chris Kenst

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Object-oriented Testing

Object-oriented testing revolves around the examination of individual classes within an object oriented program. Objects are instances of these classes. In the article ” Object Oriented Testing in Software Testing” , the author talks about the evolution between old testing methods to object-oriented testing. The author also talks about the advantages of object oriented testing, which include reliability, extendibility, and reusability.

Navigating Object-Oriented Testing

Strategies and techniques for developing test cases in Object Oriented Testing could include Fault-based testing, scenario-based testing, and class testing based on method testing,. These different test cases / techniques play a pivotal role when it comes to trying to find all defects, improper interactions among classes, or being less time consuming. Object-oriented testing can however present some challenges such as testing inheritance in larger systems or the inability to dynamically test classes.

Why did I pick this Article?

I chose this article because it offers a great understanding of Object-oriented testing and highlights the many techniques that can be used, also the many different advantages of Object oriented testing. Moreover, the article does a good job explaining the evolution of testing methods, to object-oriented testing and some challenges you may face in testing Object-oriented programs.

Personal Reflection

This article has broadened my understanding of object-oriented testing, specifically detailing the transition from old traditional methods to object-oriented. I was also able to grasp the many advantages and challenges that object oriented presents, allowing me to know why we should and should not use it in certain scenarios. The knowledge gained from reading this article will play a pivotal role when approached to testing in object-oriented environments. The knowledge for developing test cases and the advantages and challenges will guide me in future projects.

The full Article is here: https://www.scaler.com/topics/software-testing/object-oriented-testing-in-software-testing/

From the blog CS@Worcester – In's and Out's of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.

AI In Software Testing

The blog I chose was “Will AI Replace Manual Testers?” by Thijs Kok. The blog post highlighted the importance of testing for software development and the role that AI plays. I chose this blog for two reasons, one due to the fact that we recently discussed the types of testing in software development. The other reason being the rise of artificial intelligence popularity in the software and technology field. I thought this blog was able to highlight one of the main fears that people who are studying computer science or people who are already in the field have when it comes to artificial intelligence. This fear being is artificial intelligence going to be able to take over our jobs. We have seen just what artificial intelligence is able to do through a multitude of examples showcasing just how advanced the AI is when it comes to solving programming problems. For those reasons, that is why I chose this blog because I thought it would be interesting if AI could take over this aspect of the jobs we want.

The blog post started off by acknowledging the power AI has right now throughout the world and how the tech field is no exception. The author described three ways how AI is already being utilized within the software testing scope. These ways being test case generation through, test case execution and test result analysis. The blog post ended with the overall question, will artificial intelligence replace testers? The conclusion that the author reached was, no, “While AI can automate specific testing aspects, it cannot entirely replace human testers. The cognitive skills, creativity, problem-solving abilities, and emotional intelligence that human testers bring to the table are irreplaceable”. The author stated that even though AI can be very powerful it can be seen more as an enhancement rather than a replacement.

My overall take from this blog post is the importance in understanding how AI works and how to integrate to use it as a tool for the future. While we can’t use the AI to just do the work for us it can be a helpful asset that will make the job easier allowing us to focus our efforts on more important matters, things that the AI otherwise could not handle. I believe that the blog post was a great piece that anyone could read and take away various insights from. For example, it was able to downplay people’s fears on AI taking over as well as teaching people how to use it to their benefit allowing integrations for the future.

https://www.testmonitor.com/blog/will-ai-replace-manual-testers

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns by David H. Hoover and Adewale Oshineye: Ch. 1 and Introductions for Chs. 2-6

I’d like to talk about my thoughts after reading the portions of Apprenticeship Patterns by David H. Hoover and Adewale Oshineye assigned to our Software Development Capstone class. My first impression on reading the title was that this textbook would present different outlines of careers in software and information technology. After reading the introduction, however, I realized that the purpose of this book was to share different patterns and habits that would lend themselves to a successful apprenticeship in software craftsmanship.

The promotion of a growth mindset is one of the first themes established in the book. The authors talk about the growth mindset’s emergence from the research of Carol Dweck, the author of “Mindset: The New Psychology for Success”. The core belief of a healthy growth mindset is that a person’s intelligence is not fixed, and that a person can always grow their knowledge and ability through effort and learning. Through the growth mindset, people are encouraged to perceive failure as an opportunity for learning and reflection instead of as an indicator of inadequacy.

Maintaining an optimistic growth mindset is especially important for people working in software development and computer science. The volume of knowledge it seems to require to contribute anything of substance seems so overwhelming, it can be easy to tell yourself that you’re incapable of learning it all, or that you don’t even know anything as you are now. This emotional state of feeling incompetent or like a fraud despite your accumulated experience and talent is popularly referred to as imposter syndrome, and a survey conducted by Blind in 2018 found that more than half of tech workers report feeling like an imposter in their place of work. These responses came from people working with tech industry leaders like Google and Amazon, which shows that these feelings of self-doubt can exist in anyone, no matter how hard-working, efficient, or naturally talented. In a profession like software development, where the majority of a developer’s work is built on top of the sum of the work of many other people over many years, it’s essential to adopt a growth mindset to bolster your mental and emotional health despite the temptation to doubt yourself and invalidate your own accomplishments.  

In addition to the maintenance of a growth mindset, the authors propose other uniting values of a software craftsmanship community. Among them are constant adaptation, a desire for pragmatism over dogmatism, and the open sharing of knowledge. This software craftsmanship community would also value individual responsibility for one’s apprenticeship journey, and a willingness to experiment and be proven wrong.

The concept that interested me the most from the introductions of later chapters was The Long Road. I understood The Long Road as a metaphor for the lifelong journey of learning, and I recognized the necessity of the growth mindset the authors described earlier as a way to steadily propel yourself along that road. Without that mindset, the discouragement and confusion that naturally accompany learning can be too difficult to overcome.

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

Reflecting on the Initial Chapters of “Apprenticeship Patterns”

As I delved into the first two chapters of “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, I found myself engaged not just with a book, but with a conversation about the journey of a software developer. This isn’t a typical textbook; it’s a guide for navigating the intricate path of professional growth in software development.

Chapter 1: A Revelation in Learning

The initial chapter immediately struck a chord with me. The concept of ‘breaking the mold’ resonated deeply, challenging the conventional approach to learning. It advocates for a mindset of continuous improvement and learning from every experience, a philosophy I find both daunting and exhilarating. I was particularly intrigued by the idea of being a ‘perpetual apprentice,’ which suggests that there is always more to learn, and every encounter is an opportunity to grow.

Provocations and Insights from Chapters 2-6

As I browsed through the introductions of chapters 2 to 6, I found myself rethinking my approach to my career. The book doesn’t just offer advice; it provokes thought. It made me question: Am I too comfortable in my current knowledge? Am I challenging myself enough? The concept of ‘constructive discomfort’ as a growth mechanism is something I plan to embrace more actively.

A Grain of Disagreement

While I found most of the book enlightening, I did have my reservations. The emphasis on self-reliance, for instance, seems to downplay the importance of structured learning environments. In my experience, a blend of self-driven learning and formal education often yields the best results.

Personal Relevance and Perspective Shift

As a junior developer, the chapters discussing ‘concrete skills’ and ‘nurturing your passion’ seemed particularly relevant. They made me reflect on my current skill set and my long-term career aspirations. This reading has subtly shifted my perspective, making me more open to exploring unfamiliar territories in technology and more conscious of my learning journey.

Conclusion: A Journey, Not a Destination

In summary, “Apprenticeship Patterns” is more than just a read; it’s a reflection on the continuous journey of learning and growing as a software developer. I’m excited to apply some of these patterns in my career, embracing the role of a perpetual apprentice, ever-curious and ever-evolving.

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

Chapter 1

Reading the assigned sections in “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye has been an enlightening experience, reshaping my perspective on the path to mastering software development. Chapter 1, coupled with the introductory sections of Chapters 2-6, lays a foundational understanding of the craftsmanship model in software development, emphasizing continuous learning, growth, and the pursuit of excellence.

The Craftsmanship Model: A New Paradigm

The concept of viewing software development through the lens of craftsmanship resonated deeply with me. It suggests that being a software developer is more than just a job; it’s a lifelong journey of improvement and mastery. The idea that one should always strive to better their skills and contribute to the growth of others in the community is both inspiring and daunting.

The Three Stages of Becoming a Software Craftsman

The delineation of the three stages of becoming a software craftsman—apprenticeship, journeyman, and master—provided a clear roadmap for personal and professional development. This progression from learning the basics, through solving broader problems, to finally leading and mentoring others, underscores the depth and breadth of growth required in this field.

Reflections on the Introductions to Chapters 2-6

The introductions to the subsequent chapters offer a glimpse into the varied aspects of this journey, from the importance of finding and learning from mentors (Chapter 2) to understanding the value of reflective practice and incorporating feedback (Chapter 6). This holistic approach to development, both technical and personal, is particularly appealing.

Personal Relevance and Application

The chapters on reflective practice and creating feedback loops seem most relevant to my current stage. They underscore the importance of not just doing but learning from doing, which is crucial for anyone in a rapidly evolving field like software development.

Disagreements and Critiques

While the book provides a compelling model, I found myself questioning the feasibility of its idealistic portrayal in the modern, fast-paced tech environment. The path seems clear in theory but navigating it amidst the pressures and constraints of real-world projects and deadlines presents a significant challenge.

Conclusion

“Apprenticeship Patterns” offers a refreshing perspective on the software development profession, advocating for a deliberate, continuous journey toward mastery. It challenges the reader to not only aspire to be a better developer but to embrace the journey with all its ups and downs, fostering a community of learning and sharing in the process. This reading has not only broadened my understanding but also deepened my commitment to this path of craftsmanship in software development.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

Software testing

In the fast-evolving world of software development, the significance of rigorous testing cannot be overstated. A recent blog post from The Code Camp titled “Software Testing and Why It’s Important” delves into this critical aspect, shedding light on its indispensability in the development process. This article serves as a comprehensive guide, explaining the necessity of testing, its types, and methodologies, thereby making it an invaluable resource for developers and testers alike.

The Essence of Software Testing

Software testing stands as a cornerstone of development, ensuring that applications perform as intended, are secure, reliable, and user-friendly. The article articulates how testing not only identifies bugs but also secures software against potential cyber threats, a growing concern in today’s digital age. By involving real users, testing guarantees that the software offers a seamless user experience, an aspect critical to the success of any application.

Why This Article?

I chose this resource because it offers a profound understanding of testing’s role in the development lifecycle, a topic directly related to our coursework. The article’s clear explanation of various testing types, such as unit, integration, system, and acceptance testing, complements our learning, providing practical insights into their applications.

Personal Reflection

Reflecting on the content, I was particularly struck by the emphasis on security and user-experience testing. In an era where digital threats are rampant and user expectations are high, these aspects of testing assume paramount importance. This article reinforced my understanding of the multifaceted nature of testing, extending beyond mere bug detection to encompass a holistic approach to creating robust, secure, and user-centric software.

Application in Future Practice

Moving forward, I plan to integrate these insights into my testing strategies, particularly the early involvement of real users through acceptance testing and the rigorous assessment of security vulnerabilities. Emphasizing these areas will not only enhance the quality and security of the software I contribute to but also ensure a superior user experience. Security is something that I have wanted to learn more about for a long time and I think testing is a good way to move towards that

Conclusion

The insights gained from “Software Testing and Why It’s Important” are instrumental for anyone involved in software development. It underscores the critical role of testing in delivering high-quality, secure, and user-friendly software, aligning perfectly with the principles we’re learning in our course. For those interested in exploring this topic further, the full article is available at The Code Camp, offering a deeper dive into the vital world of software testing.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

Apprenticeship in Software Development

If you’re like me, you probably dislike doing reading for school and find it to be pretty tedious, usually resulting in a drab writing exercise afterwards. So, reading through the first chapter and then the introductions to the following chapters in our textbook Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman seemed like it would be similarly boring/tedious, but I found the writing to be engaging and discuss relevant topics with relatable analogies. 

The first chapter was primarily an introduction, and I found its discussion of what Apprenticeship is and means in modern society versus how it was implemented in Medieval times where the term originates. One point brought up is that modern “apprenticeships”, or positions with a similar title are more similar to what I think of as an internship, and may involve a lot of training but it mostly involves learning how to use a system/software rather than learning how it actually works behind the scenes or even how to improve it. 

By the same token, the author’s discussion of Medieval apprenticeship and how it correlates to modern situations resonated with me – particularly the division into the three main classes of Apprentice, Journeyman, and Master. Looking back, at the beginning of my Computer Science degree I was certainly a green apprentice and came in with an open mind and I was very fortunate to have family members who are undoubtedly masters to help teach me as their apprentice. Thinking about these individuals, they ARE in fact always learning more and new things and in their own way delving into their own areas of interest to try things which may have never been done before. But, as I approach graduation I feel myself starting to have more tendencies and qualities of a Journeyman as described. With early-career C.S. trends commonly involving a few different companies or departments, it’s easy to see more correlation there to the Journeyman, who travels sharing knowledge with others while also learning from them and improving their repertoire.

In reading the introductions to chapters 2-6, I found them to be quick, engaging and informative – exactly my type of reading. The chapter 3 introduction about Taking the Long Road resonated with me the most and left me with a lot to think about. Many times I’ve found myself feeling like the individual in the example, both inspired/excited by the sheer power and intellect of some other around me and discouraged/terrified of how far ahead of me they clearly appear to be. However, as the text discusses we are all traveling on the same general road as developers and Computer Science professionals, some have just been traveling on it longer, faster, and/or in different directions than us. It’s largely about the journey that gets you to your destination, which we will inevitably achieve as long as we refuse to give up.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

An Intro to TestProject as an Automated Testing Tool

Classes restarted last week, and during the first week I found myself reading and writing a lot of introductory blog posts about upcoming semester course topics. As part of my setup tasks for CS-443 Software QA and Testing, I read about one of the most popular manual API Testing tools Postman and saw reference to TestProject, an automated testing tool from the same company Tricentis. So, I decided to do some further reading into TestProject as I understood the basics of manual testing, but had not seen automated testing in action yet. To do so, I found a blog post on the Tricentis site containing an overview tutorial of API testing and how platforms like Postman and TestProject can be valuable.

The post begins by discussing the value in API Testing and mentions the utility of Postman, but also brings up some of the limitations that are commonly encountered such as test automation, scheduling, and end-to-end test reporting. Intro TestProject → This testing platform offers solutions for end-to-end API testing by providing an environment to not only test API’s, manually but also to automate API-based test flows, schedule and run them periodically, and generate execution reports without the need for third party tools or writing any code.

The blog also contains a six chapter tutorial on using TestProject, so I delved into Chapter 1 – Basic API Test Automation. This emphasizes the platform’s ability to handle a wide variety of input sources like HTML, Databases, and more, then showing the application GUI and taking the reader through how to add ‘test steps’ in TestProject to set up automated testing for a GET HTTP request using NASA’s public APIs including search parameters and discussion on Dynamic Endpoint URLs (and implementing them) amongst others. Chapter 2 offers another brief tutorial discussing the value of scheduling automated tests with image steps (guide) to doing so with interactions to Android and iOS systems.

From these introductory chapters, I was able to get a basic idea of how to use TestProject to design calls, execute tests and access result reports. The other chapters in this TestProject tutorial cover more advanced API testing and validation flows, shell commands, scheduling API automation and more. As an introduction to Quality Assurance Testing and the course in general, this chapter was intriguing and valuable to get an idea of what an automated software testing tool looks like and how to use it in a basic sense. Stay tuned to read more about these other chapters and other topics in software quality assurance and testing and other exciting computer science related topics!

Sources:
General TP Post: https://blog.testproject.io/2020/11/10/automating-end-to-end-api-testing-flows/

Chapter 1: https://blog.testproject.io/2020/11/10/basic-api-test-automation/Chapter 2: https://blog.testproject.io/2020/11/10/api-test-automation-flows-combined-with-mobile-functional-test/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.