When QA and development teams work together, everyone benefits. Developers meet their schedules, the QA team releases solid products, and customers get a product that works the way product management planned. If we agree this is the optimum scenario, why does it happen so infrequently? How can you integrate test and development at your company?
State of the Web World
Because of the Web application boom, many QA professionals have a background more in line with the end user of the Web application. Developers now do much of the testing QA engineers used to handle, while the functional and load testing of a Web application has become the job of today's QA professional. Still, high quality Web application delivery is the result of talented development and QA engineers, good communication skills, and best practices for working together.
In addition, most Web applications are constantly being updated, which makes development and testing an ongoing process, thus reinforcing the need for an integrated test and development team. For example, at a European content management vendor, an integrated team works together to continually develop and test new functions and new versions of the software. Their rapid development cycles and rigorous testing plans have to work together to meet production schedules.
But working together requires understanding each other's job pressures. The biggest pressure for both groups is time. Development has deadlines and test has deadlines. Development often sees QA as a time sink, while it seems QA never has the time needed to test a Web application thoroughly. Getting together on this crucial point is imperative if a team is to work together at all.
The following is a list of suggestions that can bring QA and development teams together:
1. Work Together From the Beginning of the Project
It is important for the integrated team to be briefed together by the Web application's sponsor. This provides QA with time to prepare the test environment and also allows QA and developers to hear each other's questions and concerns. This leads to a greater understanding of the functional use of the Web application and provides the integrated team with the necessary information to develop a shared timeline. QA and development also benefit by presenting a united front to the Web application's sponsor. This helps in discussing with the sponsor what can and can't be done and by when.
2. Understand the Web Application's Functional Use Model from the Customer's Point of View
This is a best practice. Unfortunately this best practice isn't practiced much as the Web application sponsors tend to work mainly with development. Once the Web application is written, it is passed to QA for testing. QA is typically on a tight schedule and has huge responsibilities. QA no longer just ensures the Web application works as promised, but that the application works in the way a customer would use it. This is substantially different from testing other enterprise applications.
As a result, today's QA practitioner needs a strong functional understanding of the Web application from its sponsor. Unfortunately if QA gets any information, it is usually from the development team. While this is helpful, the information is more in line with the Web application's specification, not its use model. This, for many teams, is the beginning of misunderstandings. As mentioned above, the best practice is to be briefed together at the very start of the project by the Web application's sponsor. This heads off misunderstandings and provides test with the functional knowledge necessary to begin to build an appropriate test plan.
For example, developers build a Web application to be used according to a specification. Since no two users navigate a Web site the same way, it is QA's job to test a Web application in all of the ways an end user might use it. Functionally understanding the Web application through discussions with the sponsor and development team and using visual representations such as application prototypes minimizes miscommunication.
3. Understand Each Other's Goals
One important and overlooked factor is to simply understand each other's goals. In reality, both groups are working toward releasing high-quality Web applications. Often times while the development team works to meet its own project schedule, it feels that more time spent working with QA will prolong the product delivery cycle. You can hear development's frustration in comments like "the Web application is not supposed to work that way," or "the application was fine when I tested it in development, it must be the test or the test environment." This can lead to a development and QA standoff, which eats up more time and does nothing to improve the Web application. It is important for each group to understand each other's goals. Development needs to deliver on schedule and QA must certify high-quality, highly functioning products.
4. Develop a Shared Timeline
The best practice for solving this issue is to develop a development and QA timeline at the beginning of the project providing for shared goals and rewards. For example, development has a schedule to meet, and test needs to certify the product. Each group needs time to complete each task. Setting up a schedule from the start of the project that includes time for the testing team is crucial to meeting product roll out deadlines. Repeatedly, organizations have proven that early involvement in the development process leads to stronger products and streamlined testing procedures.
5. Communicate Formally...
A best practice often overlooked is the utilization of ongoing progress meetings with development, QA, and the Web application's sponsor. The sponsor reviews the work in progress and makes suggestions through the use of prototypes and other visual representations during these meetings. QA can gain a full understanding of the Web application's use model and learns of any delays in development that would change the test schedule by attending these meetings. QA can also use this information for outlining test scripts and gathering all the platform equipment necessary for the testing process ahead of time.
I have worked with companies where test and development is a unified team with formal job descriptions and weekly meetings. Besides the weekly meetings, additional specific meetings take place between development and test to keep the process on time. These teams have found that defects detected early in the process are much cheaper to fix compared to those found late. These additional meetings also allow better use of bug defect tracking, because any new functionality or request is completely defined for the testing team.
6. ...And Informally
Organizations I have worked with also believe that being co-located with development is crucial to a project’s success. One customer works very closely with development when load testing Web applications. His team is physically located next to the developers, which helps them solve production problems quickly. Proximity and sharing tools that encourage group communication also help.
7. Use Tools That Reinforce Team Integration
Root-cause analysis tools look at internal and external data providing the ability to detect problems at the Web application's servlet level, which enables test to pass accurate performance data to development. Tools, including root-cause analysis software, enable development and QA to quickly diagnose and pinpoint performance problems prior to a Web application's roll out.
As in many integrated groups, bug-tracking software for assigning and managing bug fixes is an essential communications tool. Testers log in bugs and rate them against product deadlines and the bug's severity. Development then assigns the bug to a developer. Oftentimes test and development work together to decide what needs to be fixed.
The level of testing assigned to each team determines the types of tools needed. If developers are unit testing, configuration management tools are very useful. The root-cause analysis tools mentioned earlier are sometimes used by development or by test; production at times. Identifying who is responsible for what level of testing is important.
8. Project Management Should Have the Final Say
Another key point is who reports to whom. The QA Manager will certify that the software is ready to go, but a product manager (separate from QA and development) should have the final say. In many companies QA is part of development, but this scenario leaves the fox guarding the hen house. The best practice is to have QA report to product management, even if they are working with development. It is important to remember that QA is not part of development, even though their efforts must be integrated.
