Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in.

—Pete McBreen, Software Craftsmanship

This chapter presents the scenario where you are trying to join a talented team of developers that will provide you a great opportunity for growth and development as a developer. The problem is that the team has no obvious net benefit to hiring you and there most likely will be a net loss for a while as the team attempts to get you up to speed on your skills and ability to mesh. There is also a chance that you are not able to indirectly contribute to the group with things such as automating simple manual tasks.

The solution presented in this scenario is that we should acquire and maintain concrete skills. Having a solid grasp and fluency in a specific language, framework, etc. will help demonstrate to the hiring team that you have value to bring to the team. If you are unable to contribute directly in the beginning, you can contribute indirectly while you transition into your role with the team utilizing your concrete skill/s.  Having concrete skills will reassure future coworkers that they will not need to hold your hand and walk you through all your work every step of the way.

The action plan set forth in the reading, is that we should look at the CVs of people whose skills we respect and identify which skills listed on their resume would be useful for us to have on ours. Although I am familiar in knowledge of bash script, javascript/vue, C++, and SQL. I would benefit from solidifying this knowledge into skills that can be easily demonstrable in an interview without requiring any google searches. To further solidify my grasp on these concepts into concrete skills I feel confident about, I can practice leetcode problems, and create websites for small businesses that do not currently have one.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Automated testing is a great option for repetitive tests such as regression and functional testing but not useable for testing methods such as discovery and usability testing that requires a human to do the work. If used correctly, automated testing can save a lot of time and therefore money. If used incorrectly, it could end up costing more than manual testing.

Certain requirements that the testing process to be automated must meet are that it is repeatable, determinant, and non-opinionated. The first requirement, repeatable, means that it must be ran more than once, or else there would be no reason to automate it. Repeatable tests have three steps: set up the tests with data and environment, execute the function and measure the result, and clean up the data and environment after testing. The second requirement, determinant, means that the outcome will be the same every time the function runs with the same input. For example, when inputted 1 and 2 to an addition function, the outcome 3 must be produced every time it is ran with those inputs. The third requirement, non-opinionated means that there must be a concrete answer. You cannot automate opinionated feedback.

Now that we talked about the requirements of automated testing, now we will discuss the three steps of automated testing: prepare, take action, and report results. In the first step, prepare, you set up the data and test environment where the tests occur. This will require either manipulation of the data or putting the program in a certain state, or both. The second step, take action, the driver will run the tests. This will happen by calling the code directly, or accessing a programs api or user interface. And lastly, report results. The automated system will record and report the results from the test.

When used properly, test automation can save money and time and provide quality test results.

Source:

Testim. (2020, February 03). What is test automation? A simple, clear introduction. Retrieved May 03, 2021, from https://www.testim.io/blog/what-is-test-automation/

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

After taking a quick look at JaCoCo in class I wanted to learn a bit more about it. This article is an introduction to using JaCoCo and gives some good examples.

The article explains that when you write tests there are some criteria to consider:

“

• We want to make sure that the parts of the code that are best tested are the parts that are most likely to contain bugs.
• We want to focus our tests on parts of the application that are critical, the parts where bugs are most likely to lead to a bad outcome for our customers.
• We don’t want to write tests that repeatedly cover the same areas of the code while ignoring other parts of the code.

“

You can find which parts of the code are the most likely to have bugs by finding the most complex parts. A common way to do this is using cyclomatic complexity (check the article for the algorithm).

JaCoCo measures code coverage, can report on the complexity of each method, and can tell you how much complexity is untested. In the article a lot of the things we covered in class are repeated, but it helps to see it again to reinforce the concepts and also to reference for the future. While we spoke about it in class, a lot of the things that are said are not recorded anywhere.

The article also brings up the use of JaCoCo to measure complexity. After getting as much code coverage as possible you can refactor your code if the complexity score is too high. In the example they reduce a method’s complexity from 21 points to 9 points. That just goes to show how useful JaCoCo is. After reducing complexity and improving code coverage you can be confident your code is ready for a code review.  

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Software testing falls largely into two categories: static and dynamic. Both are valuable, but the scenario around the test being performed determines which method best fits.

Static testing is a testing technique that does not require the code to execute. This can include manual or automated reviews of the code, requirement documents, and document design, all of which are intended to catch errors in the code. Static testing is done in order to prevent errors during the early stages of development and can help locate errors undetected through dynamic testing methods. Reviews are an important facet of static testing and are the primary method for carrying out a static test. A review is a meeting or other process aimed at locating flaws and defects in the design of a program. Apart from physical walkthroughs of the code, there exist tools that automatically search for errors. These tools, such as CheckStyle and SourceMeter, can help developers adhere to standards in code and style.

Dynamic testing is a testing technique that checks the program’s behavior when code is executed. As the name suggests, it is intended to test the dynamic behavior of a software. This encompasses a vast majority of the testing methods we’ve discussed both in this class and on this blog. The two types of dynamic testing are white and black box testing, which are both techniques that I have discussed on this blog before. Dynamic testing ensures that a software is working properly during and after its installation, it makes sure that the software is stable, and it encourages consistency in the software’s functionality.

Sources:
https://www.guru99.com/testing-review.html
https://www.guru99.com/dynamic-testing.html

From the blog CS@Worcester – Ciampa's Computer Science Blog by graceciampa and used with permission of the author. All other rights reserved by the author.