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.

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.

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

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.

This week as I was looking for articles, there was one particular article that caught my eye almost immediately. It is called, “Artificial fly brain can tell who’s who” I knew that I had to write about this article. This article was posted in mid October (October 18th to be exact), so it is actually fairly recent.

This article talks about how researchers at the University of Guelph and the University of Toronto have built a neural network that almost perfectly matches that of a fruit fly’s visual system, and it can even tell the difference between other flies and even re-identify them. They obtained this by combining the expertise knowledge of the biology of the common fruit fly and machine learning to produce a biologically-based algorithm.

The article then talks more about the biology of the fruit fly, and talks more about the computer program in the following paragraph. The article then concludes by talking more about the future of neural networks and AI.

I throughly enjoyed this article, and I truly believe that it was well worth the read, and I encourage others to also find the time to read this article. The part that I found the most interesting was that using this neural-network-machine-learning-based program, this “artificial fly” was able to identify other flies with a score of .75 or about 75%. They tested this by recording the fly for two whole days and then testing the program on the third day to see if it was in fact able to identify it. They also tested just the algorithm without the fly biology constraints, and this scored a .85 and .83. This is only slightly better than the program which is very good results. They also went on to compare it to human fly biologists, and they only scored a .08. Lastly, on top of all of these comparisons, they included that random chance would only score a .05. This is unbelievable in my opinion. The fact that a computer program scored that much higher than a human is truly insane. I think that this research is a huge step in the right direction for AI. After reading this article, I am much more interested in AI, and plan to continue to research the topic more.

Article URL: https://www.sciencedaily.com/releases/2018/10/181025142010.htm

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

https://www.infoworld.com/article/3290253/application-development/6-usability-testing-methods-that-will-improve-your-software.html

A/B Testing

A/B testing is a type of testing where there are two different application designs, generally websites, that are tested over time. Data is collected on their performance with some sort of goal in mind such as product sales. If analytics show that one of the designs was better at achieving that goal then one is declared superior and is chosen as the design to go with. This can lead to even more A/B testing against other designs until the development team comes to a decision. The analytics for the test is often times done through third-party tools rather than an in-house solution. An A/B test can be as specific as you want, to the point where you only change a single small element between the two designs or they can be made completely different. It is often best to define a specific problem keeping you from your goal that you want to investigate such as users failing to complete a transaction. A/B testing is extremely clear-cut at providing measurement data for design decisions but can take a large amount of time to conduct the tests and produce the data.

Design Prototype Testing

Design prototype testing can be used to test a complete workflow in a wireframe or fully designed portion of a product before it goes into development. A UX/UI designer will create the prototype and the test will help fix usability issues before the project goes any further. It is important to define a budget for the project as well as the specific goal. Then you need to choose a prototyping tool such as Axure. Third, you will need to choose a measuring tool to gather analytics from the user such as Loop11. It is important that the development team is familiar with such tools to make the test worth the time and work investment put into the test.

Formative Usability Testing

Formative Usability Testing is a type of early-stage testing that focuses more on quality assurance. This test should occur before the first release of the developed product so that it can become the baseline for future tests. With formative usability testing the product will go through a beta test where groups perform the defined usability tests. Test cases are usually written down in order to inform the participants through specific goals in order to get meaningful results. Afterwards it is important to analyze the feedback and make revisions to the product before the official launch. This can be repeated in order to improve the product over time.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

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

This pattern also dealt with a very important aspect in our everyday activities as an apprentice. I will say feedback are necessary because they do not just correct me but they also guide me to explore new directions and track specific causes to my failure. Even though, we got positive and negative feedback, I  strongly believe if you are able to accept them regardless of what kind they are and do a thoroughly assessment of yourself, they can be useful to you. Sometime, you might believe yourself and try counter defends yourself by explaining as to why you did something to a criticism instead of accepting it as a feedback. Getting feedback that enable you to figure out what to do more or less is very important to your success. I have drawn a lot of ideas from this pattern that I think will go a long way to help me stay focus in the software development industry.

For instance, I will be very mindful of what could come of me if I am in the teams where my skills are above average or below average. I will be very careful not to think I am the best when encounter with such situation. I will also not down grade myself too much to the extent that it will destroy me because I am the less skill among the team I am working with; it will give me the opportunity to extend my tentacle and learn more to catch up with them should that be the situation.

I really like the ideas discussed in this pattern. Because, as a newcomer, I am bound to face some shocks regarding feedback I will receiver but with this pattern’s ideas in mind, I think these shocks could be turn into something useful that will help me assess myself. I wasn’t even aware of some of those techniques for obtaining feedback such as test driven development, Exams and certifications that have been discussed in this pattern until I read it. Before reading this pattern and if I haven’t come across it, I will just assume I didn’t meet the standard a company might want if I am not offered a job after attending an interview. I wouldn’t bother myself to do a follow up to know why and what I need to improve on. The ideas in this pattern are really going to help me in the future.

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