Expose Your Ignorance

In the world of software development, everyone is under a great amount of pressure to meet deadlines and deliver software. Because the entire team is under the pressure of meeting deadlines, the managers look for confidence when asking how long a feature will take to finish. Due to the new developer’s inexperience, they are unsure how to answer because they are not familiar enough with the technologies to be able to quantify how long the process will take. This pattern is called “Expose Your Ignorance.” In this pattern, it discusses the situation of a new developer who is unfamiliar with some of the required technologies their team uses, and is afraid to look incompetent.

Software developers tend to build their reputations through strong relationships with their clients and colleagues. Building strong relationships require honesty, and not just telling the client what they want to hear. Rather than pretending to know something, it is better to reassure the client by emphasizing the ability to learn new technologies and being able to apply them. Reassuring in this manner allows relationships to be built based on the ability to learn and adapt rather than based on what is already known.

The most obvious way to expose ignorance is to ask questions. The hardest part about asking questions is the fear of appearing incompetent. However asking questions and being direct is the easiest and most straightforward path down the software craftsman’s journey. Becoming comfortable with this process of learning, by asking questions to mentors, helps to prevent us from being locked into one domain of software development. An action that can be done to help with this process is to keep a list of what is unknown. Keep this list in a place that is public to the rest of the team to hold accountability and/or to help with understanding. Being in the habit of updating this list is also important to ensure continuous learning. Ultimately, possessing the ability to learn is one of the most important traits of a craftsman.

I found this pattern to be helpful because it provides a way with confronting feelings that may be uncomfortable when becoming a craftsman. I found the solution of making a list of what is unknown, and keeping that list public was interesting and changed the way I view the pattern because that is something I would not do. I would rather keep this to myself and work on it separately, but keeping this list public allows the team to hold accountability. This is because if the list has not been updated for a while, then that means the learning process has halted. I do not disagree with anything in this pattern.

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.

Levels of Testing

Levels of testing refers to the different stages of testing software during the development cycle. Each level of testing aims to test specific aspects of the functionality of the software. The most common types of testing levels are unit, integration, system, and acceptance testing. Unit tests focuses on individual components, or units, of the system such as functions. Integration testing is used to ensure that these units work together as intended. System tests verify that the entire system meets the requirements specified by the customer. Acceptance testing is similar to system testing in that the whole system is verified. However while system testing tests the entire system, acceptance testing tests the final system.

Unit Testing

Unit testing is conducted at the code level, where each individual component is tested and the results are analyzed. Rather than manually testing each component, automating unit tests is highly recommended to reduce errors in analyzing and for increased efficiency. When making a unit test, an outline stating the expected results of the code should be made.

An example of an outline for a unit test for a calculator app that simply adds to numbers together would look like:

• Program should accept two numbers
• Program should return the sum of the two given numbers
• Program should handle negative values appropriately

Once the outline for the unit tests are made, then the actual code for the unit test should be written. The test will then check the code to verify it is doing what is expected once the test has run.

Integration Testing

Integration testing tests groups of individual components that are integrated into a system. This type of testing helps to identify any issue that may occur from coding errors or errors from the integration between units.

System Testing

System testing is performed on the application as a whole. All components are assessed against specific requirements made by the customer.

Acceptance Testing

Acceptance testing involves testing the final system. This includes the system’s functional and non-functional aspects such as performance, security, usability, and more. In this testing level, end users are given access to the software to ensure the end users’ needs are being met.

Conclusion

This resource was chosen because it clearly described the different testing levels, their purpose, and why each level is important. I enjoyed reading this article because it was written in a way that made understanding easy. In the future, when creating a complex system, I will be sure to follow the different stages of testing at the appropriate time in the development cycle to prevent issues later in development.

Resources:

https://testsigma.com/blog/levels-of-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.

Test Driven Development (TDD)

Test driven development is a form of testing done in software development that focuses on creating unit tests before the actual code. Developers create small test cases for every feature with the intention of modifying the code only when the tests fail. Test driven development is also a practice that focuses on the structure of the code that allows for the creation of optimized code that remains reliable over time.

TDD vs Traditional Testing

As stated above, one of the main differences between TDD and traditional testing is that tests are created before the actual code unlike traditional. However some other differences include the testing scope and the processes that each form of testing follows. The testing scope in TDD focuses on testing small, individual pieces of the codebase whereas traditional testing tests the entire system including integration testing. The process of each type of testing also differs in that TDD is an iterative process. As tests are created, this process also includes cycles of developing small chunks of code, testing that code, then refining until all tests pass. An important part of the TDD process is refactoring. Once tests pass, it’s important to check the code if there are any optimizations that can be made, or if there is any redundancy that should be removed.

