Tag Info

New answers tagged

1

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 ...


1

I think how it will be(or how it already is) if it goes on like this, you wont necessarily get lower quality. Al though I think it will decrease the quantity to quality ratio. It depends if this is a bad thing or not. It depends if reporting bugs about screen enhancements, usability, or stupid bugs. is something you really dont want. If this is clear ...


5

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 ...


9

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. You want developers writing the minimum amount of code to solve a particular problem, ...


38

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 ...


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 ...


3

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.


0

Sometimes I use option 4 Use the strategy pattern. Create a utility class with static methods that delegate implementation to an instance of pluggable interface. Code a static initializer that plugs in a concrete implementation. Plug in a mock implementation for testing. Something like this. public class DateUtil { public interface ...


0

It seems most of the answers here mistake this question as "how do I automatically detect race conditions?" when the question is really "how do I reproduce race conditions in testing when I find them?" The way to do it is to introduce synchronization in your code that are used for testing only. For example, if a race condition occurs when Event X happens in ...


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 ...


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 ...


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 ...


0

Yes you should always test the system with all real-world architecture if you can, some problem may be only occurred in real system/data tests (out of memory/locked connection/environment stableness). If the business logic and data communication is proven to be working great, the next thing you should focus on will be stress test for the service: Regards to ...


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

Without gettting into an argument over what a 'unit' test is: Yes you should test your sql/sprocs. especially if you (foolishly) put business logic in them. you can use database snapshots to set up dbs https://msdn.microsoft.com/en-us/library/jj851212%28v=vs.103%29.aspx 'Test all your methods' is a good rule because it allows no room for ...


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 ...


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 ...


0

It sounds like your code base is growing large, and some code management will help. We use Java, so apologies in advance if I assume this. A large project needs to be broken down into smaller individual projects that compile to libraries. Java tools like nexus make this easy. Every library should implement an interface. This aids stubbing out the library ...


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 ...


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 ...


-1

I think you should try Morelia: https://morelia.readthedocs.org/en/latest/ It passes your 4-point requirements list: It's BDD tool built on Python's unittests module Executed tests are textual description. If you can automatically run traditional Unit Tests then Morelia can be run same way. I think the most common CI for github is Travis-CI which can run ...


2

You want to eliminate "professionalism and attitude" from the equation which is the only thing that will stand the test of time. It doesn't matter what job you do, if you treat your job as a profession you will always be looking to improve, which naturally makes one vested. Those who treat their job as a job, tend to just do what is necessary and may or may ...


0

If a defect is found it's the developer's fault, if a defect isn't found it's the tester's fault, and when anything happens it's management's fault. Developers are motivated to make bug-free code, testers are motivated to find the bug-filled code, managers are motivated to find bug-filled employees.


1

Involve them in every step of the process. Have them attend future design meetings. Have them present during pre-grooming and grooming if doing agile Emphasize the importance of always asking question "So, how will we test this?" during grooming. Have them present during daily scrum if you have one Have them work on test plans with developers - before the ...


3

But how are testers, aside from attitude towards their work, vested in the releases they test? So your developers only care because they might be oncall for night/weekends? If this is the case you are in a very rough situation. Because that team is much less vested in their work than you realize. If they only thing holding them accountable is a fear of ...


7

You mean, aside from the whole "giant production bugs leads to QA people getting fired" invested? At least in some companies I've worked, QA served as second tier technical support. They would get called alongside (or before) developers if an issue appeared in the field, since they often had a better grasp on the quirks of the shipped product than ...



Top 50 recent answers are included