Category Archives: Week-14

A Review of Code Review

During one of our final Software Testing lectures last week, we were able to participate in a code review, examining and critiquing a given program. I really enjoyed taking part in this activity, because it helped me understand the program on a deeper level. After all, I wouldn’t really be able to spot any places to improve without first knowing what each line of the program was doing!

For this blog post I wanted to take a look at different code review strategies, as well as any advantages or disadvantages that may arise when using this method of software testing. I was reading these posts for more information: https://smartbear.com/learn/code-review/what-is-code-review/ and https://smartbear.com/blog/collaborate/pros-and-cons-of-code-review-methods-infographic/.

Code review is what it sounds like. Team members work together to review written code and notice areas of possible improvement. There are different ways to go about this process, each of which having their own unique advantages and consequences. The articles that I read listed 5 strategies, and they are described as follows:

  • The Email Thread – For this method, a file in need of reviewing is sent to every team member taking part in the code review. This can be helpful when it is difficult to find time in everyone’s schedules to meet. However, long email threads can get complicated for the developers to look through.
  • Pair Programming – For this method of programming, developers sit side-by-side and work on the same code together. This method is great to incorporate code review into the development process but may provide some bias due to emotional connections to the work put in.
  • Meeting-Based – For this method, smaller groups of reviewers meet with printouts of code or code on a projector. Then, they examine, line-by-line, any issues or problems with the program. While this is a very in-depth approach, this also takes a lot of time. Additionally, some development teams are stationed across the world from each other.
  • Over-the-Shoulder – This informal method simply entails another developer standing over the shoulder to the author of the program, as the author walks through each change to the code. This is great for in-person collaboration, but there aren’t really any standardized metrics involved in this method. There is also no traceability to the conversation later.
  • Tool-Assisted – This method involves an external tool (whether browser or IDE based) used by the team to successfully review code while also solving some of the issues above, like keeping track of online comments, noting any change in code, and enforcing any standardized metrics. However, some tools may be costly, or may not fit as easily into the workflow of the development team.

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.

A* Search Algorithm

Summary

In the article Introduction to A*, Amit goes over two graph traversal algorithms: Dijkstra’s Algorithm and Greedy Best-First-Search Algorithm, providing a great visualization of how these algorithms work as well as cases in which they excel and in which they struggle. A summary of his description of these algorithms are as follows:

  • Dijkstra’s Algorithm – guaranteed to find the shortest path from the starting point to the goal, longer run-time because it visits vertices continuously expanding outward from the starting point until it reaches the goal.
  • Greedy Best-First-Search Algorithm – works with an estimate (heuristic) of how far from the goal any vertex is, selecting the vertex closest to the goal. Not guaranteed to find the shortest path, but runs much quicker than Dijkstra’s Algorithm.

He then explains what the A* Algorithm is, taking advantage of the best of both of these algorithms. This is done by combining the pieces of information that Dijkstra’s Algorithm uses (favoring vertices that are close to the starting point) and information that Greedy Best-First-Search uses (favoring vertices that are close to the goal).

Reaction to Content

This article is the first part of a larger series by Amit about pathfinding, however I believe that reading this article alone is good enough for a quick overview about what the A* algorithm is as well as providing excellent visualizations for the three mentioned algorithms. These visualizations are definitely helpful for understanding how these algorithms work as well as what their potential advantages and downfalls are.

I chose this topic in particular because it’s an interesting part of a subject area that I have interest in (game programming) and also is an important topic in CS in general (graphs and graph traversal algorithms). It’s a useful refresher for some of the topics that I learned in my algorithms course. Also, seeing how a potential algorithm in a game could decide how to best traverse towards a goal taking into account any obstacles in the way is interesting think about.

I think the rest of the series would likely be a good read to get a deeper insight into the A* algorithm.

 

Source: http://theory.stanford.edu/~amitp/GameProgramming/AStarComparison.html

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

Design Patterns: Iterator

I’ve been discussing AntiPatterns quite a bit lately, so I elected to switch it up and talk a bit about Anti-AntiPatterns, aka Design Patterns. As a quick recap: If AntiPatterns are common bad practice traps that developers/teams can fall into, then Design Patterns are good practices which help guide them to either avoid AntiPatterns, or to lean towards a more efficient solution.

One design pattern we’ve used many times in my Data Structures class is the iterator, and personally feel as though it was never fully explained to the class as to what an iterator even really is, let alone why we were writing one. This post from Sourcemaking.com helped a lot in terms of learning what the use of them is.

As covered in the article, there has been a push in recent programming towards something called “Generic Programming”, and the iterator is a core idea within it. An iterator is an attempt to abstract out the traversal of data items in a data structure into a separate thing. The usefulness of this is outlined by an example given in the article:

“As an example, if you wanted to support four data structures (array, binary tree, linked list, and hash table) and three algorithms (sort, find, and merge), a traditional approach would require four times three permutations to develop and maintain. Whereas, a generic programming approach would only require four plus three configuration items.”

– Sourcemaking.com

