Tag Info

Hot answers tagged

49

Where can we start? If you have a bug tracking system, get some sort of report of bugs for the past few years, broken down by module (if that's possible). Then make a histogram/pareto chart to see which are the buggiest areas (each bug counts as +1, each re-opened bug counts as +1, each "that didn't fix it you developer you" counts as +3). Those areas ...


25

I seem to recall there is a book that specifically addresses this exact scenario. Just a sec while I search Amazon... ...here we go: Working Effectively with Legacy Code I admit I haven't read this myself, but I've heard good things about it, and it has 4.5 stars.


22

You are about to embark on a journey without end, so it is the means, not the ends, that are important. Deciding where to start Business first: As Laura said, make sure that your work directly improves areas important to the business Metrics: It is critical to get good metrics both before you start and as you progress. Keep your metrics current, ...


13

Yes! Me too! Unstructured you say? You have my deepest sympathies; even so, it sounds like you have more weight to enforce rules and compliance than yours truly in my small but passionate team. Broadly speaking, this is what I did: Picked a module and began writing test cases for it - shooting for the moon, but still accepting what I managed to document ...


7

My first idea might be to break the system up into smaller components (not literally just from a planning perspective). From here you can prioritise them based on which are more important and work with those more important sections first. With such a big project this modular approach would help prevent a sense of your team getting no-where and perhaps keep ...


6

TDD is, in its truest sense, exactly as Aruna described it. The developer writes automated unit tests, watches the test fail, then proceeds to write the code that the unit test was meant to test, codes until it passes, and then refactors, all the while maintaining the core unit tests. Ideally (in my world at least), all of the tests should also be ...


5

TDD is generally code designed by developers first writing unit tests. There is a fundamental difference in how developers and QA people approach the concept of test. It is more helpful to think of unit tests as code contracts. These will be updated and changed over time and that is the primary difference. To a QA person a test, once working, should always ...


5

My first thought, reading your description was to go after where the largest chunck of sales run through the system. Keeping 80% of the dollars flowing correctly is more important than a workflow that maybe accounts for 3% of them. Since you said the testers also write the specs I'm assuming they have a good idea what business flow/transactions represent ...


4

Step 0, Get the build automated when they check into the source control system. TeamCity pro could probably be made to checkout and run a command - it is and it's free and easy to set up. Step 1, Write one test. Don't get hung up on unit versus intergrtion - just get one test. Step 2, Think of it as an oppotunity: What is it your business is about? Try ...


4

As well interrogating your bug cases, it might be worth speaking to the Business about which features provide them the most value / money. What feature would cost them the most money / bad reputation should it stop working.


4

Not to negate one anybody else has already said because I think it is all good advice, but the first step I would take is to run one very basic test. That moves you from having a system with zero tests to having a system with an incomplete set of tests that can be improved upon. My experience is that it's easier to complete a job that's already under way ...


3

I'm not sure whether or not these qualify as "well known", but they certainly qualify as "nasty" (and apply to any kind of application): Global gobs: heavy reliance on global values for information, making it difficult to tell what modifies which variable where. Ball of spaghetti: everything is closely related to everything else, and when you change ...


3

I had been into Test Driven Development and this is the way we approached it. The Developer develops automated unit tests even before he starts coding. Suppose there are 18 tests to validate the payment method. Before he writes the code, all the 18 tests would fail. After the coding is completed he would ensure that all the 18 automated unit tests are ...


2

None of TDD is manual testing. The whole idea of the "Driven"-part is that you get a collection of tests that run every time you change something to your source code, in order to maintain stability and prevent regression issues. Tests don't, howevery, need to be unit tests. If you prefer, they could be automated UI tests for example.


1

I'm not aware of a tool that's capable of doing this across multiple machines. I agree with you that TestComplete's capabilities in this regard are less than ideal. The master-slave setup is fragile at best. What I used to do in my previous job (with TestComplete) for a similar kind of situation was: As many of the applications as possible went on one ...


1

Additionally to Tangurena approach I suggest writing several tests at the highest level possible. Essentially this will be a test that your software works as intended. If most sub-systems are involved in the test, then any error in any of the systems will show a malfunction in that test. It will not pinpoint your problem but will show if some refactoring ...


1

This is a really interesting question, but it seems like the place to start is not at "what is TDD?" but more like "how can we not do things that have an overwhelming probability of shooting ourselves in the foot?" You might look through a post by "Joel on Software". It's something of a canonical reference for best practices around software development in ...



Only top voted, non community-wiki answers of a minimum length are eligible