Postman Setup: TestProject

After exploring more of testing, and different strategies, I wondered about how testing could be automated. I came across a blog for Postman, on the TestProject website explaining Postman’s use in automated API testing. This blog is focused on providing a tutorial to understand how to use Postman to automate testing, rather than understanding various testing practices as seen in my previous blogs. The article’s title is Getting Started with using Postman for API Testing by Dave Westerveld

The blog first defines what an API is, as Postman is specifically for API testing. The blog defines API as Application Programming Interfaces. These APIs are extremely important in facilitating communication between software systems. Testing them is paramount for this reason, to assure they are working properly. This is where Postman comes in. It is an automated API tester, with a fully fledged application download. The article outlines the setup of Postman, and explains how to get it to cooperate with your system: First open the app of Postman that you’ve downloaded and then sign in. After this you are allowed to make API requests, the new button is then used and an API request is created. You name the request, and create a collection, where the requests are stored. Following setup, the article explains how to execute a Postman request. During setup, the article created the collection name JsonPlaceHolder, and then used that collection as the URL for the Request URL. After this, Postman will send the request for you. This can be used to compare results from different requests of an API and assure they are the same, although some manual input IS required in automated testing. However more intricate API Testing is shown in further tutorials with Postman.

This is a topic that interested me greatly, as I have been given many suggestions to look into API testing. Through the CS-443 course, I had been looking for more options to test and explore coding. Automated testing is something immensely interesting, and I appreciate the comprehensive guide provided by TestProject for Postman. This is of great value to me as I will continue to look through this guide and potentially post more blogs on this topic, as I explore automated testing. This first blog is mainly involving setup, and the basic concept of requests, but I look forward to further automated API testing using Postman, as these articles are very well structured.

Source:
https://blog.testproject.io/2020/07/15/getting-started-with-using-postman-for-api-testing/

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.

CS-448 Apprenticeship Patterns Chapter 2-6 Introduction

Chapters 2-6 in the Apprenticeship Patterns textbooks goes over the specific different practices and patterns that software developers use in order to grow in their field.

Chapter 2 talks about the values of “emptying the cup” as an apprentice. Embrace the beginner’s mindset with The White Belt. Overcome roadblocks with Unleashed Enthusiasm. Acquire concrete skills in specific technologies to explore advanced patterns. Avoid complacency by systematically broadening your tech skills. Expose your ignorance to focus on learning needs. Confront and flex your knowledge muscles. Take audacious tasks to learn and grow. Retreat into competence when overwhelmed, then gather yourself to ascend further.

Chapter 3 explains how many people are walking the same path even when they seem to be on a different path. In other words, the experts that know more than you in the work field went through the same struggles (walked the same path) as you are to get to where they are now. It explains the story of Dave as he continues his journey in software development with a sense of assurance. However, his interactions with highly skilled hackers in online communities and face-to-face collaborations with high level developers humbled him and fueled his desire to learn. As he delved deeper into side projects and consuming learning material, Dave realized the vastness of knowledge available and the continuous learning process inherent in software development. While there is a considerable gap between his skills and those of seasoned developers, Dave found solace in the shared journey towards mastery that all developers embark on.

Chapter 4 introduces the concept of letting go of perceived competence and allow yourself to recognize that there is way more to learn and more to travel down the Long Road. The rapid learner faces the risk of becoming complacent in their success within their current environment which could stagnate their growth. It is crucial for such individuals to acknowledge the broader landscape of opportunities beyond their immediate sphere and to remain humble in the face of their accomplishments. The focus should not be on surpassing others but on personal growth and improvement, recognizing that the journey towards mastery is ongoing and that collaboration and mutual support are integral to this process.

Chapter 5 emphasizes the concept of learning and, especially for apprentices, how it is critical these patterns be applied early on in their journey. The essence of apprenticeship in software development revolves around perpetual learning and effective communication. Apprentices must constantly seek opportunities to replace ignorance with skill, not only acquiring concrete technical abilities but also in developing the ability to learn itself. These concrete learning activities such as “Expanding your bandwidth” and “Breakable Toys” pave the way for deeper self-discovery, leading to the importance of reflecting on work. sharing knowledge, creating feedback loops, and understanding personal weaknesses to transition successfully from apprentice to journeyman and eventually master craftsman.

Chapter 6 talks about the constant time and effort that should be put into studying to further develop your learning curriculum. In today’s age digital age, access to vast amounts of information is easy, thanks to the Internet and handheld devices. While blogs and online resources offer valuable content, the wisdom found in traditional books by experts like Jerry Weinberg and Kent Back is irreplaceable. Incorporating reading into an apprenticeship is crucial for success, allowing individuals to construct their own learning curriculum.

2. Emptying the Cup | Apprenticeship Patterns (oreilly.com)

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

4. Accurate Self-Assessment | Apprenticeship Patterns (oreilly.com)

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

6. Construct Your Curriculum | Apprenticeship Patterns (oreilly.com)

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.

CS448 Software Development Capstone -Apprenticeship Patterns: “Practice, Practice, Practice”

The first pattern from “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye that I would like to write about is “Practice, Practice, Practice”, from chapter 5 of the textbook. I’ve been learning how to code since shortly before I started my first semester at community college, in the fall after I graduated from high school. I’ve been able to complete the lessons that I’ve been assigned at school and through online resources, but even still today, whenever I’m working, I feel like I’m calling on every last bit of knowledge that I’ve got, and that once I’m on my own in the real world I’m going to end up drowning. This anxious feeling can get especially distracting when I imagine how much more progress and work there is to do in building myself into a competent software developer, let alone an exceptional one. Consequently, reading this textbook has been something of an exposure therapy exercise for me.

Developing some kind of practice regimen to reinforce my fundamental skills would go a long way toward constructing a sense of basic competence that I can eventually build on to enhance my skillset. Here I am about to graduate with a degree in computer science, and I honestly can’t say I know how to practice programming outside of school without starting a project and “just doing it”. This approach results in me feeling a lot of pressure to learn many new concepts and produce something useful before I get up from the chair again, and because my emotions quickly become too strong and distracting, I don’t end up doing either of those things. I need to develop a new way to practice my computer programming skills.

The phrasing of the problem presented in this pattern caught my attention because of how much I related to the sentiment: “It’s as if you’re always on stage.” I feel like every time I open my text editor to complete my daily tasks, or whenever I need to research a new subject, it’s the ultimate test of my ability and merit as a programmer. It’s going to be incredibly difficult to test my limits over the course of my career if my everyday experience feels so drastic. The solution offered through this pattern is the technique of practicing through “code katas”. The author explains that the term “kata” is borrowed from martial arts, and that it as a term which refers to a sequence of movements provided by a teacher to their students, performed without an opponent. The purpose of executing the kata is to reinforce the student’s fundamentals and build their physical control, fluidity, and power.

The benefits of applying the same practice of repeating fundamental movements to build overall competence towards the craft of software development are that it enables a practice environment without deadlines or expectations and that this method of practice allows learners to build their self-confidence without introducing the stress that comes with delivering complex software projects. About practicing with code katas, software developer Dave Thomas says “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.”

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.

Expose Your Ignorance – Embracing Vulnerability in Learning

So, before we dive into this week’s pattern, I realized I forgot to mention something in my last blog post. I previously wrote about “Confront Your Ignorance” but totally forgot to touch upon its counterpart, “Expose Your Ignorance.”

Summary of Expose Your Ignorance:

“Expose Your Ignorance” is all about embracing vulnerability and being open about what you don’t know. Instead of trying to hide our lack of knowledge, this pattern encourages us to shine a light on it, seeking help and guidance from others.

Key points of the pattern include:

  1. Be Honest About Your Limitations: It’s okay not to know everything. By admitting our ignorance, we create opportunities for learning and growth.
  2. Ask Questions Freely: Don’t be afraid to ask questions, even if they seem basic or obvious. Asking questions is a sign of curiosity and a willingness to learn.
  3. Seek Feedback: Actively seek feedback from peers and mentors. Constructive criticism is essential for improvement, and it’s important to be open to receiving it.
  4. Share Your Journey: Don’t keep your learning journey to yourself. Share your experiences, challenges, and successes with others. Not only does this help you connect with fellow learners, but it also creates a supportive community.

My Reaction:

So, here’s the thing: “Expose Your Ignorance” hits home for me in a big way. As someone who’s always been a bit shy about asking questions or admitting when I don’t know something, this pattern really challenged me to step out of my comfort zone.

