With the Shift-Up series thus far, we have explored the importance of testing and thinking as a customer. The basic premise is that we need to add another dimension to Quality Assurance other than Shift-Left and Shift-Right. This new dimension focuses on how your customer is actually using your application and if the intersection of your application, customer behavior, and your company’s business objectives all align.
To keep up with DevOps, testing and QA teams typically adopt a shift-up approach to move quality further up the software development lifecycle. The goal is to complete system testing, integration testing, and user acceptance testing (UAT) to ensure a bug-free release. While product quality has a direct correlation to increased revenue and positive business outcomes, this isn’t enough in the 21st-century marketplace. QA’s job isn’t just to de-risk applications by finding defects earlier but to help de-risk business strategy and potential problems with your user base by reporting customer experience defects.
Note: Test engineer Reena Kuni and software engineer Bekki Freeman also contributed to this blog.
On the Eggplant Functional team, the relationship between Dev and QA is very collaborative. We work closely together, use our Slack channel to organize regular walk breaks together, and frequently talk about ways to increase product quality.
It’s no secret that the digital revolution is quickly changing the way businesses and customers interact with each other. Like Blockbuster, companies that don’t understand the evolving needs and tastes of their customers will die, while companies like Netflix that fail fast, quickly adopt technology, and evolve, will thrive.
This week, I'm making what many consider a life-altering, religious change. I’m switching from Android to an iPhone.
Note: Test engineers Reena Kuni and Jeannette Smith also contributed to this blog.
Wow! It’s been quite a year in QA at Testplant. We’ve implemented so many new, big features, providing even more ways to expand our quiver of testing solutions—and yours.
In my last post, I described a test team structure that I've seen several companies (which I think are real thought leaders in testing) successfully implement over the last few months. Included in that structure is the sometimes controversial statement that scrum teams should have dedicated, professional testers; that is, we shouldn’t make developers responsible for all testing (though they should be responsible for white-box unit testing).
I recently presented at the Northern Lights conference in Manchester. This conference was hosted by the BCS (British Computing Society), and my talk was “Tools. Techniques. Trouble? Why test automation is getting more difficult, and what can be done about it.” You may have seen my blog post from ahead of the show, but if you haven’t yet, you can find it here.
I focussed on automating user interactions with the System under Test (SUT) and automating the creation of test scripts but not the automation of the testing process itself. I addressed both functional and load testing.
For those who weren’t there, here are the key points that I covered in my presentation: