https://www.practitest.com/resource-center/article/black-box-vs-white-box-testing/#:~:text=The%20Black%20Box%20Test%20is,is%20carried%20out%20by%20tester.

Black box testing is a genre of testing which does not take a codes functionality into consideration, in other words the internal workings of the code are not known to the test and the tests are formed strictly by external workings. This is very different from white box testing as white box testing operates under the idea that the ‘tester’ has extensive knowledge of how a system was created along with its inner workings. Some of the differences between black and white box testing are black box testing is carried out by ‘tester’ while white box testing is left to software developers, black box testing is considered behavior testing while white box testing is considered logic testing and black box testing is typically used in system testing while white box testing is used in unit testing. There are also ways in which these two types of testing are similar which is mainly their purpose which is to ensure that a system is working correctly and that you have the best version of the software available.

I chose this article because I liked how it not only explained black box testing but it also compares black box testing to white box testing in order to allow a deeper understanding of the relationship between the two types of testing. I am very interested in seeing how different methods of black box testing work as for the most part we have been practicing with white box testing methods in class so far this semester so the concept of testing without extensive knowledge of a system or without access to the systems internal workings and code seems both interesting and challenging to me. 

With there being a large gap in knowledge of a system between the two different types of testing it seems as though black box testing is something that is done by others not necessarily full blown software developers as developers are expected to spend their time on white box testing so It makes me wonder how exactly these tests are written and how specific results may be measured for success compared to the more straightforward nature of white box testing. Since black box testing can be used for just about every type of testing, even some of the sames types of testing white box is used for it would be nice to see and compare how tests are carried out for both types of testing on a similar component of a system in order to differentiate the information used by each type.

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 ‘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.

