Software Quality

The podcast that I listened to this week is of course again by Test Talks which is hosted by Joe Colantonio. This podcast is a more recent one that talks about software quality and the state of it in 2018. As software is getting more and more powerful and popular, it is important to try to make it the best quality software it can be so it does not ruin your project or even worse, a business. Joe talks to Shailesh Rao, who is the the current COO of BrowserStick. The first thing Rao notes as importance is comparing your software toa stress free life. It is the ultimate goal, but it is always worked on. Having a bug-free software takes time and you might always be working on it, but it’s the always working on it that is of key. Trying to make it work to your utmost ability is a great goal to have in mind and will help you in the long run. He also stresses the importance of quality itself, not just in coding, but the quality behind hiring someone, and the culture you create. He then goes on to talk about automated testing becoming more and more crucial and seeing it as a means to an end. Only about 20-30 percent of companies are using it, and while many do not use it, there is no lack of intent there and the numbers are growing. The last thing he mentions is a piece of advice which is that discipline is key. Everyone is going through the same struggle and its important to know that. Apply that discipline and don’t give it.
What I really liked about this podcast was that it talked about something that is going on now and what is important right now. It’s really cool to know how popular software quality and automated testing is becoming. It helps me know what companies will want you to know and what you should be good at. After I graduate, of course it will be important for me to know the basis of coding, and to know the most popular languages like java and c, but technology is always changing and I need to be right there soaking everything in, so I can be at my utmost prepared self.

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.

Testing Efficacy and Machine Learning

As stated in the title of this post, this week’s Software Testing topic of discussion relates to the hand-in-hand incorporation of software testing and machine learning, found at the following blog post: https://testing.googleblog.com/2018/09/efficacy-presubmit.html. Google has been taking on automated testing of their code before permanently committing to their huge repository. By doing so, they have examined “Efficacy Presubmit,” which uses the idea of automatically predicting which tests would be best appropriate to run, as well as learning about which tests are more useful or valuable than others in terms of discovering critical issues in code. Tests that are more guaranteed to pass every time are less meaningful than those that come up with failures. This process of discovering the more valuable tests would certainly assist with optimizing time and resources spent to run tests. To do this, Google applied a machine learning concept, binary classification, to “learn” whether a test would or would not pass (a binary outcome), using the numerical data given from running software tests, such as pass/failure history and runtime for tests. By predicting the outcomes ahead of time, testers can understand which tests are more likely to keep passing every time or produce more failures.

I was really interested in learning more about the software development process at Google. Many of my CS friends discuss how awesome it would be to work at Google, Microsoft, or Facebook, among other giant companies dominating the field of software development. Reading more about how developers at Google undergo the cycle of writing and testing their code (with multiple iterations before and after committing, as to be expected) increased my confidence that even within the first few weeks of my software testing course, our course content lines up with what Google (and other companies I’m sure) is doing. I also enjoyed learning about how machine learning can be applied to software testing. I had only thought of the two concepts in a mutually exclusive fashion, but the description of the data used for the classification of the tests (like the runtimes for tests) gave me perspective of how various concepts in computer science can work together to solve problems.

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.

Given-When-Then

GivenWhenThen

Blogger Martin Fowler in his self titled blog describes a template for organizing unit tests, called “Given, When, Then”. This concept is perhaps a rephrasing of what we discussed in class, the four phase test, or “Setup, Exercise, Verify, (teardown)”. The idea is to structure our test cases in a logical, easy to understand process.

Fowler describes the idea as “essential to breaking down writing a scenario (or test) into three sections”. Given a specification, any situation we need to test for can be broken down into these three steps. The first section is “given”, or the “setup”. During this phase of the test, we would create variables and set up the preconditions to a test. Fowler uses a scenario of trading stock to illustrate his point. “Given” a certain amount of stock to invest (precondition) move on to the next phase.

The next step in the model is the “when” phase. During this phase of testing, we are choosing the behavior of a function to be tested. In Fowler’s stock trading example, this translates to “Given: x amount of stock to sell- When: I want to sell y stock”.  This phase essentially defines the behavior of the test we are writing.

