Category Archives: cs-wsu

Software Testing Principles

I am writing in response to the blog post at https://www.guru99.com/software-testing-seven-principles.html titled “7 Software Testing Principles: Learn with Examples”.

This blog post highlights some useful general guidelines for software testing. In order to write effective test cases, it is important to follow some logical approach toward determining what to test for and how to test it, and this is a guide that describes such a set of principles to follow that are well suited to capture the logic involved in software testing.

The first principle is that exhaustive testing is not possible. I am not sure I believe this. In general it is useful to assume there exists no perfect test, but for simple enough applications where the number of possible interactions are enumerable, I would think that it would be possible to achieve exhaustive testing, much like an exhaustive proof, where every possible path is covered and verified. Maybe I am missing the implausible event that the test is correct but the computer running the tests is corrupted in such a way that certain tests are not run. This is relevant to a point made in this area, which is risk assessment.

The second and third principles make similar points. Always running the same tests will eventually not cover certain issues. If all of the same methods for testing are always applied exactly the same, then eventually there will be some scenario which the particular method is not suited for, and it will miss something. This leads into the later principles: the absence of a failure is not proof of success, and context is important. Developing tests suited for the particular application is necessary to ensure the correlation between tests passing and the program functioning correctly, and just because every test passed does not mean the program is going to work perfectly.

This set of software testing principles can be summarized in a few basic points. Develop test cases that are well suited specifically for the application that is being tested, consider the risk of certain operations causing a failure, and do not assume that everything works perfectly just because every test case passed.

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

Software Engineer Qualification

I am writing in response to the blog post at https://www.shiftedup.com/2015/05/07/five-programming-problems-every-software-engineer-should-be-able-to-solve-in-less-than-1-hour titled “Five programming problems every Software Engineer should be able to solve in less than 1 hour”.

This blog post shares a story about a history of people who apply for the position of a software engineer and claim some loosely related skills without actually having any chance of understanding or performing the job. The frustration of the author is expressed, and the author lists five programming tasks to disqualify any supposed “software developer” who would not be able to complete them in under an hour. I attempted them myself and they only took five minutes.

I am not sure what motivation people have to apply for a job that they are in no way capable of performing, but the author of this blog post seems to be fed up with how common it is. Supposedly, though, people who do not know what programming is are attempting to become software engineers.

I think that the list of five programming problems and the time constraint of one hour is a generous filter to sort out all of the people who have never written a program in any language ever before. It certainly would not be enough to qualify for the position of a software engineer, but that is not what the problems are meant to indicate upon fulfillment, it is simply what they are meant to reject upon failure. Somebody who claims to be a “developer” and fails to accomplish these simple tasks should revisit their resume.

The problems themselves are very basic. Find the sum of some numbers using loops or recursion, combine elements in two arrays, calculate Fibonacci numbers, and the last two problems are more peculiar but still simple demonstrations of basic problem solving. It should be evident in much less than an hour whether a person is capable of solving them, and any experienced software engineer should only need ten minutes.

The blog post acknowledges some feedback about the last two problems that are a bit less conventional than the others, but I think that the ability to solve unconventional problems is important, and I think anyone who writes code in something besides a markup language or an object notation could solve them.

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

The Problem of Testing

Software teams are increasingly facing the pressure of having to deliver quality software while still staying ahead of their competition. Release buggy software and users will be quick to switch away but lack the features your competitors provide and you will have trouble attracting new users. The traditional view of software testing is that the … Continue reading The Problem of Testing

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

SOAP vs. REST

SOAP and REST both allow you to create your own API. API stands for Application Programming Interface. It makes it possible to transfer data from an application to other applications. An API receives requests and sends back responses through internet protocols such as HTTP, SMTP, and others. Many popular websites provide public APIs for their … Continue reading SOAP vs. REST

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Discovering Backend Frameworks

Developers need a backend framework to create an application with which user can interact and perform some actions (which result in responses). In this context, the backend is defined as the subordinate processor or program (not directly accessible by users), which performs a specialized function on behalf of a main processor or software system. You … Continue reading Discovering Backend Frameworks

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Procedural and Object Oriented Programming

I am writing in response to the blog post at https://www.codementor.io/learn-programming/comparing-programming-paradigms-procedural-programming-vs-object-oriented-programming titled “Comparing Programming Paradigms: Procedural Programming vs Object-Oriented Programming”.

