Posted by
Pete McBreen
30 Nov 2021 at 22:36
Certifications can make sense in the mechanical world where there is a One Best Way to achieve a desired outcome, or there is a basic level of competency that is awkward to test for. So many mechanical trades have safety certificates that have to be periodically renewed, and most countries have the idea of a driving license that is a permit to drive a specific type of vehicle. After all we do not want an electrician or gas fitter getting creative with the building code.
In software though, as Perl programmers say There Is More Than One Way To Do It, and we do want developers to get creative, and by some reports parts of Ruby came from Perl. We don’t want to be certifying developers as capable of creating Perl CGI scripts when there is Ruby on Rails available. The same can be said for all of the cloud certifications, a money maker for the providers, but quickly outdated certifications as the could providers release new capabilities every few months, and hey presto, you need to take that certification exam again (and obviously pay the fee again).
Posted by
Pete McBreen
30 Nov 2021 at 04:14
In talking about testing in 2021 Tim Bray says explicitly about Integration or end to end testing …
The problem is that moving from monoliths to microservices, which makes these tests more important, also makes them harder to build. Which is another good reason to stick with a nice simple monolith if you can. No, I’m not kidding.
Which in turn means you have to be sure to budget time, including design and maintenance time, for your integration testing. (Unit testing is just part of the basic coding budget.)
Posted by
Pete McBreen
25 Nov 2021 at 03:01
Of all people, Honda is experimenting with detecting people by their cellphones “in the effort to realize a society where both pedestrians and vehicles can enjoy mobility safely and with total peace of mind.”
I just wish that the article was intended as sarcasm or a joke.
And Jalopnik reported it without noting the problem
Of course, the onus is on the driver and two-ton machine to not hit pedestrians in the first place, but a system that would warn the victim of a possible collision through their phone doesn’t seem like a bad idea.
Hint to Honda: Some people do not carry cellphones with them, will it be OK to run them over in your future? If anyone is driving in an area of poor visibility, then drive a lot slower, how hard can that be?
Posted by
Pete McBreen
25 Nov 2021 at 02:47
Very interesting map of the world showing UFO sightings, gotta wonder what that is about, but Doonsebury got there first
Posted by
Pete McBreen
13 Nov 2021 at 00:40
Thinking about the testing pyramid that is the common picture used in many presentations, typically highlighting Unit, Functional and UI testing, and if the diagram comes from an agile background, it will put manual testing at the top and claim that manual testing is the most expensive. The claim is normally that automated unit tests are cheap to write and fast to run, automated functional tests cost more to write and run slower, and the automated UI tests are even more expensive to write and slower to run. Manual UI tests are at the top of the pyramid, the most expensive to write and the slowest to run.
The reality may be different, but that depends on your viewpoint.
Automated testing is not actually testing. It is Automated Checking, algorithmically checking conditions on the UI. An automated check can pass if it is only checking a few items on the UI, when some other parts of the UI have changed for the worse, but are not checked. The checks pass, you have a green, but the UI is broken.
So at this point the question is whether manual UI testing is more expensive than automated UI checking, if even a cursory scan by a tester would see the problem but the automated UI check would not see the problem. Yes we can check the entire contents of the UI in the automated check, but then the code doing the checking will run a lot slower, and be more extensive. The cost of maintenance gets much larger as well, since now ANY change on that page, such as an intended refactoring, will need the automated checking code to be adjusted.
My suggestion for addressing this is to make sure that whenever a manual UI test discovers a mistake, the automated checks need to be updated to detect that problem. This makes debugging the problem and fixing the bug easier, and provides an in built regression test for the future. Ideally add a unit test if that is the smallest test that can reveal the defect, otherwise use a Functional test or a UI test if that is what it takes to reveal the error.
