In Agile work, it is common to work in short sprints or iterations, which consist of tasks where the system is designed, coded and tested. The team might carry out ten releases per year, compared with the 2-4 which is common when working traditionally. As each sprint is focused on only a few requirements, it is natural that the documentation may not be as extensive.
 
In traditional work, documentation has to be more expansive, especially when developing larger portions of the system. In agile projects the test plan often consists of only a single page or two.

Since the test plan is a short paper, it is highly advisable to supplement it with a testing strategy. The test strategy describes how the system is usually tested. Think of the test plan for a moment. A test plan contains many headlines and much of the content is the same from release to release. Typical examples include a description of the test environment, what should be prioritized in the tests, what roles are needed and a comprehensive description of the system.

All of this can be described in the test strategy instead. This way you will get a good connection between a test plan that describes what should be tested at this time and a test strategy that describes what is always important but is not specific to this sprint. The test strategy is a living document and evolves over time and is relevant even when personnel come and go from time to time.
 
It is important to strive to not over-document. Always document what is needed but document just what is needed for the work to be done.

These are some commonly used documents in agile testing:

• A test strategy that describes how the system is usually tested.
• A test plan for each sprint.
• Test specifications which contain test cases.
• Test Ideas for exploratory testing and test logs in which the outcome is noted.
• Checklists for installation testing and regression testing.

Test cases are often replaced by checklists and exploratory testing.

In traditional work, there are often lots of test cases. They also occur in Agile work, sometimes largely, and sometimes to a lesser extent. The disadvantage of the traditional test case in an Agile project is that it takes quite a lot of time to plan and write them. In many cases, checklists or “test ideas” work better.

Make a checklist per area to be tested and in each case describe in 1-2 lines what should be tested. In the end, your checklist will look like a bunch of one liners. It is also wise to create a supplementary checklist with general tests. There are several examples of such checklists in our blog. If the need arises in the future, checklists can be converted to traditional test cases.

The agile manifesto contains a number of values or principles that are regarded as key success factors for agile work. One of these is “working software over comprehensive documentation”. Of course, this does not mean that all documentation is unnecessary.
 

Documentation is a tool to achieve the goal, and the goal is working software.

In traditional development, you can sometimes feel that the documentation is a goal in itself and the documentation becomes a product that is not used.

In agile, work is different. Inevitably there is documentation needed for system maintenance and management. It may include the user documentation and system documentation, but the question you need to ask yourself is ‘what is needed during the current work?’ Document only what is needed, but certainly what is needed.

Unfortunately, development teams often become aware of this problem late in the process. Correcting this issue often means costly rework and client dissatisfaction. In this post you will learn how to use a workshop to perform a stakeholder analysis and create your own list of stakeholders within a project.

A good place to start is by creating a typical list of stakeholders. This will vary according to the industry or scope of the project, but a typical stakeholder list would include:

• Customers
• Customers’ customers
• Users
• Developers
• Marketers
• Product Managers
• Testers
• Authorities/regulators
• Laws/company lawyers

 
This list can help you to identify stakeholders, but because as said earlier, stakeholders are different for every system, you will need to conduct a stakeholder analysis. We like to carry this out in the form of a facilitated workshop.

Your participants in the workshop might include people who were involved in a feasibility study, or representatives from both the client and the system provider.

One way of starting the exercise is to simply write the name of the project or system in a circle in the middle of a whiteboard.
 
Let the participants brainstorm all the possible stakeholders. They should write the name, role, or organization of each stakeholder on a post-it-note and place it on the whiteboard around the circle.

Next, draw an arrow between each stakeholder and the project.

Divide the participants into groups and distribute the stakeholders between the groups.

Give the groups around 30 minutes to discuss what each stakeholder gets or requires from the project, and what the project needs from or gets from the stakeholder.
 
After 30 minutes the groups should present their findings. Write down what the stakeholder requires or receives from the project on one end of the arrow, closest to the stakeholder, and what the project requires or receives from the stakeholder at the other end, near the project.