One aspect of the pattern that I found particularly thought-provoking is the idea of asking questions freely. It’s easy to feel self-conscious about asking questions, especially when you’re surrounded by people who seem to know it all. However, this pattern reminded me that asking questions is not a sign of weakness but rather a sign of strength – it shows that you’re engaged and eager to learn.

On the flip side, I do have a bit of a disagreement with the pattern when it comes to seeking feedback. While I agree that feedback is important, I think it’s equally important to be discerning about whose feedback you seek. Not all feedback is created equal, and it’s important to seek out mentors and peers whose opinions you trust and respect.

In conclusion, “Expose Your Ignorance” has really shifted my perspective on learning and vulnerability. By embracing my ignorance and being open about what I don’t know, I’m creating opportunities for growth and connection in my journey as a software craftsman.

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.

Building Your Toolkit With Concrete Skills

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

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

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

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

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

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

Boundary Value Testing

Recently in class we have been learning about different testing methods, including boundary value testing. Boundary value testing allows us to test functions using the boundaries, otherwise known as the maximum and minimum values that are considered valid inputs. On top of that, we also use nominal values, or values that are in the middle of the the maximum and minimum values. We also use the values right above the minimum and right below the maximum in order to see how the function behaves around the edges of the valid inputs. We input one variable’s nominal value with the other variable’s five major values (minimum, just above minimum, nominal, just below maximum, maximum) and we see what the out put is. We then reverse the variables and repeat the process. That way, we know which variable fails and why. This is known as Single Fault Assumption using Normal Boundary Value Testing. On top of this, we also have Robust Boundary Value Testing which is the same thing, but includes the value just below the minimum and just above the maximum. Each of these types of Boundary Value Testing have two subtypes, weak and strong. Basically, weak contains less test cases and only tests each equivalence class once, while strong has more test cases and tests each equivalence class multiple times.

An article that I think does a great job explaining exactly what Boundary Value Testing is, how it works, and what it does, is called “Software Testing – Boundary Value Analysis.” I really enjoyed reading this article because it goes more in depth as to why we use this testing method, as well as giving examples as to how each are used. The article mentions how Boundary Value Testing is a type of black-box testing, which is a type of general testing method that I learned about a lot earlier in this semester. I think that it was really cool to be able to draw a line between two things I learned in order to see how they are connected, as well as how I will use them during the future, especially during my career in computer science. It also shows what the difference between valid and invalid inputs are, as well as how these inputs can be used during the testing process itself. In these examples, it lists a bunch of different test cases with each of the variables and what the output of the function will be. Personally, I think that this article is a great resource and I plan on using it as a refresher whenever I need to work on something involving this type of testing method.

Link: https://www.geeksforgeeks.org/software-testing-boundary-value-analysis/

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Week 6: CS-443

Black box vs. White box vs. Gray box Testing

Black box testing

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

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

White box testing

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

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

Gray box testing

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

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

Reflection

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

References:

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

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

Don’t Trade Programming for Promotions

Even though it may seem counterintuitive, it makes perfect sense. If you take yourself away from the code you will slowly lose your way with your craft. It’s important to continue learning and practicing even as a master craftsman. Higher positions in a company won’t always equate to “better” positions for a craftsman.

It’s a part of “walking the long road” and staying on the path is crucial to one day finishing that path. As it goes for anything in life, you can never truly fail at something until the day you give up and cease trying. If one were to take a position that pulls them away from programming it allows for their long journey to appear shortened, but in reality, they just took one of the many exits along the way onto the intended destination of becoming a journeyman then master craftsman. Along this road, journeyman status can be achieved and one may choose to stop there but personally, I’m striving to eventually arrive at master status in the future.

I also agreed with the pragmatic response offered in how to react if faced with promotions that pull away from programming. If working for a flexible company, ask for better pay or non-traditional technical management roles instead of accepting such a promotion. If working for an inflexible company, it’s better to seek other opportunities elsewhere than to let yourself become lost along the long road.

I also found myself agreeing with the notion that if the rewards offered by employers aren’t appealing, one should counter with some rewards that are better suited for their interests and professional growth. It could be helpful if one were to prepare alternative incentives and rewards before refusing a promotion (if possible) to allow for transparency and understanding of the professional goals of the individual.

I think that overall, to “stay in the trenches” is a great mindset to have. It’s equipped my mind with the knowledge that shines importance on staying within a position that allows me to continue to practice and grow as a craftsman. If I were presented with such an opportunity in the future, I’d remember that it’s more important to continue on my long journey than to let some small miscellaneous gains to pull me away from my end goal of eventually becoming a master craftsman.

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.

