Author Archives: John Ruberto

Testing Practice – Find my Bugs

Some of my favorite experiences with learning about testing is is do exercises where there are known bugs.  Somehow, knowing that the bugs exist, and my challenge is to find them, is energizing.  That is probably a good mindset to have when approaching testing in the first place. There are always bugs…

I created a couple of modules, called bugPractice, with intentional bugs for you to practice your skills.  There are likely more bugs than what I purposely put in, maybe you will find those as well.

The first module is a classic testing interview question, test a palindrome checker.  The function is called is_palindrome and it takes a single string.  It returns True if that string is a palindrome. Otherwise, it returns False.    I put in 5 bugs. If you find all 5, congratulations. If you find more, well, shame on me.  Here is the happy path execution for is_palindrome:

Transcript of happy path execution of is_palindrome()

Transcript of happy path execution of is_palindrome()

The second module is an implementation of a very simple stack data structure.  A stack simulates a stack in the real world, you can add items on top of the stack (push action), or pull items off the top of the stack (a pop).  Here is the transcript for the stack happy path:

Transcript of happy path execution for a stack class.

Transcript of happy path execution for a stack class.

These use Python, my favorite language.  If you need to brush up on your Python, I recommend a couple of resources. First, a software testing class from Udacity uses Python to teach testing fundamentals.  Second, Codecedemy’s class on Python teaches the fundementals of the language.

The most simple way to get started, download the archive, unzip it, then invoke Python interactive from that folder and follow the transcripts above to get started.

Leadership Lessons from the Latest Episode of Game of Thrones

Winter has come, and Game of Thrones fans enjoyed the first episode of season 7. This episode had a couple of good leadership lessons. By the old gods and the new, there are spoilers ahead, so read at your caution.

Jon Snow leading the North in Winterfell

Jon Snow leading the North in Winterfell

Jon Snow is an inclusive leader, which will expand his influence. He embraced the wildlings earlier in the show and most recently the next generation of the Umbers and Karstarks. These moves build his collation, expand his influence, and will aid in the battle with the white walkers.

Most organizations have an “enemy” to help focus their strategy. The most successful organizations focus their efforts outside, towards beating a competitor or changing the status quo in the marketplace. I’ve seen places that concentrate, instead, on infighting between departments. These places don’t exist anymore.

Jon Snow focuses instead on the outside threat, the white walkers, which puts the North in the best position to survive.

Secret Information in the Citadel Library

Secret Information in the Citadel Library

We see Sam Tarley in the Citadel, the greatest library in Westeros. All kinds of information that is vital to the humans is literally locked up in the Citadel. The maesters there are keeping the “memory” alive, but not making that useful information available.

Be transparent with your information, don’t horde it. You never know who needs that data to help them do their job.

Voter Fraud Detection Scheme

Our nation has been built on principles, such as “consent of the governed” – leading to free and fair elections and “freedom from unreasonable search” – which leads to personal privacy.  The right of us Americans to vote is paramount, and we use a secret ballot to choose our leaders.

Recently, a clash between these principles has arisen. Allegations of voter fraud have come up in recent elections, well, allegations of voter fraud probably happen with every election, but it’s been a persistent issue. The federal government recently asked for data from the states about the voter’s and their votes.  Most states are not going to comply, citing voter privacy.

When there is a clash of principles, we should first see if we could find a solution that meets both principles. If that doesn’t work, we should prioritize the principles and decide which one is more important, then apply the greater principle.

I believe that we can protect both principles in this case, free and fair elections and protect voter privacy, by using technology and a simple process.

First, the voter data is kept at all times by the states. The states do not need to provide the detailed records to the federal government. Instead, states will transform their data into a tokenized form – and only provide the tokenized data to the federal government.

This is how most password systems work – the password is not stored in a database, but the password is tokenized and only that encrypted form is stored. To check passwords, the same encryption method is used and compared to the encrypted version. So, the same type of process is used here – voting records are encrypted and compared.

If there is a match, meaning that the same person voted in multiple states, then the governments involved (the federal and each of the states involved) can investigate the matter further.

I created a prototype and published to github.

 

Testers Adding Value to Unit Tests

Development practices like Test-Driven Development can lead to high levels of Unit Test coverage. Sometimes, the team reaches 100% statement coverage.  How can testers add value when the code is “fully covered”?

Example of a project with 100% Unit Test Coverage

Example of a project with 100% Unit Test Coverage

I provide a few examples in this Sticky Minds article:

Review unit tests for missing cases. Just because the code is fully executed doesn’t mean all of the cases are used which might cause the code to fail.

Review unit tests against the product requirements. The unit tests will check that the code works as the developer intended. Sometimes, you can verify that the functionality meets the requirements.

Review the unit tests themselves. Having 100% coverage for unit tests means that the code was executed during a test, not that the tests are good, or even test anything.  Check that the assertions are valid and useful.

Review Exception Handling.  Unit testing is a good way to test the exception handling because the developer has full control of the mocked environment and can simulate the exceptions. These exceptions are difficult to inject in other types of testing, so making sure the unit tests do a good job is important.

Other ideas? Great, please check out the article and leave a comment either here or there.