Prioritizing Early Delivery of Major Features for Effective Testing in Software Projects

Delivering high-impact features early in the software development lifecycle is a practice that often sounds too obvious to be worth repeating. Yet, in project after project, this simple principle is either overlooked or under-executed, resulting in repeated delays, strained relationships between development and quality engineering (QE) teams, and ultimately, avoidable chaos as deadlines loom.

This post highlights why ensuring early delivery of major features is critical, what challenges typically block this goal, and how teams can address those challenges with practical, sustainable planning.

The Reality of Feature Delivery Timing

When working on a software project, not all features are created equal. Some carry more weight than others. They may be background engines like a tax calculation module in an accounting application or the image-rendering engine in a graphic design suite. Or they could be marquee features—a brand-new capability intended to be a headline feature in a new release.

These major components often form the backbone of the user experience or system functionality. That means they deserve extra scrutiny, deeper testing, and more time to stabilize. Yet, paradoxically, they are often the last to be handed off to the QE team.

Why? Because they are usually the most complex, and complexity tends to lead to delays.

Why Early Delivery Matters

1. More Time to Discover and Fix Defects: New features, especially ones being built from scratch, are naturally prone to bugs. Delivering them earlier in the cycle allows time for:

• Comprehensive test coverage

• Identification of corner-case issues

• Regression testing against legacy code

2. Resolving Workflow Disagreements: Even with the most thorough requirement documents, ambiguity or misinterpretation is inevitable. A minor issue like the wording of an error message can cause days of delay if found late. Early QE feedback enables Product Managers to step in and mediate before these discrepancies become blockers.

3. Reducing Localization and Documentation Bottlenecks: Localization and documentation are downstream activities. Their accuracy and completeness depend heavily on the stability of the feature. Early delivery means that:

• Strings and flows can be finalized for translation

• User manuals and help guides can be drafted and reviewed on time

4. Mitigating Risk in Final Stages: When critical features are delivered late, they often carry unresolved defects that threaten release readiness. This increases the risk of either:

• A compromised user experience

• Delayed product release

Common Barriers to Early Delivery

Even when the intention to deliver early exists, reality can get in the way. Common challenges include:

• Scheduling Conflicts: The team may be handling multiple dependencies that push key feature work toward the end of the cycle.

• Inter-Team Dependencies: Some features rely on libraries or APIs being ready, which introduces delay.

• Changing Priorities: Business or product direction may shift, affecting delivery timelines.

• Scope Creep: Continuous additions or revisions to the feature can extend development timelines.

Strategic Solutions

To ensure critical features are delivered early enough for meaningful testing, teams can adopt several practices:

1. Planning from the Start: Feature prioritization must be embedded in the planning phase. Identify the top 3-5 components that are high-risk or high-visibility and schedule them for early design, implementation, and review.

2. Feature Slicing: Break large features into testable parts. Even if the full engine or module can't be delivered early, its building blocks often can.

3. Parallelization: Where possible, split the work so some teams handle foundational components while others focus on complementary tasks.

4. Early Involvement of QE: Involve the QA and testing team during design and coding to:

• Define test scenarios early

• Identify potential risks or ambiguities

5. Build Internal Checkpoints: Set up mid-cycle reviews or dry runs focused only on the major features. Use these to assess readiness, gather feedback, and refine schedules.

Practical Tips for Teams

• Document Readiness Gates: Define what it means for a feature to be “ready for test.” This can include UI stability, API responses being mock-tested, or error handling being implemented.

• Maintain a Defect Buffer: Allocate buffer time for defect triage and fix cycles for high-impact features.

• Promote Transparency: Keep stakeholders updated. Use dashboards to show which features are blocking QE or causing downstream delays.

• Encourage Debriefs: Post-release, conduct retrospectives focused on the timing and testing of major features. Capture learnings for future sprints or releases.

Final Thoughts

It's tempting to treat each feature as just another ticket in the backlog. But some features are simply more important. They define the release. They define the user experience. They carry more risk.

By identifying these early and giving them the schedule, priority, and attention they deserve, teams can drastically improve testing effectiveness, product stability, and overall project success.

Early feature delivery isn’t just about code readiness. It’s about de-risking your release cycle and giving your team the runway to succeed.

Suggested Amazon Books on Software Testing and Agile Planning

• Continuous Delivery by Jez Humble (Buy book - Affiliate link) 
• Lessons Learned in Software Testing by Cem Kaner (Buy book - Affiliate link) 
• Agile Estimating and Planning by Mike Cohn (Buy book - Affiliate link) 

Some white box testing techniques – part 2

This post is a continuation of the discussion on white box testing techniques from part 1 of this article (link).

- Path testing: This is a typical application program that consists of 100s of paths between two points of the program i.e., the entry and the exit. The number of paths goes on multiplying by the number of decisions that are encountered during the execution. This number is again increased by the execution of the loops. Each of these paths has to be tested to ensure there are no bug. This seems quite easy for a straight line having 50 – 100 lines of code but what about a large program? Counting gets difficult. With a limited number of resources (and most software projects have a limited number of resources), all the possible paths have to be covered. Path testing can be made a little easy by not consider the redundant code in the program as far as possible. Path testing is responsible for checking whether or not each and every path is getting executed at least once. Today we also have a new type of path testing, called the basis path testing which is a mixture of branch testing and path testing. Even the path testing makes use of the control flow graph. It involves calculating the cyclomatic complexity. For each & every path, a test case has to be designed.

