Note: This is the second post in a series about the different roles I end up carrying out as a Quality Assurance Engineer. You can check out the first post here, where I talk about wearing my Tester hat!
Quality Assurance Engineer is a broad term that can cover a wide variety of roles and responsibilities. It can refer to a more specialized role, like Automation Engineer or Technical Support. It might be used to describe someone responsible for DevOps practices, or the person in charge of Scrum Master duties and feature testing.
One of Metal Toad’s continuing goals for developers centers around mastery. There are some high-level ideas and objectives around this, but part of reaching mastery has to do with enhancing and maintaining the code quality of our projects. We’ve put some workflows in place for our projects, including changing the way we deploy and QA.
The software industry’s shift to Agile project management methodologies has many of us happily burying the waterfall project artifacts – the 13 required management plans, comprehensive work breakdown structure (with dictionary) and predefined schedule have all lost favor as useless overhead. The Agile Manifesto explicitly values working products and responding to change over comprehensive documentation and following a plan.
When your client escalates an issue to your organization, it can be very stressful, but it can also be a chance to shine as an organization if the escalation is handled quickly and professionally. There is no way an organization of people can always be perfect, so the question really becomes is your organization one that can learn from its mistakes, handle others mistakes professionally, and focuses on solution vs. blame.
Many of the folks reading this blog are already familiar with Agile Software Development (a.k.a. Agile). Maybe your organization already uses Agile methodology, or maybe you’re considering adopting one of its many variations into your company’s workflow.
As we race towards the date of my presentation at this October's Digital PM Summit, I'm working to crank out the remaining posts in my series that started after I first presented on the topic of growth at Drupalcon Austin. This seventh post touches on one of the biggest debates of the last decade in digital and software project management: Agile versus Waterfall. In my presentation I purport to "solve" the debate in two slides. This post will give a bit more context to those two slides!
Here’s the first template post in this series, following my opinion piece on when to use a PM tool versus creating your own spreadsheet. True to our nature as proponents of open source software, we also enjoy opening up our process a bit.
