Recently I have been assigned to work on a major requirement that falls between a change request and an improvement. The previous implementation was done (badly) by a senior developer that left the company and did so without leaving a trace of documentation.
Here were my initial steps to approach this problem:
- Considering that the release date was fast approaching and there was no time for slip-ups, I initially asked if the requirement was a “must have”. Since the requirement helped the product significantly in terms of usability, the answer was “If possible, yes”.
- Knowing the wide-spread use and affects of this requirement, had it come to a point where the requirement could not be finished prior to release, I asked if it would be a viable option to thrash the current state and revert back to the state prior to the ex-senior implementation. The answer was “Most likely: no”.
- Understanding that the requirement was coming from the higher management, and due to the complexity of it, I asked all usability test cases to be written prior to the implementation (by QA) and given to me, to aid me in the comprehension of this task. This was a big no-no for the folks at the management as they failed to understand this approach. Knowing that I had to insist on my request and the responsibility of this requirement, I insisted and have fallen out of favor with some of the folks, leaving me in a state of “baffledness”.
Basically, I was trying a test-driven approach to a high-risk, high-complexity and must-have requirement and trying to be safe rather than sorry. Is this approach wrong or have I approached it incorrectly?
P.S.: The change request/improvement was cancelled and the implementation was reverted back to the prior state due to the complexity of the problem and lack of time. This only happened after a 2 hour long meeting with other seniors in order to convince the aforementioned folks.
3
Loads to be said about all that. Due to this being Programmers.SE I will ignore the aspect about falling out of favor with some folks and your “baffledness”. If you want input on those, I suggest you pay workplace.SE a visit instead.
Apart from that, let’s look at the technical issues here:
-
You are a developer (I assume here), that tells the QA how to do its job. Obviously, you should be well prepared to answer the following questions satisfactorily:
- Why do you know better? They worked in some way before, now you want to change it, so you better give them a reason to.
- Are you in a position to demand a change of the development process? QA probably has a process to adhere to and you asked them to screw it. Again, better have a good reason.
-
QA test cases are not supposed to be available to developers up front for a reason. TDD is one thing, but the whole point of QA is to have an independent verification. If you are biased by their test cases you undermine their whole system. Personally, if I was working in QA this would be my #1 reason for not giving you test cases.
-
You might have mixed up use-case/”usability” and “test-case” in your question. The difference is huge. As mentioned above, you have no rights to access QA test cases in advance, but you should get access to use-cases for the feature you are supposed to implement. Though, the use-cases are normally not maintained in QA anyways. You might even have to come up with them yourself in cooperation with a customer or product manager.
-
You said that you were “trying a test-driven approach”, which causes an immediate question to jump to mind: Why trying? Is there a culture of TDD at your workplace or not? If there isn’t then you have to tread very carefully and slowly (see the above questions, except that they will be asked by your co-developers instead of QA this time).
In essence, this might simply be a big misunderstanding and if you point it out as such you might be lucky to fix things with those other folks. We cannot tell here what exactly you said to them, but if you truly demanded from them to violate their processes, years of experience, and sacrifice the whole point of their verification work – just because of you – then you may want to approach them again in a much humbler way instead.
2
Trying to do TDD out-of-blue on highly complex requirement is never good idea. TDD is meant as long-term approach and commitment. TDD won’t make it easy to implement change requests and new features overnight.
Also, like Carl said, having answers as “if possible” and “maybe” only shows lack of understanding and commitment from side of management. If you properly explained all ups and downs of your implementation and what might happen if things stay the way they are now, they should have answered either yes or no. That is the key role of management. Deciding what to do based on what people under them say.
1