- Statement coverage: We also know this white box testing technique by other names such as segment coverage or line coverage. This coverage methodology provides coverage only to the conditions that are true. The false conditions are neglected. This helps in the identification of the statements that are often executed in the program. It also helps in finding out the areas of the program where there is no data flow because of no execution. But all the lines of code are examined and executed. Statement coverage is important for verifying whether the code is serving its desired purpose or not. In other words it gives us a measure of the code quality. We can consider it as a partial form of path testing. Disadvantages include: false conditions are left untested; it gives no report about the loop termination and does not consider the logical operators. One line of code might be a full statement, a partial one or blank or may contain many statements. There are nested statements too. The statement coverage has to be measured first and then the test cases should be designed.

- Decision coverage: Another name for decision coverage is “all – edges coverage”. Here all the conditions that result because of a logical decision are considered. It does not matter whether the conditions are true or false. This is just the opposite of statement coverage. The outcome of a decision is nothing but a branch. So the branch coverage gives a measure of extent up to which the decisions in a program have been tested. This is why most of us often get confused with branch coverage and decision coverage and use them interchangeably. But it is more than statement coverage. The decision statements include loop control statements, if statements, if – else statements, switch – case statements i.e., the statements that result in either a true or a false value based up on the logical condition in that statement. This white box testing technique is helpful in validation of branch coverage that is whether or not all branches have been covered. It helps in ensuring that no branch gives an abnormal result that may disturb the operation of the whole program. There are certain drawbacks of the statement coverage as we saw above. These drawbacks are eliminated by decision testing. 

Some white box testing techniques – part 1

In this article we shall give a brief description of the various techniques that are used in white box testing.

- Control flow testing: This is more of being similar to structural testing and is based on the control flow model of the application that is being testing. In control flow testing certain paths among all are selected judiciously so as to provide maximum coverage. The paths are chosen so that a decided thoroughness in the testing process is maintained. This means that paths that have been selected should be enough so as to cover all the statements at least once. It is usually applied to the new software systems that have to be put under unit testing (unit level white box testing). This technique assumes that there are correct specifications, correctly assessed and defined data, no bugs in the program except those in the control flow. The number of control flow bugs is fewer in the programs that are written using object – oriented or structured programming languages. This technique makes use of a flow graph usually called the control flow graph that represents the control structure of the program.

- Data flow testing: Flowing data in a program is what keeps a program active. If there is no data flow, the program won’t be able to perform any operation. The program’s data flow needs to be tested to ensure that it is constant and efficient. Data flow testing also requires a data flow graph. This graph is required to know where and why the data is going or if it is going to correct destination or not. This testing helps in uncovering any anomalies that might restrict the flow of data in a program. Knowing these anomalies also helps in branch and path testing. A number of methods and techniques go in to data flow testing for exploring various events that are taking place in the program, whether right or wrong. It is used for checking whether all the data objects have been initialized or not and makes sure that they are used at least once in the whole program. Arrays and pointers are considered to be the two major elements that play a critical role in data flow testing. These two elements cannot be neglected. Data flow testing might include static anomaly detection, dynamic anomaly detection and anomaly detection through compliers.

- Branch testing: As the name suggests, this testing technique is used for testing all the branches of all the loops within a program. Here branch coverage plays a great role. It has to be made sure that each and every branch in the program is executed once. Thus the test cases are designed in such a way that all the branches are covered. This technique is just for complementing the white box testing at unit testing level. The programmers aim that their test cases must provide 100 percent branch coverage. Also the coverage has to be proper otherwise it can lead to other potential problems such as removal of the code that was actually correct and insertion of faulty code. But providing 100 percent coverage is not possible and we are always left with some bugs and errors that never come to the scene. Branch testing lets you uncover errors which lie in those parts of the program that are least executed or never executed. But there is a potential drawback too; which is; that it is very ineffective in uncovering errors in interactions of structures and decisions. Because of this drawback, the testers usually prefer to go for path testing.

Read more about this in Part 2 - White Box testing techniques.

Tracking the URL's used in the application and having the ability to modify them

Any software application would be using many URL's in them. For example, when you take a product, you could have the following URL's in the product:
- A link for the product's home page on the organization site
- Links for Help pages
- Links for Video tutorial
- Links for customer support
- Links for online pages where the workflow is a mix of desktop and online components
- A link where a customer can buy the product
- When the product used 3rd party components, the workflow may be pointing to 3rd party links

There are complications that come in because of the 3rd party links. For example, I have run into cases where the 3rd party component that we were using became like an orphan because the organization that had provided us the component became bankrupt and closed down (was not purchased by another organization, just shut down). In this case, the component still continued to work, but the link was no longer existing. However, the link was the last part of the workflow and there would be a percentage of the users who would still click on the link and thus run into a problem.
For this purpose, the policy that should be followed should be to ensure that all the links that are actually used in the application are redirect links, where the redirect happens on the servers of the organization and the target of the link can be modified. Doing it in such a way will ensure that even in the case of the above situation where the link for the 3rd party does not exist, the modification of the redirect URL can happen on the company server and point to an alternative workflow (such an alternative workflow could even mean just pointing out to the customers that because of business reasons, the final part of the workflow does not work any more and apologize for the same). This is better than being in a situation where the workflow leads to an error, since that makes the customers think that something is not working, and if the error is not rectified, they start wondering about why the organization is not correcting the error.
However, there is a lot of book-keeping that needs to happen for this. All these links, with the date of creation, the target destination and the person who created the links (and of course, any description of what the link was meant for) are essential pieces of information to capture. This ensures that in the future, if the person who created the link is no longer with the organization, the replacing person has a good amount of knowledge about these links.

Getting the Product Manager to demo the new features to team on regular intervals ..