So essentially, your iterator is an object in itself that handles the job of traversing through the objects in a list. A real-world example of this may be the AM/FM radio controls in your car. The radio stations are the objects in a list, with their station name and frequency (or channel, I suppose) as their data. The iterator would be your “scan” button, which skips over the stations with fuzzy signals in order to reach the next one whose frequency is available to you, while all you did was press the one button. Each station is a data point in your list (your data structure) with a station name and a frequency. You, the driver, don’t need to know anything about the details of the stations you’re scanning over, because the iterator (the scan button) handles that for you when finding the next available station.

The article from Sourcemaking has several really great UML diagrams and other examples to pick apart which help elaborate on the subject even further. I highly suggest visiting their website to read more about it — they have detailed explanations on almost every type of AntiPattern and Design Pattern I’ve looked into so far.

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

Testing vs. Debugging

If you’ve been immersed in the tech industry for any amount of time, the difference between Testing and Debugging is probably pretty clear to you. The two concepts are interlocked and cannot exist without one another, even if they are very different. I recently found this article which outlines the differences between them, the purposes of each, and some tips to help with the debugging process. To start off, let’s examine a really great graphic they used to describe the differences: 

Credit to Test Automation Resources

As shown above, testing is a process usually maintained by a dedicated team (or at least a few individuals who assist the development team). The job of the tester is to ensure that the product adheres to guidelines, and that it doesn’t execute in any way that it isn’t supposed to. Tests can be automated or manual (or a mix of both), and are intended to not only find an incorrect result, but also to find specifically where the failure happens and what may result from it. Given this information, the correction of the error becomes much easier.

So then what exactly is debugging? Once the testing team observes a failure, they bring that failure to the attention of the development team. It is then again the job of the development team to run through a few instances of the error and find out what exactly is going wrong, attempt to fix that issue in a way that still adheres to the project guidelines, and then resubmit it to the testers. If the testers find an issue, it is no longer their responsibility to ensure that a solution is found. It is the development team’s job to figure out what is going wrong and implement a good solution — and that is debugging.

A lot of this is probably common knowledge in the field, however “debugging” is a term that is haphazardly tossed around (kind of like “refactoring”) that I feel its’ meaning is easily lost. Especially for those breaking into the field or students just learning about what these concepts are, having loose definitions can be confusing. Essentially, if you’re fixing a known error, you’re debugging the code. If you’re trying to find errors, you’re testing your code.

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

Big Companies and Flaws

In software teasing and quality assurance, it is very important that issues be buffed out before release of a product. A lot of companies pour a ton of resources into this and inevitably things still do slip through space. One of the issues developers deal with a lot post launch are security issues. A lot of people may think that security issues are exclusive to smaller companies because they often think that “the bigger the company the better the security”, however, this has been proven wrong time and time again. Throughout Windows 10’s 2018 history, a lot of big updates were released. A lot of these updates actually needed up breaking a lot of things. Let’s go over some of the issues and look at what a little more software testing and quality assurance could have avoided.

Microsoft had been planning to release a massive Windows 10 update in April that added a ton of new features (including security) to their flagship operating system. However, a very bad bug that was causing Windows 10 to spam the blue screen of death was discovered. Microsoft could not release this big update with an issue such as this because it would leave the operating system even more unstable than it already is in its current state. After this issue was fixed, Microsoft was ready to finally ship out the update after a long delay. However, after the update was shipped out, there were over 600 million reports of Google chrome freezing and crashing after the update.

I think the reason that things like this happen is because of rushed deadlines. Sometimes while scheduling updates, there are a list of prioritized tasks that need to be finish in order to meet a deadline. However, in this rushed period bugs and glitches are bound to be overlooked because of the stressful development runs. In this case, Microsoft had to actually take the update offline and rollback the update because their user files were being deleted. From this, we learn that time management is important but also making sure rushed development doesn’t end up making the end users’ quality of products even worse.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Grey Box Testing

I am writing in response to the blog post at https://www.guru99.com/grey-box-testing.html titled “Grey Box Testing: Process, Techniques, Strategy, Challenges”.

Grey box testing, as the name suggests, is meant to be a combination of black box testing and white box testing. In white box testing, the internal structure of the code is known, and in black box testing, the structure of the code is unknown, and in grey box testing, it is partially known. Grey box testing combines the benefits of black box testing and white box testing, combining the input of developers while testing from the perspective of a user.

An example of grey box testing is given where a tester is testing a website and something is wrong with the HTML code, so the tester is able to look at and make changes to the code themselves to continue testing. A few other types of testing are listed as qualifying as being in the category of grey box testing: matrix testing, regression testing, orthogonal array testing, and pattern testing. These methods follow the strategy of black box testing while integrating some white box testing practices to focus more on what the test cases should be looking for.

A sequence of steps is provided for how to perform grey box testing. The first two steps, identifying inputs and outputs, do not seem to be directly related to black box testing or white box testing alone. In black box testing, there would be no need to explicitly identify the inputs and outputs; they would already be given in the test specification. The creation of the specification does require access to the code, which relates to white box testing, so grey box testing in this sense seems like a real-time testing approach where there is not necessarily a pre-developed specification and learning about the environment is a part of the testing process.

Challenges in grey box testing that are listed include when a test executes and the result is incorrect, and when something being tested encounters some failure. These do not really sound like challenges, they seem to just be examples of what testing is for.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

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.

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.