Date: 28th January 2013 events #sheftest
Why QA needs to Change
By Christopher Kozak and Ashwini Ingle
It’s unarguable that Continuous Delivery has gone from being just a CTO friendly buzzword to a central requirement for a high performance delivery team. It’s no longer cutting edge to merely check in your code to source control and have Jenkins or other continuous integration box run the unit tests. You have to be able to get that code out into a live environment as fast as possible and that means Continuous Delivery. The ability to deliver code into production at will has a direct effect on your bottom line but to do this effectively you need two things, 1) understand the important areas of functionality that the customers really use and 2) be able to test these areas as quickly and easily as possible. The first is a business issue but the second boils down to automating your testing.
The trouble is that most of the industry holds on to a quality assurance process that is directly at odds with this. The reasons are mostly historical but companies have had varying levels of success in the drive to automate QA. The level varies on how highly the company values this ability. So what levels of QA do we commonly see?
We will interlace the presentation with personal experience as well as real examples of what we think “good looks like” from a project we are currently delivering for an internal system at ThoughtWorks.
The talk will be loosely related to some of the concepts discussed here (written by former ThoughtWorks colleague, Martin Anderson):
Changing the Language
By Stephen Blower @badbud65
Use positive language to support your case when raising bugs and/or understanding requirements and user-ability.
Support developers/designers/BA’s don’t fight against them
Use safety language: Quote: Paul Holland: Always use safety language. Never use absolutes.
@QualityFrog My variant: Always use safety language. Never use absolutes.
— Paul Holland (@PaulHolland_TWN) November 9, 2013
Stay away from saying everything has passed, and signing things off.
Conversely, don’t become a blocker or think you are the gatekeeper with a none shall pass attitude. You provide none judgmental, specific information for stakeholders to make informed decisions on, you’re not paid enough to say something is good to go or not.
A community of passionate individuals whose purpose is to revolutionize software design, creation and delivery, while advocating for positive social change.