Test driven development is an important method of developing which is based on first writing a test for what you want your program to do, this test will fail as you do not have any code written in orde for the test to pass but you then write the code which is necessary for the test to pass and then you continue repeating this process of writing a test then writing the code for said test to pass. You are encouraged to write the simplest possible code in order to make your test pass before moving on to the next test but you may need to do some refactoring between tests in order to ensure you do not have unused code, confusing methods or variables, etc. Test driven development is very helpful when it comes to testing the specifications of a system as you can write simple unit tests which would pass if a specification was met and when it fails you know that you still must add or change your code in order to make sure the specification was met for the end product. Other types of testing are also important to perform but test driven development can help you steer away from over complicated code and make sure that you do not have recurring duplication present when you regularly refactor between cycles.

I found this article to be particularly helpful when researching test driven development as it clearly breaks down the steps of test driven development in order for the reader to fully understand the process you must go through in order to follow this development method. Along with the thoroughly explained process this article also compares and shows how both acceptance test driven development and developer test driven development work together. As we just started working with test driven development in class I found this article to provide valuable insight into the definition and process of this testing/development model as it is something rather different compared to what we have worked on previously regarding testing as we usually have worked with code that needed tests written and not with tests that needed code to be written. Being new to TDD made it seem very confusing at first as it did not feel right to be writing the tests for code which did not even exist yet but the benefits of TDD are much easier to understand once you put this method into practice.

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 ‘sweeping the floor’ pattern in chapter four pertains directly to the beginnings of an apprenticeship or just work in software in general. This pattern explains that when you first begin the process of working in software while you will not be nearly as knowledgeable or efficient as the other members of your team with more experience you will still be able to contribute in smaller or more simple ways in order to still provide assistance and work with your team as you learn how to do more technical tasks. This strategy can be applied in every field as when you start your career or even when you start a part time job in high school you first have to be taught how to do certain tasks in the correct way but while you learn how to do the more complicated tasks correctly you will still be able to put effort into making tasks easier for others who are already able to do the more complicated tasks that come with your job.

This pattern stood out to me as I believe that this is especially important to remember when you are entering any job or looking to start your career after college as the thought of ‘not knowing’ how to do the more technical tasks can be daunting for people at times as they see it as a massive obstacle you must overcome when in reality you are not expected to be able to do every task that more experienced team members are able to do. You are expected to contribute in any way you can to help your team work and provide insight while also remembering to continuously learn along the way in order to enable yourself to do these tasks in the future so that one day you are the ‘more experienced team member’ that someone looks to for guidance. Advice like this is important for college graduates that are just starting their careers as in most cases our first jobs will be learning experiences that we need to embrace and make the best of in order to further our understanding of both the field and our colleagues. 

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.javatpoint.com/difference-between-object-oriented-testing-and-conventional-testing#:~:text=In%20object%2Doriented%20testing%2C%20the,encounter%20in%20the%20real%20world.

Object Oriented testing focuses on the behavior of an object or class within an  object oriented system with its goal being to ensure any interaction or expected behaviors are correctly carried out when the system is used. This type of testing also heavily relies on ‘real world’ situations for example when writing test cases you would base your cases on things that the system is likely to interact with in the real world input wise which makes it easier to identify any possible behavioral issues within the system. There are three different testing phases which are commonly used in object oriented programming which are Unit testing, integration testing and system testing. Unit testing is used when testing classes or objects while isolated from the rest of the software, integration testing is used to verify that objects or classes are able to properly work together and system testing is used when testing an entire system to verify that the system itself works properly. Object oriented testing also requires the tester to have knowledge of a system’s inner workings in order to properly test it. This type of testing obviously is used on object oriented software which would be any software that is written using an object oriented language so in that aspect it is limited as object oriented testing would not be relevant or necessary to software which is not in the object oriented domain.

I found this article useful as it gets straight to the point when it comes to outlining the basic idea behind object oriented testing but it also chooses to compare it to conventional testing which helps the reader to differentiate between some of the different attributes of the two testing types as well as some of their similarities. This really helps when it comes to understanding why object oriented testing is defined as its own type of testing when their are already many other testing methods. This article helped me gain a greater understanding of object oriented testing which will help me to think more in depth about the cases I am able to write while testing in the future. The specific use of real world scenarios mentioned in this article was particularly interesting to me as I had not previously thought about how using real scenarios would typically provide more accurate results and or errors as compared to randomly selected scenarios which will also influence how I write test cases 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 ‘Find Your Mentors’ pattern is about the idea of “apprenticing” yourself to someone who is more experienced than you are within your field of expertise. While this pattern should be considered for many different professions it should especially be considered for software development as having a mentor can be very helpful especially when you are trying to find your place in the huge world of software. One of the main ideas attached to this pattern is that you will have the realization that you are not the first person to start out being a software developer with little experience professionally as everyone that is currently in the field had to start at the same spot you are currently at and their knowledge can be beneficial to you in order to shape your own career and practices. The solution provided for this pattern is finding a master craftsmen in order to be supervised by them and have the proposed master shape your understanding of the field and your career, but it is also said that with computer science being a relatively ‘young’ field it is hard to find a true master as their are not many people that have ‘mastered’ all of computer science but that there are many people who may have mastered parts of computer science and you should seek out different people in order to increase your understanding of what each mentor you obtain has mastered in their time in the field.

I feel as though this pattern is very important because computer science is younger than many other fields and mentors can be hard to come by in fields which have many ‘masters’ nevermind fields which have very few like computer science. Explaining that it is ok and completely acceptable for a software developer to have many mentors throughout their professional journey in the different disciplines of computer science helps students such as myself realize that you can continue to explore further and further into the field without having to necessarily pick a specific discipline and settle to work on only that discipline for our entire careers but instead that we should feel encouraged to gain more knowledge as knowledge on other disciplines can help us to gain understanding within whichever discipline we are currently working within.

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