I’ve always been interested in the Scrum project management process, especially because we will be diving into it during my Software Development Capstone class next semester. I found a great link detailing the general methodology of Scrum, as well as specifying the roles of each party involved in the process: http://www.mountaingoatsoftware.com/agile/scrum .

Scrum is essentially a project management technique which consists of the completion of work through multiple shorter periods of progress, called sprints, towards the overall project goal. Before going over the overview of the Scrum process, there are 3 primary parties taking part in Scrum to be discussed: the software development team itself, the ScrumMaster, and the product owner. The software development team is a “self-organizing, cross-functional” group. The team does not have a leader amongst the group who delegates tasks and provides feedback. Rather, all of this is decided by the whole team. Each member of the team is also needed to develop each part of the project, from coming up with ideas, to developing solutions and features to satisfy goals of each sprint. This team has support from the ScrumMaster, who coaches the software team to perform Scrum at their best without telling the team exactly what to do, and the product owner, who serves in more of an end-user role and guides the team towards building the product best fit for the customers.

The Scrum process involves several sprints (commonly 2 weeks long). A planning meeting kicks off each sprint, where all parties create a list of tasks to finish by the end of the sprint, called the sprint backlog. A product backlog is also maintained and prioritized by the product owner, which details additional features to be added to the product and which features are most important to complete first.

Other meetings taking place during the Scrum process include daily Scrum meetings, around 15 minutes long, where the development team goes over what they’ve completed the prior day and what they intend to currently work on. The sprint review at the end of the sprint allows the development team to showcase their product, as well as the product owner to identify places to continue work for the next sprint. Finally, the sprint retrospective at the end of each sprint gives time for reflection of the Scrum process from the just-completed sprint and what needs to improve.

Reading more about this process has gotten me more excited about what is to come in the Capstone class next semester! This is such a great opportunity to take part in, especially while still an undergraduate student.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

The article that I read this week is about processing JSON data with Jackson. I thought this would be a good article to read after using JSON data a lot this week for processing input and output in our final projects, and since Spring Boot uses Jackson as the way for processing JSON. I wanted to learn more about how this works, especially after getting some errors when trying to pass in certain data types this week (particularly Calendar objects). This post goes over how to read and write JSON data to and from Java objects using Jackson for data binding. It does this by creating an example POJO to use for input and output. It creates a basic employee with the fields of name, ID number, address and other typical fields, it also has an object within an object by using an address within Employee that contains a street, city, and zip code. The article creates an example of this in a JSON input file and creates the necessary Java classes and then implements the Jackson methods (such as ObjectMapper) for databinding and outputting Java input as a JSON file.

I think that it was interesting to see how to do this with the Jackson implementation as a seemingly more proper method of converting JSON to Java objects and the other way around. Especially after spending the past week creating and getting our project to pass similar data back and forth between JSON and Java. It does seem out of the ordinary to me that both of the example classes don’t use constructors, instead using just set methods to create the object, but that’s how this implementation is supposed to work with Jackson. I particularly liked the Tree Model implementation in the article and was not aware that this was a way of processing JSON data. This article has definitely made me think more about the different ways of processing JSON data with web applications and REST APIs and the best practices to use when doing this, especially with larger, serious implementations for applications. If time permits for our final project, I would like to try and do a similar implementation in this article for our JSON processing. By doing this, it would make adding new objects to the database a lot cleaner (especially without needing a constructor) in the implementation than it currently is.

Source: https://dzone.com/articles/processing-json-with-jackson

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

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: JUnit Testing. I will be expressing my reaction to the content by sharing what I find useful and interesting. Without any further introduction, let’s begin.

The JUnit framework is a framework that uses annotations to show methods that specify a test. When defining a JUnit test, the test itself is a method in a class that is only used for testing. This is called a test class. To define that a method is indeed a test method, define it with the @Test annotation. This method implements the code under test.

Also when defining a test, testers can use an assert method, made by JUnit to check an expected result against the actual result. These method calls are called assert statements. Testers should provide messages in assert statements because it makes it easier for the user to identify and fix any problems. This works if someone looks at the problem, who did not write the code under test or the test code.

When naming a test, there are many naming conventions. A solution for classes is to use the word “Test” at the end of test classes names. This gives the reader an easier understanding that this is actually a test class. A test name should explain what the test does. If that is done correctly, reading the actual implementation can be avoided. If you are using the Maven build system, you should use the word “Test” for test classes. The Maven build system automatically includes such classes in its test.

Testers can also run their JUnit tests outside the IDE with standard Java code. Systems like Maven or Gradle can be used to execute tests automatically. The org.junit.runner.JUnitCore class provides the runClasses() method. This method allows you to run one or several tests classes. As a return parameter you receive an object of the type org.junit.runner.Result. This object can be used to retrieve information about the tests.

