New requirement after start of cycle - ensuring that there is a proper process followed ...

From the outset, let me make clear that I am not talking about a development process which is Agile or Scrum based (in the Scrum based methodology, features are taken up on the basis of a Sprint cycle, which means that features are taken up from cycle to cycle). Let us take the typical case on which a number of teams work, the Waterfall based development methodology. In this methodology, teams follow a sequential process whereby they start out with a requirements process, which is followed by a design process, which in turn is followed by a coding process mixed with a testing process. The process ensures that a phase is only started once the previous phase has been completed. So, if you consider this entire methodology, the requirements phase needs to come to an end before the design phase starts.
The direct implication of this is that once the requirements phase is completed, it is not expected that there will be a change in requirements. This is now considered to be a weakness in those situations where the requirements are in flux, but if you consider the industry where a software organization does projects for clients, the completion of the requirements phase is a critical stage. The clients typically use the entire requirements phase as a milestone which certifies that their business workflows have been captured accurately and increases the confidence level in the clients that the software mapping their business requirements will be designed accurately.
Now, look at software projects, and consider the case where after the completion of the requirements phase, there is a modification in some requirements or a new requirement that has been added. This new requirement could come in because some change in business workflows has happened, or a customer has added some new feature that is critical for success, or any other valid reason. Once such a change needs to happen, there needs to be a process to be followed to ensure that the team does not increase the level of risk beyond what has already been incurring. Typically, with a change in requirements, there is a risk of the schedule slipping, or the quality level suffering. It is better to take a hard look at the impact of such a change rather than do such a change under pressure, and then find that the software team comes under pressure later.
So what needs to be done ? Well, the group should do an impact analysis of the change before going ahead with the change. This is a process by itself that the team needs to do:
- Have a team of requirements folks to do a review of the change and estimate the change to the requirements already in place
- Work out the design changes or new design needed for this change / addition and the effort estimate
- Do the same estimation for the development or testing phase
Once you have these estimation in total, you know the approximate change to the schedule because of this change. Based on this estimation, the team needs to figure out whether there needs to be a reduction in the feature set to accommodate this change, or whether the number of resources deployed in the team need to be increased for taking this change. However, keep in mind that there will be a point in the schedule where such a change cannot be take just by increasing the number of resources; there will be an impact on the schedule.

When is a defect not a defect and should be classified as a feature ?

This is an interesting question that causes a large amount of debate in many teams during their development process. A defect is something that needs to be corrected (in terms of the discussion in software teams) - and this is without getting into the exact semantics of the definition of a defect. So, in the regular process, a tester finds a problem that needs to be corrected and is assigned to a member of the development team to fix. The development team member analyses the defect, finds the required change, and then makes the necessary fix, the fix is rolled into the product and can then be tested by the tester (the same one or somebody else) and if it is fixed, the defect is marked as verified and can be closed.
This works most of the time, but there are cases when the process does not work like this. For example, there are times when the defect that is marked in the system, when analysed, is found to have a big change. It could be that the fix for the defect causes a change in a code section or file that is used in a number of areas of the application. When this happens, it is not so easy to make a change, since there can be a large impact. The impact analysis of such a change needs to be more wide-spread, looking at the change that needs to be done in the different areas, the change needs to be thoroughly reviewed, and then once the change is made, a thorough testing needs to happen. However, this is not the case that I am talking about, where the defect is still a defect and not a feature.
The feature change is a different kind of defect. This is when a defect is logged which talks about some change in the workflow. It could be possible that when a defect is logged, the defect was logged on the basis of an interpretation of the tester, or the defect is actually tracking a specific point of the product where the feature definition was missing or flawed. Consider a case where a team has defined a new feature, where all the workflows that were written as a part of the product development were done, and then it was discovered during testing that the specific workflow of one area was not done as it should have been.
So what to do ? Well, whenever such a defect is written, it should be categorized as a feature rather than a defect. A defect means that the focus is more on the fixing of the defect, while if you are looking at the problem from a feature perspective, there will be more attention paid. The product manager, the designer, the feature team which was looking at the feature, all of them should be brought in, and they need to look at what the nature of the change should be, whether this impacts more than just the workflows before and after, and so on. It is also possible that if this is at a late enough stage, this group makes a decision that the feature will be left as it is, or the team recommends the change which is then made. Doing it as a feature will also ensure that other teams that need to look at feature changes such as documentation and localization will be informed as a matter of process. In the end, the treatment of such a change may be finally be done through the defect process, but this is done only after the change has had a thorough look at it.