After all the groups have presented their findings and your workshop is complete, you will have produced the material for a table similar to the one below.
 

 
This method is not perfect and may require practical tweaking in situations with a large number of participants. However, it does provide a solid base from which to start.
 
Keep in mind that certain requirements are to be discussed in more detail than described above, and with people who are specialized in that field. For example, any design work requirements should be relatively simple, especially if a senior designer attends the stakeholder meeting above, but other requirements, such as the law, are far more complex. Do set aside plenty of time to discuss in more detail where required.

What is “Cloud Computing”?

To understand how the cloud will transform our working lives, you need to understand what said “Cloud” is. Unfortunately, there’s no simple answer, because the concept encompasses many others, such as:

• Software as a Service, or SaaS
• Platform as a Service, or PaaS (a development platform as a service for development of cloud services)
• Infrastructure as a Service, or IaaS

 
The term “cloud” covers all the areas above, and even more that are used more rarely, at least presently
 

Development environments for cloud services

The past few years have seen the introduction of cloud-based development tools for the development of new cloud services, an example of which is Salesforce’s Force.com, in which one can build cloud services which run within their operating environment. There are countless other cloud-based development tools, including Windows Azure, Google App Engine and Amazon Web Services, and which are all examples of PaaS.

Developers who use PaaS tools don’t have to worry about the production environment’s hardware, networks or operating systems, so they can develop new features and apps in a lot less time. That also means that requirements gathering and testing teams can see prototypes much faster. Developers don’t need worry about scalability, since PaaS takes care of that, too. Whenever your app needs more processing power, the PaaS provider’s data center can provide it instantaneously.

This is not to say that PaaS is not without its downsides. Foremost is that you don’t have complete control over your information, since the company providing the platform has both the data and the service in its ‘possession’. The data may not be stored in the country where the customer has its operations, which may be a legal problem or create security issues (real or perceived). Shorter development times can give the customer the expectation that requirements and testing work will be sped up in a similar way, which is not necessarily the case as the total lead time might end up being the same, due to increased time for requirements and testing work.
 

Requirements management for cloud services

A customer who wants a new cloud service has three main approaches to choose from:

• Subscribing to an existing SaaS service in the cloud.
• Developing the cloud service in-house using a PaaS development environment.
• Outsourcing development of the cloud service using a PaaS development environment.

Requirements work will be much the same with a SaaS subscription as it would be by purchasing a COTS (commercial off the shelf) system.

However, there are some clear differences. Just like when buying a COTS system, you need requirements that define the functions the system needs to have. The difference is that you don’t need to specify requirements for the environment, version control, or other similar features since the service won’t be running in your environment.

Although you’re a client, you have very little or no say in when a new version of the service gets installed, and the company providing the service will do what their own needs dictate, whether it suits you or not. Likewise, you have little or no control over where they host the service. If your business needs to have control over the physical location of your data or software, you should stipulate that in the requirements and base your choice of provider on it.

For services that you develop through PaaS, it’s slightly easier to define the requirements for where information is stored and maintained, since some PaaS providers let you choose whether to use your company’s own “cloud” or the global “cloud”.

When you develop services with PaaS, you have to write more detailed requirements about what needs to be developed than you would when using a subscription service. Since development proceeds faster in PaaS than in a traditional environment, you can take advantage of prototyping to a much greater degree. Prototypes are always good for gathering requirements, but in PaaS, they become one of your most important tools – both to gather requirements and to have the opportunity to test at an earlier stage.

If you’re buying cloud services, you need to give special consideration to which PaaS you want the developers to use. If you don’t make an explicit choice, you may end up with custom-made services that all reside in the various providers’ own clouds, so you have to specify in which “clouds” your services are allowed to live if you want them all in one place. This is usually a minor problem if you do your development in-house, assuming your company has settled on a standard PaaS option. When you choose a PaaS provider, you should also specify uptime/availability requirements, performance, and security – all of which are known for any given PaaS provider, and which should guide your supplier selection.

