|Earliest: November 26, 2017||Latest: December 2, 2019||Total: 89|
Here are some quotes from the movie GodFather but changed for QA. After each quote is a brief description of the logic.
The GodFather is a crime novel by Mario Puzo, it was made into a movie in 1972. It stars Marlon Brando and Al Pacino as the leaders of a fictional New York crime family.
If Vito Corleone was a QA engineer these are things he may say:
GodFather QA Quotes
"Great tests are not born great, they grow great . . ."
No matter how good a test case is, there's always room to make it better. Don't assume that once you create a test case, that it will be perfect forever. There's going to change the may make the test run faster, test better or fix issues discovered by exploratory testing.
"I don't trust automation to protect us, I have no intention of placing my fate in the hands of machines whose only qualification is that they managed to con a block of code to test for them."
- Mario Puzo, The Godfather
Automation is critical to every test plan. However, it would be a mistake to let all the testing be done by automation. QA should run some manual critical path testing to make sure that the product is working as expected.
In my experience, I have found that automation may miss some critical errors and not raise an alert to the automation review team.
"Behind every successful test action there is a bug."
- Mario Puzo, The Godfather
No matter how good a test is, bugs will still get by QA. The important thing is for QA to find as many customer-facing bugs as possible. Realistically all bugs won't get found. (Some QA bugs may not get fixed because of low priority issues.)
IBM - You Make the Call
It's a slow week in QA, so I thought I put up an original QA graphic.
You Make the Call
If you were watching the NFL in the 1980s, you probably saw the famous IBM commercials where they challenged you to make the call. These commercials would show some strange plays and let the viewer think on what the correct call should be.
I reference that phrase, "You Make the Call" all the time to the engineering and operations team. So, I decided to create an updated graphic.
You can catch some of the classic IBM commercials on YouTube:
GitHub Tips for QA
Here are four useful tips on using GitHub for QA:
If your company use tags, you should know about the Tags project page. It displays the latest tag and get the ability to download the tags.
Find out the latest release and past releases with dates of deployment on the releases page. Not every project have project "releases" but those that do may have useful information here.
Learn some of the popular Keyboard shortcuts that are available on GitHub
Today I Learn: The fastest way to any GitHub Repository Wiki is to type in G W on any Repository page.
Use the Show All to view all the cool short cut options. (or simply go to the Keyboard shortcuts - GitHub Help page.)
View the Blame on Any File
Using the information from the previous tip, when looking at a GitHub file, if you type in b - you'll get modification information on that file. Perfect when you are debugging an issue and need to talk to someone about why a change was made.
One More Thing
Have you noticed that the Github search graphic is a perfect QA graphic:
I don't think it's realistic that people will be searching for bugs on GitHub.
Have you heard of the Mandela Effect?
Here's a brief description:
This is a "False Memory Phenomenon" where many people believe in a false memory. For example, Frona Broome had a false memory that Nelson Mandela died in the 1980s. That thought was shared by thousands of other people.
So how's does this relate to QA activities?
In release testing, people may have a false memory of features being tested before signing off on the current release. Everyone may assume that a feature was tested because it always is.
Note: This could also be true with automation. A feature that people may think is covered by automation is in fact still in development.
Value of Having a Checklist
This is why having a product-related checklist is critical to ensuring that all critical paths are tested. Don't just assume that someone else has tested it - find out by asking!
Reset the checklist for every release - that way you can ensure that critical features have been touched by manual or automation.
Best Screen Capture Tool for Chrome
When it comes to screen capture applications there are a lot of different options. You certainly don't need to buy one as all the major operating systems now have built-in screen capture tools.
If you constantly take screen shots of webpages in Google Chrome there's one tool that stands out above the rest. That's Snag-it.
A "Must Have" Tool for QA
What makes Snag-it the best screen capture tool for Chrome? Well, there are things that I can think of.:
- Snag-it will automatically capture the inner window browser frame area. This means that you can capture the main webpage area. You don't need to play around guessing the window area.
- Snag-it can capture the whole browser window. So if you need to show the URL in your screenshot you can.
- Snag-it can scroll and capture the full webpage. This is useful when you need to capture the whole page in a bug report or for archive purposes.
- You can select multiple regions. This is great when you have two Chrome browsers open and you're doing a comparison. You can also have shown the page against a product spec and highlight areas that are incorrect.
- You can capture both images and video using the browser region functionality.
- You can drag and drop a Bookmark icon to the Snagit Menu Bar icon, or to the Dock icon to quickly get a full website capture. Downside: If your site requires a login you would only see the login page. Still a neat way to capture a URL without having to load it in a browser.
- When you capture the website the URL is saved as part of the MetaData. You can view the content using the "Capture Info" under Effect Styles. Not only will you get the URL, but Snagit will display the Google Chrome version and the date/time of capture. All useful information in any bug report.
You can try out SnagiT for free for 15-days from TechSmith's website: Download Free Trial. After that the cost is $49.95.
What do you think?
Is there another tool that offers better screen capture functionality? Let me know what I am missing in the comments below.
Purpose of Smoke Testing
Smoke Testing is a critical part of Quality Assurance Testing. It's usually done to make sure that a deployment was done successfully. (Such as Code Freeze or Production Release)
When considering putting together a Smoke Test plan for you Software as a Service (SaS) application, here are some things to think about.
Five Things to Consider in Smoke Testing
- Critical path - Smoke test should focus on the critical path that customers will take to use your application.
- Focus on Making the Test Quick - The goal of smoke testing it to make sure they run fast. There shouldn't be complex steps to make sure the software works. Depending on the application, the smoke test should be completed in 20-minutes. Otherwise your simply running a modified version of a regression test.
- Logs should be open - Keep the Console logs open when running the test. (People do forget this!) This way you can catch errors as test are being run - such as tracking servers throwing 404s.
- Touch features that are most likely to break - Some Test should be testing complex part of the application that is likely to break - or have broken in the past. Examples might be the login process for existing users or uploading large files.
- Special Test for Production - In production smoke test, focus on features that are specific to production - such as load balance servers testing - as you may not have that in the test environment.
Test Early and Often
These are just some of the things that I think about when putting together an effective smoke test plan.
What are some of the things that you consider when forming a Smoke Test strategy?
What is Testing?
Last week someone Tweeted this:
Explain testing without using the word testing.
Seems like an easy challenge:
The job of a Quality Assurance Engineer is to make sure that the product delivered works exceptionally for customers.
Customer can be any group: paying customers, prospects, employees - you get the idea.
Alternatively it could be written as:
A group of engineers that constantly challenge the Engineering team that code complete is working as per specification.
Best QA Advice
On Twitter, someone asked, "What's the best testing advice you've ever heard?" I thought it was an interesting question, so I thought I share my "Top 5 QA Advice" that I have gotten over the years.
Top 5 QA Advice
Here are some of the best advice I have learned over the years.
"Never assume the assumption is true." - Kind of weird advice. But it was given to me when I was assuming too much when reading the testing steps of a ticket. My manager at the time said this to me so that I would try to think outside of the box and challenge the assumption that was given on the ticket. (For example, what if the user forgot the email address that they used in a "Forgotten Password" test.)
Pay attention to the details - Always make sure to check the little things when testing tickets. Because when customers are looking at the final work, they will notice the small details - especially if it doesn't seem quite right.
Learn SQL really well - Given to me by a manager a long time ago. He really stressed to make sure that I knew all the tricks of making a SQL Select statement. This not only helped me debug issues but also build some interesting QA Dashboards.
Document Everything - The manager would go on to say, "You never know when you may get hit by a bus." He was being funny. But his point was to make sure that test documents were updated and more importantly useful. This was a key thing. If I wasn't writing things down.
Always end an automation run with a validation statement. - Someone on the automation team gave me this advice when code auditing my automation. "What good is your test if you don't finish it with some validation statement." This is pretty good advice that I give to other people.
QA Off Cycle Duties
Usually the QA team is busy testing. However, there are times during the sprint cycle where there is nothing to test.
This isn?t a break for QA. Rather it?s a shift in QA duties.
Eight Things QA Does in the Off Cycle
A Combination of tasks that QA can do when there's "nothing to do."
Test Case Repository - Always be contributing to the test case repository. It's critical for QA to keep the content fresh and accurate.
Documentation - Update Wiki pages on testing techniques and test plans. Make sure that the Wiki has the most up to date information. Some things to think about: Critical Path Testing, Local Functionality Smoke Testing, Production Account information, Release Schedule, Staffing and so much more.
Review Previous Releases Testing - Self evaluation of how testing could have been done better. Think of ways that bugs and issues could have been caught early in the test cycle.
Performance Testing - How are typical tasks being performed in Production? Are new releases helping the performance of the application or hurting it? Review the findings with the product team on a frequent bases.
Load Testing - Is the website working well when it?s being hit 1,000 times? There are a lot of tools and techniques on how to do load testing without impacting customers.
Error Log Monitoring - Are there any errors that are being caught in various log tracking alerts?
Domain Knowledge - what?s going on in the industry. Are there any testing trends that QA Bloggers are talking about?
Audit Testing Functionality - What testing techniques can be done more efficiently using a different set of tools. If you haven't changed your testing tools in a year - your running on an old version of the QA Operating System. (A play of words on why Apple updates their OS every year.)
Red Herring in Test
A Red herring is is when an irrelevant topic is introduced during an argument to divert the participants from the original issue. Sometimes this is used to make false assumptions. This is commonly used in books and drama TV to mislead the viewer of the actual issue.
Red Herring in Test
In testing, a Red Herring is when multiple issues are found around common functionality. The multiple issues are the Red Herring. The core feature is what should be addressed.
Example Situation #1
Roxana is testing a new login page, and notices that the Credit Card field is not doing any server-side validation. In further testing, it is discovered that users can submit an form with an empty name and zip code. Separate tickets are filed for those issues.
The important question in this situation is the form field validation. What are the requirements and why are the "basic" functionality not set up.
Example Situation #2
During weekly testing its discovered that the local server keeps running into issues. The Release Engineering team fixes the issue and QA is able to move forward.
When testing, Its important for QA to look at the big issue and not get caught up with Red Herrings that can be distracted from the main issue.