With or without dedicated testers in your team, testing is not enough to assure the quality of your product. Intensive analysis and tight collaboration are the best quality assurance tools, especially for young, agile teams. 

Even if you have a QA team and a seemingly well-established test process, without enough analysis at the beginning of the thinking about the feature, you can be absolutely sure there will be omitted and ambiguous requirements, and the design will not meet the non-functional needs. There will be bugs that could have been avoided. All of these lead to a significant delay in your release. 

When you don’t have time to test, and you know there will be quick and dirty fixes, try to make it right from the first time. Analysis and collaboration are what your team needs to deliver high-quality features and speed up your deliveries. 

Who Tests When There Are No Testers?

Let me tell you about my last couple of teams. I have always started in agile teams as the first team member dedicated to deliberately working on the testing. They were young teams where the Product managers were doing the testing. At least some were trying to. 

The developers were not huge fans of testing, and if you ask me, it’s completely normal. But as one founder told me once, the release days were days of riot. 

So many software development teams work without testing knowledge and experience, and apparently, it’s possible. But it’s suicidal for the people’s work-life balance. It’s not scalable, and it’s not sustainable. The lack of deliberate quality assurance is a highway to hell. 

My first advice is to get a tester as soon as possible. You can team up with a testing school and let their students test. You’ll not be paying for this, and they will have a real use case to exercise on. 

Suppose you’re still not emotionally ready to initiate a testing process. In that case, the only way to assure the quality of your features is by intensive analysis and tight collaboration early and continuously until the feature is released. Product, Engineering, Design, Customer Experience – get together and start asking questions about the feature as soon as one of you comes up with it. 

Analysis Infuse Quality in Ideas

There is a misconception about testing that there must be something built to test it. The first phase of the test process is usually taught to be the requirements analysis which implies that there are requirements written already. 

But this approach is no longer applicable to modern development. Planning to start analyzing the requirements once they are written is too late. We can, and we must validate the idea before anything is put on paper. 

The primary function of testing is a corrective action with prevention capabilities. We test to find and correct errors to prevent them from turning into production bugs. However, its superpower is to infuse quality in things that are not built yet and avoid those errors. It’s done by analysis.  

Ideation 

The perfect time to start testing a feature is when there’s no feature yet. No user story has been written. We’re not quite sure what we are going to build or if we are building it at all. 

The common practice is leaving the product managers sweating over the specification for weeks and then presenting them to the team. It’s wrong, late, and inefficient. 

Product managers should not do their research alone, wasting time writing long detailed requirements that no engineer would care to read or understand. Even if it’s not long and detailed, don’t write anything. Talk about it first! 

Talk to the team about the need, the intention, the problem we’re trying to solve with the feature, and the goal we’re aiming to achieve with it as a business. Talk about how you envision your customers using the feature and how you want them to feel when they see it for the first time, and while using it.

The more we discuss the idea with the team who will implement it, the clearer it will become what they need to implement it. 

Analysis and Collaboration Techniques 

There are enough resources on ideation, design thinking, etc. What I want to emphasize is asking questions. The entire process is nothing more complicated than three meetings to brainstorm and ask questions. 

The Meeting Before the Kick-off

On the practical side, record the session. It will help you months and years later if you happen to ask yourselves, “What were we thinking?!”

Now, all of you at the meeting, take a deep breath, close your eyes or look through the window, and imagine your end-user on a device performing an operation with your feature.

• Where are they seated – at home, at the office, on the window in a coffee shop, at the airport?
• What device is this – a laptop, a workstation with three monitors, an iPad?
• Where are they coming from or going to?
  • late for important customer meeting commuting; 
  • been awake for four hours, did some workout, took a shower, and on their second large latte,
  • about to go to bed already, but too tired to fall asleep, so they are still working or casually browsing and have already made an unreasonable online purchase.
• How do they feel right now?
  • inspired and enthusiastic;
  • energetic and restless;
  • alone and depressed;
  • anxious and yet confident.
• Why do they want to use your feature at that moment – is it part of their job, is it part of their lifestyle, is it critical for their business?
• How do we want them to feel when they perform the operation – happy and content that it was quick and easy; confident that the task is successfully completed?
• Can we make a compromise with the way they feel? Can we live with our users being even a little bit frustrated because the operation is slow, tedious to navigate, the result of the operation is unclear, and they get a sense of doubt about the security of their data?
• Why do they want to do it in our system and not somewhere else?
• How many of these users do you want to reach? 
• When do we want it in production?
• Are we releasing it alone or together with other changes? These two might not have an answer we could give at that moment, but it also could be clear that there is a certain date which we cannot miss. 

All of these and similar questions add tremendous value to the discovery process. Answering them ensures the entire team is on the same page with the intentions about the feature. It drives the development of clear, thorough, unambiguous requirements and the design of the user experience that is both innovative and useful.

Whether your user is in a hurry or tired defines how strict validations you should implement. If they are inspired and energetic, that also means they will not be very patient with your features, and you cannot afford it to be slow and tiresome. And if it’s late at night and they’re about to fall asleep, you can’t assume they know what they’re doing and not unintentionally cancel the operation and have to start over, for example.  

The team now has a well-defined user need, a pretty clear UX design concept, has thought about the non-functional expectations, and has clarified what they need to proceed.

Once You Have the Feature Prioritized 

Let’s give the product manager and the UX designer time to come up with the user stories and the design. Yet again, they shouldn’t be doing this alone for too long. Once their drafts are ready for review, it’s time for the second session. 

Now we don’t want to close our eyes because there’s a document to read and mockups to look at. 

There are two review strategies depending on the product requirement document (PRD) and the UX readiness.

Design first

You could decide to look at the design first. Try to understand it. Imagine working with it. 

• Does it make sense? 
• Does it feel as it follows the natural flow of actions? 
• Is this what you expected based on the agreements from the previous sessions? 
• Is it attractive enough? 
• Do you just want to look at it forever because it’s beautiful? 
• Does it fit the rest of the system? 
• Are there any unnecessarily complex UI elements, or are we trying to make it too minimalistic for its purpose? 

One vital thing to remember is this is a collaboration session. I know that it seems like it’s a UI design review right now, but it’s not. 

It’s now the time to make sure that we can implement, test and release a high-quality, high-value feature as soon as possible without risking a load of regression bugs, generating a new pile of tech debt, and leaving our end-users befuddled when they see it. 

It’s not about the designer. It’s about the user, the team, and the business. 

Document first

The other approach, or another meeting, is to read the document first and try to imagine the design. 

You may now close your eyes again and imagine you’re the user. 

• Where are you going to click first? Then next? 
• How do you want to enter the data? 
• What do you want to see? 
• How do you expect the system to talk to you? 
• Imagine that your phone rings while performing the operation. Would you know what’s your progress in 5 minutes when you return to the system? 
• Do you shut down your computer in the evening? What do you expect the system to show you in the morning if you don’t? 

Then look at the design and compare if it reflects what you imagined. If it doesn’t, ask why. Is it because the design doesn’t solve the user experience needs as described in the product requirement document [PRD], or does the PRD not define the user need clearly? Or perhaps the requirements changed, and the document has become a bit outdated?

I want to open a big bracket here. Despite the fact that we’re talking about UX, it doesn’t mean this approach does not apply to APIs, for example. Another API will integrate with yours – how will yours deal with the other’s moods? What will your user see when they invoke your new API, it calls the external one, and the latter is unavailable, suddenly speaking a different language now and whining you’re sending a bad request or taking forever to respond? The questions are different, but you still need to ask plenty of them, and yet again, thinking together is the best you can do to make them up and agree on the best answers for you. 

The first thing every tester hears is to put themselves in the customer’s shoes. We want the entire team to do that. Remember, we are customers ourselves, and we have the privilege to provoke feelings in our users. It’s a huge responsibility. We’re changing their lives, just like another piece of software changes ours every day. We must make it right the first time and leave no place for quality compromises. 

A startup doesn’t have time for testing. It’s perhaps still validating its existence in the first place. Then you have no choice but to incorporate the testing mindset into your discovery process. Start critiquing your decisions even before you make them. 

It’s Time to Get Technical

We know what we want to achieve now. We have already done a bit of research. It’s time to propose our technical solution and break down the user stories into potentially shippable product increments of high quality and value. 

So far, I’ve seen the practice of assigning the task to a developer and then letting them walk the team through. 

However, the more I think about it, the more confident I get that the entire agile team should do the R&D together. That might be the mob programming everyone is talking about now. I’m not yet completely sure, but what I’m certain about is that a tech analysis session will not just save time but will build quality in your code while you’re building it together.

The calculation is only simple. One developer spends a couple of days alone, distracted by context switching, home emergencies, etc., and then meets the whole team anyway versus getting the entire team together and coming up with the skeleton of the code changes at once. Why not even with some tests? 

I have four questions for you for this session. Start with those and map them to the assumptions and decisions from the previous meetings. 

1. How are we going to test this?
2. What existing code do we need to modify or delete?
3. What new code do we have to write?
4. Dependencies, dependencies, dependencies?!
5. [Bonus] How are we going to test this?

Yes, this is the time when we must agree on the exact solution and how we are going to test it. Analysis will ensure that our solution serves the purpose for which it has been written and doesn’t break anything else.

I wish I had a number about how much of it can be coded and tested at a session like this. I don’t have a percentage, but it’s a lot!

It will speed up the whole delivery by times. The team will virtually fix most bugs before the code is committed. That’s why you need the entire team. Not just two developers pairing. You need the designer and tester as well if there is one. And once in a while, I would highly recommend that you invite the product manager too. 

The biggest problem in software development is that the Business, Product, Design, and Engineering are talking different languages and can’t really imagine the thinking process and the actual mental efforts to create a piece of working software. 

I claim that only the Testing is multilingual. But there are so many young teams that don’t have another option except to be too agile and don’t have the greatest testing expertise. Running collaborative analysis sessions like the one described here is their only salvation from sleeping at work and meeting each other’s expectations. 

This third session has two clear outputs – source code – written, reviewed, and tested. 

And a technical solution, explaining the changes how they were covered. And naturally, what’s remaining, if anything. 

Your feature is almost ready now. It’s so ready that you can safely deploy to production. Perhaps not today but this week. 

There are a dozen work items on your board today. Don’t overthink it. Please pick one from the To-Do or In Progress columns and run it through your new practice. There is a huge chance it will get to the Done column faster than anyone before. Try the approach for your next 6-8 user stories, features, bugs, improvements, etc. Record your experience and let me know if it’s working.

If you can’t wait to intensify your analysis practices and tighten the collaboration on your team, but you are not sure you could do it alone, book a free call, and I’d be more than happy to walk this journey with you.