J unit testing is a huge part of unit testing and so much more can be said about it. This is just an intro or short summary of the topic.

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

We’ve played around with different testing concepts like mocks and stubs in class, however since we didn’t dive too far into it, I decided I’d look a little bit deeper into the subject of mocking. I found this great overview of it on Michael Minella‘s blog.

Before diving into why mocking is helpful, let’s look at the purpose of mocks in the first place and what they even are. In class we had an example where a student object had a transcript object, and in order to get the student’s remaining credits or current GPA, the student would reference the transcript’s methods. Something like this:

If we wanted to test the Student’s getGPA() method, it would involve calling transcript’s getGPA() method. However, we don’t want to test transcript’s method, we want to test Student’s. How do we know Student.getGPA() does the intended thing, which is call transcript.getGPA()? In his blog post, Michael uses the example of a test that uses the ArrayList object in Java. When we write a test that uses an ArrayList, we don’t want to test the functionality of ArrayList — we want to test our implementation of it and trust that ArrayLists function correctly. Mocks are designed to solve this problem.

A mock is a temporary object that is used in place of the real object that would be used during a test. The mock has default values for all of it’s data types, and so whether or not a test passes is not dependent on the state of the other objects or methods inside of it. In the case above, transcript.getGPA() would return a value of 0.0 if a mock transcript object had been set up beforehand. This is helpful because it allows us to remove the potential puzzle of the functionality of the transcript’s methods and solely focus on the what the student’s getGPA() is actually doing. 

There are plenty of different mocking libraries to choose from (we used Mockito in class) and they all function in slightly different ways. The subject of mocking is a deep one, and there are seemingly infinite other concepts like stubs, fakes, dummies, and more which can all be used to ensure that your tests test are as thorough and reliable as possible. 

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Source: https://www.guru99.com/back-box-vs-white-box-testing.html

This week’s reading is about the differences between black-box and white-box testing. For starters, it states that in black-box testing, the tester does not have any information about what goes on inside the software. So, it mainly focuses on tests from outside or on the level of the end-user. In comparison, white box testing allows the tester to check within the software. They will have access to the code, in this case, another name for white-box testing is code-based testing. In this article, the differences in each type of test is listed in a table format. Let it be known, that the bases of testing, usage, automation, objective and many other categories will be different. For example, black-box testing is stated to be ideal for testing like system testing and acceptance testing. While white-box is much more suited for unit-testing and integration testing. The many advantages and disadvantages of each method are clearly defined and provides a clear consensus on how each method will pan out.

What I found useful about this article is the clear and concise language it uses for describing each category for each category. Unlike other articles I’ve come across about the topic, they beat around the bush and make it difficult to discern the importance of each type of testing. Many of the information provided by this article can be supported by activities done in class. One of the categories labeled time labeled black-box testing as less exhaustive and time-consuming, while white-box is the very opposite. I somewhat agree with this description as with white-box testing, you will have much more information to work with. Every detail of code can in some way be processed into a test as deemed necessary. The overall quality of the code as stated, is being checked during this test. While in black-box testing, the main objective is to test the functionality, which means it’s not as extensive of a test in general. Also, what struck as interesting was the category Granularity. With a single google search, yielded the meaning “the scale or level of detail present in a set of data”. Low for black-box and high for white-box, which rings true for both tests. In conclusion, this article reinforces prior knowledge on the differences between black-box and white-box testing.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

