10 Requirements Traps to Avoid
/in Quality Assurance & Quality Control- the analyst who wrote the requirements
- the customer or marketing representative who supplied them (particularly for use case reviews)
- a developer who must implement them
- a tester who must verify them
- The anticipated frequency or volume of usage
- Satisfying your most favored user classes
- Implementing core business processes
- Functionality demanded regulatory compliance
- Educating developers, managers, and customers about requirements engineering practices and the application domain
- Establishing a collaborative customer-developer partnership for requirements development and management
- Understanding the different kinds of requirements and classifying customer input into the appropriate categories
- Taking an iterative and incremental approach to requirements development
- Using standard templates for your vision and scope, use case, and SRS documents
- Holding formal and informal reviews of requirements documents
- Writing test cases against requirements
- Prioritizing requirements in some analytical fashion
- Instilling the team and customer discipline to handle requirements changes consistently and effectively
These approaches will help your next product’s requirements provide a solid foundation for efficient construction and a successful rollout.
Courtesy – ProcessImpact
Cheers,
Javed Nehal
Top 10 Estimation Best Practices in Agile
/in Quality Assurance & Quality Control1. Use more than one person – By engaging the team in the estimation process we gain the benefits of additional insights and consensus building. Additional people bring different perspectives to estimating and spot things individuals may miss. Also, the involvement in the process generates better consensus and commitment for the estimates being produced.
2. Use more than one approach – Just as one person is likely to miss perspectives of estimating so too are single approaches. Use multiple estimation approaches (comparison to similar projects, bottom up, user story points, etc) and look for convergence between multiple approaches to reinforce likely estimate ranges.
3. Agree on what “It” and “Done” means – make sure everyone is estimating in the same units (e.g. ideal days), have the same assumptions, and are based on standard developer ability/effort. When asking for estimates spell out what you are asking them to estimate. What does “Done” include? Coded, unit tested? How about integrated and system tested? What about refactoring contingencies? User meeting time?
4. Know when to stop – estimating an inherently unpredictable process (custom software development with evolving requirements) will never be an exact science. Balance enough effort against the diminishing returns and false accuracies of over-analysis. Look for broad consensus between team members at a coarse-grained level and then move on. It is better to save estimation time for periodic updates than over analyze.
5. Present estimates as a range – We call them “estimates” not “predictions” because they have a measure of uncertainty associated with them. Manage the expectation of project stakeholders and present them as a range of values. E.G. Between $90,000 and $120,000
6. Defend/explain estimate range probabilities – If stakeholders automatically latch onto the low end of an estimated range explain the low probability of achieving this and steer them to a more likely value. If your organization persistently fails to understand, present a range of likely values (e.g. around the 50% to 97% probability range)
7. Don’t reserve estimating for when you know least about the project – Estimation should not be reserved for the beginning of projects. Instead done throughout as we learn more about the emerging true requirements and the ability of the team to build and evaluate software.
8. Be aware of common estimation omissions – Consult lists of common estimating omissions (such as Capers Jones’) and ensure these items are taken into account. Look back at retrospective notes for things that did not go so well, and tasks that were missed or ran late – make sure we include enough time for these.
9. Embrace reality early – As the project progresses, it is tempting to think development will get faster and faster now all the technical problems have been overcome. However, don’t underestimate the load of maintaining and refactoring a growing code based. Especially if the system is now live; support, maintenance, test harness updates, and refactoring can quickly erode the velocity improvements anticipated, so use the real velocity numbers.
10. Review, Revisit, Remove head from the sand, Repeat – Our first estimates will likely be our worst. Don’t leave it there; review the project velocities to see how fast we are really going. Revisit the estimates armed with the real velocities to determine likely end dates. Embrace the reality you see, “The map is not the territory”, reprioritize and repeat the estimation process often to adapt and iterate to the most accurate estimates.
Cheers,
Javed Nehal
Restrict Removable Storage Devices Using Group Policy in Windows Server 2008
/in Quality Assurance & Quality ControlIn Windows Server 2008 domain, there are a set of built-in policies on removable storage access and installation. It makes restricting USB mass storage device easier.
Open the Group Policy Manager in your windows server 2008 and Do the following Steps,
SCRUM
/in Quality Assurance & Quality ControlWhy does Scrum Work?
1. The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work.
2. This reduces the need for meetings, reporting, and authorization.
3. There is control, but it is subtle and mostly indirect.
4. It is exercised by selecting the right people, creating an open work environment, encouraging feedback, establishing an evaluation and reward program based on group performance, managing the tendency to go off in different directions early on, and tolerating mistakes.
5. Every person on the team starts with an understanding of the problem, associates it with a range of solutions experienced and studied, then using skill, intelligence, and experience will narrow the range to one or a few options.
6. Keep in mind that it can be difficult to give up the control that it takes to support the Scrum methodology.
7. The approach is risky, there is no guarantee that the team will not run up against real limits, which could kill the project.
8. The disappointment of the failure could adversely affect the team members because of the high levels of personal commitment involved.
9. Each person on the team is required to understand all of the problem and all of the steps in developing a system to solve it, this may limit the size of the system developed using the methodology.
How does Scrum work?
• The first thing that happens is the initial leader will become primarily a reporter.
• The leadership role will bounce around within the team based on the task at hand.
• Soon QA developers will be learning how requirements are done and will be actively contributing, and requirements people will be seeing things from a QA point of view.
• As work is done in each of the phases, all the team learns and contributes, no work is done alone, the team is behind everything.
• From the initial meeting, the finished product is being developed.
• Someone can be writing code, working on functional specifications, and designing during the same day, i.e. “all-at-once”.
• Don’t be surprised if the team cleans the slate numerous times, many new ways will be picked up and many old ways discarded.
• The team will become autonomous, and will tend to transcend the initial goals, striving for excellence.
• The people on the team will become committed to accomplish the goal and some members may experience emotional pain when the project is completed.
Attributes:
• Scrum is an agile process to manage and control development work.
• Scrum is a wrapper for existing engineering practices.
• A scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
• Scrum is a process that controls the chaos of conflicting interests and needs.
• Scrum is a way to improve communications and maximize co-operation.
• Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
• Scrum is a way to maximize productivity.
• Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
• Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.
Scrum
Scrum naturally focuses an entire organization on building successful products. Without major changes -often within thirty days – teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble.
Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototypes. Based on modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.
Smoke Testing Vs Sanity Testing
/in Quality Assurance & Quality ControlSmoke Test:
When a build is received, a smoke test is run to ascertain if the build is stable and it can be considered for further testing.
Smoke testing can be done for testing the stability of any interim build.
Smoke testing can be executed for platform qualification tests.
Sanity testing:
Once a new build is obtained with minor revisions, instead of doing a thorough regression, a sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes. Its generally a subset of regression testing and a group of test cases are executed that are related with the changes made to the app.
Generally, when multiple cycles of testing are executed, sanity testing may be done during the later cycles after through regression cycles.
| Smoke | Sanity |
| Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In the software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. | A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. |
2 | A Smoke test is designed to touch every part of the application in a cursory way. It’s is shallow and wide. | A Sanity test is used to determine a small section of the application is still working after a minor change. |
3 | Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification). | Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. |
4 | Smoke testing is normal health check up to a build of an application before taking it to test in depth.
| sanity testing is to verify whether requirements are met or not, checking all features breadth-first.
|
Cheers,
Javed Nehal
Enabling Email Functionality in the Team System Web Access (TSWA)
/in Quality Assurance & Quality ControlBy default, the email functionality in Team System Web Access (TSWA) is disabled and users will receive the following message when trying to use it:
“Sending email is not enabled. Please contact your administrator.”
To enable you to need to change TSWA’s web.config file, which can be found following path: \Program Files\Microsoft Visual Studio 2005/2008 Team System Web Access\Web.
- Change the setting “sendingEmailEnabled” to true.
- And specify your SMTP server name under “host”.
<emailSettingssendingEmailEnabled=”true”enableSsl=”false” />
Optionally you can specify which account to use when authenticating with the SMTP server and if SSL should be enabled as well as the default email address for the sender.
Where can you use the email functionality?
- single work items (from the work item form)
- multiple work items, i.e. the result of a work item query
The email function can be found in the “Tools” menu.
The “Send Email” window allows you to specify the sender’s (“From”) and receiver’s (“To”) email address, as well as subject and message.
After hitting send a message box confirms that the mail was successfully routed to the email server.

