Hi
I’ve been in a situation where we have had to create an app from scratch in 4 weeks. Solid deadline with no more time than that!
In the timescale, what would you focus on? Is there anything you would drop?
2 Likes
Without knowing the domain: Some business activity that the user would be able to do on the phone better than on web/desktop. Scan something, take a picture, check some stats or events?
I wrote this back in 2013, it seems still to apply:
If you can come up with just one business transaction – that crystallizes why the customer will be kicking and screaming to want to use your application, then you have a very good understanding of your customer and all you need is that one testcase.
It’s still available on the Wayback machine (it’s the second part of the article):
1 Like
Are we talking about test scope? And I guess from the tone in your message doing a product in 4 weeks is an unusually short time frame?
This is a question that I like to ask during hiring interviews in that case. The scenario is this: Scenario 1: A product owner, for a product you know, comes to you on Friday lunch and says we have done some changes to the product and we are in a state of panic because we need to ship it to the customer this evening and I know it is not possible for you to test everything but I would feel better if you had a look at it this afternoon. Versus Scenario 2: Same product, same change but you get the information Monday morning instead and you have the entire week before it needs to be shipped. What is the difference what you do during the afternoon (4 hours) in scenario 1 and the first 4 hours Monday morning in Scenario 2?
For me there should in principle not be any difference between the two. As in you want to spend the first hour to get as much information as possible and like so trickle down into less and less likely areas to find information. Thus know that if you are cut short in your process it is always the least important things that remains. In my experience for this to work you need to do this for both the development of the product as well as the testing of it. If development starts with unimportant things you will be forced to test unimportant things.
So some things needs to be established. If we are talking about fixed time frame you either have to have variable quality or variable scope. It does not really matter which you chose as the principle will be the same. If quality is variable, start by making a product with full scope at low quality, and improve it in iterations. And if the scope is variable, start by adding the core functionality and add more functionality in iterations. Right now we are in the fixed time frame, fixed quality. So here is how we deal with scope. For a specific feature we describe it as what is the Must Have version of it. Like there have to be an input field where you can write your address. And then what is the Wish version like selecting it from a map or something. The we plan so the first week we do the plumbing and start with the Must Have. We also use some ideas from Deliberate Discovery where we start with the areas where we know least. That way we are less likely to get surprises towards the later stages which can cause overtime / delay.
As a tester in this I typically test in line with what we are developing like starting with the plumbing, looking at basic logic etc. Then I also make sure to do probes into areas which typically cannot be done done until the very end. But I don’t want us to find out that it is off the mark to late. In our case that is device support and performance. But that have to depend on your product and your domain. I also use any extra time to make sure to create tools to speed up test execution later. Like a tool to crosscheck translations and generate test data etc. Since early I am not to busy but will be later.
Another common pitfall when having to little time is to start to early. Like it’s is more important that we do something that we do the right thing. Where the reality is that you cannot afford to spend to much time doing the wrong thing. So invest time into do some planning. And here I do not talk about assign task in time or estimate size of things, that is a waste of time. What I do talk about is the conversation like. First we will spend a few days to explore which of these options we should go for then we will aim to have a all plumbing and must available for external feedback after week 2. We see that the biggest unknown for us is the new technology we will use here so let’s start by getting clarity about that first where we have done implementing a map selector 20 times already so that is a thing we can do whenever. Doing a sports analogy, it’s the game plan for how you as a team will win the game. Not the in minute 30 player 1 will pass the ball to player 2.
Think Risk Based, think early / instant feedback, think iterations. Don’t finish one thing and move to the next. Finish a little bit of everything and grow from there. Good luck!
3 Likes
thanks for sharing - i really enjoyed reading this one. It does still apply!
1 Like
Lots to digest in your comment. I like the idea of the “Must have” and the “wish list”.