Monthly Archives: December 2018

Choosing Testing Techniques

I recently landed upon this article, which is essentially an introduction into software testing. It gives a great overview of why different types of testing techniques are important, what different types aim to achieve, and the ins-and-outs of each.

The last section though is perhaps the most interesting, as I think it covers a topic that we haven’t discussed quite as much in our testing class (although my professor would probably beg to differ) — different reasons for choosing each type, and what may influence your choice.

In this article, the author mostly reflects on outside influences as opposed to outlining which technique to use to solve technical challenges best. I suspect this is because each technique has its pros and cons in each technical situation. Some influencing factors are:

  • The Type of System/Software App
  • Regulatory Standards
  • Customer Requirements
  • Type/Level of Risk
  • Test Objective
  • Tester’s Skill & Knowledge
  • Time and Budget
  • Development Life Cycle
  • Previous Testing Experience

By now, I’ve learned that different companies/teams will follow different testing paradigms (usually they’ll implement several of them, to be more accurate). There doesn’t seem to be an industry standard, and I’ve heard that even things like code reviews aren’t necessarily used everywhere. What I find interesting about the points listed above is that it gives some insight into the reasoning and motivation behind why teams may choose different techniques to implement for their particular scenarios.

For example, some software systems may work better with static vs dynamic testing as their primary methodology, and some (although probably most) would prefer a decent blend of each. Obviously the time and budget for the development cycle of the app will influence how rigorous the testing process is, which will influence what specific techniques teams implement as well.

Another interesting point I felt the article made was that the customer may actually have a preference for how they want their product to be tested. I think this was an interesting point because, while a customer probably wouldn’t say “I want you to use more white-box testing”, their requirements may actually require the team to modify the tests that they had intended to use in indirect ways.

I felt as though this article was an interesting overview of different ideas in software testing, from the different types of testing, to the advantages and disadvantages of each, to the reason behind choosing which one may be best. This website, Test Automation Resources, seems to have a lot of interesting and easy-to-read testing articles. I’ll likely be reading more from it in the future!

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

The Structure of Angular Structural Directives

As I mentioned in a previous blog post, we have been working on a final project in our Software Design, Construction, and Architecture class, where we are constructing a single-page website that connects front-end and back-end components. I’ve been working on front-end elements most recently, and I got up close and personal with Angular structural directives (after debugging my code for almost 2 days). This link was my main reference when trying to fix my code: https://angular.io/guide/structural-directives.

Structural directives, like the name suggests, alter the structure of the HTML layout by changing individual elements in the document. The directive is simply added to the tag of the element to be altered, called the host element. Any descendants of this element will also be affected by the directive. For example, a tag with an ngIf directive would look something like: <div *ngIf=”true”>Hello there! (I didn’t add the ending div tag because this makes the whole tag disappear upon publishing this post)

There are three common directives used in HTML: ngIf, ngFor, and ngSwitch. ngIf takes in a Boolean expression as a string and displays the host element if the expression is true. For example, if the example tag from above was present in a document, the element would still display, and “Hello there!” would be visible.

ngFor is used as a repeater directive, where items in a list or array can be displayed by iteration, or a statement can be shown a certain number of times depending on however many iterations. The loop takes on Python syntax when expressed as a String for the ngFor directive. An example of ngFor would be: <p *ngFor = “let name of names”> This is a name.</p> The loop would iterate the same number of times as the number of names present in the list, and the statement would be displayed that many times as well.

Finally, ngSwitch operates like the switch statement in Java, where one variable’s value is checked, and depending on the value of that variable, one case will be executed, which is an element defined with that variable’s desired value. For example, if you’re trying to look up profiles for different users of a social media website, ngSwitch would work along the following lines: a profile variable would be set to whichever profile name you’d like to look at, and depending on the value you chose, that appropriate profile page would display.

This article was incredibly helpful for me to figure out how to conditionally display some of the elements on my webpage, and I am certain that I will use it later on for further reference!

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

Importance of Quality Assurance

For this week’s software quality assurance Blog, I would like to revisit software testing as a career, because it is something that I am interested in pursuing. I found an article, “Software testing is big business,” from a South African website, “itweb.co.za”.
In the article, it stresses the importance of quality assurance in software. I think I have said here in this blog how fickle customers can be with software that is buggy and jump ship at the first chance if the code causes them even a slight inconvenience. If I have not said it here, I know I have read something similar before. The article repeats this sentiment, and it is probably something worth repeating. 
The article continues and says that developers often rush to add new features, while leaving quality assurance as an afterthought. The article claims that when companies allocate resources properly, about one third of IT budgets are allocated to software quality assurance and testing.
The article says that often software testers are seen as “second-rate,” which should not be the case. I was talking to my dad about entering the field as a software tester. He is a software developer, and he said something interesting that a colleague told him. He asked a coworker of his why he decided to stay a QE (Quality Engineer) when he had a lot of opportunities to be a developer. The answer surprised him, and I thought it was a good mindset that I might think about when I enter the field.
The QE said that a developer will usually work on one project at a time, and won’t be able to influence what other developers working on other projects are doing. A QE, on the other hand, will be able to influence everyone’s work. He has his finger in many, many pies.
I am more resolved to get into quality assurance the more that I learn about it. It doesn’t necessarily have to be something I do forever if I find I don’t enjoy it. I’m sure it would be easy enough to switch tracks.
I once heard some advice that when you don’t know where you want to go, a step in any direction is a step in the right direction. It is better that than being so paralyzed to make no choice. I felt this way when I had to declare my concentration, and again before that when I had to declare my major. In the same way, if an opportunity presents itself to start a career in quality assurance, I would like to jump at the chance.
https://www.itweb.co.za/content/KrxP3jqBkXkvA2ye

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