What is an Agile Process Improvement?

A process improvement program is successful only when the meaning of the word ‘process’ is clearly understood. Process means work. So when one improves, the other one also improves. The quality of the software depends a lot on the process. Whenever a change is introduced, a temporary drop in performance is always recorded. In most cases what happens is that the organization stops the implementation of changes fearing the disruption in the normal work since so much effort is required. To avoid such situations, the changes need to be adaptive. It is the agile process improvement that makes this possible. You might say that such a way of iterative improvement is not new. Well, the agile techniques introduce discipline in the whole program.

Stages of Agile Process Improvement

The following are the stages of the agile process improvement:

1. Initiating:

Ø  Stimulus of change

Ø  Set context

Ø  Build sponsorship

Ø  Charter infrastructure

2. Diagnosing:

Ø  Characterize current and desired states

Ø  Develop recommendation

3. Establishing:

Ø  Set priorities

Ø  Develop approach

Ø  Plan actions

4. Action:

Ø  Create solution

Ø  Test solution

Ø  Refine the solution

Ø  Implement solution

5. Learning:

Ø  Analyze

Ø  Validate

Ø  Propose future actions

- The improvement cycles are meant to be followed systematically so that the results might be obtained in time ranging from 2- 6 weeks.

- The whole process lets you maintain a balance the workload as well as the improvement. 

- The flow of the process is as follows:

1. Prioritized list of improvements
2. Detailed plan for the current cycle
3. Implemented improvement
4. Feedback

- After this process, the following becomes possible for the organization:

1. Identification and resolving of the issues earlier in the cycle.
2. Learning process regarding how to tackle difficulties and working of this process.
3. Adaption to the business needs that keep changing.
4. Giving response to the feedback.

- The sponsor holds the responsibility for prioritizing the improvement backlog at the start of each sprint. 

- Also, he is the one responsible for ROI. 

- Prioritization is a good tool for the sponsor to direct the change. 

- Using prioritization, the goals and feedback can be revised from quality assurance. 

- A focus can be kept on the benefit received from each improvement cycle. 

- PPQA deploys and evaluates the improvement in organization in every sprint. - The improvement package consists of 4 sprints namely:

1. Prototyping
2. Piloting
3. Deploying
4. Evaluating

- Active participation and leadership is required for a change to take place. 

- An endorsed vision and status quo is required for the beginning of the process. 

- Both of these are established via SCAMPI and CMMI. 

- The change is led by the management on an everyday basis.

- An excellent description is provided by the generic practices of CMMI for the leadership purpose.

- Similarly participation is a key element that is facilitated by the change team. - A vision is required for initiating the improvement project. 

- The initial improvement backlog is defined by 3 things namely scrumMaster, change team and the work owner i.e., the sponsor all based up on an assessment. 

- The organization is facilitated by the change team.

- With each sprint a tangible improvement is delivered. 

- The change is led by the management in a sprint.

- The effect introduced by the change is evaluated at the end of each sprint by PPQA. 

-The new improvements are defined by the work-owner who is also responsible for adding those in to the backlog of improvements and prioritizes it.

-Commitment is supported at the end of the sprint by appraisal.

-The improvements can also be continuously integrated in to the organization’s way of working. 

What are different characteristics of agile planning?

Two critical areas in software engineering are:
1. Estimating
2. Planning.
They are difficult and error-prone. These activities cannot be avoided.

The purpose of planning is to find an optimal answer to the overall product development question of what to build. The answer incorporates features, resources and schedule. It is supported by a planning process that reduces risk, uncertainty, supports reliable decision making, establishes trust and conveys information.

Planning is an ongoing iterative approach. It is an effort to find an optimal solution to the overall product development question of "what should we build?"

A good planning process supports:
1. Reducing Risk
2. Reducing Uncertainty
3. Supporting better decision making
4. Establishing trust
5. Conveying Information