For this week’s blog post I found a blog that shows you how to reproduce a bug in your application. Why is this important? Well if you see something wrong in your application but cannot reproduce it this blog may help you with it. An obvious but important step to undertake is to simply gather information, and as much of it’s you possible can about the circumstances of the issue you are looking for.  Retracing the steps just before the bug appeared is a good way to do this the same goes if someone else reports the bug. Pertaining to another person reporting the bug is it a different operating system their using? A different browser or a different browser version? Again, obvious questions to some but to others they might not think about it. Keeping track of what changes, you have made trying to reproduce the bug is very important, knowing what you’ve tried and haven’t is crucial. I know this is something I would probably not keep track of which would cause me a lot of frustration. Going off of this using logs and developer tools are extremely helpful in providing a sense of direction in the behind the scenes of the application. If using a browser, especially chrome, you can simply go to the top right and find all the developer tools by clicking the three-dot menu. The blog then lists numerous factors to consider when trying to reproduce a bug, here I will discuss a few. Going back to the user end of bug, did the user not have the correct permission or a specific permission level? If so, you may be dealing with a bug that is only seen on an administrator level or by a certain type of customer. Authentication may be something to take into factor if the user cannot log or such. what is the state of the data that the user has? Can you reproduce the state exactly? The bug may only appear when a user has a very long last name or a particular type of image file. Another simple factor is configuration-based issues. Something in the application may not be set up properly. For example, a user who isn’t getting an email notification might not be getting it due to email functionality being turned of for their account. Checking all of the configurable settings in the application and trying to reproduce the issue with exactly the same configuration is the best way to check for this. Another issue some may not think about are the race conditions. The best way to determine if there is a race condition is to run your tests several times and document the inconsistent behavior. Clicking on buttons or links before a page has loaded in order to speed the input up or throttling the internet connection to slow the input down are good ideas for this. The last one they list is a simple machine or device based issue. This is probably the most common one that we face in all honestly, we’ve come across it a few times this semester even between Mac and Windows. Essentially something is working on Mac then is transferred over to a Windows device and does not work since it was originally made for a Mac and didn’t consider something small that windows does not have and more. After reproducing the bug you want to narrow the steps down to make it as efficient as possible making it easier for either you or the developer to fix in the code in the future.

All and all I thought this blog was actually pretty helpful at explaining steps on how to reproduce bugs and to help find them and make your testing process a bit smoother..

http://thethinkingtester.blogspot.com/2018/12/how-to-reproduce-bug.html

From the blog CS@Worcester – Matt's Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

As I take another step towards my journey in software C.D.A. I dive into an Introduction on Angular Schematics. This weeks blog I will be summarizing the blog “Schematics – An Introduction” by Hans.

This blog gives an introduction to Schematics and what it is. It list the goals of using a Schematic design. It shares how to understand schematics and how to create your first schematic. It tells you about the Schematics Collection and how to use it. Where it goes over the files such as Rules and Trees.

• “ARuleis a function that takes a Tree and returns another Tree"
• “A Tree contains the files that your schematics should be applied on”

The blog also shows you how to run your new Schematics. It also mention that when in debug mode you will not be able to create a file to the file system because “schematics tool is in debug mode when using a path as the collection it should use”, but also “the default is also to run in dry run mode, which prevents the tool from actually creating files.” that can be changed by changing the default argument. The blog has an example on how to do so. It then explains that a great advantage of Schematics is that calling another schematic is very easy and having them compose together is just as easy as well. It also mention that “the best usage of Schematics for your users is currently through the Angular CLI.”

This is a well written blog that gave good examples that are understandable and on point. I found the idea of schematics very interesting and also useful because it is capable of creating new component or updating code in order to fix and break dependency. It also provides ease of use and development when working with web application in particularly Angular. This has made me consider using Schematic since it is very beneficial to do so. This blog has thought me a new topic not really covered in class. I can honestly say that there is not a single thing I disagree on with the blog. For more on the blog and its example check it out by just clicking on the title of the blog, it will link you to it. Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

As I take another step towards Software Quality Assurance Testing. I dive into Angular schematics for unit testing. The blog that I read that covers this topic was “Angular Schematics: Unit Testing by Jonathan Campos. This blog covers the basic of unit testing code, mimicking an application environment, adding a test, asserting on files created, and asserting on content created. All in order to discuss and show the methods of creating a unit test for an Angular Schematics. This is a well written blog that gave good examples that are understandable and on point. The blog has thought me that angular projects should and can be tested. Which would be something I will be practicing on any of my future angular project. In the following paragraph I will briefly summarize what was cover in the blog excluding the examples.

The basic unit testing code is just explaining the basic of unit testing, and it being the starting point step. It then goes on and shows an example of how a file should look like when the schematics generator generates it. That file does not do much it just “run the schematic in a silo and asserts that the output is an empty file tree”.  It goes on to explain that to test your code accurately you must go further more by mimicking the application environment. This is done by adding more to the unit test so it can reflect the actual environment where the code will be running. To do this some of the Angular Schematics must be run in order “to build up the Angular project workplace”. This can be done by adding code to the Angular Schematics that specifies the set option it should run with. But before anything is run an application file tree must be created. That way before each test the code will run and create the Angular project workspace. Once that is done you can add test to the testing environment. The blogger gives example of what happens in the test by creating three different testing scenario. First he test that there was any error thrown because in that test he is testing a Schematic being ran without an Angular project tree setup. Second he is testing what happens when a Schematic is ran without the required parameters. Third he is testing that everything is setup properly. Once the test were ready the next step was asserting the test for specific values that would be for either asserting on files created or asserting on content created. He goes on and explain a little more in the blog and provides examples.

For more on the blog and its example check it out by just clicking on the title of the blog, it will link you to it. Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.