Product Quality

Verification is used to illustrate how each phase of the process is, (PRS to SRS, SRS to code) etc. Meets the requirements imposed by the prior phase. As we develop the code, we’ll have to both 1) make sure that it works absolutely correctly, and 2) be able to prove that it does via documentation and audit trail.

We’ll use agile methods to do it in real time, and just-in-time, but we’ll still have to verify the code works as intended and be able to demonstrate traceability from the user stories or epics. Validation is done at the end of the development process and takes place after verifications are completed. It answers the question like: Am I building the right product?

Validation is the final “end run” on quality, where we evaluate the system increment against its product (system) level functional and Non-functional requirements to make sure it does what we intended. We’ll need to include at least the following activities for good validations. Aggregate increments of user stories into a version controlled and definitive statement. Aggregate increments of user stories into an SRS Document traditional document, repository, data base, etc.

Run all system qualities tests for non-functional requirements (reliability, accuracy, security) Run any exploratory, usability, and user acceptance tests. Finalize and update traceability matrices to reflect current state Within an Agile sprint, verification and validation are addressed by adopting Agile practices, such verifying whether INVEST criteria for documenting requirements is followed, creating and reviewing evocative documentation and simple design, reviewing visual modelling, Holding daily stand-up meetings, reviewing radiator boards, following continuous integration, refactoring, running automated development tests and automated acceptance tests, holding focused reviews, and enhancing communication by having the product owner and customer on the team.

Test Driven Development

It is a process that relies on the repetition of a very short development cycle. The developer writes an (initially failing) automated test case that defines a desired improvement or a new function, Then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. In TDD we communicate our intentions twice, stating the same idea in different ways first with a test, then with production code. When they match, it's likely they were both coded correctly. If they don't, there's a mistake somewhere. Test-driven development is related to the test-first programming concepts of extreme programming

Red block

Depicts that write the first and Write only enough code for the current increment of behavior—typically fewer than five lines of code. If it takes more, that's okay, just try for a smaller increment next time. After the test is coded, run your entire suite of tests and watch the new test fail. In most TDD testing tools, this will result in a red progress bar. This is your first opportunity to compare your intent with what's actually happening. If the test doesn't fail, or if it fails in a different way than you expected, something is wrong.

Perhaps your test is broken, or it doesn't test what you thought it did. Troubleshoot the problem; you should always be able to predict what's happening with the code.

Green – In green bar write just enough production code to get the test to pass. Again, you should usually need less than five lines of code. Don't worry about design purity or conceptual elegance just do what you need to do to make the test pass. This is your second opportunity to compare your intent with reality. If the test fails, get back to known-good code as quickly as you can. Often, you or your pairing partner can see the problem by taking a second look at the code you just wrote. If you can't see the problem, consider erasing the new code and trying again. Sometimes it's best to delete the new test (it's only a few lines of code, after all) and start the cycle over with a smaller increment.

Refactor - With all your tests passing again, you can now refactor without worrying about breaking anything. Review the code and look for possible improvements. Ask your navigator if he's made any notes. For each problem you see, refactor the code to fix it. Work in a series of very small

Refactoring — a minute or two each, certainly not longer than five minutes—and run the tests after each one. They should always pass. As before, if the test doesn't pass and the answer isn't immediately obvious, Undo the refactoring and get back to known-good code.

Refactor as many times as you like. Make your design as good as you can, but limit it to the code's existing behaviour. Don't anticipate future needs, and certainly don't add any behaviour. Remember, refactorings aren't supposed to change behaviour. New behaviour requires a failing test.

To summarize Test-driven development (TDD) is a development technique where you must first write a test that fails before you write new functional code. TDD is being quickly adopted by agile software developers for development of application source code and is even being adopted by Agile DBAs for database development. TDD should be seen as complementary to Agile Model Driven Development (AMDD) approaches and the two can and should be used together. TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. Agile acceptance test-driven development. Analogous to test-driven development, this practice consists in the use of automated acceptance tests with the additional constraint that these tests be written in advance of implementing the corresponding functionality. In the ideal situation (though rarely attained in practice), the product owner, customer or domain expert is able to specify new functionality by writing new acceptance tests or test cases, without needing to consult developers.

This practice helps uncover assumptions and confirms that everyone has a shared understanding of “Done”. During implementation, the technical team automates the natural-language Acceptance Tests by writing code to wire them to the emerging software.

Steps followed by an agile team in ATDD Agile

• Discusses requirements of a project

• Develops a common understanding out of the requirements

• Creates a set of acceptance tests

• Involves business stakeholders to clarify points

• Resolves questions and issues

• Implements the requirement

Stages of an ATDD Cycle

Discuss: In this stage of an ATDD cycle, the agile team along with the business stake holders gets into a discussion. The team develops a detailed understanding of the behaviour of the system from the user point of view in the discussion. On the basis of the understanding, the agile team creates acceptance tests that can be executed either automatically or programmatically.

Distill: In this stage of an ATDD cycle, the agile tries to implements the acceptance tests in an automatic testing framework. In this stage the team ensures that the tests are not just remain specifications but can be actually executed in the project.

Develop: During this stage, the agile team follows a Test First Development TFD approach, i.e. they will first execute the tests, make sure what are making them fail and then proceed to write the code that will make the tests pass.

Demo: In this stage of ATDD cycle, the agile team provides a demo to the business stake holders. In the demo, they can also indicate the tests they have run and the vulnerabilities they have been identified through the tests. This is how, an ATDD cycle in agile takes place.

Agile definition of done

A Definition of Done is a clear and concise list of requirements that software must adhere to for the team to call it complete. While the DoD usually applies to all items in the backlog, Acceptance Criteria are applicable to a specific user story. In order to complete the story, both the DoD and acceptance criteria must be met. Until this list is satisfied, a product Increment is not done. During the Sprint Planning meeting, the Scrum Team develops or reconfirms its DoD, Which enables the Development Team to know how much work to select for a given Sprint.

Further, a common DoD helps to:

• Baseline progress on work items

• Enable transparency within the Scrum Team

• Expose work items that need attention

• Determine when an Increment is ready for release

The Definition of Done provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design

It limits the cost of rework once a feature has been accepted as "done“ having an explicit contract limits the risk of misunderstanding and

Conflict between the development team and the customer or the product owner

Continuous Integration

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. By integrating regularly, you can detect errors quickly, and locate them more easily Teams practicing continuous integration seek two objectives. Minimize the duration and effort required by "each" integration episode Be able to deliver "at any moment" a product version suitable for release CI is achieved through version control tools, team policies and conventions, and tools specifically designed to help achieve continuous integration. Idea of continuously integrating is to find issues quickly, thus giving each developer feedback on their work, then there must be some way to evaluate that work quickly.

Test-driven development fills that gap. With TDD, you build the test and then develop functionality until the code passes the test. As each new addition to the code is made, its test can be added to the suite of tests that are run when you build the integrated work. This ensures that new additions don't break the functioning work that came before them, and developers whose code does in fact "break the build" can be notified quickly. One popular CI rule states that programmers never leave anything unintegrated at the end of the day. The build should never spend the night in a broken state. This imposes some task planning discipline on programming teams. Furthermore, if the team's rule is that whoever breaks the build at check-in has to fix it again, There is a natural incentive to check code in frequently during the day.