Author Archives: dzona1

SMURF testing

The blog I chose to write about this week details what different types of tests do and how they should be prioritized to test efficiently. The blog post starts with the writer talking about their own experience testing and how early on they tested their program only through the user interface, which quickly showed the downsides of this method. It was slow, couldn’t be run on all devices, and needed manual checks. Testing like this is called end to end testing and it is, slow, expensive, and not always the most revealing about potential problems. Instead, unit tests are much preferred as they test the very basic functionality and are quick. A middle ground between these two is instance or integration testing, which are able to cover most of the program without having to go through a limited user interface. These three types of testing create a pyramid to show that a majority of your cases should be unit tests, then instance tests being next most common, and finally end to end tests.

The distribution pyramid is based on five principles that make up the Smurf mnemonic. The first is speed, that has you prioritize many quick tests that will catch problems sooner. Next is maintainability that gives importance to tests that will scale well or not be subject to many dependencies. Utilization is important when keeping in mind the cost of running your code repetitiously and minimizing the resources used. Reliability states that you should always have tests that will only return an error when something is actually wrong and using these as indicators of crucial issues that need to be addressed. Lastly, fidelity is testing that recreates the users experience from start to finish, or end to end. Each type of test in the pyramid is distributed across these five factors in variable amounts, each showing their use.

I chose this blog because I wanted to learn more about writing test cases for a complete program in a work environment. I thought that this blog did well in that respect and helped in so far as providing an outline to begin with when starting to write test code. One addition that could have improved the post would be some examples, but they are easily accessible elsewhere. This will be a helpful resource and reference to use in the future when I am put in the position where I would need to start writing test from scratch, as well as being something to keep in mind when looking at prewritten tests to compare.

Test Pyramid Google Testing Blog: SMURF: Beyond the Test Pyramid

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

Sprint 1 Retrospective

In my CS-448 class, we are working with the Thea’s Pantry system. I was placed on the team that looks at the automated reporting system and we have just finished our first month long sprint. During this sprint one, the first issue I worked on was the Reporting Integration set up issue which was in the backlog from the last team that worked on it (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/issues/27). Then, after finishing with that, I took the next available issue that we had planned for this sprint and fixed that as well (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/issues/29). After testing and requesting a merge for both of my issues, there wasn’t anything else that we had planned for the current sprint and I didn’t want to start on another month long sprint issue, so instead I helped my other teammates troubleshoot, checked their work, and looked into things such as how the final report file is formatted, what information it has, and how we would go about creating a file like that within the code.

I think what worked the best for us was our original plan at the start of the month so that we all knew what we needed to do and could focus on that. For the most part with most problems being from the project backlog, we didn’t work collaboratively that much as the issues were largely separate but during meetings, we would be able to teach each other about the different systems we were working on. We also were able to get all of our issues done with a little time to spare at the end that we used to further develop some of the small things we would have needed to do eventually anyways. As far as what didn’t work well, when starting to help my other teammates, I felt behind in understanding on the system they have been learning for a few weeks and had to catch me up. Fortunately, with the extra time we had, I and others were able to follow along with other’s progress and quickly gained at least a basic understanding of all parts of the system.

During the next sprint, an improvement that I hope we make as a team is to work more collaboratively, even if the problems we are working on are not directly related to development. We didn’t have much of a chance to work on direct collaboration, but for the next sprint given the opportunity now, I hope that we can progress as a team more so that specialized individual programmers. For myself individually, something that I aim to improve on is my workflow. Last sprint I would try to implement code and get it in a semi working state but then would have to go back and reference other parts of the project or research some other system that was involved. In the future I plan to approach the problems first with getting a full understanding of how the system will work when fully operational and then writing the code, rather than going back and forth between coding and learning.

For this sprint, I feel that the apprenticeship pattern that was most applicable to me was Chapter 2’s pattern of emptying the cup. The book’s author talks about this in the context of learning a new language which is somewhat true for myself as I am not very experienced in all the intricacies of how javascript coding works when developing a website. I felt that this pattern described my experience because I had to learn a lot of new systems that I hadn’t used much before. This is my first time working with RabbitMQ or MongoDB and to a lesser extent the workflow of docker and gitlab. Over time, I got better at using these applications but I had to spend time learning them without “working on” the project.

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

Combining Testing Methods

The blog post that I chose to write about this week is one that gives an overview of equivalence class and boundary analysis testing. The main reason why you would use these is to reduce the number of tests you run for a program while still testing full functionality and not sacrificing coverage. It does this by sectioning the range of inputs into different equivalency classes. Equivalency classes are groups of inputs that in theory should behave identically when put into the tested function. The blog then shows a helpful diagram showcasing what this looks like plotted on a number line. This way, tests will give better information by only testing the function where problems may arise and will detail the behavior of the function near edge cases better than other methods.

The blog post also details how you can represent the classes as functions themselves for where the inputs would be, for example, true, false, or valid, by defining ranges of values with interval notation. After then going over boundary test cases, the author explains how these two methods can be used together to efficiently test around the limits of the function behavior. The blog concludes with another example plotted on a table that shows how equivalence classes and boundary testing can be combined to use a minimum number of tests while also ensuring that you test the function at its most important parts where the process will change based on inputs.

