QA Blog Posts
Having a dedicated QA team is about as essential as having an editor for a newspaper or book publisher. QA will find things that developers will miss.
In these "trouble times" some companies may look to cut QA resources to save some money.
Joe Biden Parody
Four Reasons to Keep QA
- Second Set of Eyes on the changes - A QA Engineer can spot check the changes before it goes live, from checking to make sure that there's no risk to database locks to double-checking the critical path is working fine. QA can mitigate the impact of product changes.
- Domain Experience - A good QA team knows the product and can test changes based on how different customers may use the product. There might be different ways customers can interact with the feature and the best team to test it would be QA. In addition, during the off-time, QA should be doing research on industry changes and can use that knowledge to help better test product changes.
- Documentation Overview - Hard to believe but in QA, It's not always about bugs. QA can review help and tips to see if the terminology makes sense. Documentation may make sense in the design phase, but when going through a flow, QA can catch some ways it breaks the flow.
- Different Environment testing - QA can test the feature against different environments - such as different browsers or platforms. In addition, QA may want to test features against different locations to see if language or currency changes may break design or functionality.
A good manual QA team is just part of the winning team to delivering an awesome product.
I remember hearing at the Boston's Software Test Professionals Conference - "QA Testing is the little known Secret Ingredient to Start Ups."
QA Interview Questions
Due to the world-wide slowdown, some QA Engineers are now looking for new jobs. Being prepared for a job interview can really help make or break your chances of working with the company.
Over the years, I have collected a lot of useful interview questions. Here are a few that I keep seeing over and over, they may appear in different forms.
Sample QA Interview Questions
Sample Interview Questions that you may get asked:
Tell me about yourself.
This is an open-ended questioned. This is your chance to sell them on who you are and what value you bring to the position.
What is your experience working with Engineering?
Another open-ended question to see how you communicate with other teams.
Describe the type of QA testing have you done.
Don't just throw out terms, like Regression and Automation. Explain what you did in these environments. Come with specific examples of where your actions made a difference or talk about which testing that you enjoy working with.
What are some examples of pushing back when testing a ticket/issue?
Give an example of where you challenged a developer over an issue that you found. Explain why you felt it was an issue and what you did to push the issue forward. Don't make up a story, as you may be asked the same question by different people that are involved in the interview process.
When you audit other QA engineers work, what type of things are you looking for?
If you don't do any code reviews, talk about your team communications. Don't forget your stand-ups, team meetings, and Slack chats. Explain how you're an active participant to the QA team.
Can you give an example of how you handled testing a functionality when there were no specs.
This question is a test of your ticket ownership and how you manage issues. Talk about specific examples where testing an issue didn't go as planned - at least for the developer.
What do you do on a day to day basis?
Another open-ended question. This is usually asked to see what involvement you have with the team. If your applying for a leadership position, make sure to mention the various managerial tasks. If your applying for a technical position, make sure to talk about doing technical research and other tasks.
Kanban Board for QA
This is a sample of a QA Kanban Board that was done a few years ago. Some of the project names were changed to keep it simple.
This team uses Kanban for project management because its easier to focus on tasks rather than the deadline.
It's good idea to use this type of tracking so that people will know what needs to be done and if things are are being worked on.
In this project example, there was a single dedicated QA resource for automation. His job was to make sure that Automation was always up and running. In other teams I have worked on, they would have a separate Kanban board for automation tasks. Usually the availability of time for enhancements is scarce.
Documentation is important - This is something that QA should be doing all the time. QA should always be on the front line of creating and updating the documents. This makes it easy for team members to take over projects when QA resources are on vacation or furlough.
Excellent MEME Images
It's been a while since I added some new QA Meme images into the QA Graphic Library.
Here are various MEME graphics that I have been using in the past couple of months.
Visit the QA Graphic Library to see all.
Here are a few quick video clips that I use in Slack:
I am testing this as a new blog post, just seeing how Boostrap handles videos. If it works well, I'll certainly add additional video snips.
Test Better When Working From Home
As a result of the COVID-19 outbreak, many QA Engineers are now working from home. This may cause some issues with trying to stay focus while still delivering quality testing.
Here are some ways that can help stay focus and be a successful QA Engineer.
Keep a Daily Journal
During this social distancing period, track your home progress with a daily journal. A journal is one way to measure your daily productivity. It's a good way to show that you're being a productive
Writing Prompts are a good way to get your day started in the right directions. Here are seven suggested writing prompts:
- What challenges did you face yesterday?
- What testing technique would you like to learn today?
- What areas of testing could you use work to learn more about?
- What QA blog post topic would be interesting to read?
- What's something new you can learn today that can help you test better?
- Learn some new SQL trick and share with the team.
- If you had to re-do yesterday again, what would you do better?
Set Daily Goals and Expectations
At the start of the day, write down what you plan to accomplish today. Challenge yourself to get more done than you think is possible.
Writing down your goals helps focus on what you need to accomplish for the day. Simply spend five minutes each day and write down the things that you want to accomplish for the day.
Sample Daily Goals:
- Make sure that the testing queue is clear for the latest code freeze
- Update two automation test cases for the next release
- Learn something new with text formating in Jira
- Bonus: Update the QA Wiki page with SQL tips done with date sorting.
Working from home can be challenging when the kids are also at home. It can be hard to stay focus when everyone wants your attention.
One way around this is to chunk your QA tasks so that you're in the work zone for a set amount of time.
Also it's helpful to publish your daily schedule so that everyone knows when your in meeting and more importantly when deadlines happen - such as code freeze or release day.
Never Under Estimate the Value of Testing
Software QA is all testing and validation. We want to make sure things work as the product team planned and as customers expect it to work.
However, every once in a while the meaning of test changes. Such as this tweet from the World Health Organization:
Health Care Testing
Health Care testing is very important. Tearing down barriers and restrictions are important to make sure people are properly diagnosed.
For the next eight weeks many people in the United States will be inconvenient because of the COVID-19 outbreaks.
Next week we’ll talk about ways QA can be just as productive working remotely as they can in the office.
Testing Tool Blunders
She defined a "Blunder" as:
- Mistake caused by ignorance, carelessness or not thinking things through.
- People blunder when they don't see or understand.
The same thing could be applied to automation tools.
Automation Application Blunders
Over the past five years, I have evaluated various automation tools. There has been a pattern of feature blunders that keep occurring. They are more focus on making automation easy to create and not really focus on the day-to-day automation functionality.
There's a lot more to the automation process. So here's a couple of blunders that I see over and over:
Not Debugging Automation Friendly
Did you know that QA Engineers spend a lot of time debugging automation issues?
We spend a ton of time having to find out why automation test case fails. Then we have to decide if its an issue that needs to be reported to engineering or if the test case needs to be fixed.
Automation Test Cases systems should make it easy to debug and update.
I have encountered some automation tools where you would have to "start from scratch" and completely rewrite the automation step to fix an issue.
Reusing Automation Functionality
Many test cases have similar functionality. The test may share the same path to get to certain functionality - at some point, it changes to do something else. Wouldn't it be great to reuse common code.
Wouldn't it be great if a code change was made, say an XPath change, was made there was a single source file to change?
I have found many test applications where it's not possible to share code. So then I have to make the change to the same XPath in multiple locations. Which is very time-consuming.
Test Automation systems should have the ability to reuse code. Even better to allow XPath value to be defined in a global library so it can be used elsewhere.
Ya, There Are More Blunders...
Those two are the ones that I see over and over again. I have discovered that automation tools are not always written for all the common QA automation tasks.
Sure it's nice to make it easy to create an automation test case. But there's so much more into the whole process.
QA Memes by the Democratic Candidates
Tomorrow is Super Tuesday and the Boston area airwaves have been busy with all sorts of campaign ads. So to the honor of the candidates that are running for Presidents of the United States, here are some QA Memes:
Senator Bernie Sanders - "I am once again asking Developers to test their code."
Mike Bloomberg - "This Patch is ridiculous."
Joe Biden - "Test Cases!"
Senator Elizabeth Warren - "There's something about this release I don't like."
Jira - Show Recent Comment issues
Sometimes you may want to track comments you made in Jira Issues. This might be needed for a variety of reasons:
- Track issues that you worked on to record testing hours.
- Hold Engineering accountable for responding to issues you listed.
- Track team members comments on projects
Currently there's no "easy" JQL query to search for specific information related to the comment field. The only way to search Jira for comments is to use the Dashboard Activity Filter search tool.
Tip: You can set up multiple gadgets on a Dashboard to perform different searches.
Options with the Activity Filter in Jira
Setting up the Tracking Comments on Specific Projects
Instructions on setting up the dashboard to view recent commented issues.
- Go to the Dashboard, and create a new personal Dashboard
- Click "Add a New Gadget"
- Search for "Activity Stream" - You'll need to click "Load all gadgets" to see it.
- Click "Add gadget" to the right, then click Close.
- Click "Add a filter" define the project.
- Click the '+' and then use the selector to use "Username"
- Enter in a login, such as yours.
- Then click the '+' and then use the selector to select "Activity"
- Enter in Comment in the text box.
- Set "limit to 99 items"
- Click the Save Button.
Assuming everything is right, You should now have a Dashboard view of your activity stream.
QA Time Constraint
There are only so many hours in a test cycle. Any given company there's always more test than there is time to complete them. Obviously every product manager wants their test to be run at every release.
Yes QA Testing time is Finite.
Five Things I Have Learned about QA Time Constraints
Here are some of the things I have learned over the years that have made managing short test cycles. Not all of these strategies apply to every situation - many of these are from different companies with different test cycles - but they can at least help QA move testing forward.
- Propoer Planning prevents Poor Performance - QA Project leads should have an understanding of major changes that are being done in the upcoming release to decide what areas the team should focus more on. For example, if many changes were don't to support mobile, then probably less testing should be done with print actions.
- Acceptance Testing - Have a checklist of key functionality that should be working and tested in every release. These should always be working.
- Automation Rocks- We all know the value of automation testing - it can certainly help QA test more in a short amount of time. The downside is that QA needs to monitor the results for False Positives and False Negatives. Manual testing may miss some "obvious" bugs because testers are rushing through a test to find obvious bugs. Automation is great because it can run tests a 1,000 times the same way. It's not going to miss something because the tester is rushing through to find the most obvious bugs.
- Find Bugs Early as Possible - Use Critical Path testing to find bugs early in the test cycle. Work with the Product and Marketing team to identify all the critical paths with various products and services. The earlier you find blocker/critical bugs the better it is for everyone.
- Check List - Having a physical checklist helps to make sure that the product is well tested. This helps identify when you have to balance testing with offshore teams and make sure that everything has been touched. I have found a checklist is a way to track that testing is being done.
Sometimes bugs are missed by QA because they are unique. They can be hard to find during normal regression testing.
Here are a couple of examples of bugs making it to Production due to complexity of testing:
There was a bug that only occurred for French users of a website that I was testing. The bug occurred because the translated text was too long and as a result, a dialog action button was not visible.
QA missed this in testing because the focus on testing was on English. QA wasn't notified that a particular dialog box was being translated to French - which wasn't an issue at the time since text content wasn't part of QA testing.
JBoss Installation Instructions
At another company that I worked at, I was responsible for software QA while at the same time doing some installs and training for customers. The company developers put together some documentation on how customers can install the product. The problem was that the document only handled a particular set of customers and several customers started complaining about the inaccuracy of the documentation.
QA missed this because the document was working for many customers. There were no major changes in the application that would have resulted in needing to test the installation process with the customer instructions. What happened was the sales team was selling the product to a different set of customers that required QA to check the documentation.
I then walked through the installation with a couple of customers while at the same time updating the document to make sure that it was clear for particular environments and make sure the terminology matched the audience that was doing the install.
Five Things I Learned to Handled Future situations
While the above is very specific examples, there are many more similar bug patterns that I have seen over my many years of QA testing. Here are some things that I have learned:
- It doesn't hurt to every once in a while to take a step back and manually go through the sales flow of the application. Are things working as they should be? How does the product look to new customers.
- Work with Developers to get some QA tools to help with testing. The French problem was being solved by having a special URL query for QA to force the page to load with a particular translation. This tool makes it easy to test the key languages when major changes happen in the application. Also, it makes it easy for automation to test the button visibility against various languages.
- Review the code changes. It doesn't hurt to check out the code review to see what has been changed. Many times I have found that a code change was made without thinking of other consequences - for example, what happens if customers use non triditional UTF-8 characters.
- Learn from the Bugs that Excape QA. One of my weekly tasks is to review the causes of customer reported issues and to see how it was missed.
- Learn new QA tools. There's always something new to learn in QA. There's always some new Chrome Extension, JQuery tip, database query and security lock down.
How Bugs Escape
There are many reasons why bugs are missed by QA and eventually make it to Production. Here are some of the reasons that I have encountered over the years in various QA roles.
Sometimes bugs occur because the bug occurs during a complex situation. These are hard for QA to detect or identify.
For example: If you have 99 items in your cart and your language is French, the shopping cart page crashes.
Realistically these aren't going to be found by QA. With a little help from Devs, QA can formulate test strategies based on code changes. Such as learning more about a 3rd Party library or support for Unicode.
QA Tasing time is finite. There's always too little time to test every possible situation.
This is why test strategies are so important. During off time, the QA team should get together and audit regression testing. The team should focus on what risk areas should QA be a focus on.
This is why developers' testing steps are important. QA should get a "heads up" on what to test.
Stale Test Case Repository
Bugs may escape QA because the manual test case repository tests might be state. How often are you looking at manual regression tickets? Are they update with the latest design changes? Are QA Testers actually following through the steps?
At previous companies that I have worked with, we review the manual regression steps with key stakeholders on a regular base. How often? Usually when there's a big design or code change. It's a good way to get some input in how QA is testing their product.
Don't take manual testing for granted. Make sure to review manual test cases on a regular base - especially if there's a lot of bugs making it in production.
A good QA Manager once told me, "that if an automation test case passes several releases, it should be audited. The test may not be challenging the code enough to be useful as part of regression."
In the month of February, I'll explore more into how Bugs escape QA testing. I'll talk about various strategies that I have found to work well to combat these bugs.
Jira Board Shortcuts for QA
Atlassian Jira is being used by more and more Engineering teams. It's flexibility and standard tools help make it easy for teams to track tickets and sprint progress.
During Sprint planning, it's very helpful to know some shortcuts to help make navigation easier.
Four Shortcuts to Know
There are four Sprint Board shortcuts to know. Simply type in the number when you're on the sprint board.
|Active sprints/Kanban board:||2|
|Dock/undock the filters panel:||[|
The last feature, "Dock/undock the filters panel" hides the left gray bar - which is not being used while you're looking at a particular sprint board view. By undocking the filter panel, you get the valuable real estate back.
New QA Memes
Here are some original QA memes that I came up with. These are just common occurrences that happen in QA. In particular, QA responding to conversations in Slack.
All of these images are Slack "ready" and will show up embedded in chat conversations.
These will also work as Jira comments too.
Check out the Library
These and all QA images are in the QA Graphic Library.