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.

Yagni

Yagni is an abbreviation for "You Aren't Gonna Need It," referring to code that does not add functionality to pass tests or meet requirements.

Four Reasons QA Should Be Aware of Yagni

Makes Code Hard to Read - Developers may leave unused code - perhaps for their testing or design process. When someone else picks up the code it could cause confusion as to what the functionality is doing. This is true for QA as sometimes they need to read the code review to understand how to unique exploratory testing around the functionality.

Removed QA-Only Code - Developers may add code to help QA validate certain functionality. This should get removed from the code, not commented out. This way the code doesn't accidentally get activated.

Adds Risk to the Code - If it's not part of the feature, then there's no reason it should go out in production. Keeping Yagni code in could open a back door to your application.

Applies to QA Test Plan - Check your test case repository. Are there tests that fit into the Yagni principle? Why are they are part of your test plan? Clear it out so that your tests don't look so overwhelming.

Interesting Side-Note

According to Google translate Yagni is Turkish for "That is."

Throw it over the wall

Some Developers use QA as their testing environment without testing their code first. In some situations, if the code compiled they thought it was safe for QA to test.

In software development, this is known as 'throw it over the wall' testing. Developers feel that the Change is so small - they just give it to QA to test it.

Not a Good idea

Bad news - that's not what QA is for. At least not in an agile environment.

Developers shouldn't be sending code to QA without having some sanity testing. They should at least know that the change they are making are working.

Yes they should be testing their code.

What Should QA Be Use For?

QA should be used to test security risks, performance issues, vulnerability, and usability. It shouldn't be the front line of any testing.

Developers should always be testing their code. They should have accountability for how their code works.

November Graphics

Here are some more QA based graphics that I am adding to the QA Image Library.

If there's anything you like to see, let me know!

Jira Because - You Have Issues

Billboard - Don't Tell QA

Test Your Code on a street billboard - QA reminding you to test your code before handing it to them.

Quality, Stability through superior firepower.

QA Release Checklist

Release time can be a crazy time for QA. There are always things going on, from last-minute issues discovered by QA to last-minute infrastructure changes for security purposes.

It's really easy for QA team leads to get distracted and forget some of the essentials that need to happen for a release to be deployed successfully.

QA Checklist to the Rescue

The easy solution is to keep a release checklist. Something that will help you remember key things before a release gets deployed.

There's no 'one checklist fits all.' You should create a checklist that works best for your environment.

The nice thing about the checklist is that it acts as a release journal. If there are deployment issues, you can make notes on what to do in future releases.

Example Checklist Items

• All QA team members signed off on the release
• Automation Pass
• Automation total run time is acceptable
• All Critical Paths have been tested
• Release Branch matches the test branch
• Database migrators have no locking vulnerability

Checklist Stationary

You can use any digital software to create the checklist: Evernote, Microsoft Word, Notepad ...

I would recommend a paper solution. That way you can focus your computer screens on the release.

The checklist can be next to your keyboard - reminding you of all critical tasks.

I would highly recommend getting the Emergent Task Planner and using that as your checklist. It's really well put together. You can build a timeline of when sign-offs have to occur before the release is deployed.

Unhelpful Error Messages

Someone on Twitter asked:

I couldn't think of anything right away, so I search my collection on Google Photos, and I found two that I thought are worth sharing.

Apple Error

This is there that I am now getting while trying to install Big Sur on my iMac. There's no indication of what I should do next.

There are plenty of websites that give some clues on what to try. Most of the advice is around some technical issues that Apple had during the original rollout. However, I am still encountering the issues - many days later.

Still working on finding what this error means. Hopefully, this gets fixed soon, and it doesn't involve formatting my computer!

Flavia Coffee Pot Error.

This is an error that appeared on a coffee machine at work. Multiple people have to get involved to fix this issue. Phone calls were made to the coffee company to report Error 328.

Turns out the problem is with a stuck freshpack. I found a website that explains how to fix the error.

It would have been so much better to say something like, "Clear the Stuck Freshpack."

Note: This isn't a problem anymore as the company has moved on to a machine that makes single-serve coffee with the need for K-cups or Freshpacks.

World Quality Day

On November 12, 2020 is World Quality Day.

World Quality Day is celebrated annually on the second Thursday in November.

World Quality Day

Each year the IRCA and CQI team put together a focus on World Quality Day.

This year the purpose of the day, is to put in the spotlight people that go above and beyond to improve customer value.

Quality at Drug Companies

I think there should be a focus on the various Quality Control teams in the drug testing field. These people are working overtime to make sure that the proper medication is being distributed. In addition, they are making sure that test results are accurate as possible.

Don't forget to thank your favorite QA person on World Quality day.

When Not to Automate

There are times when automation isn't practical. Here are four times when automation seemed like a good idea but in reality, it isn't.

When Automation is a feature that plays in minor significance of the product.

Don't waste valuable Automation resources in testing minor issues. You should think If automation finds an issue how likely will it get fixed? While it's great to automate everything in a project - it's more fission to automate the most critical thing.

When the product or feature may get constant change.

If things are going to constantly get changed, why would you want to build automation around it? Why subject yourself to fixing known failures? I have found in the past to wait for a particular feature to be stable before committing any automation time and resources. Your best bet here is to talk to the product manager about when the product will be stable for automation.

If developers are still coding based on an integration branch, there's too much change to add it to automation.

When it's used for Metrics testing.

There are plenty of other tools available they can help with metric testing. Don't use QA automation resources for metric testing.

When it takes a long time to run a test but has little value and slows down the ability for other critical test to run.

You should consider how long it will take to run a test and decide if it's really worth using automation resources and time to run a particular test. Even in multithreaded environments, the QA test still takes time to run.

Halloween Graphics

All week long we are celebrating Halloween here on cryan.com.

Here are some Halloween inspired Memes for those that work testing software.

Happy TestOWeen

Scary Testing

Tester of EastWick Logo

I put these are part of the cryan.com's QA graphic gallery.

Make Test Steps Great Again

One of the things that I see over and over is when QA engineers fail to provide detailed testing steps to reproduce a bug. The tester assumes that the developer understands the vague steps to reproduce the bug.

There are usually three reasons why QA gets into a vague state.

1. Rushing to get the bug into Jira. Perhaps QA found a bunch of similar issues and they are reporting as many issues as possible.
2. Working on the project for a long time and knows the project very well. Why add details that no one cares about?
3. Bug isn't critical to get into the details. Usually, the title says it all - why add details to a low priority issue?

QA is in the Details

QA is in the details business. One of the rules of any QA Engineers:

QA should always be going out of the way to paying fantastic attention to the testing details.

This applies to everything from writing test cases to writing automation. The value QA brings is in the details.

Don't Make Exceptions

The thing is if you start making some exceptions to the rule then it slowly becomes a habit.

This is similar to how when you make an excuse that it's ok to eat one Twinkie when you're on a diet. Next thing you know you justify going to McDonald's for lunch.

At the End of the day

It's important to keep providing detailed steps on how to reproduce an error. No matter how unimportant the issue is. You never know some future bug may encounter a similar issue and your detailed steps could help speed up the patching process.

Remember: Don't take shortcuts.