5 Benefits of Daily Builds

This month's newsletter describes the major benefits of doing daily builds and how it can improve your software quality. A daily build is the process of compiling your software daily so that tests can be run against it to identify any major coding issues introduced since the last build. Daily builds have become common place with Agile development, but it is not limited to just Agile teams. Teams practicing Waterfall development can also get enormous benefit from this approach.

To see the full article, click here: http://www.softwareplanner.com/newsletters/Newsletter_2010_05_SP.htm

Powerful Metrics for Developers

Insanity is defined as "doing the same things over and over and expecting a different result". As a developer, it is easy to get into a rut of doing the same thing over and over again but never really improving your development process or identifying things that can aid in bringing real success to your job. To improve, we need to understand our goals and measure our progress towards them. This article discusses how to develop metrics that aid you in achieving specific goals.

What are Powerful Metrics?
Metrics are simply a way to measure specific things you are doing, but you could create hundreds of irrelevant metrics that really don't move you any closer to solving your everyday problems. Powerful metrics are a small set of indicators that are targeted to help you accomplish a specific set of goals.

Metrics Driven by Specific Goals
Before defining your metrics, ask yourself "What goal(s) am I trying to accomplish?", then write your goals down. For example, typical goals for a developer might be to:

• Improve my estimating skills
• Reduce defect re-work
• Ensure that my code is tight and re-usable

Now that we have our goals defined, let's figure out how we can create a set of metrics to help us accomplish them.

“Improve my estimating skills"
To do this, you first need to record the actual time you work on assigned tasks as compared to the original estimates. The difference between the estimate and actual is the "variance". At the end of a project, determine your overall variances to determine how well you track against estimated hours. If you find that your variances are over 10%, consider buffering your estimates on the next project by the variance amount. For example, take the example below:



In the example above, buffering your estimates allow you to become a better estimator. After tracking this for a few releases and buffering your estimates, you will begin providing more accurate estimates. If your team is using Software Planner, you can run variance reports that automatically calculate the information above, below is an example report:


“Reduce defect re-work”
Software releases often take much longer than needed because defects are not resolved on the first round and it adds time to the release timeline when developers have to fix the same issue multiple times and testers have to regress those changes over and over again. Many times defects are re-worked 5 or more times before they are correctly fixed.

To resolve this issue, you must first have an appreciation for how often this is happening. One strategy for this is to add a field to your defect tracking solution that indicates that a defect is being re-worked. If your defect tracking solution has auditing capabilities, it should be easy to produce a report or dashboard that counts the number of times defects are re-worked. Below is a dashboard generated from Software Planner that shows defect re-work:



By knowing this, you can work on reducing re-work by employing these techniques:

