QA Image Library
Check out the growing QA Image Library. This is my personal colleciton of Slack Images for that perfect QA Moment.
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.
How should you display the date?
April 5th, 2021 - June 4th, 2021
According to the Manual of Style, the easy to read format would be:
April 5 - June 4, 2021.
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
- Right click on the page and select Inspect (Or type in Option Command I)
- Select the Network tab on the top of the DevTools page and then reload the page (Command R)
- Select any Name (These are the various request that were made during the page load time.)
- 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?
You can learn more about HTTP Requests Response Headers from DumbTutorials. It's a good place to catch up on everything HTTP.
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:
Many years ago in India there were a lot of Cobras and they were dangerous. The British government thought it would be better to encourage locals to catch the cobras. They ran cash incentives for people to kill them. However, the locals saw this as a business opportunity and started cobra farming. Once the British caught on realized that the incentive wasn't solving the problem they stopped the bounty. The farmers were stuck with a lot of cobras and ended up setting them free. The net result was a lot more cobras than before the bounty.
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 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.
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.
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
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
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.
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.
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.
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.
The purpose of these blog posts is to provide you with all the information you ever wanted to know about Software Quality Assurance testing but were afraid to ask. These blog posts will cover topics, such as what is software quality assurance testing, how to create test plans, how to design test cases, and how to create automated tests. They will also cover best practices for software quality assurance testing and provide tips and tricks to make testing more efficient and effective.
Check out all the Blog Posts.