In her post A Gentle Introduction to Version Control, Julie Meloni gives a very easy to ready walk through of version control. Version control is all about maintaining the versions and revisions of your work as you are developing it. With good documentation, you can bring back old code you previously removed, or look at issues you had in your program in the past to see if that might be relevant to current issues. There are a lot of benefits to maintaining good version control.

Version control can also be useful in a classroom setting. I can recall multiple assignments this year where we used multiple commits with different labels for different assignment levels. In this way, the instructor could look at code from an earlier part of the assignment even when it had to be modified for a later part of the assignment.

Good version control also leaves you with backups if you want to revert to an earlier version of your program. Say you accidentally release an update with a major bug that slips through, you can quickly revert to an earlier version so you can fix whatever issues there are. You can use branches when you want to split off development into different directions and move the changes to main part of your program once you are satisfied, and you can use version control to help avoid any situations where there are conflicting commits.

I agree with Julie when she points out that version control has use in most business and private settings. Really, keeping good documentation of revisions of all documents can help organize your projects and keep them easily modified and reverted. For instance, if you are keeping a financial spreadsheet, but want to save it every month so you can track the differences over time, it is essential to use good version control to keep track of the revisions to the document. Or if you make modifications to a contract, but want to maintain copies of the older versions for legal reasons. Really, good version control is just part of good organization and allowing yourself to work with all the tools at your disposal. You work hard, there is no reason to throw it away.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

For this weeks blog post I will be looking at an Antipattern known as Spaghetti Code from Source Makings site. Perhaps the most famous AntiPattern it has existed in one form or another since the advent of monogramming languages. Essentially Spaghetti Code is a very cluttered or messy design approach causing it to appear almost like spaghetti, all tangled up.

Nonobject oriented languages appear to be more susceptible to this, and this is more likely to occur to those who have yet to fully master advanced concepts involving object orientation. The general form of this spaghetti code appears in systems with very little software structure. “If developed using an object-oriented language the software may include a small number of objects that contain methods with very large implementations that invoke a single, multistage process flow. “.  On top of this object methods are invoked in a very predictable manner, with a negligible degree of dynamic interaction between any of the objects involved in the system. Causing the system to be very difficult to maintain or extend, allowing no opportunity to reuse the objects and modules in other similar systems. Spaghetti Code usually results in an inexperience with object oriented design technologies, similar to this no design prior to the implementation of the actual code. Another cause would be the result of developers working in isolation because of this their maybe ineffective code reviews.

A solution to this not so delicious mess would be through software refractoring (code clean up). This being an essential part of software development, allowing most efficient clean up. When the structure becomes “compromised” through the mess its support to extensions become more and more limited to the point of useless. Ideally code cleanup should be happening throughout the entire development process but that’s an ideal situation that not everyone (including myself) follow all the time. Doing so on an hourly or daily basis is a good start to this cleanup process.

If simple code clean up is not working what next? Stopping spaghetti code through prevention is usually the best way to resolve this matter. Before you start writing the code, have a plan of what you are designing and how to structure it. Commit to actively refractoring and improving spaghetti code whenever the code needs to be modified is an extremely useful to prevent it.

Essentially if you don’t want to have spaghetti and meatball code you need to think about the overall structure and a good idea of what you are going to be developing.

https://sourcemaking.com/antipatterns/spaghetti-code

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

Hello, again my dear readers!

It appears that this week I am very focused on the customer this week as this article I read particularly focuses on what the customer wants. The article is titled, “Figuring Out What They Expected“. When it references they, the article is referencing the customer. The person you are programming the program or application for. Anyway, let us get into the meat of this article.

The article starts out defining two things. The first is what the user model is. The user model is effectively, what the user is expecting and thinking when they use the program. It bundles everything they know about computers and all their preconceived notions about using them when they sit down and use your program. How do I use this program and what does it do for me, the user? This is the model you are aiming to nail. If no one uses a program, does the program really exist? The answer is yes but we aren’t here to talk about that. The next model is the program model. This is what the programmer programmed into the program on how it looks, works, and operates. The idea in establishing this is that the user model and program model want to be overlapping or ideally mirroring each other. Now there are two ways to do this. The first is to change the user model. Good luck with that one. People are stubborn, stuck in their ways, and how would you even accomplish that anyway? Write a manual on how to use your program? We all know no one reads manuals anymore (although to be honest people really should) and if your program is different from what the user is used to, the user is likely to just not use your program. There is almost always another way. This leaves the program model changing to match the user model. I mean, let us face it, it might suck but you can change your program to match what the user will expect. It may be a pain but if it means your program is used more and ultimately bought more, I think it is worth biting the bullet.