With an external provider, you also have to specify what will happen to your cloud data and service in the event that your PaaS provider is acquired or goes bankrupt. Look for a supplier with an escrow plan that ensures they can continue operations for a given time period after bankruptcy. ‘Escrow’ is storing your source code with a legal representative or equivalent entity. If the supplier has an escrow agreement, customers retain access to their source code and can continue development on their own if the supplier goes bankrupt.

You should also ensure that you own your information, not the supplier or its creditors. Every major PaaS provider has an insurance policy in its contracts, but if you choose another supplier, you should take extra care to ensure that your assets are protected. Review the contract and ask tough questions!
 

Testing in cloud-based development

Just as in requirements management, the most obvious differences in cloud-based testing depend on whether you are testing existing services or custom-developed ones.

When testing custom-developed cloud services, you have all the opportunity in the world to test the service thoroughly. You can test prototypes to verify general solutions and specific functionality. Since development times are much shorter in cloud-based development, you may need to adjust your test plan.

To ensure you set aside enough time for testing, you should begin testing work as early as possible, and an easy way to get started is by testing using the prototypes generated in requirements gathering. One way of doing so is by putting users in front of the prototypes to ensure that they understand how they’re expected to perform a required task.

Agile methodologies will make your work easier throughout development, and in testing, Exploratory Testing techniques come in handy. Exploratory Testing helps you learn while you test, and is a natural consequence of using prototypes for testing your new service. Another alternative is to write your cloud-based services using test-driven development.

If you’re subscribing to a finished SaaS application, a trial subscription is the only way you can conduct a “proof of concept” test, which can be thought of as an acceptance test. The point of the trial is to ensure that cloud service meets your company’s operational needs.

If your prospective provider won’t allow you to trial the service free of charge, it will be impossible for you to know what you’re buying – which itself constitutes a form of acceptance test that the stubborn supplier has failed. If they won’t let you thoroughly test the service in advance, the supplier probably won’t be responsive to your customer needs in the future, either.
 

Next steps

Start thinking about how the “cloud” affects requirements and testing work for your organization.

1. Eliminate waste
2. Deliver fast
3. Defer commitment

 
Let’s see these three principles in a bit more detail:
 


1: Eliminate waste

 
The worst form of waste in system development is almost certainly redundant, unnecessary features. Let me give you a personal example. I was once involved in implementing an order management system for a client in Sweden. The standard software contained a telesales module with a “call list” function that was originally built for a U.S. customer. The Swedish client had never worked with call lists, so we spent a huge amount of project time getting a grasp on how the function worked and determining requirements for our client-specific implementation. After several rounds of revising requirements, implementing, reviewing, and fixing, we finally completed the module.
 
Much to our disbelief, however, the client’s processes had no pressing need for call lists, and had no intention to start using them soon anyway, so we never deployed the call list module in production. Our next project? Yanking out everything deemed unnecessary in the system, including the call lists.
 
In this case, the call list function was a clear example of “waste”. It provided zero value to the client, but caused significant costs in terms of training, requirements definition, testing and correction — time that should have been spent on something the client actually wanted instead.
 
If you agree that the two main objectives of testing are to 1) verify and find errors and 2) validate that the client benefits from the system, you can draw the following conclusion regarding Lean: Validation is far more important than verification.Obviously, you do still have to verify the software and find defects, but if the function you’re testing doesn’t provide direct value to the client, all the time you put into it is just waste. So your top priority in requirements and testing work has to be customer value!
 


2: Deliver fast

 
The agile revolution has its roots in the Lean principle of “Deliver fast”. Thanks to methods like Scrum and XP, short iterations are common in software development today. This is not just about fancy words, it’s also a fundamental shift in mindset. Agile system development methods appeal primarily to developers, even if they do focus on clients and customers. You could actually forget clients and only think about developers when you think about Scrum, but Lean describes the same basic principles in a language that inherently includes clients and customers.
 