A good plan is one that is sufficiently reliable that it can be used as the basis for making decisions about the product and project.

What is Agile Planning?

- It is more focused on planning than the creation of plan.
- It encourages change, results in plans that are easily changed.
- It shifts the focus from plan to planning.
- It balances the effort and investment in planning with the knowledge that we will revise the plan throughout the project.
- As the user needs are discovered, our plans are affected and hence changes become necessary.
- Plan are needed that are easily changed. Therefore, planning becomes more important that the plan.
- Changing plan does not mean a change in date.
- Plan can be changed without changing the date by:
            1. dropping a feature.
            2. reducing scope of feature.
            3. adding more people in the project.
- Agile planning is spread more or less evenly across the duration of a project.

What are limitations of smoke testing?

Smoke testing though being quite a helpful software testing methodology has got some limitations which will be discussed in this article. 

Smoke testing is an important software testing methodologies when it comes to the development of very large software projects. "The formal definition of the smoke testing states that it a quick and indeed a dirty software testing methodology that is deployed mainly for testing the major features and functionalities of a piece of software system or application". 

About Smoke Testing

- It is essential to perform smoke testing whenever any changes are implemented in the software system. 

- Originally, the smoke testing for software systems was adopted from the hardware industry. 

- Smoke testing is quite time and cost effective since it lays its primary focus on the components that have been changed recently in order to ensure continued compatibility.

- In addition to all this, a smoke test provides an effective means to confirm that the changed code works as desired and does not hampers the functioning of the whole build. 

- Following this approach, the bugs entering the software system can be immediately fixed. 

- Smoke testing has many advantages that outweigh the limitations but still the limitations cannot be ignored.

Limitations of Smoke Testing

1. Biggest limitation of the smoke testing is that its field of application and usefulness is quite narrow.
2. Smoke testing can only be used when the time frame is small during the introduction of a new functionality or feature in to the software system or application.
3. Though being wide, a smoke test is very shallow.
4. Smoke testing does not take into consideration the fine details of the software system or application.
5. Smoke tests cannot be substituted for actual functional tests.
6. Smoke testing is a kind of black box testing and does not consider the internals of the software system or application.
7. In smoke testing the tester cannot access the source code.
8. In smoke testing the tester has to interact with the system via an interface by giving a variety of inputs and then examining the obtained outputs.
9. Another limitation is that the path coverage provided by the smoke tests is very limited since all the given inputs have to be checked.
10. Smoke tests cannot keep a control on targeting the paths and code segments that might be more error prone than the other segments.
11. Smoke test are a bit difficult to design since they should be designed in such a way that they touch every part of the application software.
12. Usually the smoke testing can be applied only when some new components are incorporated in to the existing software system or application.

More about Smoke Tests...

- Smoke tests can be thought of as preliminary tests that facilitate the further testing of the software system or application. 

- Though the smoke tests reveal simple failure, these failures are good enough to be the cause of the rejection of a prospective and deserving software project. 

- At last we conclude that there exists no such absolute best software testing methodology, each being having its own weakness as well as strength. 

- You cannot expect a testing methodology to fit the test requirements of every application software and conditions. 

- This reason only is enough to conclude that no testing methodology is most important. 

What are different characteristics of resilience testing?

What does resilience mean? It’s important to know the meaning of resilience first because so many people confuse themselves with recovery, reliability and resilience. They think it’s all the same. But it is not so.

- Resilience means to recover from a change.
- It’s slightly different from recovery and reliability.
- Every software application or system has to have some degree of resilience in it in order to be more secure and recoverable and reliable.
- Resilience is a non functional requirement of a software system or application.
- Resilience testing falls under the category of non functional testing.

It is very common for the interchanging use of many non functional tests because of the overlapping in the scope between many non functional aspects or requirements.
One thing to be noted is that software performance is a broad and vast term and includes many specific requirements like scalability, reliability, compatibility, security and resilience.

Non functional testing contains the following testing techniques:
- Compliance testing
- Baseline testing
- Documentation testing
- Compatibility testing
- Load testing
- Localization testing
- Endurance testing
- Internationalization testing
- Recovery testing
- Performance testing
- Security testing
- Volume testing
- Usability testing
- Stress testing
- Scalability testing
- Resilience testing

