Book Review: Agile Testing Condensed

I read a ton of books, and I've found that reading books about testing is my favorite way to learn new technical skills and testing strategies.  James Clear, an author and expert on creating good habits, says: "Reading is like a software update for your brain. Whenever you learn a new concept or idea, the 'software' improves. You download new features and fix old bugs." As a software tester, I love this sentiment!

I thought it would be fun this year to review one testing-related book a month in my blog, and what better book to start with than Agile Testing Condensed by Janet Gregory and Lisa Crispin?  They literally "wrote the book" on agile testing a decade ago, then followed it up with a sequel called More Agile Testing in 2014.  Now they have a condensed version of their ideas, and it's a great read!

This book should be required reading for anyone involved in creating or testing software.  It would be especially helpful for those in management, who might not have much time to read but want to understand the key components of creating and releasing software with high quality.  The book took only a couple of hours for me to read, and I learned a lot of new concepts in the process.  

One of my favorite things about the electronic version of the book is that it comes with a ton of hyperlinks.  So if the authors mention a concept that you aren't familiar with, such as example mapping, it comes with a link that you can click to go to the original source of the concept and read the description.  But if you are familiar with the concept, you can just skip the link and read on.  What a great way to keep the text short and make reading more interactive!

The book is divided into four sections:

Foundations: This is where the term "Agile Testing" is defined, and where the authors explain how a whole software team can get involved in testing.  

Testing Approaches: In this section, the authors show how important it is to come up with examples when designing software, and how a tester's role can be that of a question asker, bringing up use cases that no one else may have thought of.  They also define exploratory testing and offer up some great exploratory testing ideas, and they explain the difference between Continuous Delivery and Continuous Deployment.  

Helpful Models: This section discusses two models that can be used to help teams design a good testing strategy: the Agile Testing Quadrants and the Test Automation Pyramid.  There's also a great section on defining "Done"; "Done" can mean different things in different contexts.

Agile Testing Today: This was my favorite part of the book!  The authors asked several testing thought leaders what they saw as the future of the software tester's role.  I loved the ideas that were put forth in the responses.  Some of the roles we can play as agile testers (suggested by Aldo Rall) are: 

• Consultant
• Test engineering specialist
• Agile scholar
• Coach 
• Mentor
• Facilitator
• Change agent
• Leader
• Teacher
• Business domain scholar

I found myself nodding along with each of these descriptions, thinking "Yes, I do that, and so do all the great testers I know." 

I recommend that you purchase this book, read it, put its ideas to use on your team, and then share those ideas with everyone in your company, especially those managers who wonder why we still need software testers!  In just 101 pages, Agile Testing Condensed shows us how exciting it is to use testing skills to help create great software.  

Your Future Self Will Thank You

Recently I learned a lesson about the importance of keeping good records.  I've always kept records of what tests I ran and whether they passed, but I have now learned that there's something else I should be recording.  Read the story below to find out what it is!

I have mentioned in previous posts that I've been testing a file system.  The metadata used to access the files are stored in a non-relational database.  As I described in this post, non-relational databases store their data in document form rather than in the table form found in SQL databases.

Several months ago, my team made a change to the metadata for our files. After deploying the change, we discovered that older files weren't able to be downloaded.  It turned out that the change to the metadata had resulted in older files not being recognized, because their metadata was different.  The bug was fixed, so now the change was backwards-compatible with the older files.

I added a new test to our smoke test suite that would request a file with the old metadata. Now, I thought, if a change was ever made that would affect that area, the test would fail and the problem would be detected.

A few weeks ago, my team made another change to the metadata.  The code was deployed to the test environment, and shortly afterwards, someone discovered that there were files that couldn't be downloaded anymore.

I was perplexed!  Didn't we already have a test for this?  When I met with the developer who investigated the bug, I found out that there was an even older version of the metadata that we hadn't accounted for.

Talking this over with the developers on my team, I learned that a big difference between SQL databases and non-relational databases is that when a schema change is made to a relational database, it goes through and updates all the records.  For example, if you had a table with first names and last names, and someone wanted to update the table to now contain middle names, every existing record would be modified to have a null value for the middle name:

FirstName	MiddleName	LastName
Prunella	NULL	Prunewhip
Joe	Bob	Schmoe