You can configure Team Foundation Server to use an existing SMTP server to send e-mail alerts. Users can configure alerts for various projects, work item, and build event notifications. Although you can specify the SMTP server during Team Foundation Server installation, you might want to change the STMP server later. Similarly, if you to change the application pool service account by using the TFSAdminUtil ChangeAccount command, you must manually change the sender account e-mail address to the new service account’s e-mail address.
Note
The content of Team Foundation Server alert e-mails is not customizable. The content of the e-mails is automatically generated from the TeamFoundation.xsl file. Modifying this file is not recommended. If you do modify the contents of this file, be sure to thoroughly test your modifications. Incorrect modifications of this file can result in the failure of Team Foundation Server e-mail alerts and the inability to view Team Foundation work items, changesets, or files in a Web browser.
To perform this procedure, you must be a member of the Administrators group on the Team Foundation application-tier server. For more information, see Team Foundation Server Permissions.
Don’t use the ASP.Net tab of the IIS Manager (inetmgr) to edit a configuration file. If you use this tab, an attribute is added to the configuration element of the configuration file. This attribute interferes with normal functioning
- On the application-tier server for Team Foundation, locate the installation directory for the application tier.
- Open the Web Services directory, and then open the Services subdirectory.
- In a text or XML editor, open the Web.Config file, and locate the element.
- Update the element by typing the fully qualified domain name of the SMTP server. For example, type the following string:
- Save and close the Web.Config file.
To designate or change the sender e-mail address for e-mail alerts
- On the application-tier server for Team Foundation, locate the installation directory for the application tier.
- Open the Web Services directory, and then open the Services subdirectory.
- In a text or XML editor, open the Web.Config file, and locate the element.
- Update the element by typing the e-mail address that is associated with the service account (for example,Domain/TFSService). That is used for the application pool identity for Team Foundation. For example, type the following string:
- Save and close the file.
You must close and restart the Web services application for Team Foundation before your changes will take effect.
ABOUT IOTAP
IOTAP is a Microsoft Dynamics partner that provides billing automation and subscription management solutions + More
OUR SERVICES
Contact
11710 Plaza America Dr. Suite 2000, Reston, VA 20190, USA
- Tel : +1-703-884-3363
- Email : [email protected]