The Insider News - CodeProject

Testers who work closesly with developers tend to think the same way as the developers. So they test what works. Not that which doesn't work.

There is the "5yo test": Start the program, set your 5yo on a chair front of the screen/keyboard, and tell "Every time you can make the program crash, and show daddy how you did it, you'll have an ice cream cone". That is sort of the junior version of the ideal tester.

In one company, we hired students as testers (of end user GUI applications) on half year contracts. After half a year, they had learned the "right" way to do things, and their reporting rate had dropped considerably. When a new crop of testers came in, we had a whole bunch of new reports, for a few months, and then they had to be replaced.

In my current company, we made an explicit decision to take the testers out of the development group, to form a separate test team. Developers still write module tests (for use by the test team), but all higher level tests are made by the test team. The test team does not touch the source code (they rarely even look at it); if an issue is detected, it is reported to the developers to fix. Essentially, the test team is responsible for maintaining a 99% automated test framework that is run on every nightly build. It wouldn't be realistic to handle issues any faster than the next morning anyway. We have much greater benefit from testers being indepent of the developers.

Very similar to my experience with respect to an independent test team.

I see the advantage of separating the testers from the developers. However, the testers and the developers must still share a location. There are too many cases where the testing has been outsourced, and the tester will tell the developers that the test failed, but will omit the one bit of information that allows them to diagnose the problem. Having the testers down the hall, so the failure can be reproduced in the presence of the developer, is invaluable.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

This is the fatal flaw in Agile; sprints don't allow for proper testing.

The best testing I've had were when the testers answered to different managers and had an arguably adversarial relationship with developers. The testers job is to prove the software doesn't work, not that it does. Another way to put it is that testers and developers are trying to prove that the others are incompetent.

Joe Woodbury wrote:
This is the fatal flaw in Agile; sprints don't allow for proper testing.

After having worked under an agile regime for ten years, and seen testing growing from a developer left hand activity to a well organized and maintained automated setup, I cannot agree. Test plans are set up for nightly builds, for different phases of the release (to customers) process, and for stress testing and other special test setups. Having a fully automated test set up is of course a great advantage - agile organization or not.

There is nothing about sprints that prevents nightly test builds. The test team sprint schedule is independent from that of the development teams, so they can freely e.g. run stress testing, and develop revisions of the test setups, as if it were "ordinary" software.

Even though we have seen lots of test frameworks claiming to handle GUI testing, they rarely work very well, in particular if the user dialog changes every day. But if your application is properly designed, you may peel off the thin GUI layer to let the test framework interface at the topmost functional level, and the entire application logic may be tested. The problem is that lots of web applications are not properly designed, with lots of application logic inseparably mixed with low level presentation elements. That's a problem created by JS and web application development frameworks, not by agile environments and sprints.