I selected this blog to help refresh myself for the upcoming test about different testing methods and to reinforce what I had learned in class. I think that one of the more important takeaways from this blog is the emphasis the author puts on combining the two methods not just because they are two different methods but because they strengthen the overall testing procedure, and this will make me think about how new testing methods can be combined to lead to better and more efficient test cases. Demonstrating the testing in terms of models on number lines and as graphs help visualize what is actually happening and why it works, similar to the models taught in class but the added element of real numbers with example values helps demonstrate the importance of this kind of testing and how it can be useful for any kind of real-world situation. As an introductory post to the topic, and in my case a review, it works well but from here I would like to look more into the different combinations of testing methods that can work well together and some that may not as I learn more methods through the rest of the class.

https://www.testbench.com/blog/equivalence-class-partioning-and-limit-value-analysis/

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

Software Testing Thinking Hats

The blog post I’ve chosen talks about the different mind sets that you should use when tackling different situations. When writing tests, it helps to write tests with different goals so that you don’t forget to test every aspect of some section of code. The blog author talks about how trying to do the tests out of order or without any order in mind you can forget things and cause it to take more time in the long run. The author categorizes these as “hats” to wear during each progressive stage. There is the ambitious hat which is for when you are testing the code in the way the customer will be using the code. There is then an uncomfortable hat which is for when your tests are failing, and you need to fix what you can in your testing. The confident hat is the one you can wear while you are refactoring your code and running just to confirm everything passes. The author also makes specific mention to not try and wear multiple hats at once.
From my experience in the classes I’ve taken so far, I’ve done some built in testing in files for whole programs that I myself have written, and so I know exactly what the code should do, what I need to have pass in order to meet the homework criteria. In these cases, because I am both the author of the code and the author of the test cases, I am able to make edits in both parts with the knowledge of exactly what the test cases should be. This has helped in my current class so far but as we move forward, we will be approaching testing like it is done in the workplace and when the people testing the code are a separate group that has not touched the program code. I’ve definitely seen myself as the coder that the author describes who frantically moves around the code and tests trying whatever I can to get everything to work instead of approaching it with any methodology. I want to become both better and more efficient at testing code as it will help me write code also and further my understanding of what makes a complete program. Testing is a big part of working in the computer science field and I know that quality assurance is very important, so I look forward to both learning more about this within the course and doing more blogs about the industry.

Chris James – The TDD Thinking Hats

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

Apprenticeship Patterns

In the Apprenticeship Patterns readings, the first thing that caught my attention was the passage about how people perceive apprenticeships and that being contrasted with what this book posits apprenticeships should be. Usually when I personally think about working under and expert to further a skill, I usually equate that to a physical trade that would be difficult to learn without hands on experience but just like those other typical apprentice jobs, but it would make sense that the same experience with working under an expert and learning any other skill would also help a lot more. The growth mindset is something that I hear a lot with math, and I think that it’s a good to have in all respects when trying to learn something new. This also pairs well with what the book states on always having more to learn and that those topics can’t always be learned in a traditional classroom setting or is lost in online tutorials. The author puts in a few personal stories where the times he was able to really learn something new and furthered his mastery over the subject was when he wasn’t afraid to be behind others and develop by observing and listening to everything that they had already found through experience and invested time into the field. This is vital when you are working in computer science, because it is a rapidly advancing field with new techniques and practices and discoveries. It may be daunting to try and keep up but that can serve as motivation to continue growing and not growing satisfied with just enough. Personally, in my experience with computer science through college, the academic learning part is straightforward, and everything is laid out for you to memorize and complete but in situations where you are given an abstract or very broad problem to solve, it can be challenging to figure out where to start or what to do because of my own inexperience with coding that would be analogous to a real world project. I think that recently with more frequent research done on my own time for blogs such as these and different classes, I have started to strengthen my understanding of computer science by knowing that there is so much more to learn than what can be taught in four years.

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

Software QA Testing Introduction

After finishing CS-343 last semester, I have moved on to CS-443 Software Quality Assurance and Testing. So naturally, a new topic of the next few blogs I will be posting will be related to QA and testing in the Computer Science field. I hope that writing this blog will help me in the same ways it did for my previous class, where I can learn more about how the material that we learn is applied in commercial program development.

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

LibreFoodPantry and Thea’s Pantry

For my Software Development Capstone, I will be working on the LibreFoodPantry, a Free Open Source Software project, and more specifically, the Worcester State University food pantry, Thea’s Pantry.

After reading through the LibreFoodPantry website I found it interesting how it mixes Free Open Source Software (FOSS) with a humanitarian project, as I think those two go well together naturally, both being non-profit and for a noble cause. But another part of the LibreFoodPantry program that it also works closely with college students in the computer science field. This is another way that the entire structure of the LibreFoodPantry helps, because it allows student to learn from real software that is used in the real world and gets them involved with humanitarian causes within their major.

