|
I remember sitting watching "The King's Speech" one evening some time ago. Did you ever see the film "The King's Speech"? It's an interesting study. The thing is, most people watching it saw it as a study in how one man, a Prince who, eventually, would be crowned King. He did not want to be King and as he had an elder brother, the heir, it seemed unlikely. Of course, the brother had some interesting "relationships" with people that were inappropriate. The result of those eventually led to the older Brother, who by then was King Edward VII of England, abdicating the throne in 1936.
Most people who see the film take away a story of a triumph of will on the part of the man who became King George VI. With the assistance of the speech therapist, of course. I noticed one distinct thing early on. The Prince, Albert, not yet George, and his wife Elizabeth pay a visit to the speech therapist (Lionel Logue). After a brief, unsuccessful visit with Albert alone, this second visit consisted of Albert and Elizabeth telling Logue how they wanted him to do his job. It was interesting, because he had been asking questions that made Bertie/Albert (not yet George) uncomfortable. Stuff where Bertie/Albert did not understand the purpose of the questions. Logue explained that there was possibly information he needed to help Bertie/Albert within the answers. Except Bertie and Elizabeth would have nothing to do with such flim-flam and silliness. They wanted him to fix the physical problem of his stammer. In Software How many times does someone come in and demand the team do something that will not serve the needs of the project, team or company. When we, as software professionals, push back, they, the project manager or business analyst or manager or maybe a would-be scrum master, tell us to do what we are told. That is our job. So just do it. Being the compliant, obedient people we are we just give in and do it their way. Right? Testers should focus on finding bugs. Unless we should focus on making "sure the software works." Maybe we should focus on ensuring confidence in the functionality. Perhaps we should focus on all of these things. Nonsense. We might do those things on some projects, based on the needs of the project when they are the right thing to do. Here, by "right" I mean within a reasonable professional code of ethics. Of course, it might boil down to "keeping your job" but that has never really held much sway for me. At least not in the last 15 or 20 years or so. How do you approach or respond to someone who is telling you what you should be doing? What about when they have no real expertise or experience within their argument, other than "I'm your customer and this is what I want"? I am reminded of the philosopher-poets who wrote: You can't always get what you want But if you try sometimes, well, you just might find You get what you need What is Wanted vs What is Needed Many people confuse wants and needs. There really is a difference, no matter what people trying to sell you something might say. Sorting out what is needed from what is wanted can be really hard. There is the noise, buzz, and clamour of managers, project managers, someone else saying they "need it NOW!" Then there is the voice in the back of the head that says, "Something doesn't quite feel right. Something is out of sorts." How do we sort out what is really needed? The easy way is to tell them "that won't work." I'm not sure that works either. The not-quite-as-easy way is to say "Well, I'm not sure that will work, and here are my concerns..." The thing often wanted from us, as testers, is where we say "OK! I'll do precisely that!" Which will make the requester/demander go away happy. Odds are they'll be back, not so happy, but that won't be for a while so that is just fine for now. We can figure out something to tell them later. Not today. The option that Logue used in the film (and in real life) was simple. He said, "OK, we'll do it that way." He then proceeded to do "physical exercises" and "training" to deal with the stammer. He did this knowing that the chances of it working were incalculably small.. In the process of working through these exercises, they conversed. They talked. At one point it became clear that Bertie was actually left-handed but had been trained to act right-handed. This led Logue to comment that this was not uncommon. There were questions posed as "interesting ideas" that Bertie answered, simply because he was relaxed. His guard was down and he was more open. In the end Bertie came to rely on Logue. He even offered an apology, in a very Royal Family sort of way, for his previous “bad behavior.” In the end Logue did what was needed. It started by simply being willing to help. Importantly he took pains to not dismiss the words used to express the wishes, and desires of Bertie and Elizabeth. He made sure they knew he wanted to help. He focused on being willing to "do what they wanted" until it became clear something else was needed. And Testers? We can push back, gently. We can offer help. We can set the conditions. We must also know what to push back against. We must know why. I'm not sure I can do what Logue did, at least on a regular basis. I've tried, with various levels of success. Some folks were OK with that. Other folks wanted something like "that and only that." They wanted me to precisely do that one thing, exactly what they said. I have a hard time with that, particularly when they can't answer basic questions around the intent of the software. Granted, working as a consultant or contractor, you may have a bit of leeway that an "employee" may not have on the surface. Know how you can contribute, then do so. Or not. You may not get a CVO (Commander of the Victorian Order, an "Honour" given for personal service to the Monarch of Britain) out of it, but I expect you'll be able to sleep at night.
0 Comments
I remember reading an article on how Quality Engineering was well beyond and more complex than software testing. In the course of reading that article, it struck me that the author had a totally different understanding of those two terms.
I wanted to examine them and explore some ideas. Software Quality Engineering, simply put, is applying the practices of Quality Engineering, as a discipline, to the development and creation of software. It is part of a defined quality program focused on how software is made. It focuses on the process, goals, measurement, compliance to the agreed goals established by the development team for the project. Unfortunately, like most things in software, the formal, intended meaning of concepts have been forgotten or ignored. People will hear a term that sounds familiar and apply their understanding to it. If you use your favorite search engine and look up “Software Quality Engineering” most of the responses you get will be around software testing. For most people in software, a “Quality Engineer” does software testing. Let us look at Software Testing then. Again, a significant problem is people hear a term and apply their understanding of similar terms to the new one. The result is confusion. Common View of Testing A view which some consider to be the "real" or "correct" view, is that testing validates behavior. Tests "pass" or "fail" based on expectations and the point of testing is to confirm those expectations. The challenge of introducing the concept of “Quality” with this conception of testing brings in other problems. It seems the question of "Quality" is often tied to a "voice of authority.” For some people that "authority" is the near-legendary Jerry Weinberg: "Quality is value to some person." For others the “authority” is Joseph Juran: "fitness for use." How do we know about the software we are working on? What is it that gives us the touch points to be able to measure this? There are the classic measures used by advocates of testing as validation or pass/fail:
These may shed some light on testing or on the perceived progress of testing for some organizations. Many organizations will assert with great confidence that these measures tell them all they need to know about their testing. However, they speak nothing about the software itself or the quality of the software being tested. Nor do they tell us anything meaningful about the testing that is being done. One response, a common one, is that the question of the “quality of the software” is not a concern of “testing,” that it is a concern for “quality engineering.” Thus, testing is independent of the concerns of overall quality. Rubbish. Good testing, like everything involved in creating good software, takes disciplined, thoughtful work. Following the precise steps dictated is not testing. It is following a cookbook recipe or a script. Testing takes consideration beyond the simple, straightforward path. When people ask me what testing is, my working definition is: Software testing is a systematic evaluation of the behavior of a piece of software, based on some model. By using models that are relevant to the project, epic or story, we can select appropriate methods and techniques in place of relying on organizational comfort-zones. If one model we use is “conformance to documented requirements” we exercise the software one way. If we are interested in aspects of performance or load capacity, we’ll exercise the software in another way. There is no rule limiting a tester to using a single model. Most software projects will need multiple models to be considered in testing. There are some concepts that are important in this working. When it comes to “documented requirements,” they serve as information points for us. Many times, they make reasonable starting points for good, meaningful testing. To perform good testing we need good communication. Real communication is not documents which are emailed back and forth. Communication itself is shared and is bi-directional. It is not a lecture or a monologue. Communication requires conversation. This helps make sure all parties are in alignment. Good testing looks at the reason behind the project. We need to be able to identify and understand what the intended change will do. We need to be able to show how the business problem is addressed by the change being implemented. Good testing looks to understand the impact of what is being done to the broader application and software system. It is not enough to identify the intended impact areas. We must be able to illuminate areas within the system which may be impacted, whether intended or not. We must also identify people who may find their work processes changed by the change in software. Good testing looks at these reasons and purposes for the changes and compares them to the team and company purpose and values. Are they in alignment with the mission, purpose and core values of the organization? Good testing includes a willingness to report variances in these fundamental considerations beyond requirements and code. Good testing can exercise the design before a single line of code is written. Good testing can help search out implied or undocumented requirements to catch variances before design is finalized. Good testing can help product owners, designers and developers in demonstrating the impact of changes on people who will be working with the software. Good testing can help build consensus within the team as to the very behavior of the software. Good testing can navigate between function level testing to broader aspects of testing, by following multiple roles within the application and evaluating what people using or impacted by the change will experience. Good testing can help bring the voice of the customer, internal and external, to the conversation when nothing or no one else does. Good testing challenges assurances. It investigates possibilities and asks questions about what is discovered. Good testing challenges assumptions and presumptions. It looks for ways in which those assumptions and presumptions are not valid or are not appropriate in the project being worked on. Good testing serves the stakeholders of the project by being in service to them. How Does Testing Serve Stakeholders? Testing provides information. Applying test approaches to design can help reveal weak points in the design, before any code is written. Doing the same thing with documented requirements can head off problems in design before design begins. Then there is the reason the work is being done in the first place. Applying the same mindset or approach to evaluate the business problem being addressed, before requirements are considered, can help clarify thinking around not only the reason driving the work, but also define some of the expected outcomes. By doing this from the very inception, before the project is actually a project, many of the problems which come up later can be reduced if not avoided altogether. In that sense, the idea of “quality engineering” takes on a third definition. That is, software quality engineering is building quality software products from the very inception. To make that happen takes very similar skills to what is required for good software testing. |
The new home of Pete Walen's observations, comments and thoughts on Quality, Software Testing, Agile and Scrum. Archives
November 2021
Categories |
RSS Feed
