css: minor

1 files changed, 754 insertions, 0 deletions

diff --git a/src/notes/ase.md b/src/notes/ase.md
new file mode 100644
index 0000000..5618803
--- /dev/null
+++ b/src/notes/ase.md
@@ -0,0 +1,754 @@
+# Q1. Software Process Model - Waterfall
+## What is software engineering a response to? 
+- Increasing system complexity.
+- Failure to use software engineering methods.
+
+There are no universal notations, methods or techniques for software engineering.
+This is because different types of software require different approaches.
+
+There are cases where software projects or software can fail.
+
+### Increasing system complexity
+As new software technology helps us to build bigger, more complicated systems, the requirements change.
+
+Systems need to be developed and delivered faster meaning more complicated systems are required.
+This means more requirements for the systems.
+
+### Failure to use software engineering methods
+It is easy to develop programs without using software engineering techniques... BUT
+This can result in more expensive software development and less reliable, readable systems.
+To solve this issue, more education and training is required on these techniques.
+
+## Software engineering process activities
+### Software specification
+This is where the clients and the developers define the software that should be produced.
+This is where the software is limited in terms of what is should be.
+
+### Software development
+This is where the software is designed and programmed.
+
+### Software validation
+This step ensures that the software does what the client requested.
+
+### Software evolution
+When software is modified to meet client's or the market's new requirements.
+
+## What is a software process model
+A software process model is a set or related activities that leads to a software product.
+An abstract descriptions of high level software processes.
+These can be used to explain different approaches to software development.
+These can be interpreted as frameworks that can be expanded and personalized to create more specific software engineering processes.
+
+### Waterfall model
+The model takes the fundamental software process activities.
+Seperate process phases:
+- Requirement specification
+- Software design
+- Implementation
+- Test
+
+### Incremental/iterative development
+This approach combines the activities with specification, development and validation.
+The system is developed in a series of versions (increments)
+Each version adds some functionality on top of the previous version.
+
+### Integration and configuration
+This approach depends on the availability of reusable components or systems.
+The systemdevelopment process focuses on configuring these components to be used in new contexts and integrate them with the system.
+This lets you reuse code from previous projects and save time and money.
+
+## Waterfall model
+Activities are done in a sequence.
+Handover of workproducts between phases and milestones are used to monitor progress.
+Waterfall model is an example of a plan-driven process.
+You are supposed to have all of the process activities and phases planned out before you start development.
+The phases in the model directly reflect the fundamental development activities.
+
+### Requirements analysis and definition
+The systems services, limits and goal and made concrete through consulting with the users.
+They are then defined in detail and are used as the system specification.
+
+### System and software design
+The overall system architecture is established in this phase.
+Identify and describe the fundamental system abstractions and their relations (UML)
+
+### Implementation and unit testing
+The design is implemented in the indivivual program parts.
+The design is tested to verify that it meets the specification.
+
+### Integration and system testing
+The individual program parts are integrated and the whole system it tested.
+The software is delivered to the client.
+
+### Operation and maintenance
+The system is now installed and in use.
+The system is maintained to any issuse that weren't found earlier.
+The system is improved over time.
+
+## When should you consider using waterfall?
+For software that needs to be flexible while it is being developed.
+
+### Embedded systems
+The software must interface with hardware.
+In this case the hardware is not flexible, thus the software must be.
+
+### Critical systems
+When total security is a requirement of the specification and design.
+These systems must have finite specifications and design documents.
+
+### Large software systems
+Part of a larger system being developed by several parties.
+This makes finite specifications extremely necessary.
+
+## How can I decide on waterfall? - analyse home ground
+When one phase ends another begins.
+Steps come ordered and don't allow for going back and redoing parts. (waterfall flows only down)
+When the requirements are mostly unchanging.
+
+### Plan driven versus agile processes?
+Activities in sequence versus all activities at the same time.
+Agile development is very flexible and the requirements may be constantly changing. 
+
+## Incremental model
+You can iterate within increments and the increments can be planned.
+You work within fixed time slots and update the project backlog continuously.
+Incremental is an agile process, where you end with multiple versions that you can show the clients as the project progresses. 
+This allows for the client to come with feedback along the way.
+
+## Integration and configuration
+Development risk is reduced by reuse but there is the risk of not being able to make the desired changes at all or in the time frame.
+Most projects have some level of code reuse. 
+This is often informal.
+This reuse requires looking for the existing code, changing them to meet the requirements and integrating them with the new code.
+
+# Q2. Software Process Model - Incremental/iterative
+The incremental development is based on the idea that:
+1. Develop in prototypes.
+2. Get feedback from the users and others.
+3. Develop over multiple versions until the required system is produced.
+
+Incremental development is the most common approach to developing applications and software. 
+
+## Can it be both plandriven and agile?
+Yes, it can be either one or a mix of both.
+
+### Plan-driven approach
+Identify the system increments in advance.
+A predictable waterfall plan is split into parts.
+
+### Agile approach
+The early increments are identified.
+The later increments depend on progress and the clients priorities.
+You work in fixed timeframes and update the full project backlog as you go.
+
+### Agile-manifest (balance/mix)
+Focus on the individuals and teamwork rather than the processes and tools.
+Good software comes before comprehensive documentation.
+Work with the client instead of using contract work.
+Deal with changes instead of sticking to the plan.
+
+## What are advantages of incremental?
+
+1. Development costs are reduced
+The amount of analysis and documentation that has to be redone is much less than waterfall.
+
+2. It is easier to get client feedback
+The clients can comment on demonstrations of the different versions and see the progress.
+
+3. Earlier delivery of new software
+New features can be made available even if they are not fully completed.
+
+## What disadvantages are there?
+
+1. The project is not visible
+Managers can have difficulty measuring progress.
+It would be a waste of resources to produce documents that reflect the different versions.
+
+2. The system structure can get messy over time
+Changes lead to messy code.
+It gets increasingly difficult to add new functions to a system.
+Large, complex systems with large teams struggle with incremental for this reason.
+Large systems need a stable architecture.
+Responsibility of the different teams needs to be clear with respect to this architecture.
+This has to be done in advance.
+
+# Q3. Software Process Model - Integration and configuration
+## What are the phases?
+### Requirements specification
+The inital requirements are suggested
+They don't need to be developed in more detail.
+They should include short descriptions of important requirements and desired functionality.
+
+### Software discovery and evaluation
+With the overview of the requirements, components are searched for that provide the necessary functionality.
+
+### Requirements refinement
+The requirements are polished with the knowledge of the reusable components that were found.
+
+### Application system configuration
+If an application that meets the requirements is available, it is configured for use in the new system.
+
+## Advantages/disadvantages
+This model reduces the amount of software that must be developed.
+This in turn, reduces the costs and risks.
+
+You usually don't have control of the software that is being reused.
+This can include for example how and when new version are released and how the functionality is changed.
+
+# Q4. Comparison of plandriven and agile including Homeground
+## What is the difference between plandriven and agile?
+### Plandriven
+Plandriven means the desired result can be predicted.
+Plandriven = waterfall.
+Plandriven is an approach where the development process is planned in detail.
+A project plan is created that registers the work that needs to done, who should do it the development plan and the work tools.
+Managers use this plan to support project decisions and as a way to measure progress.
+This is a traditional approach to software development.
+
+### Agile
+Agile expects changes and frequent user inspection to get the best results.
+Agile = Iterative, more detailed Scrum and XP
+Agile methods are iterative, the software is developed and delivered in stages.
+These versions are not planned in advance but are chosen underway.
+Decisions on what should be included in a version depend on the clients priorities.
+
+## How does Böhm/Turner define primary factors?
+### Application
+#### Agile
+Goal: to handle changes in the project.
+Small teams.
+Environment is turbulent and fast-paced, project focused.
+
+#### Plandriven
+Goal: predictability, stability and security.
+Larger teams and projects.
+Environment: stable, few changes, organisation focused.
+
+### Management (onsite, qualitative control, tacit knowledge)
+#### Agile
+Customer relations: dedicated clients on site, focused on prioritised changes
+Planning and control: qualitative control. Who and how doensn't matter as long as it gets done.
+Communications: Tacit knowledge. People do things without needing much explanation or discussion.
+
+#### Plan-driven
+Customer relations: More formal and infrequent. Focused on contract decisions.
+Planning and control: Documented plans, quantitative control. It is important to know who does what.
+Communications: Explicit. Plans must be discussed and verbalized and shared with the others.
+
+### Technical
+#### Agile
+Requirements: can withstand unpredictability.
+Development: simple design, small increments, refactoring is assumed to be cheap.
+Test: Test cases define the requirements.
+
+#### Plan-driven
+Requirements: Formal project, user interface, quality, predictable requirements.
+Development: Comprehensive design, larger intervals, refactoring is costly.
+Test: Documented testplans and procedures.
+
+### People
+Cockburn characteristics can describe a programmers personality.
+One type may be more favourable than another depending on agile/plan-driven approach. 
+
+## 5 axis on the Home Ground Decision tool
+- Criticality: impact of defects
+- Personell: average cockburn type
+- Dynamism: % requirement change per month
+- Culture: % thriving on chaos vs. order
+- Size: # of personnel
+
+## What is continuous integration and how does it relate to agile?
+As soon as the work on a task is complete, it is integrated into the whole system.
+After such integration, all the unit tests must pass.
+Continuous integration uses tools to automate the process.
+Depends on unit tests.
+Does NOT remove the need for tests.
+
+## Prototype development
+
+- Prototype plan: establish objectives
+- Outline definition: define functionality
+- Executable prototype
+- Evaluation report
+
+# Q5. Key features of SCRUM
+Openness of all work.
+Respect each other.
+Focus on the common goal.
+Courage for difficult decisions.
+Duty to the common goal.
+
+3 roles.
+5 events.
+3 artifacts.
+
+## Assets
+- Scrum board
+- Project burndown
+- Sprint burndown
+
+## Three pillars
+Transparency: Everyone knows what needs to be done and who is doing what.
+Inspect: Keep an eye on where we are heading (daily meetings).
+Adapt: Change if it is necessary.
+
+## Core values
+Commitment: to reach the sprint goal.
+Focus: on what needs to be done in the sprint.
+Openness: Communication is key, don't hide issuse.
+Respect: for each other
+Courage: to do the right thing
+
+## Typical errors
+Scrum master is a manager.
+No communication with the client.
+New tasks are added to the sprint backlog in the middle of a sprint.
+
+## Daily SCRUM
+Inspect progress towards the sprint goal. 
+Adjust the backlog accordingly.
+Update (how far are we?)
+Short meeting (15 min)
+Tell the others if you need help.
+
+## Sprint planning 
+Work together with the whole SCRUM team for sprints.
+Look in the backlog.
+Make a sprint backlog. (this can't be changed from the outside)
+
+## Sprint review
+Check development status.
+Sprint review max 4 hours with sprints of 4 weeks.
+The client participates along with the team.
+Only talk about what has been done.
+Dialogue, no presentation.
+Update the backlog.
+
+## Sprint retrospective
+For increasing quality and effictivity.
+What went well/bad?
+How can this be improved for the future?
+
+## Roles
+### Product owner
+Stakeholder contact
+Updates/prioritises the product backlog
+Can be a person dedicated to the client
+The goal is the maximise product value
+Can delegate but is responsible
+
+### SCRUM master
+Ensure everyone is keeping in-line with SCRUM
+Not the management leader
+Ensure the team is effective
+Deal with the teams blockages
+
+### Developers
+They own the backlog
+Programmers, UI, UX and so on
+
+# Q6. Key features of XP - eXtreme Programming
+## What is XP?
+An agile, incremental development method with focus on:
+- Collaboration
+- Quick and early software creation
+- Skillfull development practices
+XP takes all the 'good things' the extreme. (testing, pair programming).
+
+The customre should be available full time for the use of the XP team.
+In XP, the customer is a member of the dev team and is responsible for bringing requirements.
+
+Pair programming: developers work in pairs, checking each other's work to ensure quality.
+
+## Qualities of XP that fit to SCRUM
+Pair-programming.
+Writing unittests before the code (with the help of TDD).
+Partners often have to integrate their code (use continuous integration).
+Refactor as often as possible.
+Collective ownership of code.
+Customer on-site, user stories, planning game, ...
+
+### What does XP and SCRUM have in common?
+Work should be done incrementally/iteratively.
+Teamwork, transparency, communication and prioritisation are crucial.
+Requirements are broken down into bite-size pieces.
+There is overlap with the roles. (XP client and SCRUM's product owner)
+
+## What values are XP based on according to Larman?
+Communication, simplicity, feedback, courage.
+
+### Communication
+Pair programming
+Customer on-site
+Acceptance test
+Daily standup (short meetings)
+
+### Simplicity
+Teams implement exactly what was asked for. Nothing more.
+Strive for simple designs and quality code.
+
+### Feedback
+Early and frequent feedback is crucial.
+Feedback can come from unittests, team members and the client.
+Continuous integration.
+Acceptance test that the client performs.
+Short sprints.
+
+### Courage
+Developers should be honest.
+Don't make excuses for issuse.
+Don't be afraid to make big changes.
+
+## How is XP extreme? 
+E.g. If tests are good, do them all the time.
+Takes all good things, and places them at the core of the process.
+
+## Name some key practices in XP?
+Unit test, pair review, customer on-site, continuous integration, testing, early test, unit test, TDD.
+
+## What is a user story?
+Brief feature request, a promise for conversation. 
+Written on a card with criteria for confirmation on the back.
+
+## Story maps - User story mapping
+To see the bigger picture of the user stories.
+To understand how things are now and to imagine how they could be.
+Visualize the stories you tell about your software.
+
+Story maps consist of:
+* User
+    - a card that tells a story about a type of person, doing something to reach a goal.
+* Activities
+    - Jobs done by similar people to reach a time
+* Backbone
+    - Activies and jobs on a higher goal tier, give the user story structure.
+    - This is a big goal, that the little goals are attached to.
+* User tasks
+    - Short, concise sentences that explain the goal.
+* Sub-tasks
+    - Break down more complicated goals.
+* Release slices
+    - Identify tasks. The smallest number of tasks that allow specific users to reach their goal.
+
+Story map process has 4 levels
+
+## What is the format a user story?
+"As a <user> I want <feature> so that <why>".
+Who, what, why.
+
+## How does XP describe Lifecycle for a System?
+Exploration, planning, iterations to first release, productionizing, maintenance.
+
+## What is the iteration called in XP? 
+Iteration
+
+# Q7. Product Planning: Requirements Elicitation, Product Vision, Product Roadmap
+## What main requirement activities are there?
+Elicitation and analysis of needs.
+Specification of requirements.
+Validation of requirements.
+
+## Elicitation and analysis of needs
+There are two fundamental approaches to Requirement Elicitation:
+1. Interview, where people talk about what they are doing.
+2. Observation or etnography, where you observe how people do their work and which technologies they use and so on.
+
+Use a mix of interview and observation to gather information.
+This can be used to find the requirements that form the basis of further discussion.
+
+## Requirement specification
+Is a process in which you write down user and system requirements into a document.
+Ideally, these requirements should be clear, consistent, complete and easy to understand.
+User requirements should be written in natural language and supplemented with dialogue and tables in the document.
+System requirements can also be written in natural language, but other notations, graphs, maths, etc can also be used. (state machines, automata)
+
+## Requirement validation
+Is the process of controlling of ensuring that the system requirements will are really what the client wants.
+There are different checks that can be used to validate the requirements.
+
+1. Validity checks: 
+Check if the requirements reflect the users real needs. 
+User needs can change over time, so this is an important thing to keep track of.
+
+2. Consistency checks:
+Requirements should not conflict with others. 
+
+3. Completeness checks:
+The requirement specification should be comprehensive for every function and the limits that the client wants.
+
+4. Realism checks:
+Using knowledge on existing systems, control the requirements to ensure that they fit within the budget and time-frame.
+
+5. Verifiability:
+You should be able to create tests that verify whether or not a requirement is met.
+
+## Requirement validation techniques 
+1. Requirement reviews
+Requirements are analyzed systematically by a team of judges, to check for mistakes or conflicts.
+
+2. Prototyping
+Develop executable models of the system and verify with the client that it meets their expectations.
+
+3. Test-case generation
+Tests can be designed along with requirements instead of after the fact.
+If it is difficult to design tests for a requirement, that can mean the requirement is unrealistic.
+
+## What are the steps in elicitation?
+1. Discovery & Classification
+This is the process of interacting with the stakeholders to find their requirements.
+
+2. Categorization
+Take the unstructured list of requirements and group related requirements together.
+
+3. Prioritization & Negotiation
+Conflicts can arise when there are multiple stakeholders.
+Prioritize the most important requirements, through negotiation, discussions, compromises and meetings.
+
+4. Documentation
+Here the requirements are documented.
+
+## Why is it difficult to elicit requirements?
+Many stakeholders with conflicting needs.
+Stakeholders speak their own "language".
+Lack of communication because things are assumed to be "obvious".
+
+## What is a recognized way to communicate requirements?
+Stories, Scenarios.
+
+## How are requirements documented in Waterfall and in SCRUM, in Product Planning?
+Waterfall: Verify the requirement specificatino with strict change management.
+SCRUM: Product vision and product backlog, are discussed and updated every sprint.
+Product Planning: Product vision, release plans and/or product roadmaps.
+XP: User Stories.
+
+## How are requirements negotiated with stakeholders in Waterfall and SCRUM?
+Waterfall: Be up front in the requirements phase - state it now or it will be difficult later on.
+SCRUM: Ongoing refinement of product backlog with stakeholders, say what is most important now, we will continue.
+XP: Customer on-site.
+
+# Q8. Product Refinement and Forecasting: User story mapping, personas, stakeholders, product backlog
+## What is a persona?
+User personas are a useful technique to describe users of your product.
+A fictional character with a name, picture, relevant characteristics, behavior, opinions and a goal.
+Different people can have different goals.
+Understand a personas goal is useful for creating a product that is meaningful to the users.
+
+## What is a user story?
+Short description on a type of user, a goal and a reason.
+
+## Where do we use the terms: Product Feature, Epic, User story?
+Product Feature: Corresponds to an Epic.
+Epic: A collection of related user stories.
+User story: Breakdown of an Epic. 
+
+## What is a user journey?
+The experiences a person has, when interacting with the software.
+
+## What are the key characteristics of a product backlog?
+This is to do list of items a SCRUM team must tackle.
+- Software requirements.
+- User stories.
+- Descriptions of supplementary tasks that are needed, such as architecture definition or user documentation.
+
+# Q9. Risk Management
+A risk is a potential problem.
+The possibility of loss or damage.
+Risk Management: project leaders must evaluate the risks that can affect a project, monitor them, and handle them when problems arrise.
+
+## Example of risk categories
+1. Uncertainty, project, technical, business.
+2. Keyperson from team dies, a supplier is not delivering as promissed.
+
+## Categories of risk
+### Project risks
+Risks that threaten the project plan.
+Time will be wasted and costs will rise.
+
+### Technical risks
+Architectural design.
+Arrises because problems can be harder to solve than expected.
+Vagueness in the specification.
+Project gets older and starts to decay.
+
+### Business risks
+Market risk. What if no one uses the product?
+Strategic risk. We don't need that new component after all.
+Sales risk. How the fuck do we sell this?!
+Management risk. The top management don't support the project anymore.
+Budget risks. Budget or personnel is lost.
+
+## How do you do risk analysis?
+Risk analysis and management are actions, that help a software team understand and handle uncertainty.
+It is a good idea to identify risks.
+Evaluate the probability of risks.
+Estimate the impact of a risk and form a reaction plan for if the risk actually happens.
+
+## Identify risks and calculate risk exposure and describe consequence.
+Risk exposure = probability * loss, describe consequence.
+Probability < 100%. If p = 100% then it's an issue.
+
+Prioritize according to risk exposure, establish cut-line.
+Deal with the risks above the line, accept the ones below.
+
+Establish for each risk above the cut-line (RMMM: Risk Mitigation, monitor, management)
+### Mitigate
+We want to prevent the risk from becoming an issue.
+We can reduce the probability.
+Or try to reduce the associated loss.
+Risk exposure = probability * loss.
+
+### Manage
+For when a risk has become a loss, try to minimize the loss.
+This assumes the mitigation activity was unsuccessful.
+This is done by the project leader.
+
+### Monitor
+Observe how risks change over time.
+How the probabilities, loss, or the environment, change over time.
+
+## How are risk management part of project management
+### Waterfall / plan-driven
+Risk and risk plans are part of the plans in project management.
+Development of others plans to contribute to identification of risk.
+It is planned.
+
+### Agile - inspect and adapt is reduction to produce the right product
+Daily SCRUM: Do you have any impediments?
+Sprint review: Inspects risk related to product and stakeholder.
+Sprint retrospective: Adresses risks related to how the team works.
+
+## What are Böhms primary risks?
+Personal shortcomings, unrealistic schedule, wrong function...
+
+# Q10. How is quality defined?
+## Software quality attributes
+### Nonfunctional requirements
+Safety, security, reliability, complexity, adaptability, testability, understandability, efficiency, usability, etc...
+
+### Functional requirements
+- Requirement Specification (waterfall)
+- Product backlog and User Stories (agile)
+
+## What is quality?
+Quality is evaluated aesthetically, symbolically and functionally
+Quality can be either objective or subjective.
+Quality may not always be obvious.
+
+## Definition of quality
+Quality is a reflection of one or more peoples evaluation of the compliance of a product or service with their expectations.
+Quality can be broken into three types of categories:
+1. Product quality.
+2. Process quality.
+3. Quality of expectations.
+
+Quality tradeoffs are unavoidable.
+Quality consists of:
+- Quality assurance: plan or design processes to prevent bad quality.
+- Quality control: track that work products meet quality standards.
+
+## Why invest or pay for Quality Management?
+Cost of not doing it is bad quality - fixing errors.
+
+Direct cost of error correction:
+- Loss. (effort)
+- Wasted work. (for users of the program)
+- Maintenance usually has larger costs than development.
+
+Indirect cost of error correction
+- Follows from poor quality (unsatisfied users)
+- Has potentially severe consequences (losing customers)
+
+Quality Management reduces these costs significantly.
+
+## Validation (fit for use)
+Are we building a system that is fit for use?
+Compliance with the users expectations and experiences?
+
+## Verification (requirement specification being met)
+Do we pass all tests and requirements?
+Are we building a system with all the requirements implemented?
+Unit/integration tests
+
+## Techniques for verification and validation
+Testing: of programmes and prototypes.
+Review: of specifications, documentation and programs.
+
+## Is it verification or validation?
+A user must participate in order to validate.
+Verification focuses on the compliance to the specifications and a client usually doensn't participate.
+
+## V-model
+
+# Q11. Test and review
+Tests are a set of practices that support verification and validation.
+The purpose is to ensure a program does what it is supposed to, and to discover errors before delivery.
+This is done by making sure the progrm meets the requirements and by finding incorrect or undesirable behaviour.
+Verification: Unit test, component test.
+Validation: prototype test, user acceptance test.
+
+## What is peer review?
+Evaluation of work of one or more people with similar skills (peers).
+Mostly in the form of documents but can also be analysis of code.
+
+## What is the difference between review and test?
+Review is static, and there is no interaction between errors found in review.
+Tests are dynamic and errors can come as side-affects of an initial errors.
+Reviews (inspections) and tests are complementary to quality techniques.
+Both should be used under the verification and validation process.
+Inspections can control compliance with a specifications but not with the clients or users actual requirements.
+(Unless the user participates in the review. Prototypes are preferred for user participation)
+Inspecions cannot control non-functional properties such as performance, usability, etc.
+
+## When is review good?
+For documents, designs, architectures, plans, etc.
+
+## When is test good?
+For functionality and dynamic use of the program.
+
+## What is the V-Model
+A model that shows the connection between tests at different levels and primary activities that drive the tests.
+
+## Name tests at different levels:
+Unit test, component test, integration test, system test, user acceptance test.
+
+Unit test: confirm valid and invalid input.
+Integration test: confirm that interfaces are compatible and work as expected.
+Acceptance test: validate fit for use, exploratory test.
+
+## When is test done?
+Plan driven: in the end (often a dedicated test-team aspart of QA)
+Agile: all the time (test competence on the team, accept criteria on story, automated test, TDD)
+
+# Q12. Configuration Management and DevOps
+## What is DevOps, how can you define it?
+DevOps is a method for both development and operation.
+DevOps is a development method for IT systems that connects different activities in projects.
+DevOps is a culture, that focuses on the entire software productions life cycle.
+The goal is to remove barriers between development and operation teams, to be able to react quickly to the users needs.
+It is also defined by The Three Ways:
+1. Flow.
+2. Feedback.
+3. Continuous Learning.
+
+## What is the purpose of Continuous Integration?
+When the code is checked, it is automatically integrated with the system.
+Speed up the rate of delivery and run tests constantly.
+Bsed on tools to automate the process.
+Depends on a suite of unit tests.
+Does NOT eliminate the need for testers.
+
+## What is the purpose of Continuous Testing?
+Continuous Testing in DevOps is a type of software test that involves testing at all stages of a develoments lifecycle.
+The goal is the continuously evaluate the quality of the software.
+
+## What is the purpose of Continuous Delivery and Deployment?
+### Continuous Delivery
+Ensure that code can be implemented securely.
+Ensure that the business and service application function as expected and deliver every change to production.
+
+### Continous Deployment
+Ensure that tests are automated and that every change is automatically implemented in production.
+Makes the development and release process faster and more robust.
+
+Automated access to well defined environments.
+Tools like Docker for containerization or Virtual Machines.