By Gem Hill
We talk a lot about quality being a whole team activity, how testing doesnât equal quality and how software testers often do lots of work that isnât seen as traditional testing, but how can testers actually embody these principles in their day-to-day work?
I wanted to gather stories from the testing community about how they provide value and help their teams increase quality throughout the development lifecycle with the aim to provide insights and ideas for testers looking to step outside the traditional testing âphaseâ.
The Software Development Lifecycle: Gaining Context
The lifecycle of a product or changes to a product is going to be very context dependent. Maybe you work in an agency so you have to interact with clients from different contexts and adapt to their needs. Maybe you work on an internal product and can be a bit flexible as needed. Maybe youâre a contractor parachuted in at any point of a life cycle for an application. Maybe you work on hardware as well as software! There are a lot of different ways to apply the SDLC to a situation.
Options are pretty varied. Youâll need to do some investigating to see how the work filters through various people to get to your development team. Generally though, the life cycle can be split up into
Traditionally, testers have been siloed into the implementation phase, and then sometimes siloed once more in the testing phase of the implementation phase. As agile becomes a more accepted and preferred way of working, itâs more likely that teams become more flexible in what parts of the cycle they are included in. Even if you work in an agile environment, the idea of testers stepping out of âtraditionalâ testing activities (automation and manual testing), might be unusual, or even pushed back against, as people donât realise the different types of value a tester can add to a process.
Where Testers Fit Into The Software Development Lifecycle
Another cultural shift is coming to software teams. A lot of teams and testers are starting to âshift rightâ or âshift leftâ. This means that whole teams are spreading out of the implementation phase. A couple of examples are DevOps roles which are people who are traditionally developers branching out in release and environment management. TestOps is a similar role, where testers get to grips with servers and build pipelines.
Testers are also moving out to earlier in the life cycle; planning meetings and design reviews where knowledge of UX or accessibility may be useful and pairing with developers on unit tests and code reviews to ensure testability is baked in as early as possible.
Testers also seem to fit well into product owner, business analyst [PDF link], or scrum master roles. I think there are a few reasons for this: testerâs thirst for transparency and context. Thus the product owner and business analyst role often allow people to gather the wider business and domain knowledge that can really help with testing and test planning. Testers also want to help teams do their job the best they can, and the scrum master role essentially is helping teams get the job done by getting things out of their way, while also interacting and gathering context from the whole team.
Support teams are also a wealth of useful information for testers. Support often hear about bugs in live, and user needs for new features before anyone else. Keeping an eye on what support is hearing from users can be a really good source of pain points and information.
Iâve spoken to a few people while gathering stories and thoughts for this article, and it seems like testers apply systems thinking to human systems or teams. This is why testers not only can see places where we can improve teamwork and communications, but also are happy to facilitate or suggest these changes.
Being Professionally Nosey
It may be that youâre familiar with the lifecycle in your workplace, which is great. If not, however, it might require a bit of knowledge gathering first. If you have a product owner or product manager that you know, ask them (over a tea or coffee) about how work filters to them. Ask to sit in on a planning meeting or a meeting with the stakeholders.
If TestOps sound like itâs for you, then talk to the person in charge. If you have a systems administration or ops team, ask to see whoâd be happy to let you watch the next time they set a pipeline up. Maybe start with controlling the pipeline of work to your test environment, and go from there.
Talk to the developers about the release process, not only about learning it and documenting it, but seeing where the pain points are and what you can do to help alleviate the pain of a live release.
Maybe your work touches databases, and you can sit with a database admin to see where their pain points are, or where they can help you test how the product interacts with the database.
Like most things in testing, and software in general, asking questions is the way to go. Most people are happy to talk about their work, so donât be afraid to ask questions, and if you can find out what foodstuffs they like, bring some! Food as bribery/thanks for taking some time to help rarely fails.
If you donât know what you might be interested in, then try to spend time with a few different people. You may need to talk to your Line Manager or QA Manager first about spending time outside your traditional role, but being professionally nosy is a really good skill for a tester to have!
Show Them What Youâve Got
You might need to do a bit of convincing before you take on some new work (although from my experience, most team members are happy to have a helping hand). This can also be used as an education point if you feel your team has a narrow view of what you can do as a tester.
Put on a lunch and learn. Explain to your development group what you want to try, whether that be TestOps, sitting with the support team, code reviews, or a more ad hoc approach like, running RiskStorming sessions, or example mapping during the next planning phase.
Run a meeting. Offer to facilitate a retrospective, or a product demo next time it makes sense. Often these meetings either get sidelined, or donât happen at all, but if you can get them running well, youâll get a wealth of information and maybe some kudos for taking on a job that few people want to do.
Show your team how you test. I recently ran a group testing session on a new piece of work. I gave the development team a mindmap Iâd made of the new product, and a list of devices/browsers we wanted to support, and asked them to run through a timeboxed session. It was great for them to see how I came up with test ideas (using a mindmap and a timebox as opposed to solely referring to the acceptance criteria), and it was good for me to explain my testing to people, and discover things together about the application. Â
This means my team has an idea of what testing I do, and can help assist me and see what bugs are common. This approach may lead to me having more free time to do other things which provide more, or different value, to a project and my team.
Want Some Examples?
Before sitting down to write this article, I turned to the club and asked testers to share their favourite part of the development lifecycle outside of the traditional testing phase. I got some really interesting insights, and Iâve shared a few here:
âMy favorite part is coming up with the solution for a particular user problem, or rather designing and discussing the requirements for a story. This could include writing acceptance criteria, or designing paper mocks for workflows. It forces me to think about the questions I might ask later while testing. It makes me think of issues that could come up with the system Iâm working with. It lets me collaborate with UX/UI folks as well as BAs, and developers. Testing becomes a breeze as we walk through the process of development because I know exactly what to expect or changes that are being made as the story is played. I know these things far sooner than more traditional development processes because I got involved early and stayed informed.â
âDesign review for me, as Iâm new to the company and the technology it has been a good way to understand the approach and the structure of the teams.â
 - Nichole Quinn â
âThe best part for me is when a developer has been working on some code that isnât working for them and they ask me to help them investigate the problem. I love the mystery of what may be found as the investigation progresses.â
-Â Gavin Youngs
Own The Process
As testers, we can offer so much value to teams, far more than only automating some tests or exploratory test sessions. We only need to reach out and try to make it happen. Itâs hard to begin with, as there are many misconceptions about testing, and as testers, we tend to shy away from talking about what we can do and why itâs helpful.
In learning more about the way your team works and the gaps you can fill, you can gather more information, have fewer surprises, and hopefully, help your team work better together. Teams that work well produce better products.
Author Bio:
Gem Hill is a tester at BBC taster by day, and a podcaster by night. She talks testing and mental health at @gem_hill on twitter.