Development iterations according to Lean concepts immediately demonstrate that it is less development-focused and more customer-focused than Agile alone. As an example, in Lean you use the concept of “feedback” rather than “testing”. Testing is merely a development activity aimed at getting feedback. More importantly, you use the term “improvement” instead of “correction”. If you work sequentially, under the assumption you got everything right from the beginning in the requirements, your testing will just be an error-finding-and–fixing exercise. However, if you work iteratively, your main goal will be to deliver added value to the customer via the lessons and insights gained through feedback.
 


3: Defer Commitment

 
According to the Lean principle of “Defer commitment,” you make decisions that affect commitments as late as possible, which is why the approach is also called “Just In Time Commitment”. By delaying the “freezing” of requirements until you have tested and evaluated different options, you can make better decisions, decisions that are based on the facts and experience you gather, rather than on your imagination. Lean Thinking represents a paradigm shift in requirements work:
 
You might have been taught that the later you implement a change, the greater the impact and expense. However, without feedback, your requirements work will be based not on facts but on speculation, which (unsurprisingly) often turns out to be wrong in the long run. In other words, early (wrong) decisions based on speculation are much more expensive than the late (good) decisions based on feedback. This is why it’s better to postpone certain decisions, even if it may involve some cost to introduce a change later. What you gain in increased customer value when you make the right, fact-based decision about requirements usually outweighs the cost of making that change later in the process.
 
In 1987, Barry Boehm stated that it costs 100 times more to make a change in production than to make the same change during the early requirements and design stage. Boehm himself noted in 2001 that his conclusion depended in part on of the fact that we usually work sequentially, based on locking in early-stage decisions. Boehm now believes that working according to Lean principles reduces the cost of changes in production to as little as five times the cost of the same change in requirements and design.
 
How do I get to this stage? There are a number of approaches.
 
Prototypes help you quickly produce tangible and visual solutions that work well as a basis for dialogue with clients and fellow team members. If you use prototypes along with proper guidance, the ensuing dialogue will provide you with valuable feedback, which in turn will help you discover the best solution. Usage tests, also known as “usability tests”, are intended to give you end-users’ validation as early as possible, and almost always provide early, low-cost feedback the same way prototypes do (and combining usage testing with prototypes will give you even better input).
 
So test early and often!  

How can I create a sustainable architecture for automation which works well in agile development?

 
Most people who work with Agile know that automating system testing is essential, but they also realize that it is very easy to fail in doing so. What makes test automation so hard within the agile context is that the test object is constantly changing since it is gradually refined over sprints. If there is anything a test automation engineer is afraid of, it’s constant changes and the resulting high level of maintenance.
 
Despite these difficulties, the hard truth is that without automated testing, it is not possible to work Agile in full, at least not with frequent high quality deployments.
 
The reason it’s so important to automate tests is that the number of test cases at the system testing level will continue to grow on par with the new functionality added in each sprint. This increases the total amount of functionality and code to be tested in every sprint, as new code will be added while the old will still need to be regression tested. This is different from component testing, which focuses almost exclusively on the functionality of the current sprint.

Simply put, automated tests are the only way to achieve a sufficiently high test coverage in each sprint and thus provide the high quality and rapid feedback that we seek when we are working Agile.
 
An agile project without test automation is essentially just a waterfall project in phases. It is simply impossible to satisfactorily regression test in every sprint if the tests are performed manually.
 
The result is often a postponement of regression tests and deployment to a regression test period made after every three to six sprints. This causes important feedback and bug reports to reach the team very late, even up to six months after the functionality was developed and that is exactly the same way as in a phased waterfall project!
 

What should be automated first?

 
When a test automation strategy is developed, it is easy to think that you should automate all regression tests, and that it should be done immediately. Of course this is not economically justifiable; it is not advisable to automate everything right away because manual testing will continue to play a major role.
 
It is important to determine both what is worthwhile to automate and what should be automated first to get as large gains possible by automation.
 
There are many factors which determine what should be automated first. Some of the candidates which typically fall in line first for automation include:
 
