Got asked today which versions of IE we support, by a customer that is well-known for being extremely security-conscious, and for believing that being extremely security-conscious means they need to use antiquated software without JavaScript. I should have asked which version they need us to support.
Honestly, IE6 would not surprise me in the slightest.
@LightnessRacesinOrbit Because after a 30 minute wait I got a text saying he was on his way. 60 minutes later I got a text saying he had fallen asleep :|
writing tests, improving tests, refactoring a module to make it testable, writing a new feature along with new tests are all valid tasks in...well, hopefully any methodology, it's not like agile invented testing
if anything agile would encourage those kinds of tasks more so than plan-driven/waterfall ones because one of the "investments" you have to make to stay agile is spending time on an automated test suite
if the user story isn't testable, that means either nobody knows what the feature is actually supposed to do, which is obviously bad, or nobody knows how to write tests for this kind of code, which means we need a separate story to invest in a testing framework or a refactoring to enable testing
"covering all the cases" is where we get into more technical details of what the most cost-efficient and robust ways of maintaining a test suite are, which is probably below the level you're currently working at
OK. Let me give an example that will help me understand. Let's say I have the user story "As a data manager, I want to control access to the dataset so that it is not available to unauthorized users."
I know that this means using AD to establish user groups -- I defined it in a requirement in the last release. But let's say I didn't. How would we develop that test case? How would the tester know how to test that?
this would likely have to be an integration/system/acceptance test (pick your favorite term) since it'll involve the authorization code and the dataset fetching code
I only try to cover all cases when doing white-box unit tests … they tend to be a waste of time on a feature-test level. Do the simplest test that would fail if the feature weren't implemented.
The specific groups are irrelevant for the test? The feature does not specify some group, but that permissions can be set and will be enforced. So you could use some test group. You might not even need to connect to an AD but could use some mock.
unless you implement this logic as "fetchData(isAuthorized)"
and be sure to call that from code which will someday know if the user really is authorized
but even if you did that, you're testing a feature that hasn't been implemented and can't be implemented yet, which is usually not the best use of one's time
if it is possible to implement the feature at all, then it is (usually) possible to implement a test for said feature; it's just a question of how much you have to mock out or refactor to make the test feasible
if the tester doesn't know the information needed to write the test, either the feature can't be implemented yet anyway, or the tester needs access to more information than they currently have
@Ampt Depends on whether your “definition of done” includes that a feature is implemented, reviewed, tested, and documented before it is complete. Or you could define a feature as done as soon as something more urgent turns up…
having the tests be written by someone else...I just don't see how that can even work unless all of your tests are at the integration/acceptance level, or you hammer out such a thorough spec before any implementation happens that you're basically doing waterfall instead of agile
NCEES Principles and Practice of Engineering Examination Software Engineering Exam Specifications - https://cdn.ncees.org/wp-content/uploads/2012/11/SWE-Apr-2013.pdf
Is this the sort of engineering exam they've been talking about putting into law as some sort of prerequisite to calling yourself a "software engineer"?
@Ixrec Part of my role is bringing lots of code under test coverage. It's difficult to iron out design problems at this stage, but it's amazing what horrendous bugs have gone undetected for so long – some things are just obviously wrong. If these tests are written alongside implementation, there can be a much better feedback cycle – provided that the programmer and tester are in the same team.
@amon I definitely agree with writing tests for feature X when you first implement feature X, what I don't get is why that would ever be easier/more productive with a separate person writing the tests
Fail fast for bridges - That's how they figure out the biggest truck you can drive over one - they drive heavier and heavier ones until it collapses, and rebuild the bridge with the sign.
then again this is the same reason pair programming never made much sense to me (except as an educational thing); the few times my team attempted to do anything like it in practice we always ended up with one person driving and the other watching, and we quickly realized that it was simply far more productive to go off and implement separate parts and then review each other's code as we finished stuff
@Ixrec It would never be easier, but a second pair of eyeballs seems like a good idea. Note that many great programmers haven't learned to be good testers. If I test my own code, I tend to be blind for anything that isn't the happy path, or for any thorny language-specific traps (though I'm getting increasingly competent enough to dissect my code until I see it for the crap it is).
I think your approach of dodging the actual question and focusing on the possibility of redemption is a much better idea than the obligatory "actually, you did deserve that ban, and here's why" post that we're inevitably going to be tempted to write at some point
off-topic meta-meta-question... where on SE is the appropriate place to ask/discuss about reference sites going offline and large numbers of links in old questions/answers needing to be updated to new sites and/or archive.org links?
The Whiteboard
The Whiteboard