Software system or application developers with disaster recovery plans or techniques are said to be actively and effectively engaged in reducing the risk of the software system or application crash, failure or data loss. But, the irony is that these disaster recovery plans become complacent.

This happens so because many of the software developers or testers have a false sense of security based on the existence of their disaster recovery plans. To ensure the safety of the software system or application the software developers need to test their data recovering strategies. Some software developers or testers feel this doesn’t applies to all programs because they conducted resilience testing when the software system or applications were put in place.

But one should always keep this in mind that the testing environment, the testing strategies and the range of cost effective solutions and tools available are always changing. It is required to keep pace with all these changes.

- The resilience testing strategies need to be tested and reviewed frequently in order to update for these changes.
- Some software developers and testers fear about the time and cost of test cases that give a better grade of tests and hence they are not able to put their good intention in to the practice and hence there remains a lack of resiliency in the software system or application.
- This does not necessarily means that each and every available test case should be implemented for testing the software system or application.

- There should be test plan for carrying out the resilience testing.
- A structured methodology always ensures that the amount of time consumed is minimum and the effectiveness of the testing is maximum.
- Resilience testing is some what similar to stability testing, fail over testing or recovery testing.
- Resilience testing is aimed at determining the behavior of the software system or application in the case of unreliable events, catastrophic problems and system failures, crashes and data losses.
- Resiliency is one of the core attributes of a good and reliable software system or application.
- Any software or hardware malfunctioning or failures are likely to have a considerable impact on the software system or application.

A software system needs to resilient against the following:
- Changes in requirements and specifications of the system.
- Hardware and software faults.
- Changes in data sources.

Resilience needs to be incorporated in the following stages of software development:
- Software design
- Hardware specification
- Configuration
- Documentation
- Testing

What are the guidelines to be remembered if In House Web Engineering strategy is chosen for web application development?

Due to the increasing complexity, the web application project becomes like a software engineering project management. It is important to recognize that the guidelines recommended for small and moderately sized WebE projects can be performed quickly. In no case, should WebE planning for projects of this size take more than 5 percent of overall project effort :

- One should understand the scope, the dimensions of change, and project constraints. For an effective WebApp planning, requirements gathering and customer communication are essential precursors.
- An incremental project strategy should be developed so that evolution is not uncontrolled and chaotic.
- Risk analysis should be performed. All risk management tasks are performed for web engineering projects but the approach is abbreviated. Schedule and technology risk is the most important concern for most web engineers.
- The overall project estimate should be developed which focuses on macroscopic rather than microscopic issues.
- A set of web engineering tasks is selected which is appropriate for characteristics of problem, product, project, people on web engineering team.
- A schedule is established in which web engineering tasks are distributed along project timeline for increment to be developed.
- Regardless of project size, it is important to establish project milestones so that progress can be assessed.
- A change management is facilitated by incremental development strategy recommended for web applications. There is a possibility to delay change until next increment which in turn reduces the delay effects that are associated with changes.

What is software engineering practice? What are seven principles focussing on software engineering practice?

Practice is an array of concepts, principles, methods and tools that should be considered while software is planned and developed. The software process provides everyone involved in the creation of computer based system with a road map to reach the destination. Practice provides you with the detail that is needed to drive along the road. It helps you to understand the concepts and principles that must be understood and followed to drive safely and rapidly. Practice encompasses the technical activities that produce all work products that are defined by the software process model that has been chosen. Three elements of practice that are chosen are: concepts, principles and methods.

According to David Hooker, there are seven core principles that focus on software engineering practice:
- All the decisions should be made keeping in mind that one reason for the existence of a software system is to provide value to the all of its users.
- To have a more easily understood and maintained system, the design should be as simple as possible as one should keep in mind that software design is not a sloppy process. Keep in mind that simple does not mean 'quick and dirty'.
- For a software project to begin and end successfully, a clear vision is very necessary without which the software system weakens.
- The software system should be specified, designed and implemented in a manner that someone else will have to understand what you are doing.
- Software systems must be ready to adapt the changes in specifications and hardware platforms. One should not design the software system into a corner.
- The hardest goal while developing a software system is the ability to reuse it. Reuse can save time and effort. Forethought and planning is very important to realize reuse at entry level of the system development process.
- A clear, complete thought before action almost always produces better results.

