Table of contents for A Side Note
- A Side Note: The failure to test consistently is inexcusable by Howard Clark
- A Side Note: Why I dislike XY Scatter Charts so much! by Howard Clark
- A Side Note:Get Ahead of the Testing Infrastucture Build Out by Howard Clark
- A Side Note: Job Posting for Aeronautical Engineer – Have experience as an airplane passenger? You’re hired! by Howard Clark
- A Side Note: They might be right by Howard Clark
- A Side Note: “Do More with Less…Can Someone Tell Me How?” by Bobby Washington
- A Side Note: “Fighting To Maintain A Tester’s Integrity” by Bobby Washington
- A Side Note: “To Pull the Plug or Not, Who Knew The Life And Death Of a Computer Would Depend On A Tester?” by Howard Clark
- A Side Note: “Faith in the Machinery” by Ed Cook
- A Side Note: Open-Source or Commercial Testing Solution by Howard Clark
The assumption is that you know where you are going and the terrain to some extent, versus a haphazard venture into unknown programming logic. I’m of the opinion that software testing should be performed by software developers trained in the art and science of testing. Now ideally this would be the same developers who wrote the code, who in a peer review situation would cross-test each other’s code. We’ve been led to believe that the bias these developers hold can’t be overcome and so a neutral party needs to be involved. I’m fine with that, but that neutral party really needs to have a level of technical acumen around the technologies used. If you look at the profile of a flight engineer for a space shuttle mission you typically find extensive military and aeronautical experience in addition to engineering. You aren’t going to see some brilliant microchip designer flying on a shuttle mission without certain pre-requisites, the required skills and attributes are not mutually-exclusive. Neither should the skills and attributes of a software tester and a developer be seen as mutually-exclusive.
Sample job posting:
“Candidate would be responsible for writing and executing test plans and cases, designing and developing test tools, debugging and reporting code bugs and pushing quality upstream. Qualifications for this position include a minimum of 3-7 years of commercial software development and testing experience. In addition, demonstrated technical leadership, strong problem solving skills, and prior experience tester is required. Expertise in the following areas is highly desirable: ASP.NET, SQL, C#, and Test-Driven Development. Experience developing web-based applications, object-oriented design, and strong communication skills are required. The ideal candidate will have a BS or MS in Computer Science.”
I think this can be the Achilles heel of building software testing teams when not addressed appropriately. If you think that the job requirements mentioned are over-kill and that your system is simpler and therefore doesn’t require such extensive skills, good for you! I trust you have good contingency planning when that mine lying in wait takes a foot off. Hiring for these skills would go a long way towards bridging the communication divide that typical widens as a project moves through the typical SDLC. The war between the testers and developers, us versus them, winner take all mentality needs to be peacefully resolved, and the easiest way to do that is to get both parties on the same page speaking the same language. Its a human issue, one of respect and credibility, and shortcomings in certain groups of people that lack certain qualities to make anything less than a merger of equals difficult. By leveling the playing field between the competence of your developers and testers the quality of the effort can only go up. Be clear that I have come to respect the tester’s mindset a great deal having joined the ranks almost 5 years ago. My previous life was spent developing against packaged software solutions and the occasional spurt of creativity building applications and tools from scratch and I had some of the same problems with testers that I encounter today as one myself. But what I find helps mitigate this time and time again is being able to relate from my own experience and applying it to problems and relationship building, illustrated by a blog entry from Mike Kelly(What’s your credit score?).
No matter how many times I’ve flown on a plane, and I’ve logged hundreds of thousands of miles domestically here in the U.S. over a seven year span, I would never ever go out on the tarmac to conduct the pre-flight check, or take a job at Boeing to do structural testing and analysis. Experience counts, but it has to be of the right type. Being intelligent helps, but being a brilliant musician rarely translates into being a good brick layer.
“So it is said that if you know your enemies and know yourself, you will win hundred times in hundred battles. If you only know yourself, but not your opponent, you win one and lose the next. If you do not know yourself or your enemy, you will always lose. “- Sun Tzu
To know your enemy you must become your enemy, not to insight violence or anything, which is apt to happen when deadlines start to loom. So let’s say you are already on the ground and things are what they are, one way to turn it around is to actually take an interest in the technology side of the equation. Instead of exiting early in the group meeting once the techies start, hang out and take notes. Fortunately, Google saves us the embarrassment of asking what an LPAR is during the meeting on infrastructure, but its ok to ask at the risk of looking silly sometimes too. It shows you are paying attention and want to learn. To help bring things closer to home start exploring instances where technology could truly benefit your role on the project and in life in general. It starts to build a personal basis for technology for you and will hopefully pique your interest more. Create joint ventures with the development staff, maybe even off hours before or after work to hold workshops to share each other’s crafts, something that goes a long way towards helping both parties come to appreciate each other more.
I always find it disappointing to be viewed as a geek by fellow testers because I might set up a server over the weekend, or write a small application to help ease some daily burden in computing. It raises serious doubts in my mind about what they really feel about the space they work in. If allowed, software testing could be done by anyone, and I’m all for bringing down walls and removing barriers to entry, but in allowing anyone they should be someone who actually cares about technology and software and the like.
Good development and testing — of software and airplanes — requires a variety of skills. I hope that each software and airplane component is well tested by its developers and their peers. However, components often do not work as expected when integrated into more complex systems. This requires testing of the integrated components — often by a party external to the two developers (whether they be individuals or teams).
I may not be an aeronautical engineer, yet I hope that other engineers, pilots, flight attendents, and passengers were consulted while defining requirements and testing the airplanes they create. Engineers usually don’t think like pilots or passengers.
I agree that there need to be technically fluent testers involved in software testing. However, testing is a skill independent of development. There are developers with good testing skills and testers with good development skills. There are good testers that know very little about the inner workings — of software and airplanes — that find and report very important defects. Their lack of development skills does not make them less of a tester.
Today’s software and airplanes are very complex. Both require a team of people with a variety of skills and good communication.
I would not want to use software or fly on an airplane that was only tested by the development engineers.
Ben
I am almost inclined to agree 100%, since it’s difficult to argue that a variety of skillsets, perspectives, experiences, and attitudes ar eneed to test. But when I look at the non-technical contirbutions of testers they tend to be issues with usability or mis-understandings, error and omissions, or a lack of business requirement to technical mappings. While important, these defects don’t really speak to the product. Rather they point out the human failings in trying to build complex systems from high-level extractions of functionality, or requirements as they often come to be called. So I guess to agree 100% or not depends on the context of the system under test. If we are talking about low-level software(compilers, interpreters, chip logic, embedded systems, etc.) I’d probably be safe in saying only uber-geeks apply. But when it comes to systems with high interactivity, then yes, a team with a full compliment of skills is your best bet.
Let me start off first by saying I’m always thrilled when a read about the opinions of other testing professional’s as it relates to what skill set a career software tester should have. It is also my opinion that software testers at a bare minimum need to have an understanding of technologies being implemented for a project as well as have an ear to the ground regarding new and emerging technologies. It is my belief that you must first enjoy technology. Technology is constantly evolving and changing and becoming more and more difficult to keep up with. While this life cycle can create stress, your enjoyment of technology may be the only driving force that will allow you weather those storms of frustration when they undoubtedly surface. As a tester our job is to provide timely and concise information that enables individuals to make sound business decisions. A working knowledge of development languages, concepts, and enterprise infrastructure only increases our abilities and will truly separate a great tester from a good tester.
I’ve had the privilege to work with some great developers in the past. Many of which I keep in constant contact with. One of my developer colleagues made a statement that forever changed how I viewed software testing. He told me in his opinion, “In order to test technology you need to know about it.” He said what I needed to do was “tinker”, as he called it, with code and technology. That statement has fueled my desire to learn more about software from a developer’s perspective. I’ve had this belief confirmed during my time at a previous employer.
I recall a situation where a tester in our group was accustomed to “tinkering” with code, building solutions, setting up servers and the whole bit. This skill really set him apart in our group. I told him about a defect that was occurring with an area of functionality I was testing. After looking in the code he was able to discover that the developer’s “approach/design/solution” was questionable. I asked this tester if he wouldn’t mind attending a triage meeting I had scheduled with the developer to discuss this defect. During the meeting the tech savvy tester was not only able to speak about the defect from a UI perspective, but was also able to explain to the developer what was occurring with their code under the covers. After which, the developer admitted that the solution wasn’t the best due to time constraints, but committed himself to discovering a better solution. Had I not sought the expertise of this tester, the issue may have been “explained” away or deferred with the intention to never resolve it. Needless to say the credibility of the tech savvy tester was recognized by the development staff and solidified my determination to add reading/writing code and a deeper understanding of enterprise infrastructure to my skill set.
I’ve been told that in many foreign countries, the native are incredibly gratefully when you simply attempt to speak their language. It brings down any walls that may have been formed due to past experiences or false perceptions. They tend to be more willing to assist you in your endeavors, which is incredibly important if you need to eat or find a restroom. It is the responsibility of every tester to work towards removing the “us vs. them” walls. While I understand my job isn’t to write/read code, the more I know about an application the better equipped I am to test it, the better information I’m able to provide, and greater my credibility within an organization. Thank you so much for this article