With non-relational databases, this is different.  Because each entry is its own document and there are no nulls, it's possible to create situations where a name-value pair simply doesn't exist at all.  To use the above example, in a non-relational database, Prunella wouldn't have a "MiddleName" name-value pair: 

{
    "FirstName":"Prunella",
    "LastName":"Prunewhip"
},
{
    "FirstName":"Joe",
    "MiddleName":"Bob",
    "LastName":"Schmoe"
}

If the code relies on retrieving the value for MiddleName, that code would return an exception, because there'd literally be nothing to retrieve.

The lesson I learned from this situation is that when we are using non-relational databases, it's important to keep a record of what data structures are used over time.  This way whenever a change is made, we can test with data that uses the old structures as well as the new structure.

And this lesson is applicable to situations other than non-relational databases!  There may be other times where an expected result changes after the application changes.  Here are some examples:

• A customer listing for an e-commerce site used to display phone numbers; now it's been decided that phone numbers won't be displayed on the page
• A patient portal for a doctor's office used to display social security numbers in plain text; now the digits are masked
• A job application workflow used to take the applicant to a popup window to add a cover letter; now the cover letter is added directly on the page and the popup window has been eliminated

In all these situations, it may be useful to remember how the application used to behave in case you have users who are using an old version, or in case there's an unknown dependency on the old behavior that now results in a bug, or in case a new product owner asks why a feature is behaving in the new way.  

So moving forward, I plan to document the old behavior of my applications.  I think my future self will be appreciative!  

The Command Line, Demystified- Part II

In last week's blog post, we started taking a look at the command line, and how it's possible to navigate through your computer's file system using some very simple commands.  This week we'll learn how to use the command line to create and remove folders and files.  We'll be building upon the knowledge in last week's post, so if you haven't read that, I recommend starting there.

Let's start by creating a new folder.  Open up the command window, and enter mkdir MyNewFolder.  You won't get any kind of response, just a new command prompt.  But if you type ls (on Mac) or dir (on Windows), you'll now see MyNewFolder listed in the contents of your home directory.  

To navigate to your new directory, type cd MyNewFolder.  Your command prompt will now look like MyNewFolder$ on Mac, or MyNewFolder> on Windows.  If you type ls or dir now, you'll get nothing in response, because your folder is empty.

Let's put something in that new folder.  If you are using a Mac, type nano MyNewFile.  A text editor will open up in the command window.  If you are using Windows, type notepad NewFile.txt.  Notepad will open up in a separate window.

Type This is my new file in the text editor (Mac) or in Notepad (Windows).  If you are in Windows, just save and close the Notepad file.  If you are in Mac, click Control-X,  type Y when asked if you want save the file, then click the Return key to save with the file name you had specified.

If you are in Windows, return to the command line; Mac users should already be there and the text editor should have closed.  Your working directory should still be MyNewFolder.  Now when you type ls (Mac) or dir (Windows), you should get this response:  MyNewFile (Mac) or MyNewFile.txt (Windows).  You have successfully created a new file from the command line.

We can now read the contents of this file from the command line.  If you are in Mac, type cat MyNewFile.  If you are in Windows, type type MyNewFile.txt.  You should see This is my new file as the response.

Now let's learn how to delete a file.  Simply type rm MyNewFile if you are in Mac, or del MyNewFile.txt if you are in Windows.  If you've deleted correctly, an ls or dir command will now give you an empty result.

Finally, let's delete the folder we created.  You can't have the folder you want to delete as your working directory, so we need to move one level up by typing cd ..  .  Now you should be in your home directory.  If you are in Mac, type rm -r MyNewFolder.  If you are in Windows, type rmdir MyNewFolder.  You won't get any response from the command line, but if you do ls or dir, you'll see that the folder has been deleted.

Now you know how to create and delete files and folders from the command line.  I'll close by adding two bonus commands- one for Mac and one for Windows.

For Mac users:  the term sudo (which stands for superuser do) allows you to run a command as an administrator.  There are some times where you may need to do an installation or edit which requires administrator access.  By putting sudo before the command, you can run the command as the system admin.  For example, if you typed sudo rm -r MyNewFolder, you'd be removing the folder as the system admin.  Think carefully before you use this command, and make sure you know what you are doing.  There are many commands that require a superuser to execute them because they are dangerous.  You don't want to delete your entire filesystem, for example!