• Business-critical functionality
• Functions that are used frequently by many users
• Configuration testing where tests will be run with different configurations
• Test cases which will be run several times with different test data or conditions
• Test cases where it is easy to see the expected result.
 

Is it profitable to automate?

 
Convincing management to add resources and make an investment in test automation will require making an informed ROI calculation showing whether and when the investment can be financially profitable. In order to complete the calculation, we need to know the cost of automation.
 
A good default value is that it takes 4-8 times as long to automate a test case compared to the time required for manual testing. Therefore, the automated test case needs to be executed for 4-8 iterations for the investment to break even. Tests that need to be run just a few times or very seldom are not profitable to automate.
 
Even tests that are difficult to automate should be omitted. In addition to the cost of writing and maintaining automated test cases there are also several “hidden” costs such as licenses, infrastructure, support and training.
 

What do I gain from test automation?

 
The benefits of automation are various. The time saved when executing tests automatically instead of manually is an obvious advantage. Another advantage is that test automation can lead to more exhaustive testing because with automation, nothing stops you from executing the same test several times with more varied test data and perhaps even test different environments.
 
However, the main benefit of test automation is that confidence in the system and its quality is increased when more comprehensive tests are performed. This trust makes it possible to improve and customize the system to the needs as required in an Agile project.
 
Additionally, resources become available for other tasks. Instead of retesting existing functionality, testers can put their energy into testing areas of new functionality where a human feeling is really needed. Developers also become more confident with the help of automation. There will be fewer errors left as developers quickly see the consequences of a code change, thus saving the team’s (and your organization’s) time and money!

Authentication – Understand how the authentication process works and attempt to use that information to circumvent the authentication mechanism.

Authorization – Determine that a requester is allowed to receive a service or perform an operation.

Confidentiality – Protects the disclosure of data or information to parties other than the intended.

Integrity – Whether the intended receiver receives the information or data without it being in any way altered in transmission.

Non-repudiation – Interchange of authentication information with some form of provable time stamp e.g. with a session id.
 
It is only by identifying risks in the system and creating tests driven by those risks that your software security testing can be properly focused on areas of code in which an attack is more likely to succeed. Essentially, this approach provides a higher level of software security assurance than possible with classical black-box testing.
 
Of course there is no such thing as a silver bullet for software security and even a reasonably ironclad security testing regimen is just a start.
 
Regrettably, security continues to be sold as a product but many of the defensive mechanisms on the market do very little to address the core of the issue, which is bad software. Instead, these ‘solutions’ operate in a reactive mode: by not allowing allow packets to this or that port, watching for files which include this pattern in them, and discarding partial packets and oversized packets away without looking at them. Network traffic is not always the best way to approach this issue, because the software that processes the packets is the problem.
 
By adopting a comprehensive and risk-based approach to software security testing, testing professionals can help in solving security problems while software is still in production avoiding costly and embarrassing mishaps later on in the software’s lifecycle.

Testing is often performed distributed

Today, testing can take place anywhere, from different parts of the country or just across the street. The customer may exist in one place and the supplier elsewhere, perhaps even in another country. Even acceptance tests might be performed by testers who are in different locations. Convenient as it is, this reality is not without its problems.

Some of the problems of distributed projects may include:

• Communication
• Roles
• Risk of duplication
• Difficulty in creating team spirit
• Agreeing on team resources
• Communications

When testing is spread out in location, communication becomes difficult. It is important that communication is clear, honest, consistent and that everyone gets the same picture.

Using different tools does make the communication better. Tools can include Skype or MSN for general communication or a tool like ReQtest which facilitates online collaboration specifically for the areas of requirements management and testing.

Roles

In distributed teams, more people want to make decisions. It is very important to define what roles should exist in which locations. This increases the clarity and scope of the team overall, as it gives team members a sense of structure, regardless where they are located.

Typical roles that will need to be defined are the test manager, testers, test environment manager and test data manager, although of course these differ according to the size and scope of the project.

Duplication of roles

If the same task is to be performed in more than one location, there is a risk of duplication, which could delay the project.

