https://www.softwaretestinghelp.com/what-is-mutation-testing/

This blog post explains mutation testing with a simple example. Mutation testing is a fault-based testing technique. Variations of a software program are subjected to the test data set to determine the effectiveness of the test set in isolating deviations. The example that this post uses involves a hospital site that lets new users register. The input to the program is the age of the patient. If the age is greater than 14, a general physician is assigned as their main doctor. The example data set for the tester is 14, 15, 0, and 13. The goal is to check if this data set is adequate to identify all possible problems with the code. To achieve this with mutation testing, variations of the program (mutants) must be created. A mutant is nothing more than a deviation that contains a self-seeded fault. Example mutation operators are:

• Arithmetic operator replacement
• Logical connector replacement
• Statement removal
• Relational operator replacement
• Absolute value insertion

Once all the mutants are created they are subjected to the test data set. If the data set kills all mutants, it is effective. If it does not, more or better test data should be used. Each value in the data set does not need to kill all mutants, but all the values combined should kill all mutants.

Some mutants are not useful at all. Mutants to avoid include:

• Syntactically incorrect mutants
• Mutants that do the exact same thing as the original program
• Mutants that can be killed by any data set

The number of mutants can be extremely large, even for a small program. Because of this, a subset of mutants is normally used and the mutants are commonly chosen at random. If there are some mutants alive at the end of the test, it is either an invalid mutant or the data set was inadequate. Mutation testing is a structural, white-box and unit testing method.

This was a useful post because it explained mutation testing with an example that was easy to understand. It also covered all of the important information to know about this testing method. After reading this I feel like I have a much better understanding of what mutation testing is and why it’s used.

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

For my final blog post of the year, I wanted to select a more interesting topic. The article Two-Factor Authentication with Node.js by David Walsh covers two-factor authentication and shows how it works behind the scenes using JavaScript. He even includes examples of how to implement two-factor authentication using QR codes.

Two-factor authentication is a user-verification method used by many web applications and services today. When a user tries to log in, a verification code is sent to a previously specified external device or address, such as a phone number or email. This code usually expires after a set time. The user that requested the code then enters it in the application or program to verify themselves and gain access to their account. By splitting access to your account into multiple different forms, you greatly increase the security of your account. Nobody can log into your email, even if they know the password, if you have two-factor authentication that is being sent through SMS.

David Walsh explains how the system of two-factor authentication is divided up behind the scenes. The first step is to generate a secret unique key for the user to validate two-factor authentication codes in the future. Then, you must add the site to your authentication. Finally, this code must be provided by the user and then validated to confirm it matches what was expected. If not, the user can try again with a new key. Since most two-factor authentication services refresh the key every few seconds/minutes, it is not necessary to lock the user out if they get one wrong.

Two-factor authentication is an incredibly powerful and important new form of security that allows you to put an even tighter lock around your information. As a developer, it is important to consider allowing your users to use two-factor authentication for your application, especially if any sensitive data is stores or if access to your account leads to vulnerabilities in the system. It’s one of those things you don’t realize is so important and valuable until you get your account stolen and realize it could have been prevented.

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

The article Test Case Design Techniques to Ensure High-quality Software on ReQtest brings up the three major categories test design techniques are generally classified into. These techniques are specification-based, structure-based, and experience-based. Each of these techniques covers different testing methods we covered in CS-443, especially structure- and specification-based techniques.

Specification-based techniques are also referred to as black-box techniques, which should give you some idea of what kind of testing this category covers. Testing techniques under this category are generally written to the technical specifications and client’s requirements. These testing techniques rely more on an understanding of what a program’s intended functions are, and what different states it can find itself in performing those functions. The actual structure of the code is not considered. Using specification-based testing, you can verify that your program works the way it was intended and is written to specification.

Structure-based techniques are conversely referred to as white-box techniques. As expected by the name, these testing techniques test the actual code that is written, and requires knowledge of the code and its internal structure. Many of the testing techniques of this type involving changing conditions and values and making sure code works in multiple cases, validating each branch of the code. Structure-based techniques help highlight any glaring structural or logical issues within your code you may have overlooked.

The final category is experience-based techniques. This category is pretty broad, mostly involving techniques that rely on prior knowledge or information that couldn’t be gained just from testing. This is the type of testing you just can’t plan for. However, the more you test, the more you can apply knowledge from previous tests to fix issues before they become back-breaking.

Dividing the testing into different categories makes their usefulness easier to understand. Structure-based techniques are more difficult and require more knowledge, but are exhaustive and effective at finding issues in the code. Specification-based techniques verify that the parts of your code that matter are functioning correctly. Experience-based testing simply leverages your knowledge of an area to improve testing. All these techniques have valid uses in the world of testing.

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

This week, I will be writing the posting my final reflection on an apprenticeship pattern – the Rubbing Elbows pattern.  This pattern addresses developers who feel that they are more productive when they work alone.  The problem that arises for these developers is that they feel that their learning is stagnating because they believe that superior techniques are out there and their work environment causing them them to elude you.  I have had some problems working in groups throughout my college career, but I have never felt that my learning is stagnant.  I chose to write a reflection on this pattern because I think it could be useful in the future, if I ever run into this kind of problem.  Oshineye and Hoover provide solid advice on how to improve your learning in unfavorable environments.