Going further into the specific system I will be working on, I read about Thea’s Pantry. What I found to be the most interesting thing is how the whole project is organized. With a lot of different people working on the same software and making different changes and using it for different purposes, there can be a lot of things that then don’t work with each other or become incompatible or cause communication issues. The entire project is organized in a way to allow many different iterations to exist without coming into conflict and being adaptable.

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

Rest API

This week I wanted to blog about Rest API. The repository that we have been working on in class has a decently large backend that uses a wide variety of methods to act as a good example and introduction of Rest API. I wanted to look into it and try to find more examples to look at and get a better understanding by looking at implementations that either had a different format or was used for different purposes. While looking I found a blog that detailed the documentation that developers have made a standard to put with code that aids in understanding.

The article starts off with some common mistakes that can really decrease the effectiveness of your documentation such as not enough examples, the lack of English explanations, and unmaintained documentation. As aspect that the article touches upon is that the documentation should be written to be understood by entry level developers, which makes sense as your implementation shouldn’t be opaque to the users. The article provides a survey taken by web developers that ranked the most desired features of API documentation, and ranks examples, status, and error messages in the top five. This makes sense as these are some of the things that contribute most to being able to understand already existing code. Spec-driven development is also explained here and talks about using software like Swagger to keep track of and simplify your code to easily understand how the program uses the data. The blog also puts emphasis on the industry standards that should be used, and it goes a long way to help users get a grasp of new code when they start to look at new projects.

This post was helpful in understanding how to read other repositories of API, especially as it was written in the form of the writer’s or maintainer’s point of view. Although I have not yet and don’t plan to yet, write and document an API designed by myself, this write-up was equally descriptive for explaining how to read the documentation. I think that this is an extremely useful skill to have because, like in our class assignments, we won’t always be designing something from the ground up and so we need to understand what is already there. The web page had lots of pictures to illustrate the point they were making and to provide examples. It always helps to learn more of these industry standards to be better prepared for real world or out of classroom applications and strengthen your skills as a programmer.

Original Blog Post – How to Write API Documentation

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

Response Codes

In class after learning about a few select HTTP response codes, I wanted to look into the whole library of possible codes to get a better understanding of how website calls work and the potential errors that come with them. The blog I chose to read from gave a brief introduction to why knowing the meaning of the response codes is important for managing or using a website. Before going into the specific definitions of each code, the author states the main takeaways at the beginning of the article which helps the reader know what to look out for as they read ahead.

The codes are representations of the types of responses between the web server and the browser. Every time you use a new URL an HTTP code is generated. The author goes on to explain how making sure you have successful HTTP codes is a good way to promote a website because search engines use the HTTP response codes to determine if that URL will show up as a result.

Next is the part of the article that shows how the first of the three digits are grouped and defined, which I didn’t know and is helpful to know. Some that we didn’t go over in class was 100 codes that are for Informational responses and 300 for Redirection. There is then a reference table provided that gives the corresponding code and definition for each code. The author then goes into more detail about how search engines use these codes to determine what pages get recommended to users.

I think that for myself and how I tend to learn best is by looking up libraries of every possible response/function/use for something and deepening my understanding of a topic and knowing how it works and why it was made that certain way. It will also be helpful as both a developer and a user because now when I see an HTTP response code, I will know what it means and what I would need to do to fix or get around the problem. I also learned how important HTTP response codes are for increasing your website traffic and another reason to have efficient web code for something that I wouldn’t have thought of. Doing outside of class and self-directed research on class topics is very helpful to connect different topics together as well as how they relate to work that is done in the field

Common HTTP Response Codes Explained – Neil Patel

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

Diagrams and Code

The blog post I’ve chosen is all about PlantUML diagrams and how they can be used in ways to help your coding. The author writes about why diagrams can be useful for seeing things visually in a text heavy environment like coding is. There are many advantages to representing code in a diagram. Making the program abstract and only focusing on the process of how each thing should work with the others helps to focus on concepts rather than the implementation and actual workings of the code. There are also many types of diagrams, such as sequence diagrams that show what events take place over time, a use case diagram that shows what different levels of users are able to do, class diagrams that detail different objects’ construction, activity diagrams that can show workflow, and others. PlantUML is able to be used in many different ways for many different scenarios. There are sometimes problems that PlantUML cannot solve in the most elegant way, as the author describes, but there are alternatives and some problems that PlantUML was not designed to solve.

I think this blog was helpful to read through and see just how versatile PlantUML diagrams can be after learning about how to make them in class. Another benefit to diagrams that the blog didn’t go over, but we did in class was being able to find potential problems in the code before you even type anything which can save a lot of time. I think that using UML diagrams more often can help me with coding as having a diagram that gives me a top-down view would be helpful to look at instead of scrolling through a wall of text to find what I need to do next or how I can improve my code. I sometimes find that I can overcomplicate some sections of my code and having a written out simplified plan to look back at will help me code with more focus and also help with encapsulation which I don’t do as often as I should.

After reading this blog I will be more aware of what situations could be helped with a PlantUML diagram and make one to keep me focused on the structure and entire scope of the program. There are also ways to use diagrams in order to show processes that I haven’t used yet or have talked about in other classes which could be a good tool to use in the future to explain and show complex abstract processes.

PlantUML Diagrams – Matt Hayes

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