Your favourite part of the development lifecycle

Full disclosure: I will be writing an article about this for Ministry of Testing, but won’t use anything specific in the article without asking you first!

So, we all know that shift left and shift right means that testers are getting involved all over the development lifecycle: Planning, Code Reviews, UAT, Release Management, Support, and lots of other bits that I’ve not mentioned.

What’s your favourite part of the development lifecycle? We all know we like testing (or I assume we do, since we’re here), but do you also love a good design review meeting? Three Amigos? Is live support and deployment your jam? I’d love to hear about it! Tell me what bits you love and why, maybe how you got into it?

I’d also love to hear about the things you do that are surprising for a tester role (even if they’re not your favourite thing!). Do you work closely with the marketing or support teams? Do you do a bit of UX with your team on the side? Testers can help with basically any part of the development cycle, and I want to bring together stories, ideas, and tips to help us figure out where we can provide even more value to our teams :smiley:

1 Like

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.

1 Like

That’s my favourite part as well! I mostly love collaborating, I think, and agile-y ways of working are great for that!

I like working with different people - working in an agency was great for that; we constantly met different clients with different wants and needs.

I like talking to internal users (marketing, support, content editors/managers/etc) who have a whole different set of needs that are often overlooked to focus on customer’s/external users needs.

+1. Also this sentence helps meet the 20 character minimum for a post.

My interesting area is writing user stories, screen designing, UI&UX, preparing wireframes and creating mind maps.

Planning is my favourite part. Like melthetester mentioned above, coming up with a solution to a problem.

In some situations I may have made suggestions that are not technically viable due to a lack of understanding of the technology, but it’s important to me that I can make those suggestions without feeling stupid. More often than not, these suggestions have made architects analyse/question their own solution and provided an alternative way of thinking about the problem.

For me, there’s nothing better than gathering round a whiteboard and drawing out a solution. This allows us to identify each section of our drawing to identify work items and potential risks in that area.

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.

The bad is trying to encourage the acceptance of testing and the improvement it can make, the company is moving to agile, and there is a lot of resistance.

Discussing requirements would take the first place with me. Refining the problem and the acceptance criteria, understanding the goal and the priorities, thinking ahead on how to test the product and last but not least, collaborating - ideally - with the whole team, both the brainy and the social side of me get scratched behind the ear.

A close second is support, as in investigating problems when they occur. On one hand, discovering e.g. the behaviours of badly documented systems or getting out of the users what they actually did to arrive at an issue, on the other, traversing logs, code, documentation of external tools to not just report what went wrong but also get an idea what can be done about it and learn more.
I have quite a lot of builder mindset in that regard and admittedly had to learn to keep it in reins so as not to lead the developers in a false direction. I was lucky to usually have worked with at least some devs who were either open enough to pairing with me on investigations or to trust my research and it really feels great to be a part of the team like that, too.

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 investivation progresses.

As for unusual things testers do I get my hands dirty building systems ready for testing. Building the hardware allows me to reflect on so of the issues and see the hardware issues a lot sooner.


I would like to get involved not just testing, but connecting with other group of the company (eg marketing, UX design, customer care) and other part of the development life cycle, but my position in a group not as good to do it. How can I improve this?

I would suggest that you reach out to someone within one of those departments and ask them if they can provide you with the information you would like. Find an ally within each of the departments that you want to know more about.

1 Like

I was having a conversation with Trish Khoo last week and she mentioned that testers are often good at systems thinking and then applying that kind of thinking to human systems and relationships, which means that problem solving at a team level, and relationship management and improving team communication is often something testers are good at.

It’s interesting to me how many different parts of the mindset that makes us testers can be applied to anywhere, really

It really depends on your context and team set up, but like @ali1874 says, finding allies is the best first step. Do you know a member of hte marketing team who’d be open to have a coffee/beverage with you and a quick chat about what they do, and how you can make their work easier?

Same for UX, design - in fact, can you get the UX and design team in to review work once it’s been built? Just an adhoc review of work can lead to some great insights from people who look at work through a dfferent lens

1 Like

So you deal with hardware as well as software and then test the software on hardware you’ve built/helped to build/put together? That sounds really interesting!

Thank you for your answers @gemma.hill1987, @ali1874, Important to look through the whole lifecycle, cause, as I see, not properly implemented to this company.
The other part of the company sitting in another country, not so easy to collect info from them, and find allies.