Brief QA Cycle History
Working in an agile software development cycle has caused documentation to become scarce. This is true for all the departments involved. Typical Waterfall methodologies had an enormous amount of artifacts that needed to be handed down to each department. And although documentation slowed the team down, it served as a guide and learning tool moving forward for the teams involved.
QA typically has a set of artifacts that should be created and updated for any given project. However, working in agile environments, QA artifacts have become somewhat obsolete. Exploratory testing has taken the need for more formalized test plans and test cases away, and automated testing has also lessened the need for formal QA documentation. That said, documentation is still very necessary. Here are some reasons why QA Artifacts are still vital:
Learn From Past Challenges
This one is one of the top reasons for creating some QA documentation. If QA is only running exploratory tests, then there is no evidence of what was tested, which browser it was tested on, what failed in the QA cycle, etc. As efficient as Exploratory tests are, it would be a good idea to still document these types of things somewhere. If you are using a tool like JIRA or TestRail, documenting it right inside the ticket upon verification would be good. If you are not, creating a spreadsheet of high-level test cases would be beneficial. Even if you are not submitting these to the team and/or client, keeping them for your own QA team’s record is important. You can use them to learn from your mistakes in case you missed something during testing, or to teach another QA team member how you tested a certain application.
Show Production Bug Evidence
Every QA Engineer has experienced a failed launch. Not the kind where there’s a missed bug for a broken image and/or broken link. The kind that’s so big, that the whole team is gathered in a war room on the phone with a disgruntled client. Those kinds of failed launches! Those are the times where the QA team needs to have proof of what was tested in the sprint cycle. The whole team will be trying to figure out who dropped the ball. If you have proof of what you tested, you can either show that you did test it and it was working fine OR be able to articulate that it was not tested but will be tested in the coming cycles. Either way, it’s a good idea to have it.
Provide Reassurance and Proof
Even if the client is not looking for anything from QA, it’s always a good idea to have something ready. Not only in the event of a Production Bug, but also as a "bonus” for the client. It also helps the department "look good”. Keeping a record of what you were testing for a client’s application once you complete a Project, and then handing it over appears professional and might help you when landing another contract. QA documentation has been used by many as a manual of how an application works.
Even if your QA team is running a very efficient test cycle, it’s still important to start keeping up with this type of documentation within an Agile environment. QA has a "feast or famine” type of work cycle. So, start documenting in your downtime to avoid slowing down the team’s velocity. Even if everything is fully automated, keep a record of what is tested in the automation tests for anyone to be able to read and understand what QA is doing each Sprint. This high-level documentation can be used by the entire team for reference.
Document Today, Avoid Headaches Tomorrow
Whether your QA work is for a large client or a small internal team, the value of validating and improving processes and information cannot be underestimated. The auditing and testing side of development makes life easier, sometimes so much so that teams forget it’s happening. Don’t wait until something’s broken or beyond repair to involve QA. We are your first line of defense against malfunctions and costly missteps. And if you aren’t sure how to involve QA in your next big endeavor, reach out to us, we can help.
DockYard is a digital product consultancy specializing in user-centered web application design and development. Our collaborative team of product strategists help clients to better understand the people they serve. We use future-forward technology and design thinking to transform those insights into impactful, inclusive, and reliable web experiences. DockYard provides professional services in strategy, user experience, design, and full-stack engineering using Ember.js, React.js, Ruby, and Elixir. From ideation to delivery, we empower ambitious product teams to build for the future.