You may be thinking of other aspects of testing that I am overlooking. But we have several major projects all running sprints, and all running regular (automated) testing. So at least some (I'd say 'quite a lot of') proper testing can very well be done within an agile sprint-based development environment.

You know that I'm not talking about automated testing. The context of the original post was about manual testing (by humans) and whether that should be done within a development team or separate from it. Agile sprints do NOT allow for independent testing; instead Agile has the conceit that automated testing is sufficient. It is not.

Over dependence on automated testing has led to a decrease in software quality. There is no substituting someone using the software like my father. Moreover, even in automated tests, you can test only that which you anticipated or for which the software was designed. (Such as suddenly moving the software to an international market.

Maybe I am working with testers who do not think of it as a drag, but take professional pride in developing the best automated test setup that can be made. Who has deep knowledge of different kinds of tests, and established strategies for extending the coverage as close as possible to 100%, not only measured as code line coverage, but by e.g. functional coverage at various levels as well. (Even if you have tested every line of every block of code, you don't have full functional coverage until you have tested it in all the context this code block is used!)

Testing is not a lefthand job you learned in a one-semester course in your studies twenty years ago. It is a profession of its own, with its own professional experts, its rather advanced methods and strategies. There is no doubt that after our testing experts created our automated test framework, our software quality has increased significantly. Because it is always done. Because whenever some new corner case is identified, from then on it is always tested, in all configurations. The regression tests verify that all bugs ever corrected remain corrected - that we do not make the same error again, reintroducing the problem.

A (very) small part of testing is difficult to automate. Usually, when you sit down to discuss that with developers, trying to find out why the testers could not sneak in, immediately under the hood to test the functionality triggered by user actions, you are told that "Well, but the software isn't structured that way - everything is deeply intertwingled; we can't separate the UI from the functionality". Sure, I trust you 100%: You have a messy software structure, not designed for testing. There is a concept called "Test Driven Software Development" - those coding that way never heard of that concept! This has nothing to do with agile or sprints, but with software being a mess.

It is more the other way around: Software quality has decreased becaused many software developers create an implementation so messy that automated testing is impossible. Had they made a truly testable implementation - which is fully possible! - then you could have applied a complete, formalized testing plan that could have improved the software quality. I have seen our codebase in 6-8 years going from "80% of the tests can't possibly be automated" to "99% of the tests ave automated". I know that it can be done. I have seen it be done, been involved in it.

Do you have any reasoning or explanation why agile development, with its sprint structure, is incompatible with proper testing? Even if parts of the testing must be done by non-automated procedures, what prevents the deliveries of a sprint to be handed over to a test team for those manual tests (in addition to the automated tests)? What is it about sprints that makes this difficult? How would you describe differences from whatever are the alternatives, the non-sprint-based ones? Can you tell how and why the alternatives take better care of non-automated (and if you like to include as well, automated) testing?

I am certainly not any great fan of the agile development model; I think its basic idea is "code before you think". While other methods are are essnetially "think, then code!", agile is "code, think and then refactor". I don't like it. Yet I can't see a single reason why sprints should create any obstacle to proper testing, whether manual or automated.

Your patronizing post is extremely irritating. I never said nor suggested that testing is not a highly professional, skilled profession. I have repeatedly stated my position on Code Project that the lack of respect for testing has had a negative impact on software.

Automated testing is useful, but should largely be seen as part of the engineering/build process; that is, testing will not be involved if a build doesn't pass the post build testing.

I agree that software can be often structured to facilitate testing. I am a strong advocate of this, even in embedded systems with hardware dependencies. However, I've also observed over confidence on this automated testing; that passing automated tests establish a higher level of quality that they do.

The problem with Agile and testing is that if done strictly, developers will be left idle as the testing is completed since a sprint cannot be finished until the specified tasks pass testing. Alternatively, testing will be rushed at the end of the sprint. This became such an issue at one company where I worked, that several of us engineers and testers proposed creating offsetting development and testing sprints. This was rejected since it violated agile.

Several years ago, I worked at a company where the team I was on didn't follow agile. The team sitting next to us followed it exactly. We delivered our work on time with extremely few bugs. The agile team had a horrendous backlog and missed every deadline. A big problem was trying to fit testing into sprints; and then fixing issues exposed during testing.

Quote:
what prevents the deliveries of a sprint to be handed over to a test team

You just answered your own question.

Independant[^]:
The research shows that the planet is definitely seismically active, or prone to quakes. And those quakes could shed important new light on how Mars came to be formed, as well as the rest of the Solar System.

If the planet's shaking, don't bother landing and taking

Proof that science is not carried out by looking through a telescope and guessing.

I wanna be a eunuchs developer! Pass me a bread knife!

RedHat developer[^]:
This feature makes it easy to create and consume asynchronous enumerables, so before getting into the new feature, you first need to understand the IEnumerable interface.

last Because blocking so century is

Kent Sharkey wrote:
last Because blocking so century is

Gold

Zen and the art of software maintenance : rm -rf *

Maths is like love : a simple idea but it can get complicated.

Ars Technica[^]:
It would only take 4.5 days for tribbles to completely fill the USS Enterprise.

I know I was wondering

I sometimes lose faith in the value (and sanity) of "researchers", but then something like this comes along.

I wanna be a eunuchs developer! Pass me a bread knife!

Meanwhile, biology students are in the final stages of unification with pilot-wave theory and general relativity.

Understand Legacy Code[^]:
As a developer, it’s quite common to be confronted with managers who don’t seem interested in fixing what’s already here.

'And the horse you rode in on!', probably not a good point to try

Four more things to consider:

0. Refactoring legacy code is not something to be taken lightly. It must be more carefully and diligently planned than the creation of new features.

1. The person who is charged with managing a product is more than well aware that changes as often as not result in new bugs -- and he might be kind of not loving the idea of having new bugs in his production code.

2. Next week, the person who is currently screaming "WE HAVE TO REWRITE EVERYTHING!" will probably be screaming "IF IT AIN'T BROKE, DON'T FIX IT!"

3. If you treat someone like an idiot (except in jest), it's possible that the only idiot in the room is you.

I wanna be a eunuchs developer! Pass me a bread knife!

It's worth refactoring if

someone has a design that will significantly improve the code, and
the cost of refactoring will be recouped by making it easier to add new capabilities over the product's anticipated lifetime.

The introduction of bugs is indeed a concern and is one more reason for developing automated testing, the lack of which results in what a former colleague astutely called "verification inertia".

In a major refactoring (rewrite), some things that can help are

There must be good specification documents so that the rewrite doesn't drop functionality.
No significant user-visible changes (e.g., to a GUI) are allowed, because this is likely to anger users.
Customers still want new functionality, so split the development team:
- In release 1, have a small group create the core of the new system while everyone else continues to deliver on the old one.
- In release 2, reimplement a significant portion of the product's capabilities on the new system while still delivering new capabilities on the old one.
- In release 3, shift everyone to the new system, which finally catches up to the old one and delivers the new functionality promised for that release.

Yup. Well compiled.

That's what I meant by "more carefully and diligently planned" than the norm, where you can just do a (partial) fork, to try things out.

I wanna be a eunuchs developer! Pass me a bread knife!

More or less what we are thinking to do.
Only difference is, we are very few people and we have to split our time, not the team. And we are not refactoring but rewriting it.

Our plan (easy description)
1) Code freeze for current version, only critical things will be done
2) Start new core and set it work in paralel with old staff
3) If tests / logs / checks are good. Start implementing new version of functionalities and move the ones that can be moved to the new core.
4) Do a parallel separated app with all new stuff.
5) Switch off old version in one "guinea pig" production system
6) start rolling out new version slowly to the other parts of the field
7) Go back to normal business in new version
8) start implementing new functionality in new version

M.D.V.

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.

It's not just refactoring; it's stuff that's not even implemented.

Dev.to[^]:
Recently a younger developer I respect expressed a somewhat common concern. In essence, their concern was that they were finding themselves doing a little bit of everything and not specializing enough. They were specifically concerned that nobody would want to hire them without a key specialization.

I'm more of a b-shaped developer

sans-serif

Kent Sharkey wrote:
I'm more of a b-shaped developer

According to everyone else, I'm more of an F.

I wanna be a eunuchs developer! Pass me a bread knife!

Bleeping Computer[^]:
With the release of Google Chrome 80, Google quietly slipped in a new feature that allows users to create a link directly to a specific word or phrase on a page. A Brave Browser researcher, though, sees this as a potential privacy risk and is concerned Google added it too quickly.

A Google feature with privacy concerns? This is a first!

Wow.

This is bad.

A privacy issue that makes the "attacker" open each individual page and look at it.

It'll catch on in a big way, because it's so much easier to type a search string to open each page and look at it than, say, clicking links to open the pages.

I wanna be a eunuchs developer! Pass me a bread knife!