The next part of the article goes over how to actually find that user model. The article has a simple and elegant solution… ask them. Then after you implement them, grab a few people and ask them to test them. Not a large group of people now. Only about 5 or 6 is required; after that, any more tests are fairly repetitive and not that useful. In the end, if the user has to guess how the program works, the program model is not quite there yet.

This article has reinforced my view that in this industry, the end user or customer is the ultimate determinant for a program or application. After all, we are programming an application for someone to use. If they can’t use it, its no good to them. I will admit, I’m surprised that only 5 or 6 people for usability testing are the norm. I do have a new appreciation for the Apple way of thinking where the simplest way to do something, is the way to do it.

Until next week readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

For this week’s blog, I chose to read the Test Scenario VS Test Case from the softwaretestinghelp website.

Test Case – a concept which provides detailed information on what to test, steps to be taken and what the expected result would be. It is more about documenting details. It’s important when testing is in another place than the development team. Easier to get the devs and QA team in sync. There is only a one-time documentation of all the test cases and can be easily tracked in the future. Test cases are also helpful to when reporting bugs. Testers have the reference to the case ID’s and do not require mentioning every detail of the case. It is also helpful to new testers since all the test are already laid out.  But it is time and money consuming as it requires more resources to detail everything.

Test Scenarios – a concept which provides a one-line information about what to test. It is more about thinking and discussions rather than listing everything. It is more important when you have a time constraint and most members understand what is happening.  It is better because it can save time and makes everybody think about what to test. A good test coverage can be achieved and it reduces repeatability.  But, if created by a specific reviewer or other users, they might not be in sync and cause confusions. This type of test also requires more discussion and team efforts.

I think this is a great read as it talks about the standard or old way of testing against the preferred testing by the new generation of software testing community. Test Case is the standard way of testing systems. While using a Test Scenario is new, it offers easier documentation when it comes to testing (assuming everybody understands what the system does). Although it seems like it is not beneficial since most companies change employees here and there, I can see test scenarios saving a lot of time just in the documentation. Learning about it opens up a lot of possibility in the way we think about testing but then again, there are already automated testing so test scenarios might not offer much in the future.

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

Good day my fellow readers!

As I have been learning all about software testing in class, the career of software tester has looked more and more like a job I would like to do. In my readings, I can across a blog post titled, “10 Qualities That Can Make You A  Good Tester.” I know hat you are thinking, “Ugh! Clickbait list articles.” but this one seemed relevant so I decided to have a read anyway.

The post starts off asking the question, ” What makes you think you are good at testing? Why do you qualify as a tester?” The author was saying that anyone with enough knowledge can test a program. It falls to different qualities of the tester that truly make them a good tester.

The first quality is that the tester understands priorities. What should be tested, what should be automated, what requires manual testing, what should be done first, ect. You are given a thing(s) to test and you have a limited amount of time to test them. Prioritization is a must.

Next, the tester should ask questions. The questions go farther than just, “What is my goal?” They must deeper like what changed, what was fixed, what is the product used for, or who will use it. The more understanding a tester has, the better they can do their testing.

The tester must be able to create a number of ideas. There isn’t just one way to test one thing and one product may be used in different ways. Simply put, more ideas = better testing.

The tester must be able to analyze data. Not knowing what data you get back means you are missing a big part of your testing as much of automated testing is reading and understanding data.

The tester must be able to report negative things in a positive light and be good at reporting. These are technically two points but they are practically the same thing. Reporting something in a positive way, even if negative, is a great way to build solid communication and improve teamwork. This plays into good reporting. People want to hear straight and to the point reports that get the point across and all the important parts. No one wants to sit there and read a list of negatives for minutes on end.

A tester must be able to support the developer. This goes beyond just finding a bug for example. A developer can’t fix a bug if they are having a hard time even recreating it.

The tester can co-relate real-time scenarios to testing. This sounds like a lot but it really boils down to A.B.T. Always Be Testing. Almost like improve testing. If you constantly test thing in your life outside the office, it can give you ideas to test things inside the office.

A tester must be a constant learner. Like the rest of the programming industry, nothing stands still and you shouldn’t either. Learn new technology, new tools, and new ideas.

The last trait is the tester must be able to wear the end user’s shoes. The ultimate goal of the product is to send it to the end user. If the tester can’t understand the end user, the end user will most likely not be happy with what they get.

