Break down traditional QA silos and empower developers to own quality checks.
Ever heard the expression: “Old habits die hard”? I’m sure we can all relate to that in some way or another, but this expression also stands true for software testing. With an ever-growing number of tech start-ups occurring all over the world, the need for software development grows, and software testing alongside it. More interestingly, we’re seeing a shift in the way software development teams approach how they handle testing; traditional QA practices are evolving, and QA’s are taking notice.
Now, traditional software testing isn’t dead, is it? Software development teams still follow the standard development life cycle; plan, develop, test, release.
Right, so, what’s changing? Tech-startup companies are being squeezed with so much vigorous competition out there, it pays to be first to the market. Whether it’s for a new niche that’s becoming trendy or a shift in consumer behaviour driving that change, development teams need to deliver quality, and they need to deliver it fast.
“Quality Assistance” a term introduced and made popular by tech giant Atlassian has helped create the shake needed to move the stagnant QA practices. #QualityAssistance isn’t about how QA’s become better, but about how QA’s are guiding developers to become better testers; with such guidance, developers are more self-reliant with the code they’ve written (i.e, bug-free) and they can confidently release code to production without a once-over from a QA team member.
Old habits do die hard but change is good
The drift towards a better solution is happening slowly: such a seismic shift doesn’t just occur, it evolves. The transition can be slow and sometimes difficult, but we know that ultimately software development teams are the beneficiaries.
One of the difficulties we incur during this evolving phase, is less about the understandings and benefits, but more-so about our habits. As creatures of habit, we’ve become a-custom to a standardised practice, so adapting to change takes time.
It is vital teams allow for time to experience the benefits from such change. The support from management is imperative throughout this shift and will require their understanding along this journey.
With developers gaining confidence and knowledge, eventually, we’ll see the segregation between the ‘develop’ and ‘test’ steps shift towards; plan, develop, release.
The QA’s responsibilities have evolved
While the scope of a developer has remained fairly constant throughout the years of software development (i.e, code features), the expectations for QA engineers have changed.
It’s now common practice to hire QA engineers with knowledge and know-how for writing good automation or have the expectation of learning to do so. The hiring process puts more emphasis on whether a QA engineer can write automation scripts, overlooking the fundamentals and skills required for someone who performs effective testing.
While a QA engineer writes automation and performs testing, it’s not a sustainable and reliant practice. In the end, we have to compromise and choose either: a fully functional automation suite or a partially failing automation suite in favour of performing quality checks for acceptance criteria.
QA engineers now believe that in order to remain competitive in an industry that’s rapidly growing, we have to absorb an ineffective approach and deliver on both.
Teams need to embrace the change and QA’s should be the servant leaders in driving that change by teaching and guiding developers as well as the business.
Like what you’ve read ? Subscribe and leave a clap and stay tuned for more!
