CS-443: Week 13

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

Week 13: CS-343

Anti-Patterns

Anti-Patterns are “imperfect” fixes that may seem like they solve a problem, but over time, can lead to more problems where using anti-patterns are more inconvenient than not. Because anti-patterns cause problems over time, teams are forced to go back and fix them which lead to higher costs and delayed release schedule.

Types of Anti-Patterns

Spaghetti Code

Spaghetti code refers to the logical structure of the code resembling a plate of spaghetti, meaning it is unorganized and confusing. Spaghetti code usually occurs when a developer starts a project without putting much thought into the organization of the code. Although the end product may work, adding functionality may increase fragility. Using the spaghetti analogy, adding more code would be like adding more spaghetti leading to an even larger tangled mess.

Golden Hammer

Golden Hammer refers to one tool being the solution to all problems. A developer may have used a well designed piece of code to solve previous problems, but relies too heavily on it by trying to use the code for problems that do not necessarily belong. Forcing code where it may not belong can lead to spaghetti code. The Golden Hammer concept can be thought of as trying to cut a piece of wood with a hammer.

Boat Anchor

The Boat Anchor anti-pattern occurs when a piece of code is left in the code base, so it can be saved for later use. Although the code may not make sense for the program, the thought process of saving the code is if the code is needed later it can be turned on and off with comments. Some may think because a piece of code is commented out, there is no harm in leaving it. However leaving unnecessary code can lead other developers confused about what the code is intended for and over time may slow down build times. Turning the code back on may also break the code if changes were made to the point where the saved code may no longer be compatible.

God Object

A God Object is an object or a class that has too much responsibility for the program. This violates the single responsibility principle, as every object and class should only be responsible for one single part of the program. For example, there is a customer ID class responsible for the customer’s first and last name, transactions, and more. Rather than the customer ID class manage all those details, better practice would be to have customer ID be responsible for the customer’s name while a separate class is created for transactions.

Reflection

This resource was chosen because it explains what anti-patterns are, why they are bad, and listed common types of anti patterns. The article was informative as I realized I am guilty of utilizing many of these anti patterns such as spaghetti code and god object. After reading this article I am now aware of these anti patterns, and will be more mindful to not use them in the future.

Resources:

https://www.lucidchart.com/blog/what-are-software-anti-patterns

Week 13: CS-348

Software Process Model

A software process model is an abstract framework that gives steps on ways to plan software development processes and how they can be organized and executed. There are different types of software process models but all include some form of:

• Specification – Defining what the system should do
• Design – Defining the structure of the system
• Implementation – Implementing the system
• Validation – Ensuring the system works as intended and that the system is what the customer wants
• Maintenance – Changing, modifying, updating to keep up with the customer needs/fixing bugs

Types of software process models

There are many different types of models that are available to be used by organizations. Some allow organizations to use the model directly while others are more flexible, allowing organizations to create custom steps that are more specific towards their needs.

Software processes are typically specified using Software Development Life Cycle (SDLC) models. These models specify the different steps of the software development process and the order they are executed. 

Waterfall Model

The waterfall model breaks down software process activities into sequential phases. Each phase depends on the outcomes of the phases before and cannot be started until all phases prior have been completed. Each phase corresponds to a software process. For example, the first phase would be specification/requirements analysis because developers cannot create a system without knowing its intended function. Once that step is completed, then the next phase can be started and so on.

V Model

The V model is similar to the waterfall model where steps are followed in a sequential order. Initially after each step, the model progresses downwards to move onto the next step. Once the the coding/developing stage is complete, the model then bends upwards to create a V shape. This model highlights the relationships between each phase of the development life cycle and its corresponding phase of testing. The downward process is called the Verification Phase, while the upward process of the model is called the Validation Phase which are completed by developers and testers, respectively.

Agile

Unlike the two previous models, Agile is not a model with specific steps to follow. Rather Agile is a broader term for a set of methods and practices that encompasses values from the Agile Manifesto. These values helps teams to react quickly to any unforeseen changes, while reducing risk. The software development approach to Agile is usually rapid and small cycles. Doing this results in more frequent releases with each building upon the previous releases. Agile can be implemented by using frameworks such as Scrum and Kanban.

Reflection

I chose this resource because before simply listing different types of models, it clearly defined what the software processes are. This ensures a foundation is established. Although only three of the models in the article are listed above, there are several more models which I found interesting as I was unfamiliar with some of them. Because organizations use different models, being aware of the more popular ones will be beneficial in the future.

Resources:

https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/