Testing For Success Sometimes Doomed To Failure
November 5, 2012 Yvonne Enselman
|
As my position has shifted from being a programmer to a tester, I have not lost interest in the IBM i world. How the platform functions and what trends drive development remain relevant to my job. If I don’t understand it, I can’t test it. While I find information that helps me grasp what the techies are doing, it is difficult to find information relevant to other teams in our i-focused publications. It’s time to start talking about application testing for IBM i developers and other IBM i professionals who don’t understand why platform matters. Starting from the developer point of view, I don’t know a single successful programmer who doesn’t believe in testing. It was covered early and often in the classes I took and has never been downplayed during my career. However, the team composites have changed drastically since I started in the AS/400 arena in the late 1990s. What was always my responsibility, maybe aided by sign-off from a super user, is now handled by a separate team in many shops. And while generally there is more attention being paid to testing as a process, there are substantial differences in the way every company approaches it. Frequently this results in more visibility and higher expectations as testing becomes identified as a cost-effective IT strategy, without added support or resources. As for the QA point of view, this position requires that someone take responsibility for the quality of work produced by someone else they (usually) can’t evaluate first-hand via reading the code. It is no wonder testers have a hard time trusting their compatriots. When a defect makes its way into production, QA is blamed for not catching it, although it is no more the tester’s fault than the developer’s. Both let the mistake get by. Human error occurs and 100 percent testing coverage is impossible; everyone needs to work together to mitigate those factors. This is a unique dynamic, essentially enforced symbiosis, and it is hard to establish a good relationship. Added stress comes from non-trained testers moving into QA from development or when traditional QA professionals are added to a technical team not possessing an IBM i background. There aren’t specific rules for setting up teams or how testers and developers should work together. Like most things, impacts occur due to a mix of factors like size of company, general culture, and types of development. Here are two types of relationships and some of the issues that can arise from them. By identifying potential concerns, they can be addressed before quality suffers. First is the Yellow Brick Road of Testing. You often see this when developers are doing their own testing or someone from the development side is tasked with evaluating the programming of team members. If I am the developer, or am working closely with developers, I know where we are supposed to go and it is very easy for me to follow the path. Group think is a known variable in most teams. A mistake that gets overlooked by one can be overlooked by everyone. Another concern about this type of department is that independent testing is usually done by an end user at the end of the development cycle. This leads to the most expensive issues, which require advanced business proficiency and nuance to identify, being fixed at the deadline. It adds pressure on the development team, creates a lack of faith in the tester, and builds stress on all involved. However, there is a reason the Yellow Brick Road was the path to Oz. The advantages to these close developer/tester environments are established relationships and the practice of implementing testing into development. First, it tends to be the first foray into routinized testing and the most logical place to insert the new tester position is the general app development team. Second, the most crucial time to implement testing and qualifications is early in development. By having a teammate voice issues regarding testing while programming is being planned changes are made earlier in the process, which makes them less costly to correct. Establishing QA is an involved process and placing a tester on the dev team–making programmers cognizant of testing–is a great first step. As time passes and routines are established, the whole team starts and stays on the same page. Integrated development and testing teams allows the tester to look for the patterns of concern that have been discussed in meetings. The benefit of this is having a tester who can focus on needs rather than looking into the haunted forest for flying monkeys that attack quality and productivity. However, once a team identifies over-familiarity as an obstruction to proper testing, it is time for QA to peel off from development. A second type of departmental construct is Gladiator Survival Development versus Testing Cage Match. I have the most issues with this because the culture that causes it comes from high-level personnel and is hardest on the people who actually get the work done. It is based on the more defects testers find the higher their scores. And consequently, the defects lower the scores of developers. Added to this, when defects are found in production, the testers get lower scores. This fosters tension and competition between groups who need to work together. Finding and resolving issues is something that benefits all the stakeholders in the company, but if doing my job well unfairly hurts another employee it erodes confidence. Likewise, developers who are concerned about their standings might handle issues via work-around solutions that aren’t part of the design or documented. This subverts the testing process. In extreme cases, this can even mask a flaw in the system as a whole that won’t be identified until it impacts a larger area with more exposure and greater expense to resolve. However, the worst thing about this is it makes professionals feel lousy about themselves, their work, their environment, and their coworkers. For people who find themselves in Gladiator-land, the best advice is to reach out to your counterparts. They are probably as frustrated as you and any positive connection can take the edge off the competition. Think about what the other person is being asked for or how it is being asked. What do they have riding on your collaboration and what is their risk? It is usually pretty easy to see why you need each other to succeed and how that can be accomplished. It doesn’t matter how intelligent you are or generally how strong a team player, when your job performance and evaluations are linked to the work of another person it is hard to establish trust. As more companies implement QA procedures, traditional IBM i developers are going to be faced with these challenges. By starting the dialogue, we can all learn how to enhance not deconstruct each other’s efforts. Yvonne Enselman is a former developer, an ASTQB Certified Tester Advanced Level – Test Analyst, and the technical specialist for Testing and Deployment at Brotherhood Mutual Insurance. Enselman has been a part of the IBM i community since 1997, a member of the Omni User group in Chicago since 1998, and recently became a volunteer for the COMMON User Group.
|