Last but not least, the “then” phase is all about putting the first two cases together and verifying them. Following Fowler’s stock example, the “then” phase is represented as “Given: x amount of stock to sell – When: I want to sell y stock – Then: I should have x-y stock”. This phase is where you verify the expected behavior to the actual behavior of the program.

Personally I find this model particularly helpful, in the sense that it provides a useful narrative for breaking down testing situations. To me the “given-when-then” model seems more intuitive than “arrange, act, assert” or “Setup, exercise, verify”. While all three models definitely describe the same process, I think that this model is the most clear. In any case, breaking down test scenarios into discrete parts like this is integral to creating clear, easy to understand tests.

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

Mutation Testing

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: Mutation Testing. This blog will share my analysis of Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial.  I will be expressing my reaction to the content by sharing what I find useful and interesting and displaying if I have any concerns or disagreements. Without any further introduction, let’s begin.

First, let’s start with defining what mutation testing is. Mutation testing is a testing technique that uses the structure of the code to conduct the testing process. It is simply the rewriting of code in small ways in order to take out the excessiveness in the code. This wordiness may cause failures in the software if it is not altered. It is very sneaky because it can pass through the testing process’ unnoticed.

There are three types of mutation testing: value, decision, and statement mutations. Value mutations are efforts to change the values to display errors in the programs. The change of the value is usually to either a very large value or a very small value. It is found that the most common strategy to combat this is to change the constants. Decision mutations are when the code is changed to check for errors in the design. Ways to fix these errors are by changing the arithmetic operators to find the failures or by altering the relational and logical operators. Statement mutations are when changes are done to the statements by deleting or rewriting the line.

Mutation testing is based on two theorems. The first is the competent programmer theorem. This theorem explains that most software errors made by experienced programmers are due to small syntax errors. The second theory is called the coupling effect. The coupling effect says that simple errors can couple to form other faults.

All in all, mutation testing is a fairly simple technique that is used when testing code. Sometimes errors or faults can be hidden when making tests that will cause the source code to fail. Mutation testing is the process of altering these subtle errors in efforts to run the code.  This topic is extremely important to this field because it gives us a deeper understanding of our errors, which helps greatly when correcting “bad” code.

Source: Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial

 

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

The Simple Factory – Easy as Cake?

Using the Simple Factory design pattern is a lot like making cheesecake

Software developer Sihui Huang, writing for the blog freeCodeCamp, explains the simple factory design pattern in terms that most people can appreciate – cheesecake.

Huang walks us through the basic steps in a simple factory for creating cheesecake. Starting with a number of his favorite types, he creates a makeCheeseCake() method which calls cheesecake.makeCrust, cheesecake.AddLayers, etc. The makeCheeseCake() method uses the type of cheesecake as a parameter, and calls the the steps to creating a cheesecake that all different types have in common. No matter what kind of cheesecake you are making, you still need to make the crust. So the makeCheeseCake() method is only concerned about the steps required in making any kind of cheesecake, it doesn’t care about what flavor the particular instance is. Huang describes this concept, as we have in class, as encapsulating what varies.

So Huang goes on to create a cheesecake factory class that handles all the different classes of cheesecake we can possibly create, and returns the appropriate cheesecake type by a createCheeseCake() method inside the factory class. The trick is that when you call the makeCheeseCake(), a new cheeseCakeFactory object is created, and uses the createCheeseCake method to determine what type the cheesecake is. So now the MakeCheeseCake() method does not need to know at all about what kind of cheesecake it is creating.

By separating the parts of a program that stay the same from those that vary, we can simplify adding and modifying different types of an object (in this case cheesecake) by adding a new class and adding to the cheeseCakeFactory class. No code has to be rewritten to accommodate for changes and removals of types of cheesecake.

Personally I enjoy Huang’s analogy to elaborate on the simple factory design pattern. Being able to separate varying parts of a program from parts that never change makes our code more understandable, coherent, and easy to modify. And the idea that a “factory” can handle the details of initializing different types of objects instead of having separate implementations for every object type is good design, and I think the cheesecake factory example is a good metaphor for encapsulation

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

