We're team 2, welcome to our team's project. We will be making a colour value converter with react! ## The Project Our project will convert RGB colour values into hex colour values as well as show the colour to the user so they can check that they have the right colour.  *Table showing rgb to hex equivalents* ## The team

Team Members and Roles:

🎯 Levi - Scrum Master 🎀 Jacob - UX 🤝 Fahima - QA 👨‍💻 Chi - DevOps ## How we managed the work The way we made sure that we stayed on task and that the project went smoothly was throught regular meetings organised by the scrum master as well as github project boards that were regularly updated by our scrum master. If anyone finished their task they could request a meeting to review the progress and new work would be assigned to them. The main methodology we used as a team was an agile methodology which meant that we all worked asynchronously on different parts of the project. Github is especially useful for this type of development because it allows your teammates to review your part of the code before it gets merged into the main project. 

Coding Practice

At the start of the project we discussed what coding practices we would use in order to keep our code neat and in order to make sure that it is uniform and easily understandable. Our main hurdle was making sure that everyone knew what eachothers code did and if there was an error it would be easily found and understood. Our coding practices involved: -Commenting your code. -Using spacing to distinguish between blocks of code. -Making sure that variables have reasonable names. 

A/B Testing

Please find our initial Figma prototype here:

https://www.figma.com/file/n6pLeB5rKmMbS0zp2r7Qs3/Colour-Converter?node-id=101%3A2

After reveiwing the initial prototype some concerns were raised about the accessibility of the design as well as the colours and overally desired simplicity of the app. With this information in mind a new prototype was deisgned in Figma.

You can view this below:

https://www.figma.com/file/XC3ioUHXxZM0RMqTi1yAFT/Untitled?node-id=0%3A1

The feedback recieved from sample users cemented our decision in using the second prototype as our official one. Below you can view the data collected.

Testing Strategy (definition of done)

The first thing we did for our testing strategy were some smoke tests because if a small error were to be spotted later in development it could cause as massive problem and way more work than needed. For our testing strategy we mainly wanted to focus on making sure that the user experience was as smooth as possible so before testing our logic or if the converter actually changed colours we wanted to make sure that the user inputs were properly validated and worked as expected. Once we made sure that all the user inputs were correctly validated and worked as expected we then proceeded to making sure that all of our functions worked as expected so we tested all the conversions to make sure that the colours being given were the expected colours that belong to the rbg value as well as the correct hex value being displayed. If we ever ran into problems we would bring it up on our weekly meeting and either work on fixing it as a team or someone would be put in charge of fixing the error, this was to make sure that noone felt like they were alone and so the errors can be fixed before more code was added.

CI/CD Pipeline

The CI/CD Pipeline is a series of steps needed to complete a new version of the software and it stands for Continious Integration/Continuous Delivery. The main steps in this pipeline are: **Build** - The stage where the application is compiled. **Test** - The stage where code is tested. Automation here can save both time and effort. **Release** - The stage where the application is delivered to the repository. **Deploy** - In this stage code is deployed to production. **Validation and compliance** - The steps to validate a build are determined by the needs of your organization. ### These steps for us looked like this 1.One of us would write some code in their individual machines 2.They would test their code and make sure that it works as inteded 3.They would upload their code to a branch in order to be reviewed and stored on github 4.After we checked it and agreed that it was good to go we would then merge it into the main program 5.Next time we had a team meeting we would discuss any bugs or errors that might have appeared and we made sure that everyone knew what was done and what needed to be completed.

Languages and Tools we used: