Software developer trying to bring order into his craft. I write about my journey, thoughts, and practices. Currently focused on web frontend with React.
Unfortunately, that's common, and it tends to be one of the core issues behind not knowing what to test.
Making the code the code base as small as it can be without compromising readability is an excellent approach to keep code maintainable. I'd say that it's one of those practices that we should follow almost always :) But this approach won't fix the situation :/
Usually, when we don't know what to implement, we should ask management or someone who should know that. The real problem comes when management doesn't know what needs to be implemented because the client also doesn't know what needs to be implemented! It might seem that the client is at fault here, but actually, it's just the way these things work, and the sooner we accept that, the faster we can start working on a solution.
Most often, the client has a general idea of what the app needs to do for it to benefit the business, and it seems quite well thought out when he talks about it. But as we start to develop three issues become apparent:
The client kind of knows what needs to happen, but he doesn't know HOW the app should make it happen.
We find out that we didn't entirely understand what the client meant.
The idea that the client had of what the app needs to do keeps changing.
The longer it gets to release something that real users can use, the worse the three issues above will get, and ironically, the harder it will be to release something that real users can use. And this is because we lack feedback/guidance from the real world, so everyone involved in making the app (from clients to devs) will get stuck in their heads trying to guess what the app needs to do to be a success. But we are awful at guessing, and it's easy for this process to keep going on indefinitely and burn through all the project's budget.
One solution to this problem is to simplify an application to the point where we can sit down with the client and easily map what's on his mind into inputs and outputs. Or in other words, we can write acceptance tests for the app. So if a client wants an app with 50 features, we might start with a single feature, or with degenerates of 5 the 50 features that we can figure out with the client how they'll work. Which approach to take will depend on which one leads to the shortest route to deploy something for real users because the goal is to get stuff out there as soon as possible. The faster we deploy, the sooner the client gets money, the quicker we get out of our heads and get guidance from the real world, and the more likely the project is to succeed. Also, there isn't a better way that I know of, to make sure that we're on the same page as the client than to show him/her a working application. After we have something working, it doesn't matter how minimal it is, the conversations start to become a lot more specific and a lot more productive.
Well, I ended up writing a bit more than I was expecting. The essence of what I wanted to say is that not knowing what to expect as an output of a test, can be a sign that there's a problem with how the project is being managed and that it is urgent to reduce the scope of the next release to the point that we can clearly define the requirements. Otherwise, the project will likely fail.
I hope that my mumbling is useful in one way or another xD
aaah thankies!! I can't go into much details regarding the project but I'll definitely try to use your suggestions in order to help ease the unit testing process. I appreciate your input a lot \o/ (though I guess you could use this reply as a blog post wink wink)
Software developer trying to bring order into his craft. I write about my journey, thoughts, and practices. Currently focused on web frontend with React.
Unfortunately, that's common, and it tends to be one of the core issues behind not knowing what to test.
Making the code the code base as small as it can be without compromising readability is an excellent approach to keep code maintainable. I'd say that it's one of those practices that we should follow almost always :) But this approach won't fix the situation :/
Usually, when we don't know what to implement, we should ask management or someone who should know that. The real problem comes when management doesn't know what needs to be implemented because the client also doesn't know what needs to be implemented! It might seem that the client is at fault here, but actually, it's just the way these things work, and the sooner we accept that, the faster we can start working on a solution.
Most often, the client has a general idea of what the app needs to do for it to benefit the business, and it seems quite well thought out when he talks about it. But as we start to develop three issues become apparent:
One solution to this problem is to simplify an application to the point where we can sit down with the client and easily map what's on his mind into inputs and outputs. Or in other words, we can write acceptance tests for the app. So if a client wants an app with 50 features, we might start with a single feature, or with degenerates of 5 the 50 features that we can figure out with the client how they'll work. Which approach to take will depend on which one leads to the shortest route to deploy something for real users because the goal is to get stuff out there as soon as possible. The faster we deploy, the sooner the client gets money, the quicker we get out of our heads and get guidance from the real world, and the more likely the project is to succeed. Also, there isn't a better way that I know of, to make sure that we're on the same page as the client than to show him/her a working application. After we have something working, it doesn't matter how minimal it is, the conversations start to become a lot more specific and a lot more productive.
Well, I ended up writing a bit more than I was expecting. The essence of what I wanted to say is that not knowing what to expect as an output of a test, can be a sign that there's a problem with how the project is being managed and that it is urgent to reduce the scope of the next release to the point that we can clearly define the requirements. Otherwise, the project will likely fail.
I hope that my mumbling is useful in one way or another xD
aaah thankies!! I can't go into much details regarding the project but I'll definitely try to use your suggestions in order to help ease the unit testing process. I appreciate your input a lot \o/ (though I guess you could use this reply as a blog post wink wink)
haha thanks a lot for the suggestion. I think I'll follow it :D