Tag Info

Hot answers tagged

77

I do not think it's good that they make a contest out of finding the most bugs. While it is true that their job is to find bugs, their job is not "find the most bugs". Their goal isn't to find the most, their goal is to help improve the quality of the software. Rewarding them for finding more bugs is about the same as rewarding a programmer for writing the ...


17

I am going to disagree a bit with the other answers. "Finding bugs" for a tester is a bit like "writing code" is for a developer. The raw amount is meaningless. The job of the tester is to find as many of the bugs that exist that they can, not to find the most bugs. If tester A finds 5 of the 10 bugs in a high quality component and tester B finds 58 of ...


14

Based on my personal experiences, this is not a good thing. It almost always leads to developers filing bugs that are duplicates, ridiculous, or completely invalid. You'll typically see a lot of these appearing suddenly at the end of a month/quarter as testers rush to meet quotas. About the only thing worse than this is when you also penalize developers ...


6

There is nothing wrong with making a game out of finding bugs. You have found a way to motivate people. This is good. It's also revealed a failure to communicate priorities. Ending the contest would be a waste. You need to correct the priorities. Few real games have a simple scoring system. Why should the bug hunt? Rather than score the game simply ...


5

Performance testing seems to be popular It's popular in theory. In practice, I've seen only a handful of automated performance tests done and they were done haphazardly. How would I test that Build 1.4 is a pass/fail for this test? You define a pass/fail criteria. If you need the tests to be consistent, define some failure criteria and measure. If ...


5

Finding bugs is their job. As long as they aren't making things less efficient (for instance, by opening a bug for ech of 10 typos instead of one to cover several of them) this is encouraging them to do exactly what they're supposed to be doing, so I can't see much of a downside.


5

I worked at a place that took 5 hours (across 30 machines) to run integration tests. I refactored the codebase and did unit tests instead for the new stuff. The unit tests took 30 seconds (across 1 machine). Oh, and bugs went down too. And development time since we knew exactly what broke with granular tests. Long story short, you don't. Full integration ...


4

I'd say there are plenty of companies that do this. IBM for one big (400k+ people) one (I work there). There are lots of old applications, some running on mainframes that haven't been touched in years, and now can't really be changed, ever. They could be replaced, but it is hard to replicate their function exactly without full test coverage. There are ...


3

Ideally things would vary according to the rule of common sense. Martin Fowler talks about a unit as a class (plus related classes in some cases) and IMHO a unit should be a useful lump of code, this may be a single method where a method is quite complex, or a whole class as classes are the means of dividing a system into manageable components. A single ...


3

When we speak of running tests with parameters, what we commonly mean is running a bunch of tests with A=5, immediately followed by running the same bunch of tests with A=6, and so on, all of this together constituting a single test run. What you seem to need instead, is to run all your tests just once, but with a specific configuration, which may change ...


2

There is no "one size fits all" answer to where you should put the boundaries of your SUT. The optimal size of a SUT for unit-testing depends on a lot of factors, including The language and toolchain you are working with (how many errors can be detected by static analysis/compiling the code) The complexity of the product you are making How familiar the ...


2

Concept is good enough! Now, you must decide on what did you build - integration or acceptance tests and support/enhance them for single purpose. Here is the difference: Integration tests are used by developers to verify that application is basically working and run often from dev machine. TDD tests and bug reproduction tests goes this way. Integration ...


2

1) It is very hard to test static void methods but they must do something so what is it they do? If they modify global state you could read that global state, but the best thing is to refactor them into a better structure. 2) Unit testing is only for public methods. Even if you test all methods you can probably not input all parameter combinations so even ...


2

The answer to your question is highly case-specific. You already seem to be aware of various performance testing techniques. You must determine what your expected measurements are. It may be acceptable to start by saying "our expected measurement is the current measurement" and then just track changes over time. If it's "impractical or even impossible" to ...


2

There are many companies that claim to provide "commercial off the shelf" (COTS) products that will replace your legacy systems. My observations: If the system being replaced adheres strongly to some standard, then a COTS solution is likely to be a good fit. Examples are enterprise accounting, payroll and tax packages provided by companies like SAP, IBM ...


1

This is an expansion on @CandiedOrange's answer. To get started on shifting the attention to more useful objectives, consider something very informal and unofficial. For example, the developers could buy some small tokens and trophies. Each day that at least one significant bug was reported, leave a "Bug of the Day" token on the tester's desk. Once a week, ...


1

Sounds like you have way too many integration tests. Recall Test pyramic. Integration tests belong in the middle. As an example take a repository with method set(key,object), get(key) This repository is used extensively throughout your code base. All the methods that depend on this repository will be tested with a fake repository. Now you only need two ...


1

Integration tests will always be long running as they should mimic a real user. For this very reason you shouldn't run them all synchronously! Given that you are already running stuff in the cloud it seems to me like you are in a prime position to scale your tests over multiple machines. In the extreme case, spin up one new environment per test and run ...


1

It sounds very much like Paypal payments are processed. Paypal allows for sandbox accounts purely for testing purposes. Here is the link to Paypal testing guide I heard good things about it from my friends.


1

Testing software is a full time professional job. It needs a good brain, talent, and lots of experience to become a good tester. It's ridiculous to assume that a software developer, no matter how clever, can come close to a professional tester when testing is just a small component of his daily work. On top of that comes the problem that subconsciously the ...



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