• Better steps-to-reproduce - Many times re-work happens because the tester has not provided enough steps to reproduce the issue consistently. Work with your QA team on providing really great reproducible steps. Even better, have them record the steps into a movie that show how to reproduce the issue. This can quickly be done by using Jing (http://www.jingproject.com/), a free utility that allows you to record an issue and it creates a link so that the developer can see it in action.
• Better Unit Testing - Sometimes developers rush through the development and do not fully test it before sending it back to QA. This takes discipline, but if you take the time to fully test it before sending it back to your QA team, it will save you time in the long run.
• Peer Code Review - Another set of eyes on your code can help you reduce re-work. Consider asking a peer to review your code before compiling it and sending it to your QA team. You can speed up code reviews by using tools like Code Collaborator.

“Ensure that my code is tight and reusable”
To do this, you must do peer code reviews. By having others inspect your code, you will begin to write tighter and more reusable code. To measure the effectiveness of this, measure the number of defects found during code review versus defects found during quality assurance. This will quickly identify how code review leads to a reduction in defects found during QA, which is more costly to fix than during development. Keep track of code reviews and defect statistics, below is an example:



You can speed up code reviews by using tools like Code Collaborator.

Summary
Dedicate yourself to improving your job by identifying your goals and tracking metrics that help you determine how you are trending towards your goals. The metrics listed above work fine for my team but I would like to hear what metrics you find are helpful in your organization. To communicate that to me, please fill out this survey.
If we get great feedback from this, we will publish the results in our next month's article so that we can all learn from each other.

Sign Up Today
Start improving your project efficiency and success by signing up for our monthly newsletters today.

Want a FREE BOOK of code review tips from Smart Bear Software?
You may not realize it, but Software Planner has a sister - it's Smart Bear Software. Both companies are owned by AutomatedQA and our teams relish helping developers deliver software reliably and with high quality. Smart Bear’s Code Collaborator tool helps development teams review code from anywhere, without the usual grunt-work and pain that often accompany peer code review.

Bugs cost 8-12 times less to fix if found in development rather than QA (and 30-100 times less if found in development rather than after release). And of course bugs found in development mean less time spent chasing them down for QA folks! Smart Bear believes so strongly in code review that they will send you a free book of code review tips. They conducted the world’s largest case study of peer code review with Cisco Systems, spanning 2500 code reviews, and the book presents these findings along with other peer review best practices.

If you know anyone who might be interested, please pass this information on to them -they can visit http://www.codereviewbook.com/?SWPnews to request a copy of their own!

Helpful Software Testing Tools and Templates
Below are some helpful software testing resources and templates to aid you in developing software solutions:

• Software Planner
• AutomatedQA TestComplete (Automated Testing Tool)
• Code Collaborator (Peer Code Review Tool)
• Software Development and QA Templates
• Test Case Training
• Pragmatic Agile Development

Powerful Metrics for Testers

Insanity is defined as "doing the same things over and over and expecting a different result". As a tester, it is easy to get into a rut of doing the same thing over and over again but never really improving your test process or identifying things that can aid in bringing real success to your job. To improve, we need to understand our goals and measure our progress towards them. This article discusses how to develop metrics that aid you in achieving
specific goals.

What are Powerful Metrics?

Metrics are simply a way to measure specific things you are doing, but you could create hundreds of irrelevant metrics that really don't move you any closer to solving your everyday problems. Powerful metrics are a small set of indicators that are targeted to help you accomplish a specific set of goals.

Metrics Driven by Specific Goals

Before defining your metrics, ask yourself "What goal(s) am I trying to accomplish?", then write your goals down. For example, typical goals for a tester might be to:

• Ensure that each new feature in the release is fully tested
• Ensure that our release date is realistic
• Ensure that existing features don't break with the new release

Now that we have our goals defined, let's figure out how we can create a set of metrics to help us accomplish them.

"Ensure that each new feature in the release is fully tested"
To do this, we must have assurance that we have enough positive and negative test cases to fully test each new feature. This can be done by creating a traceability matrix that counts the number of test cases, number of positive test cases and number of negative test cases for each requirement:

Requirement	# Test Cases	# Positive	# Negative	Comments
Visual Studio Integration	104	64	40	Good Coverage
Perforce Integration	0	0	0	No Coverage
Enhanced Contact Management Reporting	45	45	0	No Negative Test Case Coverage
Contact Management Pipeline Graph	10	8	2	Too few test cases

“Ensure that our release date is realistic”
To do this, we must have daily running totals that show us test progress (how many test cases have been run, how many has failed, how many has passed, how many are blocked). By trending this out, day-by-day, we can determine if we are progressing towards the release date.

Software Planner provides graphs that make this easy:

Another way to do it is to create a Burn down chart that spans the testing days. On the chart, it will decrement each day by the number of outstanding test cases still to be run (awaiting run, failed or blocked) and we can compare those totals to the daily expected number to determine if the release date is realistic. Let's assume we have a 2 week QA cycle, we can define the number of test cases to run and daily we can keep track of how many are still left to complete versus how many should be left to complete.

In the example above, we can see that we are not getting through the test cases quickly enough. On day 5, we are behind schedule by 15 test cases and we can see this clearly on the Burn down graph -- the red area (actual test cases left) is taller than the blue area (expected test cases left).

“Ensure that existing features don’t break with the new release”
To do this, we must run regression tests (could be manual or automated) that tests the old functionality. Note: This assumes we have enough test cases to fully test the old functionality, if we don’t have enough coverage here, we have to create additional test cases. With regression tests, you can normally stick to “positive test cases” with this group, unless you know of specific "negative test cases" that would be helpful to prevent common issues once in production.

To ensure you have enough of these test cases, it is a good idea to group the number of regression test cases by functional area. Let's assume we were developing a Contact Management system and we wanted to be sure we had regression test cases assigned to each functional area of that system:

Functional Area	# Test Cases	Comments
Contact Management Maintenance	25	Good Coverage
Contact Management Reporting	0	No Coverage
Contact Management Import Process	10	Good Coverage
Contact Management Export Process	5	Coverage may be too light

To determine if release dates are reasonable for your regression testing effort, use the same Burn down approach illustrated above.

Summary

As the new year begins, dedicate yourself to improving your job by identifying your goals and tracking metrics that help you determine how you are trending towards your goals. The metrics listed above work fine for my team but I would like to hear what metrics you find are helpful in your organization. To communicate that to me, please fill out this survey:
http://www.surveymonkey.com/s/DW656JZ.

If we get great feedback from this, we will publish the results in our next month's article so that we can all learn from each other.

Peer Code Review: An Agile Process

This month's newsletter discusses how peer code review can be used by Agile teams to drive better software quality. The article was written by Gregg Sporar of Smart Bear Software and published in the proceedings of the Agile Development Practices conference in November 2009, Gregg has kindly given us permission to share it with you. We hope you have a great holiday and enjoy Gregg's article.

Is Peer Code Review Agile?
Peer code review is one of the most effective ways to improve software quality – but is it agile? Done correctly, it absolutely is. The Agile Manifesto[1] states:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Research has consistently shown that code review produces software with fewer defects, which aligns with the emphasis on working software. And what could be more interactive than two or more software developers talking (or instant messaging or emailing) about the code and making real-time improvements?

Yet many agile practitioners consider peer code review to be part of the “bad old world” of waterfall development and reject its inclusion in agile projects. This newsletter shows how code reviews can be conducted using methods that align perfectly with the fundamental principles of agile development.

Moving Beyond the “Code Review Stigma”
Historically, the process for conducting code review was pretty “anti-agile.” As originally conceived by Michael Fagan in 1976, code inspections[4] were a heavyweight code review process that led to an entire generation of software developers who believed meetings were necessary in order to review code.

Heavyweight processes and meetings are not regarded favorably on agile projects, and that stigma has tainted the concept of code review. This “guilt by association” has worn away over time, but misconceptions still linger.

The biggest misconception is that meetings are required to do code review. Fagan stated that meetings are required, as have other researchers. But Lawrence Votta of AT&T Bell Labs was not convinced. His study[6] showed that if developers read the code before the meeting in order to find defects, actually having a meeting will only increase the total defects found by 4% (while often tying up several hours of valuable time per participant).

Recent studies have confirmed that code review can be effective without meetings. Jason Cohen, founder of Smart Bear Software®, conducted a study[3] at Cisco Systems® that showed that a lightweight peer code review approach was as effective as a heavyweight code inspection process, but more time-efficient by a factor of 7x.

Yet even agile devotees who recognize that meetings are not required have misconceptions about code review: “We only use the latest techniques here – code review is from the past and provides no value,” or “All the unit tests pass, so why do we need to do code reviews?” If you take away the meetings and the heavyweight process, but leave the interaction, responsiveness, and dedication to continuous improvement, then code review is very much an agile practice.

How Does Code Review Align With Agile?
Delving into the underlying principles[2] of the Agile Manifesto provides specific evidence that code review is agile:

Working software is the primary measure of progress. Software developers are fallible, just like all other humans. We make mistakes. Some of those mistakes can be detected automatically (unit tests, static analysis tools, etc.) but just as professional writers have human editors in addition to spell-check software, software developers benefit from having one or more other developers examine their source code. It is interesting how much time we spend during an iteration discussing the requirements with our stakeholder(s) and the emerging design and architecture with other software developers, but when it comes time to actually write the code the tendency is for each developer to work in isolation. The interaction during discussions of requirements, architecture, and design uncovers flaws. The same principle applies to the writing of the code. Code reviews uncover flaws and have another key benefit that is prized by agilists – the feedback is kept close to the point of creation and happens sooner – before the code gets to QA or customers.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. That’s a tall order. To help meet it, agile teams frequently practice collective code ownership. The goal is that each portion of the source code is understood by more than one member of the team. To reach that goal, it is important to pay attention to the bus number for each part of the code – how many team members would have to get struck by a bus before no one was left that understood the code? If the bus number for a section of the code is less than two, then that’s a problem. By encouraging the reading and discussing of the source, code review helps maintain collective code ownership, increasing the bus number for the reviewed code. That way, if a team member is on vacation, or leaves the team, progress can continue at the same pace.

Continuous attention to technical excellence and good design enhances agility. All software developers have egos and most of them are naturally curious people who enjoy learning new things. Developers who know that their code will be reviewed tend to write better code because they know that their reputation is on the line. No one wants to be thought of as the weak link in the chain. A corollary is that developers who review other’s code get an opportunity to learn new tricks and techniques. A key step in mastering any craft is to benefit from the experience of others.

Types of Lightweight Code Review
Lightweight code review provides the right mix of code review process with agile practice, allowing effective and efficient code reviews without overwhelming burden. There are four different approaches to doing lightweight code review in an agile environment. Each has its strengths and weaknesses and they are not mutually exclusive, so there is no single right or wrong approach. As with so much in the agile world, each team needs to decide for itself which approach is correct.

1. Over the shoulder. This is the easiest technique of all: when it is time for a code review, find a developer and sit down with him or her in front of the code. Face to face communication is an easy, high-bandwidth medium for the author’s explanation of the code. An obvious drawback is that not all teams have all members in one location. An additional issue is that the reviewer is being interrupted – after the review it will take time for that developer to get back to the same level of productivity. The biggest risk with this sort of approach, though, is that it can end up being a walk through instead of a review. If the reviewer has no prior access to the materials then typically the author does most of the talking, which can result in a passive reviewer who spends more time nodding than asking questions about the code.
2. Email pass-around. When the code is ready, send it out over email. One of the advantages of this approach is that reviewers and authors can be in different locations. Another advantage is that the reviewers can do the review at their convenience. One obvious downside is that as the review proceeds and the emails get nested in multiple replies, it becomes more difficult to follow the conversation. And if files are reworked and line numbers change, it can be challenging to determine which version of a file – or even which line – is being referenced by a particular comment. But perhaps the biggest drawback is that it can be difficult to answer a simple question: When is the review finished?
3. Pair programming. One of the Extreme Programming world’s key contributions has been pair programming, which in some ways is a continuous code review. The advantages are that no workflow or tools or interruptions get in the way. Further, the review is at a deep level since the developer who is reviewing has the same level of experience with the code. One obvious downside is that the time commitment is non-trivial. A less obvious downside is that the reviewer is “too close” to the code to give it a good review. After all, a key benefit of code review is to get outside opinions. If two developers are pairing to the extent that they have the exact same view of the code then the code review will likely not be as effective.
4. Tool-assisted review. Code review tools exist to help overcome the shortcomings of the approaches listed above. They can package up source files, send notifications to reviewers, facilitate communication, ensure defects are fixed, and more. The obvious downside is that they require at the very least time for installation and configuration, and in the case of commercial products, money for license purchases. A popular tool for peer code review is Code Collaborator (http://www.codecollaborator.com).

Techniques for Optimal Code Reviews
Regardless of which type of lightweight code review your team chooses, there are tips and techniques[5] for preventing wasted time and improving the results:

• Limit the amount of time – a developer should spend no more than sixty to ninety minutes at a time doing code review.
• Go slowly – typically 200 to 500 lines of code per hour is the maximum rate for an effective review.
• Limit the amount of code – as a product of the time and rate recommendations, the total amount of code for a review should be no more than 200 to 400 lines.
• Have the author annotate the materials before the review starts. Just looking at the code using a different tool than their standard editor can lead developers to spot problems in their own code before the review begins.
• Review checklists (if used) should be short, contain no items that are obvious or can be detected via automation, and should focus on things that are easy to forget (e.g. “Are all errors handled correctly everywhere?”).

Overcoming Resistance
A key Agile Principle[2] is: “The best architectures, requirements, and design emerge from self-organizing teams.” If peer code review is mandated by someone outside the team, its chance of success decreases. If team members do not want code review to succeed, it will fail.

Even when suggested by a team member, code review can still face resistance. A key to success is to start slowly. Do not attempt something like: “Starting today 100% of all code written must be peer reviewed.”

The key is to instead get the best return on time invested by initially doing code reviews only on a limited part of the source code. For example, one approach is to have the developers agree on the “top ten scariest source files” and then only review changes to those files. Or only review changes made to the stable branch of the source code. A slightly more extreme approach would be to just review unit tests – if the unit tests are complete and are passing, then those results indicate the underlying implementation is correct without investing additional review time.
The amount of code that gets reviewed can be expanded after a team has experience with code review and sees its value over time.

Summary
Peer code review is agile, when done correctly. The legacy of heavyweight code inspection processes has biased many agile developers away from code review, but there are multiple types of lightweight code review that work well in an agile environment. With the right approach and techniques, and by phasing in the use of code review over time, agile teams can more easily deliver working – and high quality – software.

Learning More
Read about the results and other insights in the book, Best Kept Secrets of Peer Code Review, written by the founders and associates of Smart Bear Software. Request a free copy of this book at http://www.CodeReviewBook.com.

References

1. The Agile Manifesto, http://agilemanifesto.org/, 2001.
2. The Agile Manifesto Principles, http://agilemanifesto.org/principles.html, 2001.
3. Jason Cohen, Best Kept Secrets of Peer Code Review, http://codereviewbook.com, 2006.
4. M. E. Fagan. “Design and code inspections to reduce errors in program development.” IBM Systems Journal, 15(3):216-245, 1976.
5. Smart Bear Software, 11 Best Practices of Peer Code Review, http://smartbear.com/docs/BestPracticesForPeerCodeReview.pdf, 2007.
6. Lawrence G. Votta, Jr., “Does every inspection need a meeting?” Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering, p.107-114, December 8-10, 1993, Los Angeles, California, United States.

Sound Off!
We value your input regarding this newsletter. Please take 2 minutes to fill out a survey (5 quick questions) that asks your opinion about this newsletter: Click here to take survey:

http://www.surveymonkey.com/s/7KKWHC9

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

1. Software Planner - http://www.SoftwarePlanner.com
2. TestComplete (Automated Testing Tool) - http://www.TestComplete.com
3. Code Collaborator (Peer Code Review Tool) - http://www.SmartBear.com
4. Software Development /QA Templates -http://www.softwareplanner.com/Templates.asp
5. Test Case Training - http://www.SoftwarePlanner.com/Services.asp
6. Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf

Reducing Costs with Good Requirements and Code Reviews

Teams constrained by resources are always looking for a competitive advantage in reducing costs and improving software quality. This advantage can be achieved by implementing two best practices:

1. Writing good requirements
2. Providing peer code reviews

Studies have proven that the later a defect is discovered, the more it costs a team to fix. A study conducted by Dunn - "Software Defect Removal" - found that a defect that costs $1000 to fix when discovered during requirements analysis costs $25,000 to fix when left undiscovered until the quality assurance testing phase. Another study conducted by Jason Cohen, highlighted in his book - "Best Kept Secrets of Peer Code Review" showed that defects cost half as much to fix when found during code review vs. when discovered during quality assurance testing.

Defining Good Requirements
A good requirement contains these elements:

• A narrative that explains what the requirement is going to accomplish
• A prototype that depicts exactly what is expected (screen shots, report layouts, etc.)
• A list of validation rules (e.g. allowable field sizes, allowed values, data validation, etc.)
• A list of security rules (e.g. only administrators can access specific features)
• A list of performance criteria (e.g. must be able to add a record in 3 seconds or less)
• A list of audit rules (e.g. when adding or changing a record, store the history of the change)
• Success criteria (e.g. objective criteria that can be evaluated to ensure this requirement meets the need)

Let's explore how taking this approach saves costs. Imagine we needed to develop a new screen to track our customer contacts and the screen entry needed to collect company name, contact name, email address and phone number. A poor requirement would simply describe the process (e.g. "create a data entry screen for collecting contacts") but would not include any of the other descriptive elements.

Without a prototype to guide him, the programmer might take liberties and design a screen that had a lot of ancillary fields (like birth date and marriage status) that may not be needed and may not include important fields (like email address and phone number). If no validation rules are specified, the programmers may not test a scenario where a new contact is added whose email address is the same as an existing contact -- causing a duplicate contact record.

If no security rules are identified, the screen may allow anyone to delete a contact and this may cause your team to lose an important contact record. If no performance criteria are set, the team may not test a scenario where you have 100,000 contacts in your contact list and your new software may slow to a crawl. If no audit rules are in place and a person deletes a contact, you may never know who deleted an important contact and why.

With a good QA team, many of the issues above would shake out during the quality assurance phase. However, the cost of discovering these issues and re-working the code is dramatically higher when discovered at this time. If the requirements had been written using the detailed elements above, the programmer would not have taken liberties to add additional fields and leave out important ones, they would have stress-tested the solution with large number of contacts, they would have implemented validation logic to ensure all fields were validated, they would have added logic to prevent duplicate records and would have audited records when deleted.

Defining good requirements is equally crucial for Waterfall and Agile projects -- the difference is that Agile projects will break the requirements into smaller units of work that are described by User Stories (what a user wants to do in each case). In our example above, a Waterfall approach would define all of the elements of each requirement at the outset of the project. An Agile approach would break each of those elements into separate User Stories (a User Story for the prototype, a User Story for the Validation Rules, etc.) and would incrementally implement each item in an iterative fashion.

It's also imperative to review requirements as a team (internal teams and client) once they are developed but before they are signed off. The review process lets extra eyes ensure that the elements above are addressed and that the requirement will meet the actual need.

Reducing Defects with Peer Code Reviews
As code is developed, it is important to review the code with your team. Below are a few items to look for in code reviews:

• Ensure the code functionality meets the specifications in the requirement
• Ensure each subroutine contains proper error trapping and handling
• Inspect logic errors that can cause looping, memory leaks and performance issues
• Inspect variable declarations to ensure that variables are cast properly to reduce boundary issues and invalid type casting
• Review coding standards to ensure the code meets your internal standards, is well documented, and easy to maintain

The most efficient way to perform code reviews is to have team members inspect the code (called Peer Code Reviews) on a regular basis and openly discuss possible issues discovered during the code review. This activity can be done before checking the code in (called "pre commit") or after checking the code in (called "post commit"). The decision for pre or post commit is entirely up to your team and the way your team works best together.

By inspecting the code regularly, you can discover defects earlier in the development cycle which, like writing clear and detailed requirements, will reduce costs. Imagine a scenario where you reviewed the code and noticed that no logic had been added for preventing duplicate records from being added.

By discovering the issue prior to testing, you eliminate costly QA time to discover and report the issue. And if QA doesn't find the issue, you will spend exponentially more fixing it once the software has shipped to customers.

From a technical perspective, imagine a scenario where you had some logic that reads data from a database using a record set, then executes a loop over and over again until all the data is processed. A common programming mistake is not checking for a "no data found" or "end of file" condition.

A peer code review could quickly discover that the loop may be entered even if no data was loaded into the record set, which will only cause a failure under that condition. If this defect is not found until QA testing, your QA testers may see erratic behavior where it works sometimes (when data is found) but not other times (when no data is found). It may take your QA testers 2 to 3 days to discover the actual issue, so you have just added several days of effort to a problem that could easily have been discovered during a peer code review.

Reduce Project Costs with These Best Practices
Obviously, the sooner in your development cycle that you identify discrepancies in requirements and find defects, the less expensive the corrective measures will be. By writing good, detailed, and clear requirements at the outset of a project, and by having both team members and customers review them, you ensure that developers spend their time building the right thing the first time. By doing peer code reviews on your code before it goes to QA, you ensure that bugs are found immediately, while they are still easiest – and cheapest – to fix.

Can Tools Help?
Tools can help you with both of these issues.

Software Planner (http://www.SoftwarePlanner.com) allows you to keep all your requirements in a single place and allows your team to setup workflow to ensure that requirements are reviewed for best practices. Software Planner works equally well for Waterfall and Agile environments and allows teams to spot issues with requirements before it is too late and more costly to fix.

Code Collaborator (http://www.CodeCollaborator.com) allows your team to conduct peer code reviews online, a task that is painfully tedious and error prone without a tool.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

• Software Planner - http://www.SoftwarePlanner.com
• TestComplete (Automated Testing Tool) - http://www.TestComplete.com
• Code Collaborator (Peer Code Review Tool) - http://www.SmartBear.comSoftware Development /QA Templates -http://www.softwareplanner.com/Templates.asp
• Test Case Training - http://www.SoftwarePlanner.com/Services.asp
• Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf