Manual and automated testing are the two ways to run tests. One involves human touch while the other needs very little from a third party to work. While one would think automated testing is better in almost every case. That’s not necessarily true. To start, in most cases automated tests are just better. They are more efficient and save people a lot of time. They can be run over and over again. And can be run every time code is pushed, instead of having to be manually runned. Oftentimes the only times manual testing is useful is when things are tested for use by humans. Meaning things like testing how an app feels to use or how the functions in practice. These areas require testing things that are hard for a computer or code to test.

Manual testing can be more cost effective depending on the circumstances. But manual testing is also subject to more error due to the nature of human involvement. Tests are more adaptable because they can be changed more easily. While automated tests being changed might take more time to change to make sure they work with the code. Automated testing offers more coverage since they can be made small and can cover various areas of coding. Automated tests can also handle larger test cases that span over a large area. While manual testing struggles to handle something so large. Overall I’d say that automated tests seem better to use in general. Aside from things like testing for human feel, automated tests seem to handle most things better.

https://www.testrail.com/blog/manual-vs-automated-testing/

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Security testing is a major area of testing that is very important. In today’s world, security is imperative to a softwares effectiveness. Without security software will be targeted and used against people. The cost of data breaches result in humongous money loss. Some of the goals in security testing is to find weakness in code, finding the impact of security breaches, report findings, and eliminating risks. Some of the principles of security testing is having realistic tests that test real world applications. Tests that are through and wide spanning. Continuous testing because the nature of security and attacks is always changing. Testing should be a collaboration of all parties involved in the software development process.

We always hear on the news about data breaches for some company that cost billions of dollars. It’s hard to put into perspective how much money that is and how that actually affects people. The security of software has real world consequences on people. It’s not something to take lightly. We have to protect software in order to protect the people using it. It’s just as important as testing to make sure the software works. In the blog it said that negligence in security breaches leads to a higher fine. Which makes sense since if you willingly ignore security breaches you’re putting peoples livelihoods at stake, not just at the company. There are many different areas to security testing. API testing, HTTPS, Cloud, basically any area that requires communication is subject to hackers. 

https://fluidattacks.com/blog/security-testing-fundamentals/

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

TDD or test driven development is a method of building software by creating tests first and then writing the implementation of the code. This blog breaks down what TDD is and the steps to the process. TDD aims to help developers build a program that meets the requirements. By building to meet certain criteria, programmers will always keep the goal in mind. Building with certain behaviors or outputs in mind. The first step is to write a test list. Essentially you are writing tests with the end behavior in mind. It is writing tests, but this stage is also an analysis. An analysis of what the programmer or team or whoever thinks the final program behavior looks like. The next step is to write a test, one that is robust and fully implemented. With one test implemented, the program implementation is now taking shape. Because the program must be made in a way so that it will work for the test. Now that you have a test, the next goal is to make that test pass, by any means necessary. After that you can refactor depending if the tests or implementation needs to be changed to make the program better. Then it becomes a matter of repeating the process until the test list is through.

I think TDD is a very interesting approach to programming. Usually we think of the typical process of build first and then testing. But TDD reverses that, and it creates a very dynamic when it comes to building software. I never really thought about it before but the way you build a test does affect the way the program is implemented. Like if your test is expecting a string or integers, you have to build the implementation in a way that returns those types. There are many ways to make a test that does the same thing. But those tests go about it in a different way. Thus that changes the way you program the implementation. I also think TDD adds focus and direction to programming. As you always know what you need to return or what the expected output looks like.

https://tidyfirst.substack.com/p/canon-tdd

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Black box testing is one of many testing paradigms in the world of testing. I think black box testing stuck out to me because it has the coolest sounding name. This blog is an overview of what black box testing is, when and where to use it, and the pros and cons. The main idea around black box testing is to test a program without knowing the inner workings of the program. Essentially you give the inputs to the program and receive the outputs. But you don’t know what’s going on in the in-between. Black box testing can also be split into even smaller forms that each serve a different purpose. For example, there is functional testing that aims to assess the program’s ability to return outputs that match the specifications. Another example would be system testing, which aims to test the program as part of a larger system. Testing to make sure that the entirety of the program works. Some of the pros of black box testing is that it simplifies testing because it focuses on user requirements. Cutting out on other factors to make sure that the user experience is good. Cons include limited test cases because of limited knowledge of the program. Tests are often simple due to the nature of the lack of information.

I think black box testing is an important part of testing because it’s testing based on the perspective of the users. Most users of an application don’t know the inner workings of said application. So making sure that everything is working on the user side ensures that the user experience is quality. After all, if the people using the application hate it, then they want to use it. And they probably dont want you to work for them again.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

In another podcast from Stack Overflow again by Ben Popper with special guest Johnathan Schneider, discusses the nature of technical debt surrounding open-source projects. The main example used throughout the podcast is refactoring code, switching from java 7 to java 8. And in later examples sometimes java 8 to like java 17. As they explain the difficulty when switching, especially when more manual work is needed, talk about the ways technical debt is created. After more discussion around the software he made to help refactoring, goes into more detail about the nature of technical debt. We think of technical debt as something that we impose on ourselves. Like taking shortcuts or code that needs to be updated. One of the main points of this podcast is to think about technical debt more as maintenance. Obviously sometimes it is self-inflicted, but often it just comes with the territory. As new things come out, things will need to be updated. It’s easier to think of it as something that needs to be done for the sake of the health of the program. Rather than as something I did that I need to fix because of my own short sightedness. 

I chose this podcast because it is related to our discussions of technical debt and refactoring code. In class, we talked about the nature of technical debt and how often it is a code structure thing or maybe a breaking change. It is more thought of as something that comes as a result of not thinking ahead. While I think that is true in many cases. I think a lot of the time it can’t be avoided, like in the case of code versions. Thus it’s better to think of it as maintenance rather than something that could have been avoided. For me, mentally saying that this problem is something that couldn’t have been avoided is better. If I think it’s my fault then I feel like an idiot and get down on myself. Maybe it is just a mental thing, but it goes a long way for the mentality of a person or team. Another aspect of the podcast I think it is important to think about is how the open-source nature plays a part in this. Code is being worked on at all times, different people. So when the code is updated and your code no longer works. It’s important to realize that this isn’t your fault and just is the nature of things. The code not working is not your fault and just needs to be maintained so it works again.

Citations

https://the-stack-overflow-podcast.simplecast.com/episodes/open-source-ecosystem-reduce-tech-debt/transcript

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.