GoodHarts Law

Recently I was browsing around Sketchplanations collection and found this graphic around Goodheart's Law:

GoodHeart's Law

When a measure becomes a target, it ceases to be a good measure.

QA View

Understand GoodHarts Law is useful for QA because it helps understand that without a clear objective - specifically one that benefits the consumer- can cause a loss of focus. Thus all the work and effort may cause more harm than good.

Some questions to ask when working on a project. Don't wait for a retrospective to ask these questions. Think about these at the beginning of each sprint:

What are the goals of the project?

What solution are we trying to solve?

Will this solution actually fix the problem or will it cause more pain points to the customer.

Check out sketchplanations

Definitely check out other Sketchplanations drawings. They do a great job in explaining various topics.

Computer Change Up

Last week I got assigned a new laptop, and this week I'll be configuring all the various QA applications on it. One of the things that came to mind during this process is how many testing tools that I don't really use anymore.

This got me thinking that moving to a new laptop is a good time to do an assessment of the tools that I really need to have. Over the years, I tested various apps, but never uninstalled them.

Consider a Change

If you're using the same laptop/desktop for the past three years, you may want to consider changing a laptop/desktop before starting that next big project. It's a good way to start from fresh.

Five Things I Have Learned

1. Getting the computer into a productive state takes time. It takes time to find the right software and licenses. Once you have the installation done, there some time needed to get the software configured to how you remember it - such as custom keyboard shortcuts and layouts.
2. I used the opportunity to rearrange my physical desktop. The new MacBooks have USB-C ports and I can connect external monitors on either side. This allowed me to switch things around so I can have a more practical workspace.
3. I have found that cloud services make migration so much easier. Dropbox and One Drive make moving files between the computers easier. Also, many of my apps settings are stored in DropBox, so they pick up various configurations when the applications are installed.
4. Keep it simple. I am committed to not installing software on this computer that is also not essential to my work. My other computer had a lot of graphic apps that I really don't need.
5. Document Everything. I used various sources to store software license keys. As I am installing apps. I am recording them in a single app - so I have a single source for next time. Including documenting what apps are being used for what functionality. Think of it as a Wiki page for essential apps.

Manual Of Style

Sometimes QA will encounter some wording that may look a bit off. They may need some clarity on the reading of the text.

One of the best solutions is the Manual of Style by Wikipedia. This is the writing style guide that is being used for millions of webpages.

This is a useful reference to have when you're looking for support to a better solution than being implemented.

Example Format

How should you display the date?

According to the Manual of Style, the easy to read format would be:

Stlye for the Modern Era

The nice thing about this style guide is that there's a whole section on hyperlink format. Check out the link section to get an idea on what text to link to.

Chrome Requests Response Headers

Sometimes QA needs to debug the HTTPd request the browser is making. This is usually to make sure some conditions are met or to figure out why something isn't working.

In Google Chrome this is pretty simple task.

Finding the HTTP Header

1. Right click on the page and select Inspect (Or type in Option Command I)
2. Select the Network tab on the top of the DevTools page and then reload the page (Command R)
3. Select any Name (These are the various request that were made during the page load time.)
4. On the right, select the Header tab

This is where you'll see the request and response between your browser and the server. There's a lot going on here!

You should be able to get a lot of data that may help troubleshoot any issues.

Why Should QA Know This?

QA should have the knowledge of all the tools in the browser toolbox. Debugging JavaScript, jQuery and Angular isn't enough. Sometimes, as part of validation, QA may need to read the HTTP Request Headers and verify that the browser is sending the correct information.

You can learn more about HTTP Requests Response Headers from DumbTutorials. It's a good place to catch up on everything HTTP.

Cobra Effect

The cobra effect is when you provide a solution to a problem that results in the problem becoming worst.

How the effect got it's name:

QA Example

Here is a real-world example where I have seen the Cobra Effect in QA.

The $1 Patch Jar

There was a point in time that we were having too many Production Patches. Many of these patches were a result of engineering not providing detailed descriptions of the risk of the changes being implemented.

Management implemented a "$1 Patch Jar" where those that were responsible for a patch had to put in money. This was to encourage developers to test their code.

The problem was that people were putting in a lot more than $1 just to cover any future mistakes. As a result, Developers were more relax about testing their code knowing that they already "paid" for the bug and the patch count didn't go down.

The jar was discontinued. Management instead implemented more responsibility for Dev and added that responsibility to their performance review.

I intended to post a couple of examples, but I could only think of the one. If I think of something in the future, I'll sure to post that.

Automation

Automation is not testing it's checking.

What is Automation?

Automation makes hunmans more efficient, not less essentials

Automation is not a silver bullet - it won't immediately increase productivity, but if approached correctly, it will eventually support increase releases, greater test coverage, and overall quality of the product.

The Great Debate?

There's this debate in the testing community on the purpose of automation.

There's one group that talks about how automation is testing. They argue that automation tests to make sure that the build is stable and any changes doesn't break existing functionality.

There's a different group that says automation is checking. They argue that automation is only checking predefined paths and not testing situations that may be unique to the change being made. While critical paths may be working, some other functionality may be broken.

Team Checking

I am with the team checking. I believe that the purpose of automation is to check the stability of the build. Once automation passes, QA can perform manual testing.

Automation can be limited to the scope of checking/validating. In my experience, it can be tricky to automation 3rd party integration. Manual testing can be more effective in validating functionality.

Automation Has Value

Saying "Automation is Checking" doesn't change the value of automation. Automation plays a valuable role in the testing process. Don't put your eggs in one basket and solely rely on automation as your testing tool. Automation complements manual testing.

Automation test cases should be designed so that the build/branch is stable for manual testing. It should be checking that the critical paths are working.

Final Thoughts

There's no such thing as a manual or automated tester. Are you a manual or automated programmer?

June QA Images

It's been a while since I added some images to the QA library. Here are some new ones to my growing collection.

Be sure to check out all the QA Images in the QA Image Reference Library

http://www.cryan.com/qa/graphics/2021/QualityAssuranceLogo2021.jpg

http://www.cryan.com/qa/graphics/2021/ReuseAutomationCode.jpg

http://www.cryan.com/qa/graphics/2021/ModernTestingChalk2021.jpg

February QA Images

Here are some QA graphics that I created for fun. I did some searching online and was surprised that there are good options to choose from.

Feel free to use these in any email or Wiki page.

QA Rule 1

Test Better

Think QA

The Art of QA

QA Reference Page

Check out all the QA Images that I have in my QA Library.

The Best 2020 QA Posts

It's time to look back at some of the best posts of 2020. (Check out the 2019 Post.)

• Slack Tips for QA - (February 11) Some useful tips and tricks to get the most out of Slack.
• Dynamic Bookmarklets - (June 24) Great way to build a Bookmark that is time based.
• Letter to the QA Manager - (September 9) An interesting letter that I found. Helpful in understanding the relationship of a QA Engineer and a QA Manager.
• Best QA Advice - (October 14 ) Some great QA advice that I have gotten over the years.

2021 Goals

I'll keep posting useful QA Tips and Tricks that I learn. Most of the information is around the Software as a Service model.

I don't have any specific content targets. I'll keep the content going through February. I may take a break for some time to think of useful content to post.

QA Graphic Collection

Here's some new graphics for the QA library. All month long, I have been collecting and using some QA memes.

Be sure to check out the entire QA graphic collection.