21 August 2016
I am in search of assignments - professional and educational - in Europe. Please contact me concerning prospects: firstname.lastname@example.org, +48 519 152 106 or Skype: bogdan.f.bereza
2011 "How testers communicate"
2011 "Automatic test design"
Manual test preparation usually involves to some degree the use of natural language. This creates a lot of problems: different test analysts have different description styles; different organizations use different description guidelines; and different testers may understand a description differently.
"Mobile app testing"
Multiple versions of applications have always been bad news for testing. Many PT readers will remember from experience the nightmare caused by variation between web clients: platforms, browsers, plugins etc, all in various releases. Test design was shrunk by having to repeat test execution across a large number of combinations: all important tests simply could not be done.
»»» read more go up
2013 "The evolution of testing"
From Here to Eternity: The Evolution of Software Engineering
There is an evolution in everything, including software quality engineering. Even though you may be forgiven for believing software engineering is purely rational, scientific and engineering-wise, in reality its development has over years followed a bumpy, turbulent road, like any other social phenomenon.
During early, pre-transistor, pre-integrated circuit days of computing, so
beautifully described by Richard Feynman in his reminiscences from Manhattan Project, software projects were very few and – by today’s standards
– very small. So, there were enough geniuses and Nobel prise laureates to
people them and to conduct them competently without special processes, organisation, or tools. »»» read more go up
|March 2013 "An
untested business process"
Already on arrival some days earlier, I was rather taken aback when my shuttle bus stopped somewhere in the middle of the rather crowded and badly-lit street, at a place not easily recognizable as any bus stop, except for a long queue of nervous-looking people
with suitcases, and heard a laconic info from the bus driver “Termini”, the name of the main and biggest railway station in Rome. No railway station was there anywhere to be seen, but – thanks heaven for Google Maps and its Street View! – I managed to recognise a rather morose and ugly wall of a huge building as the station building. »»» read more go up
2012 "Test environment virtualisation"
Chaos and failure fascinate me. I love to hear and think about endeavours that ended badly, preferably in a spectacular manner and, better still, for trivial reasons. And every time I indulge in this perverse pleasure, I ask myself: why didn't someone prevent it? Why didn't they see it coming? And above all: why couldn't they check first to see whether what they were going to try to do would work? [...]
Automated test execution is started on Friday afternoon and expected to continue throughout the weekend: it is stopped on Saturday morning by maintenance operations. Testers cannot get the access rights, configurations, identities and passwords they need because they have to queue with other support users: developers and even users. »»» read more go up
2011 "The certification drama"
My concern is that the rules and constraints imposed on customers, partners and competitors of some of the leading providers tend to stifle development, creativity and innovation. In this article I will seek a solution. [...]
The procedures by which examination questions are set and marked are not
disclosed or are shockingly vague and unhelpful to trainers and candidates,
containing statements like “questions can be drawn from this syllabus, lower
level syllabuses of the scheme, their references and expected practical experience”. This means that virtually any question and answer is possible. In some cases, even the accreditation and certification rules themselves are kept secret! »»» read more go up
"Tests are requirements"
Suppose there is a requirement stating that a given function accepts users aged
between 20 and 70. A test analyst, using equivalence partitioning/boundary value analysis, designs the following test cases: age of user is 19, 20, 21, 50, 69, 70, 71. This tester actually elicits additional requirements, more detailed than the original requirement! »»» read more go up
An e-mail arrived from a prospective customer to a mobile app vendor, with a
rough-and-ready request for tender to develop a bar-code mobile app, designed
especially for the recognition of certain brand-related issues. And of course, it
asked for the tender, including time and price, without providing sufficient details; actually, no details, except the list of mobile platforms this app was supposed to run on. This looked like, and was, a typical example of common customer's attitude: “What the devil do you need requirements for? Just give me your quotation and if I accept it, start coding like hell!”
»»» read more go up
2004 "On test training"
"Who saves money on test training knows the price of everything, but the value of nothing”, said Oscar Wilde (well, not really, but he might have if he had lived today). [...] Personally, I am rather cynical about so-
called “workshops”. They are manna from heaven for overworked test training instructors, but are they really good for students? »»» read more