Give one person in each location the role of test manager and ensure that they understand the risk of duplication and are prepared and able to avoid this pitfall. Provide clear responsibilities and think about the importance of good communication.

Team spirit

To create a stronger team spirit, it is important to get to know your team members, whether they’re in the same place or located elsewhere. Camaraderie doesn’t just happen, it needs to be fostered and grown with trust and by time.

It is important to get the team to work in the same direction. Trust is based on the participants having a common understanding of each other as well as the big picture of the project.

Write a contract about team resources

If testers are borrowed from other activities, there will be a risk that they have conflicting priorities, maybe even inherited from their leaders or their usual activities.

An example of this is acceptance testers who in actual fact really belong to the line operations team. If they still need to perform their regular duties while they do tests, the tests are likely to suffer.

One practical idea is to sign a formal contract with the managers who lend resources to your team. In the contract you should describe the extent to which the person is needed for the tests. This will help set both the managers’ and the team members’ mind at rest, knowing that both you and their own manager have signed off approval on the ‘extra’ work they will be doing.

Summary

Having a geographically distributed team involves a number of challenges to be addressed for the work to function as effectively as possible. Some of the problems include communication, clarity of roles, duplication of roles, camaraderie and disagreements when it comes to team resources.

To a certain extent, the same differences exist when it comes to the subject of automated testing. In the agile way of doing this, the goal is that what the team agrees to do in a sprint is delivered with high quality when the sprint is completed. This means that the sprint contains activities for requirements design, development and testing. Everything should be completed before the team starts the next sprint.

Sprints are usually about a month long, but can also be shorter. The next sprint builds on what has been done before and therefore the amount of regression testing quickly becomes very extensive.

The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.

The word regression means that the system can regress, meaning that it could be worse than it was before the change. Sometimes we therefore refer to this phenomenon as “improvement deterioration” or “worsification” or even “unprovement”, since while trying to improve the system we unintentionally made it worse than before.

To be able to regression test all existing functionality, tests are often automated by the developers. Writing automated test cases is not technically complicated. What is complicated is the master test design, which testers have profound knowledge about. You therefore have an important role to play when transferring testing knowledge to developers. As a tester, you also need to understand more of the technology used to be able to help with automation.

In return, when you work as a tester in an agile project you often get help by the developers. The developers write the automated tests, generating testing data, setting up test environments and anything else that makes the team deliver on time. Suddenly you as a tester are an important and natural part of the team because you have knowledge and experience to perform these tasks. When the developers and you share the same definition of ‘done’ no one will think that everything is done just because the coding is finished. Furthermore, you will probably even get a better understanding of the problems that developers face daily.

If you have test automation in place, you as a tester will be able to focus on the manual tests that are needed for the newly developed functionality through exploratory testing, all while learning more about different areas you wouldn’t know of in the traditional approach, and being part of a cohesive and efficient team.

Method

A Decision Table is usually divided into four quadrants as in the table below.

The upper half of the table lists the conditions being tested while the lower half lists the possible actions to be taken.

Each column represents a certain type of condition or rule.

A few guidelines for constructing a decision table:

To construct a Decision Table follow these steps:

1) Draw boxes for the top and bottom left quadrants.

2) List the conditions in the top left quadrant.

When possible, phrase the conditions as questions that can be answered with a Y for yes and an N for a no.

This type of Decision Table is known as a limited entry table. When a Decision Table requires more than two values for a condition, it is known as an extended entry table.

3) List the possible actions in the bottom left quadrant.

4) Count the possible values for each condition and multiply these together to determine how many unique combinations of conditions are present.

Draw one column in the top and bottom right quadrants for each combination. For example, if there are two conditions and the first condition has two possible values while the second has three possible values, draw six (2 * 3) columns.

5) Enter all possible combinations of values in the columns in the top right quadrant of the table.

6) For each column, that is, each unique combination of conditions, mark an X in the bottom right quadrant in the appropriate action row. The X marks the intersection between the required action and each unique combination of condition values.

How to ensure that the Table is Complete

