Regression Test Planning is like Packing for a trip

This is a follow up to last week's post.

Vacation Packing Experts will tell you take less than you need. Such as this tip from The Blonde Abroad:

How does this relate to QA Regression Test Planning?

When planning the test strategy for a new function to add to the regression test, you should revise the coverage to focus on the most important functionality. When a feature is first created every part is critical but over time some of the features become less critical. When it's time to add the feature to regular regression - as part of the QA Transition Plan - some minor features are treated as critical issues.

Three Tips to Writing a Test Plan

It's QA job to balance the priority of testing the functionality to the amount of time that is available for regression testing. Here are some best practice tips I have learned over the years:

Know What is Important - The QA Team Lead needs to work with the product and Developer Lead on the critical parts of the feature. The group needs to decide what functionality is critical to the product going forward - post-launch. This is where the packing analogy comes in - decide now what is critical to take on the next release journey.

Tag Jira Tickets - When writing the test case, it's a good idea to reference the original Jira Ticket. I can't tell you how many hours have been spent searching in Jira for the QA ticket, just to find the product description or specs. I have found that test tickets may have error log notes that may help debug issues that happen long after the product was released.

After all is said and done more is said than done - I have seen projects that were once mission-critical, become a very low priority in a very short time. Despite all the "sense of urgency" that was initially given, other projects become more important. Ideally, a good QA Lead will follow up with the product to verify the priority of the feature functionality. However, balancing other projects usually distract QA from the ideal process.

Testing is like

Using some of the phrases from WordStream:

Testing is like herding cats. Cats are fiendishly complicated to manage, they eat when they want, sleep when they want, come and go as they please. A cat is going to do what it wants when it wants and there's precious little you can do to change that. QA Testing isn't entirely like that, but it's close.

Weekly Release Testing is like World of Warcraft because getting to green, and staying there, is testing hand-to-hand combat that never ends. The closer you get to the release day, the more cunning and more ferocious the feature testing you must face, and defeat. Release Day is a battlefield littered with the corpses of features that weren't up to the challenge.

Regression testing is like bacon: Everyone loves it. Some people try to say they hate it. That just means they love it even more.

Testing is like a can of Campbell's vegetable beef soup. If you can, think of the juice as the product features; you need the juice to make soup, and you need the features for testing. The vegetables are like testing best practices. The meat is like gray-hat testing. Last you have sodium which is about 85% of our daily value and it's not really that good for us. But it's also what keeps the soup fresh, and that freshness is why I get to keep eating my cans of soup. Similarly, there is a ton of code in the codebase today, but about 25% of the code created is not used on a daily bases. But that code is fresh, and to the end-users, that freshness is just as important as any other code.

Automation is Not

Here we go...

Here are the eight things that people may think what QA Automation is - but they are so wrong:

Automation is not....

1. A substitute for manual testing. It should complement the sum of all the testing done in a release cycle.
2. Easy. It takes time to build a strong test foundation that can be properly maintained.
3. Hard. There are a lot of "quick" hit automation tools. Make sure to have a plan. Don't create tests that just "chicken peck" functionality.
4. A One and Done. Automation requires lots of regular maintenance work for feature changes and to build in complexity.
5. Testing. It's only for verification of a specific predefined path. Just keep in mind that customers may not take the same approach - this is why manual testing is good.
6. One Size Fits All. There are lots of automation solutions available. In the past two companies I worked at, both decided to build their own - just so they could have ownership.
7. Just about Selenium. There are other alternatives available. Don't think you're limited to Selenium rules. Check out Katalon Studios, Robot Framework and CasperJS to name a few.
8. Abracadabra. It's not magical and worth QA time to understand the technology behind it so they can get the most out of it.

What do you think of my list? Did I miss anything? Or am I way off base?

Bug Bash

In some companies they have an internal company-wide product show-me - otherwise known as Product Palooza.

What is a Product Palooza?

Bug Bash

QA Should have a similar type of event - named Bug Bash. The event would showcase some of the unique bugs that QA has found.

Bug Bash target audiences would be for the Product and Engineering teams.

Some Example Exhibits:

• Most Complex Bug Found
• Tools that QA Uses to Find Bugs
• Tips and Tricks on Testing your own code
• Testing Technology and Techniques
• Testing Challenges and Ways They are

A Bug Bash can help QA educate the engineering team of the various testing challenges. It can be used for the Product team to help understand planning and test time allocation.

Managing Testing around furloughs and layoffs

Many companies are cutting expenses and implementing short term furloughs and layoffs. This means that QA has to balance testing with smaller teams.

Some ideas to make this process less impacting to the team

