Hello!
I’m Marcos Felipe, and I’m currently enrolled in CS443 (Software Quality Assurance & Testing) at WSU. Over the semester, I’ll make a series of blog posts related to this course.
From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.
Hello. I don’t really know how you got here but welcome to my blog. I don’t really blog but I guess I will have to start somewhere, so I might as well start here. I started this blog for a class I was taking in my Senior Year of college, so at least initially, most of my posts will be responses to assignments from that class. At the moment, I don’t know what direction I want to take this blog but I hope you will consider coming back to this page one day to see how far I have gotten.
Welcome to my blog where I will be detailing my various Computer Science endeavors.
This semester I am taking both the CS-443 Software Quality Assurance & Testing and CS-448 Software Development Capstone courses and will post updates regarding those courses here!
From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.
Hello! My name is Kurt Maiser and this is my first blog post for CS-443 (Software Quality Assurance and Testing) at Worcester State. I’m a Junior in the CS program here and made this blog for the class (at least initially). I am looking forward to the year and to writing some code! See you all in Zoom.
From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.
To the reader who is currently viewing my blog, hello!
My name is Sofia Hoda. As of the writing on this post, I am on my second year at Worcester State University and am currently a Computer Science major with a focus on Software Development. During my studies I work as a Mathematics tutor at a community college, which brings me much joy. If time permits in the future, I hope to study further so I can incorporate Mathematics and Software Development in my future career.
I created this blog to catalogue my findings regarding Computer Science while I am taking my CS-443 course, though I hope I get to use it as a way to also talk about any future projects I might work on.
I will do my best to make this blog interesting for anyone who may come across it. And to the readers who are also taking CS-443 on SP21, I hope we get along this semester and do our best!
From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.
This second sprint brought with it some challenges in moving to online classes for the ongoing epidemic, but with it a stronger grasp on communication and documentation using GitLab and Discord, both out of necessity and intentional effort. We have learned to better work with LibreFoodPantry workflow and are ready to go into our next sprint with our REST API, Database, and Frontend all working in isolation.
Create file with definition of done.
Research Angular Testing and create a Spike project that covers most cases we will encounter.
For the first half of the sprint, we were still having weekly meetings to work together. One of our troubles last sprint was that we were discussing things in person and not doing well documenting the reasons for decisions we made. We improved on this even while having in-person meetings. By the second half, although we were all coping with changes brought on by moving to online classes, we did well in keeping each other updated and communicating through GitLab. In hindsight, it’s probably a good experience to be forced to do this. Especially if this epidemic inspires more software companies to promote working from home.
The biggest issue we had as a team was working with merge requests. There were a couple cases where code on a feature branch was not kept up to date with the master branch. As a result, there were a lot of merge conflicts to work together on resolving as a team. Overall, working through these together as a team was a good experience, because this is bound to happen when working in tandem with version control. However, now we will be reminding ourselves to pull changes from origin/master as we are working on our local branches.
We also improved with creating merge requests for each individual features, although this took a few weeks for us to all do efficiently. GitLab has a great feature where you can tightly-bind an issue to a merge request, but this caused a couple of problems for me. When the merge request is accepted, the issue is automatically closed. This messes with our workflow, because we want the issues in the “done” column, only to be closed by the product owner. Moving forward, the issues should be linked with their merge request but we will have to take care that the description doesn’t include a “Closes issue” tag.
Furthermore, when a branch is automatically made in GitLab, it creates a very verbose branch name, which is simply annoying if your Git isn’t configured to autocomplete branch names when pressing “tab”. In the future, I will create a new merge request and manually select my already-created branch. Then I will manually link the issue.
The team’s willingness to quickly meet over Discord about an issue we were having was the best thing about this sprint. In the few cases where something occurred outside of class time that required all of us, we were able to set up a time the same day or the next day and resolve the problem. This flexibility to schedule work within the sprint is what helped us get as much work done as we did.
The next sprint will involve combining our individual pieces into a working product that is capable of storing actual checkout transactions. There is a still a lot to learn and to do, but we are well on our way to finishing a viable product that we are proud of, albeit with much room to grow in the future. We will have to pay close attention in the next sprint to creating well-written documentation as we combine our API, database, and front end so that future developers can easily recreate what we’ve done and get it running.
From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.
To become truly good at programming is a life’s work, anongoing enterprise of learning and practicing.Ron Jeffries et al., Extreme Programming Installed This pattern from chapter three caught my attention, the quotes they used in the beginning of this pattern were nice and sometimes we need something to remind us that the 1000 mile journey … Continue reading The Long Road
From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.
From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.
Hello everyone! Today I wanted to write a blog about someone else’s blog post that I found online last week while reviewing for one of my final exams. Its by James White ( https://blog.scottlogic.com/2017/09/25/mutation-testing.html ) and in his blog he talks about mutation testing, which is one of the topics we’ve covered in class recently. Mutation testing is a way to test the code that you have written by altering your code with changes that are designed with the intent of being detected by different tests you have written for your code. Basically, it mutates your code so your tests can find the mutation and, if that happens, then you know your tests worked correctly. If the mutation survives in your code then you know the tests didn’t work.
What I like about James’ blog is that he makes the idea easy to understand, and incorporates plenty of different examples to walk readers through how mutation testing works. I specifically like his example of why mutation testing is needed, and how, in his example, mutation testing was able to point out a flaw in his code that otherwise would have gone unnoticed, since you could have changed the line of code or even deleted it all together and, without mutation testing, it would have looked correct even though it wasn’t.
The other thing I liked about James’ blog is the different examples he gives of what these mutations look like. How it can change (input > 0) to (input <= 0) or how it could mutate code to check true instead of false. I also liked how he addressed the common question of how long it would take mutation testing to run, since that is a question I had myself once we started learning about mutation testing. I also thought it was pretty cool that he mentioned how mutation testing can help point out instances of redundant code, and some other neat things about it too. Overall I enjoyed reading his blog, and it helped me better understand the material we learned about in class.
From the blog CS@Worcester – Nick’s Blog by nramsdell1 and used with permission of the author. All other rights reserved by the author.
hello, for the last time I have recently been learning about how to create application and use static testing tools. First of all I learned how to create an application with gradle. This is done by adding a few lines to the build file, the plugin for application and the path to the class with the main method. The binary to run the application will show up in the distributions folder. The next thing I learned was how to use check-style which is a tool for checking code style against a specific style sheet I used two different style sheets sun_checks and google_checks. These tools generate reports about your coding style based on the style sheet. I think these are very good for making sure you are writing clean code. The last tool I tried was spot-bugs which works similarly too check-style except instead of checking for style it checks for potential bugs and generates a report based on this.
From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.