Differences between the different levels of tests

In these 443 blogs post I am going to write about the differences between the different levels of tests. There are four basic levels of tests which are unit/component testing, integration testing, system testing, and acceptance testing. Unit testing when you separate each part of the program and test them individually and confirm that they perform what they were design to do. This is usually done in the beginning of the development and usually done by the developer first than hand over to the testing team. Integration testing is when you break the program into combinations and test if they actually work together. This exposes any flaws that show if the components don’t work together or not. There are many ways this can be tested, bottom up or top bottom. System testing is one of the higher levels of testing. It’s when you test the whole program to ensure that it all work properly and meets the requirements. This is one of the most important steps before deploying the product and it confirm that the product is almost ready to ship. This can be tested in an area where user can test the product. This usually done when a special testing team to see if the product fulfills its requirements for the business. Acceptance testing is involving a lot of user end. Acceptance testing test whether the system complies with the user end. This step is to find out many different problems that can occur like bugs that can harm the product in anyway. During this step you can find out if the program will be installed or not into the user’s system. Every single of these testing levels is important and testing early to avoid error in the future and testing for often is well worth it. This important because finding and fixing errors near the finishing stage which be more difficult and more time consuming than finding them early. All in all, these four levels of tests are important, and I learned more about those four after reading this article. It changes the way I work because I know the importance of the levels and what to do in those levels.

https://reqtest.com/testing-blog/differences-between-the-different-levels-of-tests/

From the blog CS@Worcester – Phan&#039;s CS by phancs and used with permission of the author. All other rights reserved by the author.

Code Smells

Today I am doing another smells blog post but this one is going to about code instead of design. This article that I am doing it on contains many of the code smells and I will be being writing about some of the things I learned from them. First, code smells within codes:

Comments – I learned to remember that comments should be written for people, not the machines. I will also try to refactor my code as possible to avoid to comments for example better method names and cleaner code, so it would be easier to understand and follow.

Long Method – I learned that shorter method is better than longer method because it is easier to read, understand, and maintain. I will always try to minimize the size of my method as small as possible to be more efficient.

Long parameter list – I learned a great to limit the number of parameters by using a object to combine it if I actually need the values of the parameters because the more parameters there is, the more complex it is.

Duplicated Code – never have code that duplicated.

Conditional complexity – don’t have large conditional logic block, use design patterns to avoid this problem.

Combinatorial explosion – I learned that this is when we have lots of code perform the same operation but have a little difference. I think the best way to avoid this is to make a method for the operation.

Large class – if a class seem too large than you can break it into smaller class, so it can be easier to understand.

Large class – if a class seem too large than you can break it into smaller class, so it can be easier to understand.

Also, Code smells between classes:

Data class – I learned to avoid class that only data because a class should have data but should have method to manipulate the data.

Lazy class – this just means that every class should be important enough to be a class.

Shotgun surgery – this means that you should avoid making a class that effect other classed when making an update.

Solution Sprawl – this is when you have need multiple class to do one thing, it’s better off to simplify the code.

All in all, this article has All in all, this article has code smells and I learned a lot from them. I now know how to avoid these smells and how to deal with them after reading this.

https://blog.codinghorror.com/code-smells/

From the blog CS@Worcester – Phan&#039;s CS by phancs and used with permission of the author. All other rights reserved by the author.

What Causes Design Smells?

Hello, every and welcome to another blog post by Phan CS. Today topic is about to be about design smells. According to this article “design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality”.  Design smells affect the software quality and the organization in a negatively way. The organization will be affected because the presence of the smells in the framework will be used by clients and depending of the feed back which is usually going to be negative, the whole community is going to feel the same and it’s also hard to fix design in the API when the API is already in use. There are many causes of design smells. First, when a class has multiple responsibilities this would consider a violation of design principles which they named multifaceted abstraction smell because abstraction should be unique. They had an example of this problem in the article which explains that calendar class in the java.util package support date-related functionality which it is supposed to but also supports time-related functionality as well which is a violation of design principles. Second, inappropriate use of design patterns which is when programmers try to apply design pattern because they are pressure into using them by don’t fully understand how use them and this result of too many classes. Next, is language limitations, this when two methods that support different primitive types belong to the same class and its java does support primitive types which result in it’s impossible to remove duplicate code. Also, when programmers mistakenly think classes are doing things instead of being things, this can cause problems that can result in design smells. Finally, design smell is usually created when a programmer is in a rush and is hacking the code because it requires less time and effort to do it this way. When the environment is following practice usually other programmers will so the same. All in all, design smell should be avoided because it bad for product. I thought this was interesting in many ways. This change the way I code because I will be thinking about what I am doing more.