When you consider a typical software project, you will find that most members of the team are pretty much focused on what they are doing, getting deeper and deeper into the stuff. In your heart, you know that there are so many advantages to be had if people had an overall picture of the project and what is happening across the project, what features have been implemented, the ones remaining to implement, and the linkages between the various parts of the project.
However, at the beginning of the project, the team might have got an explanation of the feature set that the software project was expected to target, and more such details. But as time progresses, the team gets more and more involved with the features or sub-features that they are implementing, and have much less time to take any interest in features other than the ones that they are busy in. This is something that is quite natural, more so when the team is in a schedule that is tight, and the team is fully involved in whatever they are directly doing. However, it is essential to ensure that the team continues to have some information and knowledge about what is happening in other parts of the project. This is important for several reasons:
- Large products typically have features that interact with and are dependent on other features. So data may be moving out of one feature and moving into another feature, or the development of one feature may not be possible until there have been changes done by other members of the team. Because of this, it is important that team members have a good idea about the work being done by other members of the team.
- A team needs to have some amount of preparation for all kinds of possibilities, which means that if a person working on a feature needs to leave (this could be because of some personal emergency, or because of attrition). Hence, for features that are critical, it is important that there should be some planning done for situations that can quickly become critical, and for that, team members should have some idea about the work ongoing in other parts of the team.
- The tendency to do everything on their own can be pretty intense. But as team members compare their notes, they will find that there are many aspects of the code that can be shared across the team, such as common functions (which would include items such as date handling, working with data from a web API, and so on).
Now all of these items deserve their own detailed planning, but the first critical area that helps the team members get an idea about what is happening is by setting up a meeting / demo at a periodic interval. We used to have a schedule of around an year, and we would setup such a demo at around every 3 week intervals. We would typically have a meeting of around 2-3 hours, where the Product Manager would demo the features that have been implemented in the past several weeks, and also provide a background about the workflows that the feature could have, explaining the needs of a customer that could be met by this feature, explain about the possible linkages with other features in the product, and answer any queries that the team members may have.
Such a demo ensures that the team gets a good perspective of where the product is currently at with respect of features. When we setup such meetings, we thought that maybe only 50% of the team would attend, since things were fairly busy and it was totally optional. However, we found that almost the entire team showed up for these meetings on a regular basis; this also showed that the team really did want to know what was happening in other parts of the product but did not have any such platform where they could learn more.

Project Management - Writing down the issues as they come to you ..

One of the most difficult items that would come up during my experience as a project manager was about collating issues for later use. For example, there could be an issue with a team member in terms of their productivity, or issues with a vendor about their quality standard, or even responsiveness to an email sent for a query, and so on. There are numerous items that pop up like this during the course of a project, and the project manager has to resolve then on an ongoing basis. This is the typical life of a project manager.
However, I found that even though these items were resolved on a regular basis, the lack of capturing them in a detailed way made things difficult later. One of the prime examples of this was about interaction with an external team. We went through a post-mortem with the team, after a cycle where the external team had caused us some amount of grief. There were deliveries that were not on schedule, the quality level of one of the deliveries was bad enough that the delivery was rejected (although to get to the point of rejection took a couple of testers a period of around 2 days, and we did not really want to spend this kind of time period for this delivery of an external component).
Similarly, at the end of the cycle (and sometimes during the period of the cycle) there would be the need for feedback on team members, typically other managers, based on the cycle and the quality of their work. However, in all these cases, there were problems. When you are going through a busy cycle, how often do you really remember what happened in specific instances; and there is a lot of feedback that you should not look too much in the past but look towards the future.
So what would you do ? I would typically keep a specific file that would list issues where I thought some later feedback is required or where I felt that the person to whom I was corresponding could have dealt with issues better and I kept the same file in a special folder, and also kept copies of the relevant emails on this subject in the same folder detail.
Not only did this help in driving specific issues through later post-mortem, but even for my study, where I was discussing these sort of issues to drive process changes or improvements, it would really help that I could recall specific issues, the conclusions, my feedback on whether there were specific improvements that could be made, and also had email to even correct people if they pointed out something that was different from what had actually happened (and you would not believe how many times something like this had actually happened).

Processes of the last few days and weeks of a product release schedule ..

