The goal in your test cases is to validate a problem that has been solved. It starts with understanding the problem and reproducing it. If you don’t know the problem you can’t reproduce it. If you can’t reproduce it, you can’t validate the fix. One action drives another, impacts another, and makes another come to fruition. Without knowing the problem, you cannot reproduce it, without reproducing it you cannot test it. You need one to…
If you can’t do it through the app, there is probably an API that will you do it or a background process. And although this is great, this begs the question – why can’t you do it through the app itself? Why is it restricted? What was the reasoning? And if you’re now doing it through the API, why do you then need the app? What is it giving you? Give your App the same…
When your company is new, your licensing model is simple and perhaps even non-existent. “Want our product, please take it, and thanks for using it.” “Want to use it for your team? Here’s a team license.” “Want to use it for this building? Here’s a site license.” Simple, achieves the goal. You might not need a license today, but if your customers need to hire a licensing expert to understand what they need to buy…
Upgrades used to control Software Delivery. How well do you upgrade from one version to the other, do you run them side-by-side, etc, etc? When we deployed client/server the big separator is that they were ALWAYS distinct. Now we live in a world where we can “toggle” between the old and new, bringing about its own challenges. If you’re building software that toggles between feature sets there are a few scenarios you should always be…
The countdown is on, you’re almost there. Get that project out the door. Make it count. Complete. You’ve done the work, it’s almost time to celebrate your achievement.