Object oriented programming seems to be the focus of all that is ever taught in a computer science course after the basics of syntax and control structures are covered, which are the basis for procedural programming. The shift into object oriented programming seems to mostly be for the sake of establishing proper design principles such as encapsulation and normalization to reduce redundancy, but these are not mutually exclusive features of the object oriented programming paradigm; it is still entirely feasible to write procedural code that is still “good” code.

The blog post does not directly define what procedural programming is about, but it alludes to the writing of straightforward code that makes use of variables, scope, functions and control loops. Then comes the brief anecdote of writing thousand-line long programs that start to become difficult to maintain, and how the object oriented programming paradigm is the solution. Object oriented design is definitely helpful for improving the scalability of a large program by introducing better organizational practices to the code structure, but the principles of encapsulation and modularity can be applied directly to the poorly maintained program anyway without changing paradigms. This is not to say that object oriented programming is bad or unnecessary, but the point is that procedural programming is not bad and does not need object oriented programming to “fix” it. Procedural code happens to be the most common poorly written code because it is most commonly used by beginners, who learn about better coding practices once introduced to object oriented programming.

Some of the faults with object oriented programming are described in the blog post, adding that it is not the best idea to avoid the use of procedural programming for the sake of adopting the exclusive use of object oriented programming. Modularity regarding class extensions and modification of a class can make things difficult in languages that focus on object oriented programming, where overriding a method or re-implementing a class may have adverse effects on subclasses. It is ultimately decided that multi-paradigm programming is a good choice, where the benefits of procedural and object oriented programming can be combined.

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

Positive and Negative Testing

I am writing in response to the blog post at https://www.guru99.com/positive-vs-negative-testing.html titled “Positive Vs Negative testing”.

Positive and negative testing have some features in common with the details of boundary value testing that we covered in class. Robust boundary value testing, in particular, tests values not only on the boundaries but also inside and outside of the boundaries. Testing input values that are inside the boundaries is called positive testing, and testing input values that are outside of the boundaries is called negative testing.

The blog post confirms as much. Positive testing is about providing valid inputs and testing that the application behaves as expected. Negative testing is about providing invalid inputs and testing that the application does not do anything that it is not expected to do. Boundary value analysis and equivalence partitioning are listed as techniques for positive and negative testing. Testing input data that is chosen within the boundary qualifies as positive testing, and testing input data that is chosen outside the boundary is negative testing. Equivalence class partitioning has partitions that are also valid or invalid based on whether they are inside the boundary. Testing valid partitions is positive testing, and testing invalid inputs is negative testing.

“Positive testing” and “negative testing” are separate types of testing by themselves, but it does not necessarily make sense to only use one of them; they do not provide a complete analysis of the program’s behavior. Positive testing will yield no conclusions about the behavior of the program given invalid inputs, and negative testing does not verify that the program behaves as it is supposed to when it is given valid inputs. Boundary value testing and equivalence class testing are specific methods that use positive and negative testing, and the process of testing inputs directly falls under black box testing, which does not make the distinction between whether an input is categorized as valid or not, only whether the program behaves correctly. Doing both positive testing and negative testing will provide sufficient information about the behavior of the program to be confident about whether the program is going to behave correctly.

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

Spring Framework

When Spring came out, it was a simpler, a light-weight alternative to J2EE, to make J2EE development easier. Enterprise Java refers to Java enterprise software. It’s a computer software used to satisfy the needs of an organization rather than individual users. Examples can include: accounting software, billing Management, business process management, CMS, CRM, ERP, etc. … Continue reading Spring Framework

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Test Coverage

Raw Coverage vs. Meaningful Tests If you’re shooting for a high-coverage number at the expense of a solid, meaningful, clean test suite, you lose value. A well-maintained suite of tests gives you confidence in your code and is even the basis for quickly and safely refactoring. Noisy and/or meaningless tests mean that you can’t rely … Continue reading Test Coverage

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Mutation – Testing your tests

In this post I will be looking at mutation testing. This is aimed at people who are not familiar with mutation testing. I will give an introduction to what mutation testing is; show some examples of what it can do; consider its limitations and look at how mutation testing can be added to a Java … Continue reading Mutation – Testing your tests

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.