What is White, Black, and Grey Box Testing?

Software testing is broken into three main types: white, black and grey box testing. All three types have the same goal, however, they achieve these goals differently.

The blog “Black box vs white box vs grey box” from Shake does an excellent job in breaking down and explaining the unique roles of each testing type.

Black box testing:

The black box testing type focuses on the interface of the software. Software testers working with this type of testing approach the application from the user’s perspective. Because of this, no code of the program is required.

Usually, testers use the basic input/output technique to test the program, making sure that it is working as expected. The main goal of black box testing is to find usability issues and design flaws that affect the user experience.

White box testing:

While black box testing focuses on the user’s perspective, white box testing is all about testing how the program executes its function and therefore needs access to all the program’s code.

The main responsibilities of white box testing include identifying security vulnerabilities, evaluating broken paths, and testing outputs, loop errors, and data flow of the program.

This is achieve through the use of three main techniques:

  1. Statement coverage — it ensures that every statement in the code is run and tested at least once. This process also identifies all the “dead code” or unused statements and branches.
  2. Branch coverage — it is similar to statement coverage, but rather than individual statements, branch coverage ensures that all possible branches of the code are executed by detecting all the conditional and unconditional branches, then executing them.
  3. Path coverage — this technique uses multiple test cases to cover every possible execution path through the software.

The purpose of these technique and white block testing as a whole is to reduce the risks of bugs developing later on development.

Grey box testing:

As the name suggests, grey box testing includes a combination of both white and black box testing. Testers approach the program from the user’s perspective, but with access to some of the internal structure of the program.

The goals of grey box testing include, examining the risk level of all variables in the software, identifying re-occurring errors, and optimizing the number and quality of tests by balancing coverage and effort.

Coming into CS443, the terms “white”, “black” and “grey” box testing were all foreign to me. While I had recalled hearing the terms being said, I never fully understood nor retained the concepts.

This article was very insightful in teaching me the concepts of white, black, and grey box testing. I think realistically, most software testing would be done in the grey box. This is because the advantage of grey box testing is taking the advantages of white box and black box testing. For a final thought, I hope to have the chance to do some white box testing to see what that would look like in a developer setting.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Embracing Humility: “Sweep the Floor” Week-4

Starting from the Ground Up:

“Sweep the Floor,” a pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, underscores the importance of being willing to start with basic, often menial tasks in the early stages of a software development career. This pattern teaches the value of humility and the significance of understanding the foundations of a project or an organization from the ground up. It’s a reminder that every task, no matter how small, contributes to the larger picture and provides valuable learning opportunities.

A Resonant Lesson:

This pattern resonates with me, not from direct professional experience, but from understanding the universal value of humility and starting from the basics in any field. “Sweep the Floor” reflects an essential truth – that true mastery and understanding often begin with the simplest of tasks. It aligns with my belief that to build something significant, one must first understand and respect every small component that contributes to the whole.

The Value of Small Beginnings:

What I find particularly meaningful about this pattern is its focus on the learning opportunities that lie in seemingly insignificant tasks. These initial responsibilities can offer insights into the intricacies of systems, processes, and team dynamics. They provide a unique vantage point to observe and understand the workings of a project or a team.

Influencing Future Work Ethics:

While I am yet to start my professional journey, “Sweep the Floor” influences how I envision my approach to future work. It instills a sense of respect for every aspect of a project, no matter how minor it may seem. This pattern reinforces the idea that a willingness to start with humble tasks and a readiness to learn from them is crucial for long-term growth and success.

Balancing Humility and Aspiration:

I agree with the core message of this pattern but also believe in the importance of aspiring to more complex and challenging roles. Embracing humble beginnings should not deter one from seeking growth and taking on more significant responsibilities when ready. The key is to find a balance between learning from basic tasks and progressively seeking opportunities that challenge and expand one’s skills.

In conclusion, “Sweep the Floor” offers a profound lesson for anyone embarking on a new path, particularly in a field as complex and multifaceted as software development. It’s about embracing the small, seemingly mundane tasks with the understanding that they lay the groundwork for future expertise and achievements. This pattern is a testament to the fact that every great journey begins with simple, humble steps.

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.