Author Archives: alidanordquist

Working in Agile and Scrum Teams

Source: Hapticmedia and The Scrum Guide

Agile is a methodology that allows for iterative development that is constantly being improved upon for the best product and efficiency. Those who use Agile follow the manifesto, consisting of 4 values and 12 principles of best practices. 

The values are: 

  1. Individuals and Interactions Over Processes and Tools
  2. Working Software Over Comprehensive Documentation
  3. Customer Collaboration Over Contract Negotiation
  4. Responding to Change Over Following a Plan

The first value relates to prioritizing how the team is working as a whole rather than following a strict set of protocols that may hinder productivity. The second value focuses on getting a working product to show the customer over spending too much time on documentation that does not progress the project. The third value involves the customer in the development process, allowing for constant feedback and a product the customer will love. The fourth value is similar to the first, reacting to changes the team needs to make to be more efficient and create a working product is more important than sticking to a plan created in the beginning. 

A type of the Agile methodology is called Scrum. Scrum breaks down a project into small “sprints” where the team works on a small increment of the whole project. In each team there are the Developers, a Product Owner, and a Scrum Master. The Product Owner acts as the communicator between the developers and the customer and maintains a priority list of what needs to be done. The Scrum Master oversees the developers and ensures they are being as effective as they can be. During each sprint, there are 4 main components, the planning meeting, the daily scrum, the sprint review, and the sprint retrospective. The planning meeting happens at the beginning of the sprint and is where the team decides what they will accomplish this sprint. The daily scrum is a daily meeting where everyone decides what they will do that day and what they will do better from the day before. The sprint review is a meeting with the customers/stakeholders where everything that was accomplished is presented. The sprint retrospective is a meeting between the scrum team where they discuss what went well overall and what needs to change for the next sprint. 

Agile is a very effective methodology for software development. Over 85% of developers use it and it improves delivery time and team morale. It also allows for all team members to be on the same level where everyone is important and always making valuable progress. I hope to be in a team that uses Agile because it is the most effective compared to other methods of software development, like Waterfall. I am looking forward to experiencing the Scrum process first-hand in the Software Development Capstone next semester and I have high hopes of what it will do for my long term career.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Application Programming Interfaces

Source: altexsoft

Application Programming Interfaces, or APIs, are the communicating code between a client and server, kind of like a user interface for the computer. They are what receives information from the user interface, sends it to the server to get a result, and sends that result back to the user interface. APIs can be private, partnered, or public. Private is where the API is only available for an organization to use. Partnered is where the API is available to a group of organizations that are in partnership with each other share it. Public is where the API is available to everyone. In our setting, the Thea’s Pantry API is public, mainly used by food pantry volunteers, but the code is openly available on GitLab. 

There are also different types/formats of APIs, like Remote Procedure Call (RPC), Service Object Access Protocol (SOAP), and Representational State Transfer (REST). RPC is when the client requests data from the server and the server sends it. SOAP is a protocol that exchanges data in a decentralized environment, it uses XML messaging between the client and server through HTTP or SMTP. SOAP is known for its high security of data. REST is a protocol where resources are given a URL that can be used to request the data using HTTP methods. REST is simpler and more versatile than SOAP because it requires less complex code writing and uses many formats beyond XML. 

In class and in the homework assignments, we focused on REST API with JSON messaging. We practiced sending requests for GET, POST, PUT, PATCH, and DELETE and some of their different responses like success, entry error, and server error. We also learned how to write our own requests for creating guests, changing a guest’s information, retrieving a guest’s information, and deleting a guest from the system. Some methods, like POST, require arguments as well. To post a new guest, the request needs to have the new UUID and all the information their user will have, like if they are a resident and if they receive financial assistance. To receive a list of users that fit a certain criteria, the GET request needs to have a specific tag in the URL to specify the endpoint. 

Learning APIs will be extremely helpful for the future. In software development, APIs are everywhere. While REST is the most common, it is still useful to know the other kinds as well, like SOAP, and how to use them. Everyone uses APIs: Google, Amazon, Microsoft, Netflix, and many, many more. Getting first hand experience using and building APIs allows me to expand my skillset for real-life applications.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

