OK, let’s cut to the chase. Testers are part of your team, not an anonymised bolt-on. This was an attitude prevalent 20 years ago, but at least then, testers were taken seriously. What we have now is too many making evaluations of what testing is and where it should fit in. Testing is a free-for-all area that many self-appointed experts reside in. And the more testing becomes test engineering, the more foolish those people look.
Who (as a tester) has not heard the response to you job “what, you just sit around surfing website all day?”. Well, these people are not worth correcting, but it illustrates a point – even with 20 years QA experience, it amazes me how many feel need to tell me what I do, and why I do it. My twitter feed gauge my annoyance levels, full as it is, of strongly-worded diatribes on this subject. It is bad enough that in contracting, I am generally following in wake of amateur balls-ups. And balls-ups that went on for too long, as no-one took interest or monitoring the ongoing development of tests.
Part of problem is that testing world is full of enthusiasm, but few with real test engineering skills. Want to impress your average company? Create hundreds of brittle UI automated tests, built on latest “funky framework”, then bask in the multiple “oooooooh!”, then time exit before anyone notices that:
- No-one is using the test framework repo, apart from the tester.
- No-one else is checking out the repo.
- The tester becomes “Manuel Jenkins”, as the test framework only ever running on their pc.
- The hundreds of tests are pointless, useless and throwaway
Then I come in to mop up the mess, and deal with bad perceptions/understanding about test engineering. There is a problem around the decision-making process, usually made by project members who view a project like this:
Generally, process and products are selected based on personal taste or even fashion (the worst). These are always sold with over-optimistic promises of improving things, simply by their existence on project. These helpful individuals may not even be connected with tech – maybe they just enjoyed a pretentious demonstration at a conference. And react like they have never heard the time-honoured sales line “All you problems are solved with this product!”. The people that decide test framework are the team, because they are the saps that have to use and maintain it.
Though a broad statement, test engineering is very effective bridge between development and devops. Yes, developers can factor in test framework maintenance and coding tests, into their workload. But why? It’s far better to have a well-maintained test framework they can use as necessary, rather than being concerned with it’s mechanics. Calling test engineering “developing in test” provided more confusion, as many role descriptions were essentially for a developer who was also prepared to write acceptance tests. By that, I mean tests that directly map to requirements, not unit tests.
If the test engineer is charged with creating and maintaining UI and API tests, this can save the developers a lot of unit test work, and if test framework set running on the build server, an excellent sanity check for every build. And based of real-life scenarios. The common whine when trying to get is that it gets in the way. Really? A failing test is an obstruction, and should be (whatever the reason it fails). Acceptance tests should be part of the build pipeline. Tests don’t obstruct, they inform.
I am generally following in wake of amateur balls-ups. And balls-ups that went on for too long, as noone took interest or monitoring the ongoing development of tests. Want to impress your average company? Create hundreds of brittle UI automated tests, bask on the multiple “oooooooh!”, then time exit before anyone notices that:
- No-one is using the test framework repo, apart from the tester.
- No-one else is checking out the repo.
- The tester becomes “Manuel Jenkins”, as the test framework only ever running on their pc.
- The hundreds of tests are pointless, useless and throwaway
Then I come in to mop up the mess, and deal with bad perceptions/understanding about test engineering. There is a problem around the decision-making process, usually made by project members who view a project like this:
So process and products are selected based on personal taste, fashion (the worst). These are always sold with over-optimistic promises of improving things, simply by their existence on project.
Though a broad statement, test engineering is very effective bridge between development and devops. Yes, developers can factor in test framework maintenance and coding tests, into their workload. But why? It’s far wetter to have a well-maintained test framework they can use as necessary, rather than being concerned with it’s mechanics. Calling test engineering “developing in test” provided more confusion, as many role descriptions were essentially for a developer who was also prepared to write acceptance tests. By that, I mean tests that directly map to requirements, not unit tests.
If the test engineer is charged with creating and maintaining UI and API tests, this can save the developers a lot of unit test work, and if test framework set running on the build server, an excellent sanity check for every build. And based of real-life scenarios. The common whine when trying to get is that it gets in the way. Really? A failing test is an obstruction, and should be (whatever the reason it fails). Acceptance tests should be part of the build pipeline. Tests don’t obstruct, they inform.
jaffamonkey 