How did you make your feature deadline?

General opinion:

That’s the feature — planned.
It will take me X no of days to implement the feature — implementation.
For fixing the mess-ups a day more added — buffer.

Deadline: X+1 days.

Alternate opinion:

If my colleagues at GreyB would be your QA. Bye-bye, your deadline.
Your feature is never going to make it with your general timeline.

Why would you never go over their testing?

1. Writing Software = Learning Something You Don’t Know When You Start
   If you have a weak understanding of the thing you are working on, your planning will be weak. That’s definite. You won’t know many of the flows of your own product. When planning ask your product lead the WHY and come back with HOW before you implement it.After implementing verify if you made the right thing.
2. Nice confidence
   You’ll miss a lot of perspectives until you work with a developer mindset. Believe me, never give him the code just as are done. You’ll have to find a corner to cry. Develop, take a 5-minute break, and come back to USE the feature with your IDE off. You’ll destroy your feature yourself.
3. The 3 Weeks and 3 Months Problem
   There’s a quote that goes like “If I give you 1 month to do some work that can be done in 1 week, you’ll spend 1 month doing it”. Something like this I don’t know exactly.

But you know what there would be a difference between that 1 week and 1 month. In 1 week you would have rushed to complete the stuff somehow. What would happen after that?

• It’s working on my machine — but we can’t ship your machine, We already have dockers,, Kubernetes etc. for that
• It’s not replicating — I don’t care, it’s in the client’s default settings
• I had tested it — You should have tested better
• I never knew this flow — Make the better test cases. We so your team doesn’t need every feature KT after you have made it. No need to destroy everyone’s sleep, let TDD handle this!
• It’s not a bug, it’s a feature — Yep, an undocumented feature

In 1 month,

• It would be working on the client’s machine
• Every possible incident would be tested
• You won’t need a tester’s testing
• The requirement would be the delivered feature.

Obviously, you can’t have this long deadline. Instead take some time to plan before you implement, with your day building it. Add some sensible time to handle screwups if any and a day to test and review.

So, your deadline is X+2 at least.

Amount of time it takes to develop!= The timeline

deadline_time = deadline_time + time_to_plan + time_to_review + time_to_test + time_to_cry_in_corner

What ways do you use to make the testing faster and get things to reach production?

A code that can’t be tested is flawed

Originally published at https://haox.illued.space on September 13, 2023.