Today, I am going to review and summarize Episode 283 of Software Engineering Radio.  This episode’s guest was Alexander Tarlinder, author of “Developer Testing: Building Quality into Software”.  The topics covered in this episode are quite relevant to the other posts I have done and one of those topics is specification based testing, which we have discussed in class.  I also selected this episode as the subject of this post because Alexander provides tips on how to test software effectively, both as a developer and as a tester.  The episode begins with Alexander providing an explanation as to why he wrote his book – he felt there were gaps within the software testing literature that needed to be bridged.  He claims that much of the existing literature on software testing will often focus too heavily on documentation, focus on a specific tool too much, or leave out crucial information on what to include in your test cases.  This can be hard to relate to for developers.  He defines general software testing as a process used to verify that software works, validate its functionality, detect problems within it, and prevent problems from afflicting it in the future.  He defines developer testing similarly but with the caveat that developer testing more systematically tackles the hard cases, rather than the rigorous; this is a result of developers being knowledgeable about the programming techniques implemented and the inherent bias that accompanies that.  Alexander argues that bias possessed by developers necessitates the need for additional testing to be performed by unbiased testers.  He insists that it is still necessary for developers to perform their own testing, though.  By performing testing during development, it ensures that at least a portion of testers’ workload will be a more of a “double-check”, allowing them to focus on the rigorous and unexpected cases that developers might overlook.

Alex then summarizes the main points of the discussion and provides tips on how to improve software testing.  The conversation strays a bit, so here is my summary and what I took from it:

• Encourage developer testing – Developer testing is a necessary practice to both ensure that the finished product is of high quality and functional and to allow testers to work rigorously, which will detect and prevent any potential problems in the future.
• Adopt an Agile development strategy – Agile development allows for rapid delivery of product and forces developers to adhere to effective working practices.
• Write code that is testable – Consider a Develop by Contract(DbC) approach where the caller and the function being called programatically enter into a “contract” with one another.
• Learn various techniques – Specification-based testing is a fundamental testing technique to learn, but it can sometimes lead to an approach that is too focused on where the data is partitioned, neglecting the in-between cases.

I think that this discussion contributed to my knowledge of effective development and testing practices which will help me a great deal when it comes time to implement them in the field (or an interview).

This blog post(2/9) is part of an assignment for the Fall 2017 session of CS443 @ Worcester State University.

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

We’ve been talking about path testing in class, such as tracing the concepts and expected behaviors of our code through a series of program graphs. I wanted to learn more about the different variations of path testing, and I found a good blog regarding this topic.

EngineYard: Ben Lewis – Happy, Sad, Evil, Weird: Putting Use Case Planning Into Practice

According to Lewis, happy path testing is one that developers take when testing for expected behaviors. But Lewis states it is imperative we take unexpected actions into account as well. Rather than solely thinking like a developer, we should be also thinking like an end user; the “actors” who are going to be using our finished products.One way of evaluate a myriad of action-consequence scenarios an actor may encounter is to follow a series of testing paths:

The Sad Path
In Lewis’ blog, he describes the “sad path” as one we should follow when we are testing our code.  He suggests it gives us insight on what should happen when an “actor” does something we don’t intend the person to do. If a user submits invalid information for example, we should run tests to determine that we are providing an appropriate response to this. This may include highlighting why the information is invalid, and prompt the user to reenter something that is valid instead. I feel that the significance of “sad path” testing is to ensure that our projects are as user-friendly as possible.

The Evil Path
When we take the “evil path” approach, we ought to be putting ourselves in the mindset of a malicious actor. For instance, we should run tests attempting to infiltrate sensitive information that we expect to be secure.  I believe “evil path” testing is important because we should have our users privacy and security in mind when developing our projects.

The Weird Path
Lewis suggests that taking the “weird path” is when we look for problems that may occur beyond our control. For instance, perhaps a portion of our project needs a certain server to be active in order to function properly. In this case, we should test that our program is appropriately detecting that the server is online, and if not, perhaps we can redirect the actor to an user-friendly status page to inform the user when the server is likely to be available.

The Happy Path
Last but not least, we should test the “happy path,” which can be described as ensuring that our project is behaving as intended. If our code has a submit form for instance, we should ensure that our code is submitting the information appropriately.

My main takeaway from Lewis’ blog is that the end user (actor) does not always interact with our projects in a manner that we may expect. Rather than simply testing expected behaviors, I feel we should evaluate possible unexpected behaviors that an actor may choose to do as well. I intend on doing this during my professional career when testing future projects.

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

This week I read a blog post from TestLodge talking about the characteristics that make up a good software tester.  The post found at https://blog.testlodge.com/characteristics-good-software-tester/ helps identify some of the attributes that a tester should have in order to be proficient in their testing as well as excel in their career.  I chose this post because it provided a different perspective than most.  As a student initially learning these skills I often get too focused on how to do different testing procedures and sometimes forget to look at why I’m doing them and what purpose do they have. Articles and posts like this help me to take a timeout and look beyond the skill set that I’m trying to acquire to help put me in the right state of mind.  The post breaks it down into 13 different characteristics.  Characteristics like testers have to be a strong communicator and be a team player.  This is good to remember, especially early on in our careers, so that we don’t ignore failed tests or improperly communicate what failed in the software to the rest of the development team and let an inferior product be released simply because we were to scared of upsetting someone by telling them part of the code is wrong.  Other characteristics like thinking creatively and paying attention to details.  These attributes will help us examine closer what the goal of the test that we need to write is and think outside the box in order to write the most effective test.  We need to be able to realize that just because we did a test a certain way in class for a project one time, that may not be the best way to write the test every time.  A good tester should also be organized and should meet deadlines.  Time management is crucial in the software development process.  Staying organized with all your tools, notes, and team communications will allow you to complete more tests.  It will also help you keep track of your deadlines and prioritize your tests so that way you are not delivering a product late of missing important tests and creating too many tests for less important features.  I felt like this post is good to revisit from time to time so that I don’t get too focused on just trying to write a perfect test and develop a broader skill set that allows me to recognize the right approach to each situation and to stay organized without rushing into a project and failing from the start.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.