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.

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.