UML Diagrams With PlantUML

Week 5

This week I chose to expand my knowledge on UML class diagrams in PlantUML. I referred to the PlantUML website where they go over every command that is available to use and how they work. I wanted to read up on class diagrams to prepare myself for creating them in the homework assignment on UML diagrams and for refreshing my knowledge on UML. 

The website goes through all the types of elements you can create, relationships between them, putting labels on relations, defining visibility, adding methods and variables, and how to add notes. 

-The UML block is contained in “@startuml” and “@enduml”. In the dev container we used in class it is contained in ““`plantuml" and ““`”.
-To create a class, use “class <name> {<body>}”. If you want to make an abstract class or interface, you would do “abstract <name> {<body>}” or “interface <name> {<body>}”. 
-To define visibility modifiers for attributes and properties, use + for public, – for private, # for protected, and ~ for package private. By default, the diagram will show these symbols in colors and shapes, but that can be changed if wanted. A static attribute is defined with
“{static}” before the name.
-The site shows a lot of ways to create notes and all the things you can do to change them, like location, size, color, line breaks, etc, which can be useful to categorize notes in your diagram. 
-You can also change the colors of classes and elements, which can help to organize as well.
-Another element you utilize is arrows, when a class is defined, you can say “implements <class>” or “extends <class>” and it will automatically use the correct arrow. But, you can create your own arrows for associations by using “–>”, “-[bold]->”, “-[dashed->”, “-[hidden]->, or “-[plain]->” with the class names on either side. Notes can be attached to arrows as well. For example: Order “many” –> “1” Customer

I referenced the site a lot while doing the UML homework for a refresher. While working on the base assignment, I was cross referencing a lot to make sure I was doing it correctly, but when I got to the advanced assignment, I felt a lot more confident and comfortable with creating UML diagrams in VSCode and only needed to reference it for creating static variables. 

UML diagrams are essential for smooth code developing and finding any structural issues before you’re too deep in a project. Having the knowledge and practice to create them will definitely help me outside of this class. Using PlantUML is now something I feel like I can say I can do in real life. In the future, if we make more diagrams in class or if in a job they ask me to make one, I feel comfortable telling them I can make one.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Understanding GitHub

Quarter One Blog

The video I watched is a basic tutorial for GitHub. Corbin, the creator, explains that GitHub is essential for version control and organization, and how important it is when your code becomes more complex. He starts off by explaining what a repository is and how to make one in GitHub. Then, he shows one of his repositories for a project with a working program. He says if he wants to start making changes and adding to the code, he would create a branch to prevent the code from breaking and save a lot of time if he needed to backtrack and fix it. He shows how to make a branch, as well. He provides the basics for what we went over in class and in GitKit chapters and explains how to do it in a slightly different way than what was said in class. I chose this video because I find it useful when I have multiple ways to explain a topic and I can understand it better.

The process for creating a repository is not something that we went in depth on in class, so having Corbin explain how to go through that process was helpful. He touches on what the difference between public and private repositories are. In class and in FOSS applications, they would all be public repositories, but if you were just using GitHub to put your private code in the cloud and for your own version control, a private repository would be more useful.

Corbin provides a visual and explanation for what branches and forks do, but it is not as clear as what was shown in class. Having the different explanations of both is helpful for a deeper understanding. He goes over having a completed branch, how to merge it back to main, and explains what the version control deletions and additions look like. 

Outside of the Software Process Management class, understanding GitHub is super useful in the real world. Other classes, like the Software Development Capstone, will require the understanding of GitHub to complete the final project. A lot of companies use Git for version control and collaboration, and look for those skills on applicants’ resumes. I feel confident and comfortable that I can navigate and use GitHub in my life going forward. 

Last year, I took Software Testing before understanding Git. While I was able to figure it out and get through the class, having the knowledge I do now with the actual process and reasonings of it, I feel like I would’ve spent less time troubleshooting silly issues.

From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

CS348 Introduction

Hello! This will be my blog page for CS-348 Software Process Management.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

CS343 Introduction

Hello! This will be my blog page for Software Construction, Design, and Architecture!

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Week 12- Test Driven Development

During week 12, we learned about test driven development. Test driven development is a testing method that outlines what functions need to be tested, writes the tests, then writes the code. It is an iterative process that goes through each test one at a time, building on what is already written. 

In class, we practiced the method by building a Mars Rover. We read what the rover should do and made a list of what we needed to test and build. We started with the easiest thing on the list and wrote a test for it. Then, we wrote the minimum amount of code to make the test run. We tweaked the test block, if it needed to be, and then ran the single test. Next, we repeated the process for the next easiest thing on the list. We will repeat the process until all of the tests are written. 

Test driven development focuses on just the tests before the actual code is written. It was a little confusing at first to think about how to write a test before the code, but once it clicked, it was easy. 

I found a website on test driven development and it described the process in a slightly different way. BrowserStack explains test driven development as a “red-green-refactor” cycle. The red phase is when just the test is written and it doesn’t pass because there’s no code. The green phase is when the bare minimum code is written for the test to run and it passes. The refactor phase is tweaking the tests and code so everything runs and passes. The cycle is run through every time a new test is written and repeats until all of the tests are written and pass. 

Test driven development is a very useful method for debugging. Since the tests are being run at every new addition, bugs are found as they appear and do not slip into the cracks as easily. The method also is very efficient and allows the programmer to easily add new functions later on in development. The iterative process is easy to maintain for the programmer, and provides a much larger testing scope than other methods. 

I liked working with test driven development. I think the process is very organized and straightforward. I would definitely use this in the future for projects that require thorough tests and with functions that build on each other. 

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

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Week 10- Stubs and Mocks

During week 10, we experimented with stubs and mocks. Stubs and mocks are two forms of testing doubles that allow a team to write tests before the whole program has been written. Stubs and mocks simulate the code’s fleshed out methods and allow for testing methods to be written in advance. 

Stubs are methods or classes that are either empty or return a set value so they can run and be tested. Stubs are state testers and focus on testing the outcome of methods. Mocks are more dynamic, the test block can define what it wants the outcome of any method to be and then test for that outcome. It can also test for multiple set outcomes in the same block. Mocks are behavior testers and test the interactions between methods, rather than the outcome. 

The reference I found was a blog that compares and contrasts stubs and mocks by BairesDev to get a better idea of their use cases. They explained what stubs and mocks are, the advantages and disadvantages of each, and the situations to use both of them.

Advantages for stubs are their predictability and isolating the method. They will always return what you are expecting because of how simple they are. Since stubs do not involve any other calls or methods, they are great at isolating testing to just that method. Disadvantages are user error and the lack of behavior testing. The user might have a discrepancy in what they return in the stub and what they expect in the test. If your method needs to interact with other methods, stubs are not great for testing behavior because they only look at the outcome. 

Advantages for mocks are being better at testing subtle bugs and issues and testing the interactions between methods in your code. Since mocks are behavioral tests, if the methods don’t interact how they’re expected to, the test will not pass, which goes beyond what stubs do. Disadvantages are increased complexity and brittle tests. Mocks make your tests more complex than if you were testing the fully written code, which may take more time to adapt to once the program is finished. Brittle tests can occur if tests are too connected to the mock expectations, and small changes can cause a lot of errors. 

Overall, stubs are useful when testing independent methods and those that only need to be tested for the outcome. Mocks are useful when methods are dependent on others and can find errors that might not show up if you were just testing outcomes. Both are great when writing tests, but have different applications and both should be used when testing programs. 

Source: https://www.bairesdev.com/blog/stub-vs-mock/

From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Week 8: Path Testing

This week, our class learned about path testing. It is a white box testing method (meaning we do not actually run the source code) that tests to make sure every specification is met and helps to create an outline for writing test cases. Each line of code is represented by a node and each progression point the compiler follows is represented by a directed edge. Test cases are written for each possible path the compiler can take.

For example, if we are testing the code block below, a path testing diagram can be created: also shown below. Each node represents a line of code and each directed edge represents where the compiler goes next, depending on the conditions. Test cases are written for each condition: running through the while loop and leaving when value is more than 5 or bypassing it if value starts as more than 5.

I wanted to learn more about path testing, so I did some research and found a blog that mentioned cyclomatic complexity. Cyclomatic complexity is a number that classifies how complex the code is based on how many nodes, edges, and conditionals you have. This number will relate to how many tests you need to run, but is not always the same number. The cyclomatic complexity of the example above would be (5-5)+2(1) = 2.

Cyclomatic Complexity = Edges – Nodes + 2(Number of Connected Components)

The blog also explores the advantages and disadvantages of path based testing. Some advantages are performing thorough testing of all paths, testing for errors in loops and branching points, and ensuring any potential bugs in pathing are found. Some disadvantages are failing to test input conditions or runtime compilations, a lot of tests need to be written to test every edge and path, and exponential growth in the number of test cases when code is more complex.

Another exercise we did in class was condensing nodes that do not branch. In the example above, node 2 and 3 can be condensed into one node. This is because there is no alternative path that can be taken between the nodes. If line 2 is run, line 3 is always run right after, no matter what number value is. Condensing nodes would be helpful in slightly more complex programs to make the diagram more readable. Though if you are working with a program with a couple hundred lines, this seems negligible.

When I am writing tests for a program in the future, I would probably choose a more time conscious method. Cyclomatic complexity is a good and useful metric to have, but basing test cases off of the path testing diagram does not seem practical for complex codes and tight time constraints.

Blog post referenced: https://www.testbytes.net/blog/path-coverage-testing/

From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Week 6: Boundary Value vs Equivalence Class Testing

This week we learned about boundary value testing and equivalence class testing. Boundary value testing focuses on making sure the values in, out, and around the expected boundary works as it should. Equivalence class testing does the same, but also tests the function itself.

I wanted to know more about the two methods and found a blog post that explains them a little more in depth. The author, Apoorva Ram, says they are more thought processes than testing methods really. The thought process of boundary value testing is self explanatory: testing the edge boundaries of the function. The thought process of equivalence class testing is organizing every possible input into groups of expected outputs and testing the result from each.

Ram also explains the benefits of the methods and how they can be used in software testing. The two seem to go hand in hand. Planning your tests before writing them and knowing the expected output makes the testing process a lot smoother. You know what points you need to hit and have a plan to execute them. Additionally, knowing all the points you need to hit allows you to prioritize ones that are more important.

For example, say you have a boolean function that looks for the input value to be between 15 and 30, but accepts values from 0 to 100. Boundary testing would test the values of xmin-, xmin, xmin+, xnom, xmax-, xmax, and xmax+. In this case: -1, 0, 1, 50, 99, 100, and 101. It mostly makes sure the 0 and 100 boundaries work. But equivalence class testing breaks down the function into classes of values that will give every result: invalid inputs (under 0 and above 100), false cases (between 0-14 and between 31-100), and the true case (between 15-30). In this case: -1, 12, 20, 45, and 101. This method tests the valid ranges as well as the function ranges.

In my opinion, equivalence class testing is better than boundary value testing because it actually tests the function and not just the illegal argument exception, and it eliminates redundant tests like xmin+, xnom, and xmax-, all testing for the same output without actually testing the function. Though ideally, a mix of both would probably be the method I choose. For this example, I would test each equivalence class and its boundaries: xmin-, xmin, xmin+, xtruemin-, xtruemin, xtruemin+, xtruemax-, xtruemax, xtruemax+, xmax-, xmax, and xmax+ (-1, 0, 1, 14, 15, 16, 29, 30, 31, 99, 100, 101).

Blog post referenced: https://testsigma.com/blog/boundary-value-analysis-and-equivalence-class-partitioning/

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.