Tag Info

New answers tagged

1

I would recommend you to use Thread profiler to identify the real root cause of your production environment. Most of the time, it might be due to heavy traffic. If you really wants to make a copy of your production db(at least a part of it as a QA db) use slony to replicate data from the production to some other database.


1

There's no magic formula for thoroughly testing your code. I imagine even for a trivial function, like stringReverse() you can come up with a plethora of edge cases, lots of time thinking/writing tests: What if the string is null? What if the string is empty? What if the string is huge and takes up a large portion of available memory? What if the string's ...


0

A SDET role is pretty much what you make it, as evidenced by all its different names: QA/Developer, QA Engineer, Automation Developer. My current title is actually Test Engineer, which I had never heard it called prior to taking this job. Regardless of the specific title, it is a new position in most companies, so the expectations can be loose. "Help us ...


0

A lot depends on what will be riding on the software. If this is your basic Web app or your basic iPhone game, you probably don't have to do THAT much. If human lives will be riding on it, you darned well better believe you need to test the holy crap out of it. The Therac 25 story should be well known by now. Several people died as a direct result of its ...


2

For a long boolean expression you generally don't test every possible combination, but you test that each individual parameter has the appropriate effect. For example, given the following expression to test: (A or B or C) and D and E Test A by setting B and C false, and D and E true. Toggling A should now toggle the result of the entire expression. ...


0

If the number of possible combinations is reasonably small, you can test all of them. But if it is not the case and it is very difficult to maintain tests that cover all possible inputs, I would recommend testing only the most typical cases and edge cases(if there are any).


3

A substantial gap between business software and life-critical systems is the use of formal proof. Another is the strictness of the environment. Formal proof Tests are great to ensure that the system is free from known, identified bugs and that new features won't break existent ones (regression testing). However, the presence of tests doesn't imply the ...


-1

Parameterized tests work well for testing functions/features that have simple input when you want to test a variety of input. They don't work well for testing different functionality and complex input. They should not be used as a convenience structure to write less code.


2

I would like to say that the refactoring phase in the TDD cycle is the second most important step, and the one that make the switch from simpler and cheap to intended code. The most simple example I can think of is a constructor. My first test can be that my new class receives a certain parameter and check the value of a parameter. That's pretty easy to ...


1

You have to mock or emulate, and you have two very good reasons to do so. First of all, you have to mock or emulate whatever parts of the system your code interacts with, precisely because you don't want to alter the system, and you don't want your tests to depend on something as uncontrollable as the system. Yes, your emulation will not be perfect; yes, ...


0

The problem that you have is really in thinking about writing your test cases. You are getting stuck in TDD Dogma of needing to have only one test fail at a time. You define the behavior that you want to be that a function determines if two groupings of three elements have the same values. Then you define the test case checking only the first one. You ...


1

A lot of this boils down to what is "cheap, useless and ... little effort as possible." Here's another simple example: Write a function that returns the result of two numbers added together. Test: check func(2, 2) = 4 // Simple: func(a, b) { return a + b} I would like to think this is the first strategy I would take. Seems simple enough to me, but ...


0

Just create a specific factory or use default with redefinable value ended_at, as follows: factory :foo do ended_at { |foo| foo.ended_at || Time.zone.local(2014, 5, 5, 22, 15) } end or with ignore block: factory :foo do ignore do ended_at { Time.zone.local(2014, 5, 5, 22, 15) } end after :build do |foo, evaluator| foo.ended_at = ...


3

Implementing the "cheap" solution first is a good idea, not just because it forces you to write tests that cover all expected behaviour, but also because it sometimes ends up with you writing a simpler solution than you might have in your head. A good example of this is given in the book Beautiful Code, describing the FIT testing framework. This system ...


2

I think your problem arises only because the requirement is very simple and the solution comparing all 3 values at once maybe just a one-liner. Having slightly more complex requirements, and it will perfectly make sense not to implement anything beyond the scope of the already implemented test cases. Nevertheless, your "cheap approach" has indeed one ...


0

You're correct that demanding perfect Test Cases is unrealistic for most code (with a possible exception for Mars Rover code). I'd argue that it's necessary to honor the intent of the Test Case / specification in addition to the 'letter of the law'. In your example the developer has the opportunity to write an obvious bug. The correct action would be to ...


1

Named constants are often a better idea than magic numbers. In this context, however, there's not a lot of magic involved. On the other hand, in some languages, the time-value constructor uses a zero-ordinal value for only some of its values (e.g., JavaScript's Date()'s month number), or have illogical behavior such as accepting out-of-range values as ...