As part of a normal product cycle, the last few days and weeks are the ending points of all the hard work, frustration and rewards of the schedule. It is a critical time period in the schedule with the following properties:
- The team is doing their final set of testing / verification. Towards this end, the entire set of test plans and cases would not be running since that may take up more time than is available. For shorter time periods and for quick verification that everything is running fine, a subset of the test cases would be made ready to execute. If automation is made available, then these should be running on a regular basis.
- Any changes to code or defects fixes are being monitored very closely and thoroughly to ensure that there is no risk from these changes to the code. In some cases, when time in the schedule is short, only defects that are deemed very high severity will be fixed and that too when the impact of the changes can be safely evaluated
- All the release documents including the Help file and release notes are all ready and reviewed
-  External testers / pre-release testers have been using the software for some time and all of them have verified that they have been using the product and a majority of them have also deemed the software product ready for release. This can be critical. When the software is near the release period, people not belonging to the team and who are an approximation of the customer base of the product should be comfortable with the quality level of the product and the set of features in the product.
- In many cases, during the testing process, features that require connection to an online server are typically connected to a test or staging server rather than the live server. During the last few days, these connections are changed to the live server and the product is testing with those rather than with the staging server. There is a possibility that this kind of change may bring about some instability in the system and hence the changes need to happen before the release date (atleast a few days before the release date).
- When the product also needs to be released on DVD and on the product web store, there is a need to do final verification on such systems to ensure that everything is working fine (which includes generating actual DVD's and installing from them to ensure that everything works as it should).
- Defect stats are monitored very finely to ensure that there are no surprises at that end.

The managers of the team looking at reviewing processes before the start of every project / product cycle

One of the most critical factors in making a project cycle successful is the processes that are used by the team. What do processes do ? Processes define what the team is supposed to do in different circumstances, whether this be part of the regular routine work of the company, or whether this be involved with exceptional circumstances. Some of the most critical and regular processes that a team deals with and which define whether the team will be successful or not are:
- The process used by the team members for the design phase (whether this be the high level design or the low level design)
- Processes during the coding phase (code re-use, code marking and modification processes (such as commenting with the code, etc), code review process, etc)
- Processes used during the testing phase (process of filing a defect, determining whether the defect has indeed been fixed and can be closed, etc)
Like these, there are numerous processes that are used during the development project, and they play a critical role in ensuring that the work gets done efficiently, and at the same time, as desired. A team may be using processes that have evolved after a lot of experience, or could have been designed by a small set of people (for example, when we wanted to incorporate a component from a new third party vendor, we had to define a process for testing, defect logging and communication with the vendor that worked for the vendor and for us, else things can go real haywire).
When the team is doing one release after another, the processes that they are following are typically those used in the previous release project, and since people are used to these processes, it is pretty easy to follow these processes. However, it is important that the management of the team spend some time in collecting information about how well these existing processes have worked, whether there is a need of modification of some of these processes, and whether some new processes need to be added.
One of the prime examples of collecting such information is the post-mortem meeting. One of the discussion points can be the processes being used in the team, and whether the team feels that there needs to be some modifications in the process being followed, or whether there needs to be any new processes to be created (and such a discussion cannot just start in the post-mortem meeting, but the team needs to be informed that the topic of the new processes will come up in the post-mortem meeting, and that gives them more time to bring the points for the meeting; in fact, the team managers should think through some seed points for such a discussion and include this in the earlier communication, and that will encourage the team to think through this in even more detail).
But this cannot be just restricted to one meeting. If required, specific agenda groups within the team need to be formed to explore some of these processes (for example, every cycle we set up a team to discuss improvements in the coding processes, including the code review process to see what are some of the improvements that are possible and whether some of the processes are no longer applicable and need to be dropped).
The managers can also play a critical role in such a discussion. Each manager can hold a similar discussion within their teams and figure out what are some of the improvements or changes that the team is looking for. When there are processes involved with the external teams, it is important to do a discussion with the external teams to figure out tweaks with such processes as well. There is not a single step to modify such processes, it can be incremental, taking several weeks or even months, but there has to be clarity that initiating such a process of review needs to happen.

Critical to do a smoke testing of the regular build - saves time and effort

For teams that have setup a smoke test of their regular builds, the benefits are such that they may not even understand about why such a post needs to be done; after all, it seems to be obvious that if you put a smoke test to do a quick check of the regular build (in our case, it was a daily build), there are multiple advantages. The most prominent advantage is that as soon as the build is available, the smoke test can be triggered to be run automatically, which in turn will take the build through a series of tests and determine whether there is a problem that needs to be resolved.
Sounds great, right ? After all, there are all advantages to having such a smoke testing of the regular build, but a number of teams do not use it, and at the same time, there are some additional effort that does need to be added in the calculation. Let me lay out the case which we used to have. Because of the size of our code and the amount of synchronizations that needed to be done with the source safe, we would have a daily build that would kick off in the night around 11 PM and typically get done around 7 AM. Now, the problem we used to have was that it was not possible to get anybody to be there to check whether, even if the build did get formed, whether the build would even launch and whether there were any major components or workflows that were broken.
When somebody from the testing team would typically get in around 9 AM, they would check the build and then provide their feedback. Our earnest hope used to be that there no problems revealed in this check. However, once in a while, the morning verification would reveal some problems that needed to be fixed, and it would mean that the build for that day would be late or would even have to be canceled, which had some impact on the defect find / fix rate.
The ideal solution was to have a smoke test run on the daily build. Now, the problem was that thought it sounded like an ideal solution, there were some incremental efforts that we had to calculate:
- Somebody had to write the smoke test cases and integrate that with the build system to provide an email output to several members of the team about the success or failure of the smoke test
- As and when we made some changes to any of the major UI or the workflows, we would need to update the smoke test to incorporate these changes. Sometimes these would get missed, and then you would find that the Smoke test stopped in the middle of some feature, and then it would take effort to do the diagnostic of what the problem was.
- The smoke test did yield some false positives as well. The team would then have to spend some time looking for the break in the build, and also examine whether this was a genuine catch, or whether the smoke test malfunctioned, and the problem could be ignored.
- The tools for running the smoke test could be expensive and the expenditure may need to be approved by somebody who does not understand as to why there is a need for such a software, so some amount of negotiation and discussion would be needed.
- Suppose the smoke test would start running at 7:30 AM and run for around 45 minutes, somebody from the team would need to be in place or looking at the report from the smoke testing at the completion time of the smoke test, and hence there would be a rotating chair where team members would be assigned this role for a specific period.

Introducing a code lockdown near the critical milestones ..

In a typical software development cycle, there are specific milestones near the end, with the expectation that the team would have stabilized the code and the product, and there would be few defects left near the end. However, there is a certain gentleman by the name of Mr. Murphy, who has a law called Murphy's Law (in our team, the definition of the law is simple - if something can go wrong, it will). So, as we approach near the last milestones, there are certain defects that do come up and need to be fixed. However, there are differences in the approach during the time when defect finding and fixing was ongoing, and the time when the team was close to the ending milestones.
The difference in approach is about the strictness in letting code changes go through. In the earlier parts of the cycle, the team would file defects, these would be verified by the developer and then the developer would make a fix for these defects and these would then flow to the tester. However, there were not too many restrictions on defect fixing and code changes, although defects that caused change in functionality or were risky were typically taken to a committee which approved the fixing of the defect, and at the same time, senior members of the team would be involved in code review to ensure that the code being checked in was as safe as could be determined during the process of code review.
However, as one reached closer to the ending stage milestones, there would need to be more restrictions used to minimise risk. At this stage, a problem in a defect fix could cause more problems to the product and even end up having some dependency issues on other parts of the code. The risk was too high of letting code changes go through without some kind of check. Towards this end, a dual check was introduced. The defects would all be passed to a defect review committee which would review a defect and give preliminary approval for some of the defects to be fixed, subject to a more rigorous review of the code. Once the committee gave an approval, there was a higher amount of inspection given to the code during the code review process, and once the approval was there, the code could be checked in the source safe. No code was allowed to be checked into the product area of the source safe (if developers were doing some other work, such as some advance work on a feature planned for the next release, then they could check in their changes to a different branch, but not to the main branch) unless there was approval (some teams have been known to actually put a check to ensure that no code was allowed into the source safe even by mistake, only when the administrator would give access would such a checkin be allowed).
Such a strategy may ensure that late breaking defects would not be easily fixed, but also would reduce the amount of risk in the end stages, and that is a pretty critical achievement.

Working with external teams for getting them to resolve their defects

When we do our planning for the next release of the software, we normally consider a number of risks, seeking to define a risk database that tabulates various known issues that could cause problems to the schedule and the smooth progress of the project. One lesser known risk that sometimes does not make it to the list of known risks relates to defects with people who are outside the core development team. For example, you may have a component that is being used in the product, and there is a defect against that component. Such defects have a higher risk than defects that are with the core team, even if the defect is of the same severity. There are many reasons for these defects having a higher risk. Some of these are:
- The outside team may not follow the same schedule or the priority as the product team.
- In fact, supporting the product team may be a lower priority for the component team, since they may have been given a task of providing support to other teams. This can happen a lot in organizations where there are a number of teams, and a strategic product will get much more support. For example, if the MS Access team and the MS Office team report defects in a component used by both teams, who do you think will get the priority support. In such cases, there will need to be more discussions, escalations, and other such measures before there is support granted.
- There is a much higher degree of coordination and communication needed when interaction with a developer who is outside the core development team
- The same defect may be treated as expected behavior by another team that is using the same component. You may be having a doubt about why a defect can be treated as a feature, but in some cases, a particular workflow behavior may be seen as a defect by one team, and desired behavior by another team. In such cases, the situation may be such that the defect may never be fixed.
- When the defect is with a component that is an open source component similar, there is no guarantee that such a defect may be fixed.

Given some of these reasons above, defects with developers who are outside the core development team are a much higher risk than most teams tend to visualize. We once had a hair raising case where the component we were integrating had a defect, but somehow the developer working on it was not able to replicate the defect. This was close to an important pre-release milestone, and we needed to get some fixing done on this defect, but this back and forth discussion and coordination at a remote location meant that it took around 2 weeks to get the defect fixed and a new component integrated, and this was a big problem for us.
What do you do when you have such dependencies on extended teams ? Well, you can never really get away from the defects, but atleast have processes setup to reduce the time period and coordination cost for these defects. What should you do ?
- Have an understanding with the remote team about the level of testing at their end. If necessary, send them test cases and ask them to provide completed test cases before they provide the component. This helps in reducing the chances of defects passing through their end.
- Setup a process where they can received updated copies of your software so that they can test with such latest software
- Ensure that the external team totally understands your defect management system and processes and they have been provided permissions for the software.
- Have a protocol with them about exchanging information with them about defects and if there are queries on these defects
- Have a regular meeting with them, this help in ensuring that any issues from either end are resolved quickly
- Ensure that any serious defects are communicated to them at a higher priority. This also includes defects that need to be fixed on priority.
- Define an escalation matrix with them, so that if there are cases where you are dis-satisfied or need quick action, what is the process to follow.

All of these will not mean that you will not have external dependencies on defects with external team members, but the problems associated with these defects will be reduced.

Dot / Patch release: Estimating the features where there is a change required

One of the previous posts I wrote about was that of a Dot / Patch release (Estimation of dot / patch release) where there was an effort to show what are some of the reasons for a dot release or a patch release and the broad level points about how to estimate the amount of overall effort needed as well as the generation of schedule needed for the release. This needs to be done even if you already have a hard date for the release of the patch / dot release, since if the generated schedule is going far beyond the required date, then there is something wrong which would need to be solved (possibly by adding more resources, although that cannot be done in every case).
This post talks about actually doing an estimation of the changes required by working on the different features to see the overall impact of the change. Consider a case where a dot release has to be made for the application, with a change made in one of the features for a major defect. Now, the dot release has to be made in a couple of months, with the exact release date being decided based on the estimates for the different areas of the release (development effort, testing, localization, etc). One of the starting points for this estimation effort is figuring the effort needed for development, and for that, there needs to more detailed investigation of what areas need development effort.
How do you do this ? The first and most important starting point is to ensure that you have an experienced developer to do the investigation and estimate. The actual effort can be done by somebody in the development team, but the investigation should be done by a senior and experienced developer. How do you start:
- First, make sure that the developer has been given details of the change needed in terms of requirements
- Give the developer some time to discuss with other team members about the areas which are impacted.
If this is a core area, then the developer would need to go across the application to determine the impact. For example, there may be a need in the user security framework, and that would spin across all the application. If the change is localized to a specific area, then it is easier to make the effort estimate of the change. There is no great complexity in this area, as long as the developer does a thorough job.
- The senior developer should spend time with the actual developer who is going to work on the release and make sure that he has enough understanding of the changes required, and depending on the skill of the developer assigned, make sure that the correct estimate is given (which may included a required buffer).
- The developer also needs to ensure that he has spent time with people from the localization development team and the installer / release teams so that he has an idea of the amount of time needed from their side and can also include these in the effort estimate.
- The developer needs to spend a fair amount of time with the testing team so that they have a good understanding of all the changes that are going to happen in the release as well as the actual impact of the change including all the areas of the application that are impacted. 

Being able to estimate effort needed for smaller releases (patch / dot release)

One of the most difficult tasks to estimate are the smaller projects that a team needs to do. Consider a long project, the typical new version release of a software (for a typical long example, consider the schedule for the release of a new version of Microsoft Office - is it always typically more than 1 year); now even when the team is busy doing this release, there will be always be the need for doing a dot release or a patch at the same time (or even multiple such releases). Why would this happen ?
- There could be a security issue for which an urgent patch needs to be released,
- There could be some new feature that is meant to be pushed through before the next release
- Because the release schedule is long, defects that are found during the next few months are collected and released in an interim release that is then released
- And this is one of the most interesting reasons for a release - I know several people who will not take a new version of a Microsoft until a service pack has been released, since that is when it would have stabilized - so this puts pressure on a company to do a release within a few months

With all this, who does these interim releases ? For products where there is already a definite schedule of interim releases, a small sub-team can be setup to take care of these releases. Such a team will soon gain expertise in doing these smaller releases, and can work on the main release if there are no interim releases ongoing. However, for teams where there is no definite schedule of release of these interim releases, it does not make sense for a team to put dedicated folks to work on the product. Even more, in my experience, when people are assigned to such interim releases, there is a need to rotate the people working on such releases, since these are seen as essential but maintenance, not with the excitement of working for something new.
Now, once people are assigned to do the project, there is a need to figure out the schedule for such a release. However, in most of these cases, the end date is already fixed - the Product Manager already has a date in mind about when these releases need to be released. But, the team still need to define the estimate and a probable schedule in mind:
- Whether this be a dot release or a patch (a patch is a small set of files that is downloaded and can be installed, a dot release is typically the full installer with a few changes in the files). The advantage of having a dot release is that it can replace the original installer
- Define the change that is happening (this typically means the files and features that are being changed, and the estimated impact of this change)
- The amount of time needed for the development team to make the required changes
- The amount of time needed for the testing team to test the area and surrounding areas (this would also include the installer created for the release)
- Typically most products have language versions, and those need to be created and tested when a dot release or a patch is made. So, the estimate for the amount of time needed for these activities also need to be incorporated into the schedule.

Together, all of these can be woven into a schedule for the interim release. If it turns out that the deadline given is less than the projected schedule end, then you need to push back. For a small release, it is next to impossible to meet the project with the required quality principles, unless sufficient time is given. We once had a situation where a particular variation in the installer made a small error in the registry, which then prevented those who installed from being able to install another update, and there was a lot of backlash over that - we had to release another patch for that one.

Read more about the estimation done by a senior member of the development team.

How to decide whether to add another language support to the software product

The time is long gone when you could have only English as the language in which you are planning to release your software. Over the past many decades, software products have seen an increasing amount of revenue coming in from releases made in different languages, to sell in different regions of the world. So, although sales in the United States may be still your highest source of revenue, an increasing amount of revenue comes in from sales in Japan, in Europe, in Latin and South America, and in the emerging regions of China and India (for the last 2, there is another challenge that you have to meet, namely about how to prevent piracy and have more legal sales of the product in these regions).
So, if you have an English only version of your product, what will happen is that you will sell it in the United States, Great Britain, Australia, (and other English speaking nations of the world), and to some extent, you will even sell the English language versions in some of the countries, selling it to those consumers who want the English language versions of the product. But, what about the Spanish speaking world, the Japanese speaking, the French speaking, and so on ? Well, in many of these regions, there will be also a reluctance to buy the product just because the company has not chosen to bring out a specific language release. So, it always makes more sense to release specific language versions of the product, and releasing with the same set of features as the English language version.
The process of creating multiple language versions of the software is much easier. What is basically required is to translate all the UI elements in the application (includes strings, error messages, text within images, and any other text that the user can see) The way that the software code is written makes it easy to extract all these UI elements, and send them off for translation. Once these are translated, these are then incorporated back into the software, and then tested to ensure that there is no functional issue, and no cases where the translation leads into text that is messy or otherwise not right.
If it is that easy, why not just translate the software into as many languages as required ? Well, the previous paragraph was an over-statement; the process is expensive both in terms of revenue and resources. The process is not so exact. It can happen (and this especially happens with Japanese, German and Russian) that the translated text is much larger than the English language version, and there needs to be effort spent to either increase the size where the text is to be fitted (and this would need to be done in all languages) or the text needs to be re-translated into something smaller. For large products, a complete translation, which also includes the thorough testing of the product, can run upto almost a million dollars.
So this why there needs to be thought about translation into a new language. Reasons for the same include:
- Marketing estimate of enhanced revenue
- Potential sales in that region over a period of time
- Negative image getting developed because of the lack of product in that language
- Need of a partner. In many cases, when doing deals with partners, the partner would want the product to be there in multiple languages, and if the language is not supported, the deal could be in danger

Working with people who are not so responsive as developers or testers ..

It can really test the patience of a team when they work with people who do not seem to follow the same guidelines, processes and schedules as the rest of the team does. It seems a bit odd though. The schedule is the most important item of a software development project, with a lot of effort going towards determining whether the team is following the schedule or not, and if there are any slippages from the schedule, it can imperil the success of a project. If there are slippages of the schedule, then it would take a lot of effort from the project manager and other managers and senior members of the team to get the project back on track. In such a case, it seems strange that there can be members of the extended team who are not so committed to the schedule (actually, it is not right to say that they are not committed to the project, it is just that it can be a challenge to get them to follow the details of the schedule).
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.

Sharing of test data with vendors along with test cases ..

In several previous posts, I have been outlining some details with respect to interaction with vendors, for example - (Outlining focus areas of testing, Process for answering queries from vendors, Extracting relevant test cases); all of these outline some areas of interaction with the vendors. Working with vendors cannot be just one single area, there is a lot related to information regarding processes, tools to be used, focus areas to be decided, and so on. Yet another area of interaction between the vendors and the core testing team is the data to be used for the various areas of testing.
Having testing data is very important. You may have all the required test cases for doing a complete feature testing of the application, but without the test data, all this does not mean anything. For example, if you are testing a video application, then you need to be able to test for the different video formats that the application would support, and there are a large number of such video formats that are needed to be tested (unless you are in the video domain, you would not really believe the number of formats that exist because of the large number of companies that do something for video). For each such different type of video format, you would need to have the required data in this regard - multiple number of video files in each format (as another example, you could have a video file that is just a collection of images, another without audio, and yet another that has a combination of video and audio - there could be a defect that is only found if the video file does not have any audio - we once found a defect like this and it was a big pain to figure out what the problem was; after this, we had to add files with and without audio to our testing matrix).
And video files are large. The total size of the video test data that we used for complete testing was more than 50 GB in size, and it was guarded with great care. Because of the sheer size of the test data, we had decided not to put this test data in the source safe we used (because the data backup of the source safe meant that the guys running the source safe were not happy over backing up so much data that was binary rather than being coding text files) and hence had made multiple disk copies of the this test data, and there was some amount of effort required to ensure that there was a master copy of the data and all copies were synchronized to this copy.
Are you getting an idea of the problem we faced when we added a vendor testing team to this matrix. We had to tell them the focus area of testing, we had to prepare the extraction of the required test cases and make sure that these made sense for somebody wanting to do the testing who did not have the same amount of experience as the core team, and then we had to also pass on the large test data to the vendor while linking this test data to the test cases. Even though we had a fast connection to the vendor, there were some permission requests that also had to be processed since some of the test data that we had was from the vendors with no permissions to pass on, and hence every time we needed to pass them onto a vendor, we needed permission (no monetary problem, just the paperwork and time required), and since the test data was changing with new video cameras entering into the market, there were synchronization problems. And in an unusual case, we found that a particular set of high end video files required a very high end machine and this information was not captured properly. So when the vendor tries to use those files, things were not working.
The challenges may differ depending of the type of test data, but there is a need to ensure that there is a strategy to prepare for the passing on the required test data to the vendor.

Working with vendors: Telling them the points of focus for the particular version ..

In some of the previous posts, I have been talking about the issues and processes involved in ensuring that the interaction with the vendors (especially when they are involved in testing) is fine. In the last post (Working with vendors to ensure that tools are synchronized), I talked about how the team should be spending time on defining a process for transferring knowledge about the tools used by the team during testing. Now, this is easy for tools that are in generic usage, such as tools for Defect Management, Source Safe, or for capturing the details of Test Plans and Test cases. However, this is more complicated when the tools are specialized such as Fiddler, and other such tools that take time for vendors to learn more.
In this line of thought, there are several other processes that the team needs to transfer to the vendor team and do this in a systematic way to increase the level of efficiency. Some of the processes that the team might need to convey to the vendor team are:
- Certain specific processes such as the dealing with defects that have existed for some time. Consider the case of a defect that has been present in the product for more than one version, and the team has decided that they do not want to make the fix. Similarly, there may be cases where there is a difference of opinion with respect to the functionality, but anybody who needs to do this testing will be able to log a defect. In such cases, the team members know about these defects and do not try to file them, but somebody who is new to that area such as a vendor team member will not know, and will file defects in such areas. It is for the product team to ensure that they have transferred instructions regarding how to handle these defects to the vendor. If this does not happen, there will be wastage of time when the vendors actually do these testing. I saw such a case whereby there were some new members to the vendor team and there was a delay in passing on such information, and suddenly there was a buzz in the team about the vendor finding a number of defects that the team members had not found. There was some pressure on the testing team, but then it was found that most of these defects were of the types that the team already knew about, and there was a sigh of relief in the testing team (they would have come under a lot of pressure if the vendors found a number of defects that the core testing team was not able to find).
- Similarly, there are certain points of focus for every release. Or it could be the case where this is a patch or dot release that is focusing on a certain area, and it is incumbent on the product team to pass on the application focus onto the vendor team. This is needed to ensure that the testing done by the vendor team focuses on the relevant area instead of spending time on other areas which are not relevant. The team needs to decide on the best way to do this, one way to do this is to take the application where test plans and test cases are captured and create a plan that shows the vendor the focus areas where testing needs to be done. However, this pre-supposes that the test cases are written in a way that a subset can be used by the vendors and would make sense.

Working with vendors: Ensuring that tools are synchronized ..

This is part of a series of discussions on how to work with people outside the software development core team, which in most cases are typically vendors. You would be working with vendors for a variety of reasons:
- Part of the testing needed is done by the vendors
- There is a sudden work to be done besides the core work, and the additional work testing is needed to be done by vendors
- The product is being localized into many languages and the testing in various languages is being done by vendors
- Multiple other reasons such as these, all of which raise the need for vendors to take part for testing.

Now, when you have vendors working with the core team for testing purposes, you will be lucky if there is a continuity in terms of the personnel from the vendor side over the years. Our experience has been that unless we are able to provide business to the vendors the year round, people on the vendor side move onto different projects and would not be so easily available the next time when there is a need for the vendor. In addition, there are times when there is a sudden need for testing, and at that time, testers from the vendor side who have experience in the product would not be available.
In previous posts (Process setting, Kickoff and knowledge transfer), I have already been talking about some processes involved in working with vendors who assist in testing, and how to ensure that getting them trained is done as easily as possible. However, there is another area where there is a need for ensuring that knowledge transition happens efficiently, and that is in the area of tools that are used for the process of preparing the data as well as doing the testing.
Applications such as Defect Management systems and source repository systems are easy for vendors to understand, given that even if the vendors have been using a different tool for these functions, the basic concept of using these tools does not change too much, and hence it should be fairly easy for them to pick up a new tool.
However, it gets problematic when the team is using specialized tools, and there is a high chance that the personnel from the vendor site would not have the experience in using such tools. We had this in a previous project, where we were using specific tools such as 'Fiddler' for testing out the flow between the desktop application and an online application. When we spoke to the vendor team around the start of the project, they had no experience in a similar tool, and yet it was necessary for them to do the testing (we could not do the testing of this tool in all the areas where it was the vendor responsibility, and hence it was important for the vendor to learn this tool). So, finally we had to run a project whereby we did a few rounds of web conferencing with the vendor and explained how to use this and other such tools. However, it would have been more efficient to have already prepared such a document for the various tools that the teams use, along with something like a self-learning document.

Read more about working with vendors in the next post (Processes when dealing with vendors)

Getting everybody on the team to do some testing - helps in understanding the process

This is a common topic for everybody that works on a software product or on a software project. Every product has a testing team (although the reporting structure of the team can vary from products where the testing team works as an independent team, or the team can report into the overall manager of the project), but the focus of the post is on a specific phrase called 'everybody tests'. The testing team is the last and probably the only major element in the entire project (leaving aside the processes such as design reviews and unit testing) that controls the quality of the product, and everybody should have a stake in their success. However, this is easier said than done. Many a times when there is some kind of struggle regarding the amount of time available for a product, the thought has gone towards the amount of time dedicated to testing, and whether can be some kind of compromise.
I would like to showcase my experience. I am not on the testing team, but have a good idea of the kind of effort it takes, as well as the amount of time it takes to reach a phase where the testing has come to a completion and a large percentage of the defects have been removed. However, this is one of the biggest problems - there is no such thing as 100% testing, and it can become extremely critical for people to understand that. One of the best ways of doing that is to experience the testing environment and also go through some of the pains involved with the entire testing process.
So, I had the designation of something called a Product Specialist, and my job was to determine the business requirements and provide those in the form of requirements to the development team, work with the team to ensure that those got done and interact with users for training and other purposes. There was a level of understanding of the product that was adequate for my work, but if you asked me, there were levels of complexity in all the workflows that I did not possess. Further, there was always a level of impatience regarding the time-frame it took the development team to get the work coded, and a higher level of impatience regarding the time it took for testing.
However, at a certain phase, we all were way behind in our schedule, and all the non-testing team members were asked to do integration and acceptance testing (we were not qualified to do the system testing part). This was the first time I was doing testing, and the process of ensuring that data was available, of looking at the test cases and selecting the ones for a greater detail of testing, and then the entire process of testing, all these gave an entirely new perspective to the process of testing for me. I had the same feeling as a testing team would get when somebody from the development team would query and deny a defect I found or treat it as a low level of defect that did not really need a fix, and so on. Overall, this experience lasted 2 weeks, and provided me a perspective into the testing process that I never had earlier. An additional benefit was about getting a much higher level of learing of the various workflows in the areas that I was testing. As a result, as I moved into positions of project management, I would always have discussions about ensuring that everybody in the team was asked to do some level of testing, even if they were very busy.
Even if a developer was doing testing, it provided them an invaluable experience of seeing how the feature workflows behaved, and how sometimes even small things can get critical to users if it serves to hinder their workflows in some way. And this is only one of the advantages of having a developer or another role in the team doing the testing.

Ensuring a proper kick off and knowledge transfer to external teams that also work on the software ..

When you consider the software team, you would have a development team, a testing team, designers (including the user interface designer) and also the management team (and one could include the product managers or the product management team in the set of managers). When you consider these set of people, they have a lot of knowledge about the product and the features in the product, especially the people who are working on specific features. There are a few other people who have the same amount of knowledge on specific features. Given their level of knowledge, they take this level of knowledge as granted when they have a discussion with other people who are not on the team, and it can be difficult for them to realize that other teams do not have the same kind of knowledge that comes from working on the same product for a long period of time.

Any product team will need to work with other teams that provide services such as translating the software into other languages, do the documentation for the software and other related services that the product team will not do. The problem with this concept is that people working in these teams do not have the same kind of knowledge of the product that the product team has, and this can be a source of friction in their interactions. In some of these cases, the software team would do the right thing, find out the level of knowledge of these external teams and prepare time to ensure that these teams get a ramp up of the software program. But, even in these cases, it is a fair approximation that they will never reach the same amount of knowledge as the product team, and expecting such a level is what leads to frustration.

In my experience, the frustration comes when the product teams work with external teams that have little or no experience with the product (and this can happen often enough when dealing with external teams, since these teams typically cannot afford to have dedicated people for handling products, and their attrition rate may be different from that of the product team). So, the product team has some amount of knowledge transfer with the external teams, and assumes that there will be some questions that would come from the other teams. However, it may turn out that it takes time for these new people to understand the product, and the queries only come later in the timeline, and this is unexpected for the product team.

The way to handle this is to have a line of managers who understand that new people take time to understand the functionality of the product, and these people will never get the time that people in the product team have. So, there are 2 processes on how to handle this - prepare an effective training program that provides as much information as possible without over-doing it, and equally, learn from the teams that have gone through such an experience and learn what steps can ensure that the external teams learn faster, and what are some of the common problems and frustrations that can crop up in such a relationship.