The Differences Between Black Box, White Box, and Gray Box Testing

For this week’s blog post, I chose this blog by Lucie Saunois. It talks about the differences between Black box, Grey box, and White box testing for software or applications.

Black Box Testing

Black box testing reviews only the functionalities of an application. Testers do not really know the internal structure of the application. Testers typically have a “user” profile. This method aims at checking if the final stage of the application works like its supposed to. Common things the tester would look for in a Black box testing are missing or incorrect functions, interface, performance, program initialization, and external database access errors. To do this test, each different user has their own scenario to test, and all functionalities must be tested.

White Box Testing

White box testing reviews the functionalities of an application as well as its internal structure.  All of the internal components of the application are tested through the source code. Testers have a “developer” profile and not a “user” profile unlike in Black box testing. White box testers need to have competence in programming since they need to understand the source code. It is mostly done in the developing stage of the application. Therefore, it allows them to test the data flow and the handling of exceptions and errors. Scenarios for this test are created by the testers based on the source code. Testers only check if the code produces the expected results.

Gray Box Testing

Gray box testing is a compilation of both Black and White box testing. Gray box testing tests both the functionalities and the function of an application. In this test, the testers know the functionalities and also the internal structure of the application, however, they do not have access to the source code.

 

This blog explaining the differences between each kind of testing is really easy to follow. The way they were describe was easy to understand. She also wrote about their benefits and drawbacks of each method of testing. I really find her examples interesting towards the end of the blog where she uses an analogy by comparing it to testing a car system. I think finding blogs like these would help anyone understand the different testing methods out there, it is simple but very informative.

 

 

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

Stick to the Plan Stan

               Coding is at its very core an art piece. If we think of coding as a work of art why is it that some people expect to sit down and code a “master piece” in one sitting without thinking about what they want to code. True art take meticulous planning; sketches, rough drafts, concept art, and experimenting are things that make paintings and art so perfect in their final form. What needs to be don’t to make a programmer an artist?

                Well with our recent focus on UML diagrams it got me thinking about a similar planning stage to coding like that of an artist. After all UML diagrams show code as an image and flow chart in an eye pleasing way. With a bit of research I found that a lot of coders, and teachers believe that planning before writing code is much more effective than just trying to get it done as you go. I stumbled upon Khan Academy which is a website that I have always respected and thought highly of. Anytime I have problems or questions with any subject Khan Academy was always my go to for information. When I saw that Khan Academy actually had a lesson plan for how to set up coding before writing any code I was intrigued. Turns out like their other lesson plans the steps were all set up clean and backed with reason to why this strategy works.

 

Khan Academy laid out these steps that I believe when thinking about your coding structure can really help:

1. What do you want to make?

2. What technology will you use?

3. What features will it include?

4. But what features must it include?

5. How will you implement it?

6. What’s your timeline?

                I believe planning is important to the success of your code. The examples that Khan Academy use look similar to a mock UML diagram. You come up with the function each class will need the variables, and don’t implement them, but rather conceptualize what your code should do. The author offers a sample of what the concept would look like. Disregarding abstract and interface classes the layout would be easy to transfer to a simple UML rough draft.

Objects

  • Brick (.isHit())
  • Paddle (.move())
  • Ball (.move())

Scenes

  • Start
  • Game
  • End

Logic

  • Ball-brick collision (function, use bounding box)
  • Paddle-ball angling (function, invert angle)

User interaction

  • Keyboard-paddle movement (keyPressed)
  • Buttons for scene changes (mouseClicked)

User data

  • Ball deaths (array)
  • Ball hits (array)

In the end I think the information we are learning about UML Diagrams, and keeping neat and organized work flows is vital to thinking about planning out your code. Create a plan and stick to it Stan.

 

-Computing Finn

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

Qualities that Make a Good Tester

Everyone want to be good at their job. But what’s make they good at it, especially in software tester. I came on a list “10 Qualities that Can Make You a Good Tester” on a blog website. The blog points out 10 points of what make person is a good tester, though the rich experience in the industry by the author. Other than the obvious, tester make sure the code work correctly, there are more to it. Tester need to have the overall look on the project, why the code work and not work. What is the cause and how it effects the consumer and developer.
I thought understand priorities is very important. Tester usually have the list of tests to check, but they need to know which test is important and and plan to doing it. Ask question, to understand the overall picture, I learned that though my project at school. When we look at the code the setup by others, there will be questions on what they mean by it. Team player and good communication is great for tester, we always have connection to the developer and consumer. By understand problems easily, we can be more effective, save time and money. Positive attitude is also important, overall job of tester is to help others. This is not just applying to tester, but to overall everyone, though positive attitude we can make the production better overall. The last progress of tester usually is report, tester need to have detail and easy to understand on what the issue of the application. Think of the issue not just how it effects the project, that tester assign to, but on how it effects on the real-world application. From the point of view as end-user. This is good list on overall what make testers good. We need to keep these points in mind, in any computer career. It will help us on long term.

Link to article

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.

Your Interfaces Are Your Responsibility

This week, I looked through the Google Testing Blog and spotted a great post regarding your job as a programmer in writing good interfaces. I thought it touched on some great points and used some great examples, so here I am, writing about it. The blog post is part of a series of posts from Google called “Code Health”, which essentially outlines some of their standards for code quality.

“Code Health: Make Interfaces Hard to Misuse” uses an example of an empty Vector which has a “num_slots” slots available for use. Marek Kiszkis, the author, outlines two ways to write this class. The first way relies on the person who implements it to manage the expansion of the number of slots of the vector. They must check the slots remaining before adding into it to ensure that it has the room for a new item. The second way the Vector class is written has the Vector automatically expanding by a certain number of slots as items are added in. The implementer has very little control over the function of the Vector, however the Vector’s lack of flexibility can be a desirable outcome, as misuse much more difficult. The author provided a few different examples beyond this of easy-to-misuse Interfaces, such as requiring the caller to run initialization functions, perform cleanup, etc.

The article is finished off with a reminder that, while making interfaces this way is a good thing, you still need to be selective with this methodology. Sometimes writing an interface in a “overly-defensive” way will result in needlessly complex code, where implementation is more difficult to execute than necessary. The documentation is equally as important as the structure of the code, and keeping that in mind will help you write usable, stable, and effective code for others to utilize.

I found this blog post surprisingly relevant to my current course-load. In both this class (CS-443) and the Software Architecture & Design class (CS-343), will be implementing interfaces much more frequently than we have in previous courses. Having a better understanding of safe and effective ways to writing them will be extremely useful in the long run.

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

Blog 3 CS 443

My blog this week is about an article which talks about things that could possibly go wrong while discussing about testing and how someone could improve their testing. In the article, the author points out several flaws which many testers tend to make. Some of these mistakes testers make include things such as caring about how many tests there are instead of the quality of the tests, how many people have a hard time adapting to creating new tests as a test case evolves and when people believe there is only one way to test something.

I thought the author had a lot of good reasoning behind his thoughts on testers, which can be applied to more than just testers too. This applies especially to his first point which pertains to when people care more about the volume of test cases they have written versus the quality of those test cases. The author’s point, which I agree with, is that it does not matter how many test cases you write, if they do nothing to actually test the code, than they are completely useless. This thought also makes me want to pay more attention to the test’s that I write to make sure that they are effective and proper to what I am actually testing for. Another comment the author made which makes me want to look more at the way that I move through testing is that many people have a hard time adapting their tests as the strategy of said tests changes. Being able to change and adapt your tests as the test strategy changes shows a true understanding of the purpose of the testing that is happening. Finally the author brings up the point that people often have the thought that if they are testing something one way, they have tested that thing fully. However, if they run the same test with a different data set they could discover some new bug that you would not have seen before. This is another good example by the author of pointing out a flaw that many people can and tend to make, and one that I plan to focus more on myself.

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