To complete Step 5 above, ensuring that no combinations are missed, follow these steps:

1) Start with the last condition and alternate its possible values across the row. Note how often the pattern repeats itself. For a condition with two possible values, the pattern will repeat itself every two columns. If three values are possible, the pattern repeats itself every three columns.

For example, for a table with three conditions each with values Y or N, there are eight (2 * 2 * 2) columns. Complete the third (last) row by entering Y once across the row followed by one N. The pattern repeats itself every two columns. The third row would look like: Y N Y N Y N Y N

2) Move to the condition in the row above the last condition. Cover each pattern group with a value for this condition. Note how often the new pattern repeats itself.

For example, complete the second row by entering Y across the row two times followed by two entries of N. This pattern repeats itself every four columns. The second row would look like: Y Y N N Y Y N N

3) Repeat step 2 until all rows are complete. To complete the first row, enter Y across the row four times followed by four entries of N. The first row would look like: Y Y Y Y N N N N

How to Flag Error Conditions

If a specific combination of conditions is invalid, then define one action to flag the error or invalid condition.

How to Simplify the Decision Table

If two or more combinations result in the same action, then the table can be simplified. Consider the following example:

Condition 1 Y Y
Condition 2 Y Y
Condition 3 Y N
Action 1 X X

The same action occurs whether condition 3 is true or false. As a result, one column can be eliminated from the table as follows:

Condition 1 Y
Condition 2 Y
Condition 3 −
Action 1 X

A Practical Example of a Decision Table

Company X sells merchandise to wholesale and retail outlets. Wholesale customers receive a two percent discount on all orders. The company also encourages both wholesale and retail customers to pay cash on delivery by offering a two percent discount for this method of payment. Another two percent discount is given on orders of 50 or more units. Each column represents a certain type of order.

The Decision Table records the conditions for discounts in the top left quadrant along with the ranges for the conditions in the top right quadrant. The bottom half of the table lists the actions taken, i.e., the discount rates that apply, based on the conditions. Each column represents a certain type of order. For example, column two represents cash on delivery orders of less than 50 units from retailers.

References:

Curtis, Graham Business Information Systems: Analysis, Design and Practice. Wokingham: Addison-Wesley.

Martin, James, and McClure, Carma Diagramming Techniques for Analysts and Programmers. Englewood Cliffs: Prentice Hall.

Just because you’re used to working in a more traditional approach and Agile projects operate differently does not mean you’re irrelevant. This is especially so when we consider requirements management in Agile projects.
 
 
When working traditionally it is common that many of the requirements are written at the beginning of the project. All too often, this approach works badly because you can not think of everything at once. As the product evolves, you learn more about what is needed and new requirements arise, while other requirements will disappear.

In agile work, requirements are developed throughout the project. Often a product roadmap that describes what is to be done during the year at a very general level is used.

A few weeks before a new sprint is started, the product owner selects the requirements to be implemented in the sprint and these requirements get documented in enough detail so that it becomes possible to implement them.

This approach is called ‘just in time commitment’ and essentially means that documentation should not be developed until it is really needed. The requirements are growing, hence the course of development.
 
 
It is important that testers are involved in gathering and documenting of requirements. Testers often add a lot of value in these discussions and the result is that the requirements will be of better quality. Requirements elicitation can be made using discussions and workshops with customers.

Testers should also be involved in reviewing the requirements as part of test planning. Doing so provides an excellent opportunity to ensure that requirements are testable early on.

Since testers are involved in much more than just testing, they will easily be able to participate in design discussions and through their input the product will contain less errors. Additionally, the testers themselves get a much greater understanding of customer needs which will be useful in future projects.
 
 
A popular way to document requirements is through user stories. User stories are short, so there will be much less documentation than usual. When there is little documentation, it is harder to determine by testing what is right or wrong behavior. The documentation must be replaced by more communication within the team and with the customer. This will become possible because the whole team is not segregated and is working together, bringing about more opportunity to learn and use your own specialized knowledge for the greater good of the team and the work you’re doing.