• Documentation - make sure that everyone update their smoke testing and regression test steps.
• Schedule - if the team is going on furlough on different weeks make sure that everyone knows who going to be out and when.
• Regression Testing Test - make sure that the test case repository is updated with the latest test. Particularly make sure the test steps are up to date.
• Ticket Testing - Make sure testing steps are clear if tickets are being released while the tester is out. If there were any new discovery while testing a ticket - it's critical to make sure that it's well documented.
• Wiki Page Update - Make sure that project base QA Reference pages are updated with the current contact and release plan. (More information on QA Reference Page in a different post. )
• Product Review Meeting - After layoffs occur it's a good idea to meet up with the Product team and go over regression planning. With a smaller team, it's time to rethink testing priorities. The product can help lay the groundwork on what areas should get the most focus. In some businesses, it might be good to include customer support as they may have ideas on areas of the product that gets the most attention.

QA Tag Lines

Everyone once in a while I encounter a situation where we need a good QA tag line. It might be for a marketing event or just something to spice the mood up around the office.

My coworkers will come up with some creative content, and some are good and some need a little bit more creativity. At the end of the day, I appreciate the thoughtfulness and work that they put in each submission.

Creative Tag Lines

Here are some suggested tag lines for any QA team. Some of these are based on classic commercial tag lines.

• It Matters
• Good Enough is not Good Enough
• Quality Up
• Question Everything
• Quality is Job 1
• What could possibly go wrong?
• A little science...a little magic...a little quality.
• Say "No" to bugs.
• Make it Right - Mike Holmes
• It's time to get serious with QA

Got a Tagline?

If you know of any other tag lines, please share. We are always looking for something new.

Enable Reader Mode in Chrome

There's a little known feature in the desktop version of Chrome - the ability to see only the text on webpages. This has been available in Safari for years. Google finally has decided to bring it into Chrome.

The feature is "neat" because you can basically eliminate ads from articles, which can be a distraction some times. In some cases, you can bypass the paywall and see the article that is blocked using the conventional way.

Enable the Feature

To enable the feature you need to open Chrome and go to this URL:

This is what you should see:

Use the pull-down menu on the right of the "Enable Reader Mode"

Then click on the blue "Relaunch" button and Chrome Browser will restart.

Toggle Reader Mode

Now when you visit some websites, you'll see a new icon to the right of the URL, now click on it and you'll have the same reader mode as you get in Safari.

Fixed some Classic Posts

I spent some time today reviewing some old blog posts. Some of these were old and needed some refreshing updates.

I fixed up:

• Baltimore Riot Unknown Casualty
• Mather Tomb
• Thomas Seward Gravestone

Here are my notes on these posts:

• Fixed a lot of the spelling and misc sentences that just didn't make sense. Maybe it made sense when I was putting it together, but definitely not now.
• Updated the images so that the post looks good on Desktop and Mobile
• DIdn't add any additional content - I would like to update the pictures, as when they were taken I wasn't thinking of posting it.
• Corrected data from comments that people left in the post
• Updated some basic phrases

Test Description

The best way to write up ticket testing - for QA - is two simple steps:

• What do you want QA to test?
• What is the expected outcome?

Example Test Situation

Simple Steps To Get

By using these steps, it gives clear guidance to the QA Team on how to properly test the code change. The "Expected Results" helps clarify the specific change that was done.

Note: QA is still free to do exploratory testing around the change - time permitted. The expected results help clarify the specific changes that were made.

In the Past…

I have encountered a lot of issues that had vague testing descriptions that lead to a lot of unnecessary interactions between QA and Dev. Basically it wasn't clear exactly what was changed and how the functionality should work.

Find Empty Name Ids

One of the challenges with writing any QA automation is XPaths. They are essential to finding elements on a page. You need them to verify functionality or to take some action - such as clicking a button.'

The XPath helps automation find that location, it's primarily built using name ids. The reason name ids are important is because they are supposed to be unique on a page.

More often than not, Developers will leave out adding name ids. This means that QA has to use the full XPath location. This now makes the automation code risky because if someone makes a simple change to the page - such as adding a new element, the automation test may fail. This is because the XPath flow is broken.

Use JQuery to Help with Ids

If you're testing a site that uses jQuery, you can run this simple script to find all the areas of the page that don't have a name ID:

To use this simply open up the Chrome console panel and paste in the above code. If the page element doesn't have an ID or class, the element will get highlighted in red.

Not every single DIV tag needs a class or ID, but this is a good technique to find out where they are missing on the page.

Bookmarklet

Here's the code in a bookmarklet format, so that you can run it whenever you want:

If you know about Bookmarklets, then you know that you can simply Drag/Drop this to your Bookmark toolbar: Check Name IDs

Knowlegde is Powerful

Knowing the availability of empty DIVs without a name ID can help with the automation process - QA can now request an ID in all the key points in the web code.

Simply take a screen shot and ask Devs to put name IDs where needed.