Stranger in a Strange Land: Bringing Quality Assurance to a Web Startup

Member Submitted
  • work actively with your information systems team to get the environment you really need. Even small applications can deceive you. For example, we launched a simple application, SantaTracker, on Christmas Eve so kiddies could watch Santa's sleigh fly around the country. The test environment was broken, so we were not able to test on the same architecture that it was to run in production, but we weren't concerned. After all, it should have worked exactly like our regular FlightTracker application! Right? Wrong! It was a disaster!
  • Learn about the development tools. They present their own quality issues and offer some solutions, too. For example, the first version of our content management tool did not have any version control. It took more than a year to upgrade to the release that offered this capability, and even then it didn't enforce version control. We had to constantly police the process to ensure that developers version their code. The software on which our Java applications were based had complex configuration parameters we didn't fully understand when we first put it into production. We had tested our intelliTRIP product with a production load in terms of transactions per second, but never with a realistic number of concurrent users. As a result, the servers kept crashing on the first day we put it in production. If we had understood the configuration and the user session management parameters better in our Java-application management tool better, we could have prevented this problem

II. Define Processes
Collaborate with your counterparts to formalize your processes:

  • Get control of the production environments. Work with your information systems team to create a production update procedure. When I started, developers launched their own changes to production. It was hard to wean them away from this bad habit. Even after we thought we had implemented good production update procedures, we lacked the discipline to enforce it under pressure. For example, since we did not have good configuration management, it became impossible to build baselines of intelliTRIP, so developers would simply move new classes into production to fix problems. Only?after two years did ?we begin to be able to require developers to build scripts and installation documentation before we accepted any software from development for testing.
  • Get involved from the beginning of each project. This is hard work. It forces you to juggle many tasks, but it is essential. Participate in all documentation reviews: Those for requirements, functional specifications, and design specifications. Make sure the documents are complete and clear. Look for ambiguities, gaps, lack of detail. All parties, including marketing, development, test, customer support, sales must agree on a vision for the product. This vision is a short phrase that describes the main thrust of the product. With intelliTRIP, development and test were told to produce a server-side version of the original client-side product as quickly as possible. Sales and marketing believed that the purpose of the product was to quickly locate fares from airline Websites. Since development and test wasn't told that part about quickly, we released the product even though we knew that is was sometimes slow to return results. This type of disconnect can be prevented by including a vision statement in the requirements
  • Define quality. Work with marketing and product development to define quality IS for each product: Should the priority be good, fast, or cheap? (You can only have two of the three!) Even if you choose fast, don't sacrifice the process. At, we once implemented a promotion that marketing believed to be simple and wanted to rush to production. Since the product manager did not

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014), Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 2009). Lisa was honored by her peers by being voted the Most Influential Agile Testing Professional Person at Agile Testing Days 2012. Lisa enjoys working as a tester with an awesome agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world.  For more about Lisa’s work, visit and follow @lisacrispin on Twitter.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!