http://www.codeops.tech/blog/linkedin/what-causes-design-smells/

From the blog CS@Worcester – Phan&#039;s CS by phancs and used with permission of the author. All other rights reserved by the author.

Nailing Code Reviews

The article How to Conduct Effective Code Reviews by Billie Cleek covers code reviews, when to use them, and what your objectives and goals should be when working on or submitting a code review. He discuses the different roles you can take in a code review (which are almost analogous to our roles in two of my classes this semester) and what you should expect to do while in those roles in the process of a code review.

A code review is basically a conversation between developers on a proposed set of changes to a project. It can be a discussion about why a certain part of the code is the way it is, whether or not something is effective, or if certain changes need to be made and how to go about that. Code review boils down to having a constructive conversation regarding the development of your project, and what changes might need to be made.

I personally have had a lot of trouble communicating difficulties and voicing my opinion in past classes. It is hard to find your voice and be confident, stating the issues you see and opening yourself to feedback, however through code reviews everyone who participates stands to gain knowledge from their peers as well as experience in effectively communicating to your colleagues. As long as you are able to give and receive feedback in a helpful but constructive manner, you can help clean up a project, fixing errors and making it clear and understandable for viewers to read.

In a way, I feel like my software classes this year have done a lot of work in preparing me for being effective in code reviews, as well as in the workplace in general. A lot of the important skills in code reviews are just as important in group work: effective communication, making sure questions are answered, and mutually agreeing on the decisions being made are all essential to having an effective and useful code review. Building these skills in general will make you a better team member, and help you work better in a group on big projects.

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

Version Control: A Primer

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&#039;s Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Terminology – Error, Fault, Failure, Incident, Test, Test Case

Greetings reader!

In today’s blog,  I will discuss the differences between very important terminology in software testing: Error, Fault, Failure, Incident, Test, and Test Case. This blog will define each term and explain how they all correlate. Without any further introduction, let’s begin.

The differences between error, fault, failure, and incident are as follows:

An error is a human action that produces an incorrect result.  A fault is a flaw in a component or system that can cause the component or system to fail to perform its required function. A failure is a deviation of the software from its expected delivery or service. An Incident is an unplanned interruption. When the status of any activity turns from working to failed and causes the system to fail it is an incident. A problem can cause more than one incident which are to be resolved, preferably as soon as possible.

An error is something that a human does, we all make mistakes and when we do while developing software, it is known as an error. The result of an error being made is a fault.

When a system or piece of software does not perform the correct action, this is known as a failure. Failures are caused by faults in the software. Note that software system can contain faults but still never fail (this can occur if the faults are in those parts of the system that are never used). In other words, failure is the exposure of one or more faults.

A test is a process that evaluate the functions of a software application with an intent to find whether the developed software met the specified requirements or not and to identify the defects to ensure that the product is defect free in order to produce the quality product.

A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application.

All in all, these terms are pretty elementary, however they are all important in Software testing. These terms all coincide with each other and I hop this blog was able to explain them in short detail.

 

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

The Criticisms of Design Patterns

Design Patterns have grown to become a standard in the field of Software Development ever since the Gang of Four published their book, Design Patterns: Elements of Reusable Object-Oriented Software in 1994. However, some people in the field of Computer Science have leveled criticisms towards Design Patterns for a few reasons, even if it is widely accepted that they are tools in the belts of developers at this point.

A legitimate criticism of them seems to be that many of the patterns are heavily language dependent, as some languages have easier work arounds for problems that present themselves in others. Peter Norvig, a director of research at Google, showed that 16 of 23 patterns from the Design Patterns book can be replaced solely by implementing them in Lisp or Dylan rather than C++ (page 9 of this PDF). Part of the argument here is that if languages don’t have the same design patterns, then those languages that do have more design patterns are requiring that developers find work arounds for their missing features.

Another issue that many seem bring up is that the emphasis on using design patterns results in developers relying on them too heavily. Similar to the Golden Hammer AntiPattern, once a developer (or team of developers) becomes comfortable with a tool or concept they end up attempting to cram the problems they’re given into some implementation that would allow them to use the solution they’re comfortable with. In this way, even if Design Patterns are intended with the intention of writing code in good practice, if they’re implemented when it isn’t necessary it can quickly turn sour.

The idea behind Design Patterns is that, if they are used correctly alongside correct Object Oriented Design principles, the patterns should emerge naturally. If you ever find yourself asking, “How can I use the Singleton Pattern here?”, then you’re misusing the tool in your tool belt. They are better viewed as teaching methods for successfully upholding good design in complex situations, in a way. If you’re writing code and it dawns on you that what you’re attempting to write is similar to a pre-existing design pattern, then you have a direction to follow. This article in particular gives a great example of an application of the template pattern, and shows how you’d get there in a natural way as opposed to forcing a pattern on a piece of code. 

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