https://www.geeksforgeeks.org/specification-based-testing

  Specification based testing is a type of software testing that directly uses a systems specification in order to design tests. WHile considered a type of black box testing specification based testing can be used on any type of system but works particularly well when testing web applications. When practicing specification based testing you would first look at the code and its documentation in order to see what must be tested based on its functionality and uses. The objectives of specification based testing are functional accuracy, conduct based compliance, error detection, reliability/robustness, full coverage and compliance with the standards.

  There are 7 types of specification based testing listed which are “state transition” which is used to uncover errors in a system when switching states, “decision table” testing which can test functional and non functional system requirements, “equivalence partitioning” which is similar to decision table testing except it is best used when testing different inputs while decision table testing is best used on different combinations of inputs. Then there is “boundary value analysis” which consists of creating a test case for each boundary value, “all pair testing” which makes a test case for every possible input, “classification tree” is based on deriving test cases from a decision tree and “use case” testing which focuses on the functionality of the entire system rather than any individual component.

  I selected this topic/source as we have been practicing specification based testing in class recently and I was interested in researching more into the topic and the different types of testing that are classified as specification based and this article from “geeksforgeeks” went in depth not only into what the definition of specification based testing is but also the different types and the objectives of this type of testing. 

  This article was very helpful in my opinion as is gave me a perspective on specification based testing as a whole and after practicing some of the different types of specification based testing in class and reading this article I have a greater understanding or not only what this type of testing is but also how to go about testing in this fashion and writing test cases which pertain to the specifications of a system. I would consider this type of testing to be one which is more self explanatory than others but being able to understand its importance and its limitations is something that will help me when testing in the future.

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 ‘Unleash your enthusiasm’ apprenticeship pattern is one which I would consider very important. The basis of this pattern is that you should not feel the need to suppress your own excitement over crafting software when you are part of a team but you should be mindful of the team’s dynamic and attitude before blindly acting on your own enthusiasm. Essentially it is completely normal for a newcomer in software development to be excited to learn or even to be working within a professional team but the newcomer should always keep in mind that their enthusiasm may be warranted but depending on your colleagues you may want to keep your enthusiasm to yourself in order to not make any negative impression which is important in many different fields not only software development. But even if you judge that your enthusiasm should be kept to yourself based on a team or individual’s dynamic you can still ask questions in order to better yourself.

  I found this pattern particularly useful as I myself along with some fellow computer science majors I know are hesitant to show excitement over software development at times as I do not know if it would be considered as unprofessional. This pattern explained to me that while you do not want to overly express your excitement throughout the learning process it can be helpful to question things and give your ideas even as a beginner when working in a team as the perspective you offer the team is fresh and can lead to helpful solutions or enhance your own learning process and the more you know about what you are developing with your team the more useful you will be when trying to work together on productive and time effective solutions. Being aware that it is for the most part encouraged to share your thoughts, question or ideas when you can at the very least so that you can get an explanation on why an idea would or would not work is something that will help me to be more open to sharing my thoughts with others whether it be colleagues, other students professors etc.

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 ‘Your First Language’ pattern from chapter two consists of the idea that you are just starting out and only have a basic understanding of one or maybe even two languages. The problem which is presented is that you as an apprentice believe that your job depends on being able to produce the same quality of work in a specific language that the others around you can even if they may have more experience using said language or that getting any job will depend on your knowledge of one particular language. Then the solution presented it to decide on a ‘first language’ which you will dedicate to familiarize yourself with and when trying to solve a problem you will use this language and further your understanding of its inner workings. Then if an employer requires you to use a specific language you approach it by taking small steps at first and then exponentially grow your steps as you gain more knowledge in order to efficiently learn another language. This pattern encourages you to seek help from experienced friends in order to quickly progress through a problem as long as you do not grow a reliance on them for all the answers. 

  I have a great appreciation for this pattern as I feel it is something that many students and or apprentices may struggle with. Initial thoughts on a first language can be intimidating and heavily influenced by the schooling you go through if any or even others opinions online if you do not pursue technical training initially. You put a lot of consideration into a choice like this and it is important but this pattern highlights the thought that many people may have that they must fully master a language in order to be ‘employable’ in that said language when realistically even people that are considered to be ‘masters’ of a specific language are still learning. What really matters is that you take the steps in your first language and learn from the experience so that you can adjust the steps to learn other languages in the future as your first language is basically your jumpstart in the world of programming languages.

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://unstop.com/blog/structural-testing

  Structural testing is one of many types of software testing, although structural testing is directly testing the internal structure of the code which means it is important that the individual performing structural tests is very familiar with the language used for the code. This type of testing uses white box testing techniques and it is more concerned with how a system is running rather than its functionality which is the more common reason for testing. There are four different types of structural testing which are mutation, data flow, control flow and slice-based testing. Mutation testing is a type of structural testing which relies on changing small parts of the code’s structure in order to test for errors, there are different types of mutation testing which are based on changing different parts of the code’s structure in order to find possible errors. Data flow testing is used to analyze how data flows through a program and control flow is used to show the order in which statements will be executed. Slice-based testing takes a portion of statements which may affect the final value of a variable and uses those slices to test the change. There are three different techniques used while doing structural testing which are called statement, branch and path coverage. Some common open source tools for structural testing include Cucumber, JBehave, Cfix and JUnit.

  I found this article interesting as it not only gives an in-depth explanation on structural testing but it also provides you with both techniques and tools which can be used to perform such testing. The advantages and disadvantages section particularly piqued my interest as one of the first advantages listed is that early defects can be easily identified which I would infer is due to the direct testing of the code structure versus testing its sole functionality. The cost of this type of testing however is a huge disadvantage as the time and money it takes to go through all of the testing necessary is much more than other types of testing. This article did teach me a lot about structural testing as most of the testing I have personally done has been testing what inputs get a certain output and testing direct implementation of a body of code versus actually testing the structure and being able to see how a piece of data flows through code which is a very important aspect of testing even if this testing is very expensive.

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 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.

https://www.altexsoft.com/blog/front-end-development-technologies-concepts/

The frontend of an api or web system is the visual representation/interface that is seen and used by visitors, customers, etc. You interact with the frontend through your browser so frontend development is very important for any online website or service. When creating the frontend of a system the developers use HTML, CSS and Javascript which are the same tools used to make web apps. Frontends are very different from backends as the user does not see the backend or really necessarily interact with it. The backend is what happens on/in what it is developed for. Backends govern the functions and any operation that takes place within the system.

Backends are developed using different languages based on the developer or customers preferences. The backend also consists of the web server and storage of the system which it supports. But even though the backend contains what makes the site/app function, the front end is still just as important as it is what is presented directly to the users. Through mainly html front ends bring the actual user experience into play and help to dictate the functionality of a website even though the frontend is not directly involved in the execution of the functions.

I chose this article as it was very helpful when it comes to understanding what exactly a front end is and why it is important when developing something such as an app or website as it truly is the entire user experience. The user experience overall can make or break an app or any other type of programming which requires a front end and therefore the front end development process is very important.

I feel as though an article like this would be helpful not only to myself but to my peers as it thoroughly explains what a front end is as well as what a backend is. This helps fully differentiate the two so that there is no confusion in the development stages of either. Both frontends and backends are similar but also drastically different in how they are developed and the purpose they serve. This article helps to differentiate the two and helps the reader gain an understanding of what is included in each in order to develop an effective system that thrives for both the developers of the system and the users of the system. I would recommend this article to anyone questioning the difference between frontend and backend as well as anyone wondering how to develop an effective api in general.

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.