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:

  1. 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".
  2. 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".
  3. 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
    When the question is "is it must-have?" the answer "if possible" means "no". – Carl Manaster Dec 19 '12 at 6:15
  • It looks like you tried to do the right thing when what was wanted was the fast thing. My commiserations. You could perhaps clarify what you mean by "I asked all usability test cases to be written prior to the implementation (by QA)"; I think you mean that the specification of requirements was insufficient to explain the required functionality, so you wanted a more explicit definition of what would be counted as 'correct' - am I right? – AakashM Dec 19 '12 at 10:11
  • @AakashM sorry for the late response. The short answer to your question is "yes". The long answer is: the req.s cannot explain all of this big-ass change request clearly anyway. I needed both a good understanding and easy, up-front testing in order to be confident. – arin Dec 26 '12 at 23:45

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.

| improve this answer | |
  • I second the idea of a differnt question on qwhat went wrong on workplace. It is clear that a good bit of the problem stemmed from the OPs inability to manage upwards correctly. To the OP if you choose to write this question, focus on how you asked for these things not on what you asked for. – HLGEM Dec 19 '12 at 18:57
  • @Frank awesome response, thank you. Honestly, I haven't looked at the issue from this perspective before and therefore I am glad to have learned these issues with this type of demand. No, there is no TDD implemented at my workplace. Additionally, and perhaps insufficiently, I wanted to cover all bases and learn more regarding the spec with the QA test-cases up-front. The req would attempt to touch all bases of the product and hence I wanted to be very safe. As to the reasons of friction, as you've said it is entirely off topic and not all related to my demands. – arin Dec 27 '12 at 0:01

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.

| improve this answer | |
  • Cannot agree more. – arin Dec 27 '12 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.