The first piece of advice they give is to find ways to work on tasks with another developer, “side-by-side”.  Oshineye and Hoover believe that some things can only be learned while in the company of other developers.   Even if many techniques don’t require you to collaborate to learn, many ‘microtechniques’ do.  They believe that it is also beneficial to rotate programming partners, because you may find that, after some time, your partner has beome a troublesom one.  Your peers are not the only element conducive to a good working environment though; the physical location is actually important, as well.  According to Richard Sennett’s the Craftsman, an ideal work environment is one in which “absorption into tacit knowledge, unspoken and uncodified in words” takes place.  As many of us are aware, those kind of environments are few and far between, so ‘rubbing elbows’ with another developer is the modern day substitute.  Working with others exposes you to work habits that allow you to gradually refine your skill and extend those habits beyond software development.

The action they advise you to take, if you are somebody currently experiencing this problem, is to find somebody who has already expressed an interest in working collaboratively.  Try to coordinate with that person to meet once a week for a while and see how long you remain motivated.  If the business of your life begins to put a strain on your motivation, adapt and find ways to keep pushing forward until the motivation returns.  I found this pattern very helpful and I will utilize it in my future collaborations.

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

The Sustainable Motivations pattern is aimed at apprentices that are having a tough time sticking it out through the more difficult aspects of the craft.  These might not be constrained to the craftwork itself, but could involve management, handling stakeholders (practically it’s own craft, and probably deserving its own book and set of patterns), and just dealing with burnout.  Even if the apprentice hasn’t yet experienced a motivation deficit, they’re likely to encounter one at some point.  They also tell the apprentice to avoid “Golden Locks”, that trap a person in a position because it feels too good to give up, even though it does not contribute to longer-term goals.

Their solution is to commit motivations to writing, spacing some of them out over a few minutes.  They ask the apprentice to determine which of those are externally driven, which internal, and which may not be necessary.  The end result should be a list of five important things that motivate the apprentice, so they can “look at it when times get tough”.

Motivation can be tough for me.  I tend to be energetic at the start of projects or semesters, but struggle to find ways to keep going once the shine wears off.  One of my concerns as making my way in the professional world gets closer and closer to reality is that I won’t be able to sustain motivation.  I’m always worried that a month or two in, I’ll wear down and burn out and not be able to keep going even though I love programming.  As an apprentice software craftsman, finding ways to motivate myself (and the discipline to keep going if and when motivation fails) is probably one of the most important things I can do to set myself up for future success.

I realize while writing this that I don’t actually know for sure what my ambitions are.  I know that I want to spend some time in the software industry, if only to pay off my student loans and ensure that I’m comfortable.  Even if the motivation to do that is the only thing I get out of this pattern, it’s worth it.

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

This apprenticeship pattern seeks to solve the problem of the apprentice that wants to seek out and join a skilled team to contribute to and learn from (also, it pays the bills).  However, a truly novice software developer may lack the skills needed to contribute, and faces (perhaps fears) rejection.

The writers offer a solution and an action item to assist it.  The solution is to develop and maintain concrete skills, items that can go on a resume, get through HR filters, and convince a hiring manager that it’s worth it to take a shot on the otherwise unproven apprentice.  These include picking up new languages and technologies, and most importantly writing a project in them, especially if it’s something the apprentice can put on a repository site or their own personal site for potential employers to look at.  The action item (short of finishing a half-dozen personal projects) is to look at the CVs of skilled proffessionals, and to figure out which skills they have that the apprentice could learn.  This goes hand-in-hand with keeping one’s own CV up to date and figuring out which parts are likely to catch the attention of hiring managers.

I think that the development of concrete skills is one of the more valuable things that I’ve gotten out of my education, and I wish that I’d had more opportunities to develop some.  I think it’s really important for students to have opportunities to create projects that push not just conceptual learning, but force the development of concrete skills because they’re the best tools for the job.  I have also been lucky to have an employer that’s willing to let me work on software projects for the business which has given me a lot of experience as well.  I would add to this pattern a suggestion to find an external source of pressure to create a project that works and looks professional.

This is, I think, a pattern that seems obvious and is harder to put into practice than it might appear.  It’s easy to commit to doing things by looking over a CV and developing a list of skills, and harder to actually get them done.

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

The apprenticeship pattern is another helpful one for the future. It is very similar to the other pattern talked about this week, but unlike the last one this week, Sustainable Motivations, it does not apply to the project we worked on over the last semester. Sustainable Motivations had to do with keeping ones motivation when faced with a task that did not cater to any of the reasons a programmer would be interested in programming. A project that is tedious, vague, or furstrating. This pattern, Nurture Your Passion, has to do with ones working environment instead.

In the real world not only are there hostile projects, but also hostile working environments. Corporations that do not care about you, or software craftsmanship. Ones that have abusive managers, demoralizing hierarchies, cynical coworkers, and project death marches. Things that kill a software craftsman’s passion in the their very craft. Things that can make them into one of the same people that contribute to that environment, even.

How does someone keep up their passion in the face of this? The answer is again looking to the future, as it was for Sustainable Motivations. You must look at the Long Road before you and visualize your road map for the future. You then have to see the conflicts between your current situation and the future one you want, and deal with it.

Your future may not align with the corporations, but you must do what is best for you. Project death marches that kill your passion? Stop playing along, leave early, at normal business hours. Do not fall prey to the hero mentality that will cause you to burn out in a couple of years, this is supposed to be a lifelong journey. Steer cynical conversations to positive and helpful topics. Try and steer unproductive meetings to something productive. Leave abusive ones. Work on making your hostile environment less hostile, and if you can not then leave.

The future they desire is what one should base their decisions on. You should never o off your Long Road unless you want to. Being pushed off of it is something that should be avoided at all costs.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.