Life in Testing
We all hate finding bugs. Like ants and spiders they get into everything. But also serve a purpose; ants fight termites and spiders eat other bugs. So can bugs in software be good? If you work in quality assurance or testing, they are good for business.
Here are Four tips to writing better bugs
Continue reading “How to Write Better Bugs with These Four Tips”
I am active on a number of social media sites and writing platforms. This quick article will highlight a few of the additional articles I have written for other platforms and how to follow me on social media. That way you can stay current on what I’m working on and testing discussions.
Over the past year, I have written a few articles on LinkedIn revolving testing and balance. I recommend taking a look at them if you like what I have written here. Below are links to articles I have written for LinkedIn, DZone.com, and Testlio’s company blog.
It is easy to let your regression suite get out of hand. We tend to throw every test case we create in the regression suite. It is a test case dump yard for everything test we create that isn’t in the smoke test. We want to make sure everything works as expected before each release. When we do this long enough, we end up with thousands of test cases.
Before you know it, your regression suite is a forest, when you only need a few trees. There has to be a better way.
Test cases are the keystone of the QA house. Test cases document functionality of the applications we test, training material for new team members, and the building blocks of our test plans. With them we can demonstrate and clarify what we are testing during our regression and production test runs. Without them the following problems arise:
Continue reading “The Key to Lasting Testing Success are in the Test Cases”
When your test automation is running fine, everything is great with the universe!
Then it happens. A test cases fails and your trace isn’t entirely clear as to where it failed. Even when the trace is clear, you still have to walk through the test steps to capture a screenshot for the bug. Imagine being able to capture screenshots at the moment of failure.
Imagine no longer!
“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Dwight D. Eisenhower
This seems like one of the most obvious parts for testing in QA. After all, it’s our artifact in Agile and the testing process. Believe it or not, I still see this fundamental lost in testing teams. Why is that? Why do we need test plan anyways?