Before you can achieve continuous delivery, you need to first start implementing continuous integration. Some say CI is just for developers, but testers also play their own important roles. This article describes solutions that will help you add value to the development lifecycle—whether you work in an agile, DevOps, or traditional context.
Bonnie Bailey writes that as testers, some of our track record will be pure luck—for better or for worse. We should, however, strive to test well enough that users must be crafty to cripple the software we stamp.
Robbie Bridgewater writes on the difficulty in finding bugs during testing since no single computer can run all of the major browsers—not to mention the added challenge of testing various mobile operating systems. In this article, Robbie compares four possible solutions to this dilemma.
Payson Hall shares with us a useful list of review criteria via a case study of a troubled software development project. Reviews can be messy. Sometimes it’s hard to know where to start, particularly when you are in triage mode and can only review a small sample.
The loudest voice in the room might push for a stable, predictable, repeatable test process that defines itself up front, but each build is different. An adaptive, flexible approach could provide better testing in less time with less cost, more coverage, and less waste.
How do you adapt inspections to a twenty-first century distributed workforce? A key part of the inspection process is the team meeting, which provides peer pressure to participate and consensus on defects. Teams working in multiple time zones have limited opportunities for the team meeting. A list of requirements and the functions needed to solve this problem based on real-world experiences should help anyone faced with this problem.
Code review is one quality initiative you can't afford to skip. Don't have time for a full-blown, line-by-line review? No problem. Discover how even something as simple as a peer review can benefit your project and ultimately improve your code.
Thirty-year system software engineer and testing consultant Jon Hagar details the challenges that embedded software testing poses. Learn how risks should feed attacks, especially when maintaining the safety of devices like pacemakers and braking systems.
Are you suffering from chronic disinterest in what your team is delivering? Are your product owners unavailable or distracted? Are your sprint reviews ho-hum experiences with low attendance? If you answered Yes to any of these questions, your agile teams are in trouble-and you need to attend this session. Experienced agile coach Bob Galen explores real-world patterns for how to increase the interest in-and the energy and value of-your sprint reviews. First, Bob explains how to prepare properly, the keys to dry runs, and the role of a Master of Ceremonies. Then he examines ways to orchestrate pro-active reviews that include the whole team and engage your audience when demonstrating "working software." Next Bob discusses how to perform a review follow-up and gather feedback for high-impact improvements. Finally, Bob wraps up by exploring ways to make sprint reviews a centerpiece of your agile adoption and transformation.
Traditional performance evaluations, which focus solely on individual performance, create a “chasm of disconnect” for agile team members. Because agile is all about team performance and trust, the typical HR performance evaluation system is not congruent with agile development. Based on his practical experience leading agile teams, Michael Hall explores how measurements drive behavior, why team measurement is important, what to measure, and what not to measure. Michael introduces tangible techniques for measuring agile team performance-end of sprint retrospectives, sprint and project report cards, peer reviews, and annual team performance reviews. To demonstrate what he’s describing, Michael uses role plays to contrast traditional, dysfunctional annual reviews with agile-focused performance reviews.
Would you tell your publisher to stop editing in the middle of your manuscript and publish your novel now? Of course not! Then, why would you tell your QA/test team to stop identifying problems with requirements documentation? All deliverables—and especially requirements—should undergo a rigorous assessment based on their quality attributes and measurable evaluation criteria. Mark Haynes describes quality models and attributes he has used to evaluate requirements documents. He shows how you can detect imprecision-that will haunt you later-and remove it with a set of formal criteria and informal heuristics. Discover how you can use quality attributes, even subjective ones, to conduct a quality dialogue within the development team. Mark shares examples of poorly written requirements for you to evaluate and try your hand at improving.
Want to improve the quality of your products? Of course you do. But how? Mette Bruhn-Pedersen uses a simple, but effective method that includes both clients and users in the development process. His company organizes and conducts verification sessions early in the development process. These sessions consist of two parts: First is a demonstration of the implemented functionality using test cases as examples; second is a "play" session in which the customer is given control of the system to explore the functionality from a business perspective. By observing the client, testers get a better understanding of what functionality is most important to the client as well as increasing their knowledge of the software's intended use. Sometimes, the clients find important, new defects during the session. And almost always, testers learn they need to add new test scenarios based on their observations during the play session.