Overview of Regression Testing and its objectives.

Regression testing is an important part of the software development life cycle. regression means going back. If any kind of modification is done in software, testing needs to be done to ensure that it works as specified and that it has not negatively impacted any functionality that it offered previously.
Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged.

The objectives of regression testing are :
- To identify uncovered and unexpected defects.
- To ensure that changes or additions in the code are safe & are not liable to break the existing functionality of the application.
- To ensure and track the quality of its output.
- The changes to the software application have not introduced any new bugs.

Regression testing is necessary when there is a change made to an existing tested software. Each change implies more regression testing needs to be done to ensure that the system meets the project goals.
Regression testing can become cost effective if the test cases are automated the test cases may be executed using scripts after each change is introduced in the system. Also, teams do not execute all the test cases during the regression testing. They test only what they decide is relevant.

In short, regression testing means rerunning tests of things that used to work to make sure that a change didn't break something else. The set of tests used is called the Regression Test Set. It's enormously helpful when you change an application, change the environment, and during integration of pieces.
Regression testing is a simple concept, but it needs to be done just right to work in the real world.

High-level Best Practice Four(4) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second and third area and there practices are already discussed.

Change Propagation

Propagating file changes across branches needs to be managed. The practices involved with this work space are :
- Do not delay to propagate a change. When it’s feasible to propagate a change from one
branch to another (that is, if the change wouldn’t violate the target branch’s
policy), do it sooner rather than later.
- It is much easier to merge a change from a file that is close to the common
ancestor than it is to merge a change from a file that has diverged considerably.
This is because the change in the file that has diverged may be built upon
changes that are not being propagated, and those unwanted changes can
confound the merge process.
- Changes can be propagated by the owner of the target files, the person who make the original changes, or someone else.

Changing requirements and implications on testing

An ideal software development cycle involves a process whereby the requirements are frozen pretty early and the entire cycle happens with those frozen requirements. And if requirements do need to change, then a major impact analysis needs to happen, and the change is thoroughly studied before any change is taken. However, in the real world (and something that is increasingly acknowledged by incremental and Agile software methodologies), requirements can and do change and it is better for the software industry if there is a lot more effort put in to figure out how to incorporate the world of changing requirements. One of the folks impacted by changing requirements are the testing team, and once should evaluate how they can respond to such changing requirements. Let us start off by calling it a common problem and a major headache, and then work out what we can do. Here are some steps:
• Work with the project's stakeholders early on to understand how requirements might change (stakeholders have a much better idea on whether the requirements are fully known and stable) so that alternate test plans and strategies can be worked out in advance, if possible.
• It's helpful if the application is initially designed in a manner that allows for adaptability so that later changes do not require redoing the application from scratch, or at least minimise the amount of effort required for change.
• Coding practices of commenting and documenting, if followed religiously, makes handling changes easier for the developers.
• Another way to minimise the need for changing requirements is to present a prototype to the stakeholders and end users early enough in the cycle. This helps customers feel sure of their requirements and minimize changes.
• The project's initial schedule should allow for some extra time commensurate with the possibility of changes. Better to build such a time in the schedule.
• If possible, and if there is some amount of flexibility in negotiating relations with the client, try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version. This however does not work if the changes affect the workflows directly.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application. This should be possible if there is a good change control process in the project.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. This is typically done by delineating a proper change control process and explaining this to the stakeholders along with examples if necessary. Only after this, let management or the customers decide if the changes are warranted.
• Changes have a major effect on test automation systems, especially if there is a change in the UI of the application. Hence, you need to be sure that the effort put into setting up automated testing is commensurate with the expected effort required if there is change which causes re-doing of the test effort.
• Try to design some flexibility into automated test scripts. Not easy, but if you have initial ideas of change this should be possible.
• Focus initial automated testing on application aspects that are most likely to remain unchanged. This ensures that later test automation effort is done when there is some stability in the requirements.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• The last plan may seem very strange to a test manager. Focus less on detailed test plans and test cases and more on ad hoc testing; keep in mind however that this entails a certain risk.
Overall, when requirements are changing, teams also need to be more flexible to respond to such changes.