QA Blog Posts
QA Image Library
Check out the growing QA Image Library. This is my personal colleciton of Slack Images for that perfect QA Moment.
QA Memes (October)
Here’s more collection of QA memes. Some of these you have to be doing QA for a while, but most of these you should understand.
Best Release Ever
Hello, QA Wants to go Home!
why can’t developers actually test their code?
QA up at Night
A common question that gets asked CEOs is:
What Keeps you Up at Night?
The response usually centers around new projects and uncontrolled risks to the company bottom line.
So, What about QA? What issues are keeping QA up at night? I can't speak for all of QA, but here are the top six things that keep QA Managers and Leaders up at night.
Six Things that keep QA up at Night
Ticket Scope Creek - Product making last-minute changes and not adding the change to the spec document. This can cause some unfortunate consequences later. For example, the product team didn’t realize that an extra line in a description field pushes the next button below the visible frame view.
Tight Deadlines- sometimes a feature has to go to Production with very minimal time for proper testing. In these rare cases, QA has very little time to fully test the feature. Example: Product wants to ship a new feature in time for the customer event, unfortunate delays with development means a shorter test cycle.
Dev Environment not Matching Production - Some testing can’t be accomplished because the testing environment doesn’t match production. Most of the time it’s load balancing and Cache that may cause issues. Example: New customer login path doesn’t take account of having different servers. QA passes the feature but the release is rolled back because users aren’t able to log in.
Developers that don’t test their code - some developers don’t test their code before handing it off to QA. They feel when it passes code review it’s good enough. Unfortunately, developers don’t check for how the change impacts the code. Most time code review is to test logic. Example: Developer submits code for QA and the build fails because the developer forgot to properly close a SQL insert statement.
Dealing with the Cash Register - Making the sale process smooth is critical to any business. QA needs to make sure that customers can buy and the sale occurs correctly for the customer and for the company. It’s important that customers are properly charged for the goods and services that they order. Example: At one of the companies that I worked at, a team of QA engineers was responsible for making sure that purchases were successful. They were trained to understand various tax rules and security regulations. Not all companies have the luxury of having a skilled team, so QA has to do their best to make sure that the sales process is good after every release.
Automation Failures due to UI changes - When a developer makes a UI change and doesn’t tell QA, it can cause some issues after the first automation run. The overnight tests may fail and QA will spend much of the morning fixing all the failed runs. This can cause other bugs to go undetected for a while. Example: A developer changes some of the IDs in the main navigation to keep with the new CSS standards. The change is considered minor and no ticket is created. On the first day of testing 90% of the automation fails because the old IDs can’t be found.
What do you think? Are there other cases that cause you to lose sleep?
Share your story in the comment section.
Recently I was doing some location testing using Google. The purpose of the test was to find a place in the United States where I could expand the radius targeting more than 50-miles.
When you use Google targeting you are allowed to expand that radius only when your location had a small population density.
If your range has a high population count Google will force you to have a smaller target.
I tried many remote areas of the United States and the only place that I could expand the target range to 100-miles was Winnemucca, Nevada.
I am sure that there are places in Alaska that would qualify - but I wanted to test for a place in the lower 48-states.
Hopefully this helps someone else doing targeting testing using Google Locations.
Code Freeze Meme
It’s been a while since I added QA graphics to the QA library. Here are some more images to add to my collection.
This week's theme is "Code Freeze"
Since today is Labor Day, I decided to go easy on today’s post and highlight some QA logos that might be fun for presentations or Notion headline.
I wish I knew more about...
Today’s blog post is all about the Ministry of Testing blog challenge for September.
Write a blog on the topic "I wish I knew more about..." before September 17th
My answer is simple:
I wish I knew more about Quality Chrome tools that can help me be a better tester.
I feel like there are a bunch of Chrome plugins that are out there that I should know about.
The next time that I have downtime, I’ll spend a few minutes searching the Google Play store for extensions that might be useful.
Some search queries that I can think of:
Fuzz testing (fuzzing) is a quality assurance technique used to discover coding errors and security loopholes in software, operating systems, or networks. It involves inputting massive amounts of random data, called fuzz, to the test subject in an attempt to make it crash.
This is usually a technique done with Automation to see how fields respond to random text and interactions.
Manual testers may want to use Bug Magnet, a popular Chrome Extenstion to add random data to fields. This is more exploratory testing than Fuzz Testing. Fuzz Testing is focused more on how the software reacts to a huge set of random data being entered.
Fuzzing is a critical part of testing as it checks for potential vulnerabilities with the software application and logic.
You can learn more about Fuzzing at the Open Web Application Security Project Foundation website.
In QA, it's good to not have any bad surprises. This is especially true around code freeze. Nobody wants to encounter blockers or critical issues that may impact the ability to release on time.
This is why many companies implement an Early Evaluation of releases. It's a chance to see where the release branch is, and if there are any issues.
Basic Definition of Early Evaluation
Early Evaluation is when QA builds the latest version of the release branch to a dev box a few hours before code freeze. If the build is successful, QA runs a suite of Acceptance Test to see if the release branch is stable. If there are any blocking issues, QA will notify developers of the issues.
There are three main components of the Early Evaluation:
Is the Release Branch really Stable - This is the time to find out build issues. Not at midnight or off-hours when code freeze happens. Key developers may not be near their computer to help out.
Are there any Database Migrator issues? Some developers may not check for migrator conflicts when merging their code in. Checking for migrators errors can help determine of certain functionality are working as expected.
Acceptance Testing - The QA team should have a suite of manual acceptance tests. (These are specific tests that QA has defined are critical for sign off) QA should be checking for any Blocking Issues This is also a good time to run automated acceptance tests. If there are any automation failures, QA should check to make sure its not related to release intended changes. Fixing these now will help with overnight automation runs.
Worth the Time and Effort
Code Freeze day can be crazy, but it's important to take a break and test out the release as part of the early evaluation. In the past, there has been a lot of good bugs found before code freeze, saving a lot of time during code freeze.
Google's Lighthouseis a useful extension to test the performance of any website. It's useful to learn about the load times and suggest ways to improve the site.
This is built into every chrome browser, simply go to the Developer Tools page, Command - Option - I, and then click on the Lighthouse on the top menu bar.
Official Product Description
Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public, or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO and more.
You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.
Useful for QA?
This is a useful tool to check for broken images that may go unnoticed during testing. Especially since the test is run on another server outside of VPN.
In addition, the "properly size" images can highlight any images that may cause slowness in load times - particularly important for mobile users.
Also useful for QA to test login processes. Since some portions of the site may require logins, you can use this tool to see how much of the site is exposed without logging in.
Easy to run, and just about instant results make it a quick tool to assist QA with some general page testing.
They are constantly adding new audit metrics using industry best practices.
Ask QA: Should You Always Report Bugs?
Someone recently asked me:
Should you keep raising bugs that you know won’t get fixed? Isn't it a waist of people's time during the ticket triage to look at very minor issues?
Answer: First of all, QA should not be looking for reasons to NOT create bug reports. QA should file tickets for every bug that they encounter. Then they should assign the right priority to that issue. It's up to Product/Dev to decide on how to triage the minor issue.
Tickets should be created for every issue. Here are some reasons why:
Sometimes they get fixed: In some instances, I have seen developers fix multiple issues in a common code base just because they have the file open and can make the modifications.
It's a test of a good QA Team - Engineers and Product will see that QA is active and finding things. It shows that QA is looking for issues and reporting them. If customers are reporting issues that QA isn't finding, well that could question how good the QA team is.
Bug Patterns - I have found that finding little bugs can lead to finding the bigger bugs. When developers are sloppy in some areas, it's a sign that they may be sloppy in another area. So when I find a minor issue. It makes me stop and think, is there another issue here that may not be so obvious.
Maybe the Feature isn't Ready, yet - If QA finds a lot of minor issues, it's might be something that the product team to sit back and take notice. Should a new feature/product really go to market with so many minor issues? If they aren't addressed now, when will they be?
Don't be Discouraged
Minor tickets can be frustrating to find and report - even if QA knows that no one will read the full bug. However, there may be a time when the bug will get fix, so it's important to report the issue.
- Don't spend too much time writing up the minor tickets. Just do the bare minimum on reporting. If the Dev team needs clarification, you can always go back and add value to the report.
- Generate a report of the minor bugs. If you do daily or weekly QA reports, make sure to highlight the minor bugs found. This will help highlight the issues that QA has found. There's strength in numbers.
- Combine Issues - When you have some downtime, revisit some of the old minor issues and see if it makes sense to combine several minor issues into a single ticket - which may make the new ticket a higher priority.
Test Cases Specs
On January 25, 1988, Presiden Ronald Reagan gave the following quote at his last State of the Union address:
"As ancient Chinese philosopher, Lao-tzu, said, "Govern a great nation as you would cook a small fish; do not overdo it.""
The idea behind this quote can be applied to Test Cases for regression. I often see that when initially creating the QA test engineer will overwhelm the test case with complex steps and validations. It's important to keep the test case as simple as possible.
Tips and Tricks
Each test should focus on one test result. (This will make it easier to downgrade tests.)
The test case should piggyback on a parent test. For example, the common path to the functionality being tested. This will make it easier to change future enhancements and make it easy to test that test against other paths that customers may take.
Keep the test as simple as possible. If there's complexity involve consider splitting the test up.
Test Cases should be easy enough that anyone new to the organization could be able to follow the steps. However, don't keep it too simple to miss out on the reason behind the test.
Just like developers have code review, QA should have their test cases reviewed by their peers.
Google Chrome URL Page
Google Chrome has a lot of useful built-in debugging tools. You can access many of these via single page URL Cheat Sheet:
How Does this Help QA?
There are some useful items here for QA. Here's a few that I encountered.
Chrome Flags - This is where you can see all the experiments available in the current browser. This is useful to check on every once in a while. You can find out what new tools are may get released soon and you can play with them.
Accessibility - This allows you to take a deep dive in Chromes Accessibility based on what's loaded up right now. You can find out more about Accessibility testing that's available in Chrome on the Accessibility Page.
User Action - This is useful when you want to see how Chrome responds to certain keyboard/mouse actions.
Inspect - You can setup the Port Forwarding. Useful when you need to debug an issue on a particular server. You don't have to change your system settings, simply enable it at the browser level.
Net-Export - If you need to do a data dump of web activity, this is the place to get it done. Simply enable the logging and perform the activity. A full dump of all the activity will be dump into a JSON file. This is useful when a developer may not be able to reproduce the error on their end, and they may find something in the logs to explain why.
Dino - Everyone's favorite Dino game is available whenever you want.
Fun to Explore
Take some time to check out all 85 links on the Chrome URLs page.
Again, to access the page type this URL in the Browser URL field: chrome://chrome-urls/
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:
Here’s a traveler’s secret. After all that packing, chances are you won’t use half of what you plan to take. So why not save yourself the trouble and leave half behind? A neat trick that I’ve always done is set out all the clothes that I want to bring and definitely think I’ll need and then take just half of them.
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....
- A substitute for manual testing. It should complement the sum of all the testing done in a release cycle.
- Easy. It takes time to build a strong test foundation that can be properly maintained.
- 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.
- A One and Done. Automation requires lots of regular maintenance work for feature changes and to build in complexity.
- 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.
- 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.
- 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.
- 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?