One big thing stands out to me after reading this list… the end user is everything. In just about every article I have read the end user will without a doubt make an appearance in one way or another. If I can’t get my head around what the end user wants, I will not last long as a tester. The co-relate real -time scenarios was an interesting one as I like most, probably leave work at the office and never take it home. This takes work and home and fuses them keeping the skill of idea generation at the forefront. What surprised me a bit was that the reporting skills were geared toward streamlined and quick reports. I had expected reports in the testing world to be longer and more technical. This may just be the writer’s individual experience but it does make sense to me. The people testers report to literally made the thing they tested. They probably don’t need a nitty-gritty teardown.

Now I have some things to work on as a programmer before I graduate. They don’t seem hard thankfully, just something that requires a lot of time.

Until next time readers, have a good day!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

In this simple and straightforward guide of “5 Basic REST API Design Guidelines” . This guide shows 5 basic design guidelines that make a RESTful API robust and strong, it is key factor for API success. Each REST API design are different depend on what are the principles it for. The 5 basic design guidelines that make a RESTful API are Resources (URIs), HTTP methods, HTTP headers, Query parameters, Status Codes.

First is Resources (URIs), although we think naming is easy, but every have rule and constant. REST API unlike we use action verbs for other computer coding, RESTful use concrete names. URI case is naming resources in a program, there are 3 main types of case conventions. CamelCase has been popularized by the Java language, the main drawback is to be ineffective in contexts which are not case sensitive. snake_case has been widely used for years by C programmers, and more recently in Ruby. spinal-case is a variant of snake case which uses hyphens “-” to separate words. URLs are “case sensitive”, because of this reason it is recommended to use spinal-case.

One of the key objectives of the REST approach is using HTTP methods as an application protocol in order to avoid shaping a homemade API. use HTTP verbs to describe what actions are performed on the resources and facilitate the developer’s work handling recurrent CRUD operations. There are 4 main methods: the GET method is used to retrieve information from the given server using a given URI, a POST request is used to send data to the server, PUT method is to replaces all current representations of the target resource with the uploaded content, and DELETE is to removes all current representations of the target resource given by a URI.

HTTP header fields provide required information about the request or response, or about the object sent in the message body and query parameters which have 4 types paging, filtering, sorting and search.

Last is status codes, it is very important that make use of the proper HTTP. There are a lot of status codes, but the common use such as 200 – Everything worked, 404 – NOT FOUND – There is no resource behind the URI…

Resource modeling requires a careful consideration based on the business needs, technical considerations and cost-benefit. I thought this guide are simple and easy to follow. REST API should be simple and work as it intended to.

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