0

I am not sure where the ended_at method is defined, but there is no reason why you could not extend it so that it would take whatever kind of string input you want using Time.parse


0

If you're looking for quantitative metrics that show if QA is doing its job, here are a couple common ones: number of open defects and # of total defects, the ratio between the two, the change in the ratio throughout the iteration. number of P1, P2. P3. P4 defects found in pre-prod environment vs production environment Average Defect cycle time Here are ...


0

Quality management, both assurance and control, is risk mitigation against poor performance and defects, both of which are probabilistic. Part of the probabilistic outcome is aleatory, meaning due to random variability where no action has any real effect. Trying to decipher how well your QM activity is doing when you have both random and non random effects ...


6

Ultimately, the metrics that you choose depend on the specific questions that you want to answer about the quality of your product and processes: If you want to know how good your defect reports submitted are, track the number that are withdrawn or marked as not reproducible. You'd also want to track what organization (development, quality, customer ...


0

From the way your question is phrased, it sounds like you're generically asking if you should verify something executed correctly. The answer is yes. If it's something simple like a system call, then you would return the runtime's exit code For example: Runtime.exitValue() This is assuming whatever you executed itself returns a proper error. If I run ...


1

Your example is flawed. When uploading a file to the server, if something wrong happens, such as a timeout, or a server-side error, this would result in an exception. If this doesn't result in an exception, the underlying methods you are using which didn't threw one are a problem, and you should switch to a library which does things correctly. For ...


1

A tester who is not taking the code-to-be-tested directly from the repository is doing it wrong. (1) A developer who is checking in known-faulty code into the repository is doing it wrong. (2) So at this stage, there is already no way for this scheme to work without one or both sides violating very basic premises of how development and testing ought to ...


1

Although it is a bad idea in general (the other answers perfectly explain why), there is a few special situation where intentionally injecting bugs into the production code in a controlled, temporary manner can make sense. When you refactor the test code - and you should, test code deserves the same attention to detail as production code - you might want to ...


4

Is this industry standard to rush things? To some degree. Companies are in business to make money, and (almost universally) business people want things faster - even at the expense of some hand-wavy quality. Furthermore, is it industry standard not to do testing, comment code, create documentation etc.. ? At my current company, we have no QA ...


0

Look at it with the business eyes: either, this way of work is wrong, it means sooner or later the firm won't be able to find developers, or to hire enough of them to fix all the unmaintable code. Or, the code still generates enough money for the firm to survive. Therefore, there's nothing wrong.


0

You are complicating things unnecessarily. Remove the funcTest and integTest dirs, using packages in the test dir instead.


1

A "stub" is used in "top down" programming. That's when you are building your application from the general to the specific. In so doing, you will use "stubs" as "placeholders" for the specific applications that you haven't had time to build. They often return things like dummy or random values to the more general part of the program. That's all right, the ...


2

Perhaps this is best answered with a concrete example. Let's consider the case where you're creating a desktop application. You've decided to have a function named createMenubar, createToolbar and createMain so that your application constructor is neat and tidy. Your main code will look something like this (this example is in python): class ExampleApp(): ...


4

A stub method is a method that just returns a simple but valid (though not necessarily correct) result. They are typically made when building the infrastructure and you don't want to spend time on every method needed right now. Instead you create stubs so everything compiles and your IDE's auto-complete knows about the methods you are planning to use. ...


3

As others have already said, it's not the job of QA to solely find bugs. I would go further and say it's not their job at all, technically. Developers should be responsible for keeping their own code bug-free. Test suites should be run before new code is ever even committed, and if the test-suites fail, then it should never be making it to QA in the first ...


8

As others have said, the developers should not be purposefully adding bugs in the software, but it is a legitimate strategy for your test suite to add bugs into the software as part of the testing process. It's called mutation testing. The idea is to use software to automate the creation of small changes in the source code (called mutants). The changes are ...


0

I recommend against deliberately injecting bugs into EVERY build you send to QA. You could, from time to time, let's say once a year, do a covert "QA audit". Take a "tested and working" codebase, and as many small new features from your Todo list as possible. Implement them "a bit more sloppily" than you usually do. Think of the edge cases, write them down, ...


2

This isn't necessarily as crazy as it sounds. It rather depends on your motivation. If you are looking for a stick to beat your test team with, well that would be crazy. On the other hand, one of the most difficult things in software development is to know how effective your testing approach is. So if you structure it properly, you could use this technique ...



Top 50 recent answers are included