For Windows users:  a handy command is explorer.  Typing this in your command window will bring up the File Explorer.  This is useful when you want to switch from navigating the folder structure in the command line to navigating in the Explorer window.  For example, if you knew that a folder called MyPictures had images in it, you might want to open up the Explorer to take a look at the thumbnails of those images.

I hope that these two blog posts have gotten you more comfortable using the command line.  Have fun using your newly-learned skills!

The Command Line, Demystified- Part I

When I first started out as a software tester, I would always get nervous when I had to do anything with the command line, and I was so impressed when my coworkers could type tiny commands and get dozens of lines of text in response.  The one thing that helped me when learning the command line was a course I took in Linux.  I was confused for much of the course, but I did manage to learn some commands, and over the years I've been able to gradually expand my knowledge.

The command line is hugely helpful when you want to navigate through your system's folder structure, create new folders or files, or execute runnable files.  In this post, I'll be walking you through some simple commands that can help you get started using the command line like a pro.  Most of the commands I'll be sharing will work in both Mac and Windows; when there are differences between the two, I'll point them out.

First, let's look at some useful keys:

The up arrow
The up arrow copies whatever command you just ran, and if you click on the up arrow more than once, you can cycle back through all of the commands you have run so far.  For example, if you ran these three commands:
ls
cd Documents
cd ..
and then you were to click the up arrow, you'd see cd .. . If you clicked the up arrow again, you'd see cd Documents, and if you were to click it a third time, you'd see ls.

The up arrow is really helpful for those times when you ran a complicated command and you need to run it again, but you don't feel like typing it all over again.  Simply click the up arrow until you've returned to the command you want, then click Return to run the command again.

The tab key
The tab key has auto-complete functionality.  To see how this works, let's imagine that you have a folder called MyFolder that contains three sub-folders:
LettersToDad
LettersToMom
graduationPics
If you wanted to navigate from MyFolder to graduationPics using the cd command (more on this later), you could simply type:
cd grad
and then click the tab key.  The folder name will auto-complete to graduationPics.

This command is helpful when you don't feel like typing out an entire folder name.  Typing just the first few letters of the folder and hitting tab, then Return, is a really fast way to navigate.

In order for the auto-complete to work, you need to type enough letters that there's only one possible option left when you click the tab key.  For example, when you type
cd LettersTo
and then click the tab key, the command line doesn't know if you mean LettersToDad or LettersToMom.  The Windows command line will cycle through the possible options as you repeatedly click the tab key.  In Mac, if you click the tab key a second time, it will return your possible options.

Next, let's learn some navigation skills:

The command prompt:  The command prompt is a symbol that indicates that the command line is ready to receive commands.  In Mac, the command prompt looks like this: $.  In Windows, the command prompt looks like this: >.  The command prompt is preceded by the working directory.

Working directory:
The term working directory refers to whatever directory (folder) you are in when you are using the command line.  When you first open the command line window, you'll be in your home directory.  This is your own personal directory.  For example, in Windows, my personal directory is C:/users/kjackvony.  In Mac, my personal directory is /Users/K.Jackvony, but the directory location will display only as ~ , which means the home directory.

ls or dir
This command - ls in Mac and dir in Windows - will list all the files and folders in your working directory.

cd <folder name>
This command will change your working directory to the folder you specify.  For example, if you said cd Documents, your working directory would change to the Documents folder.

cd ..
This command moves you up one level in the directory.

Let's look at an example.  I am using a Mac, so I'll use ls rather than dir.

1. I begin in my home directory:
~$

2. I type ls to see what's in my home directory, and I get this response:
Desktop
Documents
Pictures
Projects

3. I type cd Documents, and my working directory is now the Documents folder:
Documents$

4. I type ls to see what's in my Documents folder, and I get this response:
Blog Post Notes
Images for Testing
ProfilePhoto.jpg

5. I type cd "Blog Post Notes" (I'm using quote marks because the directory name has spaces in it), and my working directory is now the Blog Post Notes folder:
Blog Post Notes$

6. I type cd .. and I'm taken back to the Documents folder:
Documents$

7.  I type cd .. again and I'm taken back to my home folder:
~$

Now that you see how the example works, take some time to try it in your own command line, with your own folders!  Remember that if you are using Windows, your prompt will look like a > rather than a $, and you'll want to type dir instead of ls to see what's in your working directory.

Next week we'll continue the command line adventure by learning some more navigation skills and how to create our own files and folders.