Benefits to TDD

Test driven development allows for the creation of optimized code by nature because of the process that TDD follows. Once code is written, if the tests fails then the developer is forced to go back and fix the code until the tests pass. The test coverage that TDD covers is greater than traditional testing methods. This is because before any code is written for a specific functionality, the test is created beforehand which ensures every function passes testing. Using test driven development also helps in reducing the number of larger, more complex issues that arise. This is because testing is done on a consistent basis, where development does not progress until each set of tests are complete.

Conclusion

I chose this article because it clearly explained what test driven development is, differences between traditional and test driven development, and the benefits. I also appreciated the use of examples the article used to further explain what the TDD approach would look like in real scenarios. Learning about different approaches to developing software is helpful because I am exposed to approaches that could be more useful than what I already know. I plan to try test driven development in the future.

Resources:

https://www.browserstack.com/guide/what-is-test-driven-development

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.

Static vs Dynamic Testing

Testing software and ensuring it works as intended is a crucial part of software development. Two approaches to testing are static and dynamic. Static testing involves testing the software without running the code, while dynamic executes the program and tests its behavior in various situations.

Static Testing

The term static testing comes from examining the code in a “static” state rather than actually running it. Because the code is never actually executed with static testing, the focus of testing is on analyzing the software’s documentation along with the design of the code, and the code itself. Static testing is most beneficial in the early stages of development. Since the code is never being executed, a fully working implementation is not required unlike dynamic testing. Issues identified early in development are easier and less costly to fix resulting in better maintainability, and decreased time and money spent in the long term. Some static testing techniques include informal reviews, walkthroughs, static code reviews, and more.

Dynamic Testing

Dynamic testing involves actually executing the software and testing its behavior based on various inputs. Test cases are created to conduct test runs to identify defects and ensure the software meets the required specifications. Along with testing the software with various inputs and comparing to the expected outputs, error conditions are also tested. Error conditions are inputs that are outside of the valid input range, and the software should be able to handle the invalid input without any unexpected behavior. Dynamic testing is performed after coding and development are complete, whereas static testing usually begins in the early stages of development. Because dynamic testing executes the code, the software must be far enough in development where the software functions, performs, and secure as intended. Those reasons are why dynamic testing is to be completed after development. Some dynamic testing techniques include unit testing, integration testing, and system testing.

Conclusion

This article was chosen because it clearly explained what static and dynamic testing are and the differences between them. The article was also easy to follow along. I enjoyed learning about when static and dynamic testing are most beneficial because I was unaware that static testing begins in the earlier stages of development while dynamic is performed after development. So far in my software development journey, I have not written many tests for the code I have written, and have mainly done manual testing which takes extra time and may have errors. Gaining insight in these techniques will be helpful when testing code in the future.

Resource:

https://www.guru99.com/static-dynamic-testing.html

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.

Concrete Skills

For this post, I read about the Concrete Skills pattern. This pattern is about when seeking a new role on a development team, the team may not want to risk the possibility that one may you be able to contribute to the team. They may think this because you may not have much concrete work to show your skillset and prove to teams you are able to contribute. The solution to this problem according to the text, is to acquire and maintain concrete skills. In order to do this, the text suggests collecting CVs of people whose skills you respect. Collecting CVs helps give an idea to what skills are useful and looked for when joining these teams. After learning these skills, then build a project using them to demonstrate that you can apply those newly learned skills.

I found this pattern to be useful because I am currently in the process of applying to jobs, so this pattern is very prevalent to me. Collecting CVs of those already in the industry, or those with more experience is something I had not thought of. However I believe it is a good way to find skills that you may be missing. Collecting a list of skills is also useful in the sense that common buzzwords used among CVs can be noted to help get past HR filters and managers who construct teams based off of those buzzwords.

I found the statement that describes hiring managers requiring to take a leap of faith on choosing who they hire, and having concrete work allows you to meet them halfway to be interesting. I found this to be interesting because it changes my perspective on the hiring process.

This pattern has changed the way I go about looking for new skills to learn. When learning new skills, I sometimes plateau and get overwhelmed with what I should be looking into. Now after reading this pattern, going into the future I will start collecting CVs because having a list of skills will be useful to direct my focus in the skills I should be learning.

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.

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.