I have heard the term “agile testing” thrown around many times in my classes and other conversations about software development, but I’ve never really known about what it means. When I was writing my blog post about the Scrum process (post found here: https://kathleenmlaw.com/2018/12/03/scrum-isnt-an-acronym-but-what-does-it-mean/), the term came up as well. Obviously, it’s pretty clear that agile testing is very important to software development. I did some reading about what agile testing entails, and found a couple of links which helped me understand more about its significance: https://www.tutorialspoint.com/software_testing_dictionary/agile_testing.htm and https://reqtest.com/testing-blog/agile-testing-principles-methods-advantages/.

Essentially, agile testing is an iterative process of collaborating between end users, the development team, and the testing team. Project development is based on the needs of the customer or the testers. Agile testing is a continuous process which begins at the start of a project or project sprint and remains throughout the course of project development, rather than just happening once as a “testing phase.” This makes the agile testing process more unstructured. Because testing occurs throughout the entire project, rather than just at the end, any errors that come up during development can be fixed at any time.

The amount of communication between all parties is also very high, with testers and developers working closely together to come up with project solutions that fit not only customer specifications, but also testing requirements. Because all parties (including the developers and end users) test the product along with the testers, there is decreased time waiting for feedback and ongoing discussions about how the project is going. Most importantly, every member is on the same page with each step of development.

There are several methods of agile testing that can be utilized during the agile development process: Behavior Driven Development (BDD), where development and testing is based on desired behavior of the program; Test Driven Development (TDD), where the tests to be passed drive the development process, and exploratory testing, where testers explore the program to be tested and then write tests based on what they find.

Here is more information on BDD and TDD, respectively: https://kathleenmlaw.com/2018/10/05/what-is-behavior-driven-development/ and https://kathleenmlaw.com/2018/10/12/more-about-test-driven-development/.

Some of the many advantages of implementing an agile testing environment include the incorporation of all members in the development process, the regular and consistent feedback received from all parties, and the flexibility that comes with continuous, synchronous work on development and testing.

I definitely feel more in-the-know now that I have done more reading about what agile development and testing entail. Now that I’m almost done with my undergraduate career, I’m excited to put these new skills to action in the workplace.

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.

Throughout the semester, we have been learning a lot about good coding practice, which includes the implementation of various software design patterns. While we can try our best to fit our code into these design patterns, oftentimes this is not the case, at least for me. So, here is a list of several software design “anti-patterns,” or bad-practice patterns. My good pal James Blash (found at www.jwblash.com) gave me the idea to look more at these anti-patterns. The link that he recommended is https://sourcemaking.com/antipatterns/software-development-antipatterns.

This list has several great examples of different ways that code falls into more of bad practice. Here is a brief overview of some of the interesting design pattern problems that I found from this list.

• Cut-And-Paste Programming – This anti-pattern involves the reuse of existing source code, rather than programming new code from scratch. This can result in multiple errors of similar nature, as errors from the existing code can affect the rest of the program when pasted elsewhere. A fix to this problem utilizes more of a black-box reuse development process, such that the issue of reusing buggy code is more likely to be bypassed.
• Input Kludge – This anti-pattern occurs when behavioral testing fails because software accepting free text input uses “ad hoc” algorithms, which does not account for illegal statements or combinations of characters (e.g. strings when the input only accepts numbers, etc.). Solutions include the use of free parsing software or simply examining and possibly revising the algorithms to account for and properly handle “input kludge” being entered into the system.
• Golden Hammer – This anti-pattern occurs when developers use sort of a “one-size-fits-all” approach to coding; in other words, they take advantage of one or a couple of solutions to attempt to solve all other issues in their programs. A solution to this problem involves further education or training for team members to learn more about other ways to solve problems that arise, rather than just sticking to one familiar concept.
• Poltergeist – This anti-pattern uses poltergeists, or classes with very limited use throughout the program, but can potentially break the whole system when it isn’t there. Often, poltergeist classes start other processes taking place in the program. The solution reorganizes the class structure such that longer-lived objects in the program take on the responsibilities that the poltergeist(s) handled, thus removing the need for the poltergeist classes altogether.

Hopefully with this new information in mind, I hope to try to avoid some of these issues later in my classes, as well as my career!

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.

In class, we have started to look at mocking and how to implement this technique in our unit testing. I was pretty confused about how mocking worked, so I wanted to do more research on it this week. This  link has simple explanations of the premise of mocking, as well as other short, yet effective, examples of mocking: https://javacodehouse.com/blog/mockito-tutorial/ .

So what is mocking? In unit testing, we evaluate the functions of different classes and methods within those classes. These methods depend on outside classes, or dependencies, in order to function properly.

But what if the code for those other classes isn’t completed yet? Or, what if there are errors lodged in our dependencies, causing our methods being tested to fail? We still want to ensure that our methods are working properly, without depending on other classes’ behavior.

Mocking can be implemented here. Mocking simulates these dependencies to keep our tested methods independent. As shown in the picture below, the mocks eliminate the need for other classes or dependencies coming from outside of the methods that we want tested.

Image from https://medium.com/@piraveenaparalogarajah/what-is-mocking-in-testing-d4b0f2dbe20a

There are several mocking frameworks out there, including Mockito and PowerMock. We used Mockito in class, so I will be going over that framework more in this post, even though both have the same function.

First, we need to initialize our mocks. Our class did this differently than what is explained in this article, which shows the annotation @Mock for the classes that we want mocked at the beginning of the unit testing, and then using the following statement in our setup: MockitoAnnotations.initMocks(this).

Now that this is set up, we can start performing our testing! Two functions that we used extensively are the “when” “then” pattern, and the “verify” method. The “when” part of the “when-then” pattern passes in a function that requires use of the mocked class and returns a “stub” of the type to be returned from our mocked method. “Then” shows what is expected to be returned after completing our mocked method. “Then” methods can include “thenReturn(returnValue)” or “thenThrow(exceptions)” for different outcomes from the mocked method.

The “verify” method comes in handy when testing void methods. Because we aren’t returning anything, “verify” lets us examine, for example, if the void method is only being called once, that the correct method is being called, or that other void methods are being called instead of the one we want.

Reading this article was really eye-opening into the many different ways that mocking and Mockito can come into play, and I hope to work more hands-on with it in the future to learn even more about how it works.

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.