Important notes

  • Never wipe off client’s input data both and staging and live site without approval from client
  • Never use/ input any Vietnamese or Offspring related names, emails, data… to the projects working with agencies. Email to test for all projects: testing3128@gmail.com/ 051079lowie
  • Never use too simple passwords. Follow the strong password rule
  • Never send passwords directly in emails/ chats. Put them in one off message tool, use https://onetimesecret.com/
  • Always recommend clients to update password after going live
  • Always flag to clients to update live content, including email for contact form during going live

Project - Member’s responsibility

PM : Overall responsibility

  • Meet timeline
  • Provide assets
  • Clarify requirements to team

Main dev

  • Quality of code
  • Meet the requirements
  • Flag all potential tech issues + suggest solutions

Co-dev

  • Quality of code

QA : Product quality

  • Meet requirements
  • No bugs
  • Flag all potential quality relating issues to PM

Tech director : Tech quality

  • Analyze initial requirements, flag all possible technical issues, provide solutions
  • Decide on platforms, plug-ins, libs… to use for the produc
  • Check all technical key points upon each release

Standard projects - Checklist

Requirements Analyzing (to be all clarified with clients before starting)


Kickstart meeting:

  • Tech brief, milestones break
  • PM to communicate to client about timeline, any flags/ requests
  • PM to plan and assign tasks to team members
  • Tech lead to create Tech specs
  • PM to create an “All assets” message to provide: font, design download, access to existing resources...

Test plan and test case building (or QA checklist)

QA to post reports (include QA checklist) to Teamwork after each testing round, contains all credentials


CMS Guideline: During testing the CMS, QA will create guideline, PM to review before sending to client together with beta report


Data population: QA to generate data through CMS at Beta version testing phase


Go live:

  • Need an official confirmation from client
  • Post – live testing
  • PM to notice to client to update password/ email/ all missing content

Standard projects - Flow

QA checklist

GUI

Page layout as per design/wireframe

Element style guide (if present)

Perfect pixel (if required)

Consistency

Cross-browser & mobile responsive (refer to Testing Environment)

Miscellaneous:

  • favicon, page title, pagination...
  • No CSS & Javascript error & warning
  • User friendly error messages & pages
  • Irregular styling issues (too long, overflow...), animation,...

Functionality

  • Elements work & interact as per functional spec (specific per project)
  • Configurations & settings applied and reflected correctly on front-end
  • Multimedia elements (image, audio, video) correctly rendered
  • 3rd party plugins/integration display & function correctly
  • Authentication & authorization

Additional

  • Data check: no testing, Vietnamese or Offspring data (for Agency projects)
  • Guideline document
  • Recommend to install SSL cert + make sure both www and non www work + http is forced to https
  • Recommend client to change password + update email for Contacts

Testing environments

Desktop

  • Windows (10): Edge latest, Chrome latest
  • Mac: latest Chrome, Safari from MacOS version

Mobile

  • iPhone
  • Android

Tablet

  • iPad (portrait)

Simulator

https://www.browserstack.com/

User: developers@offspringdigital.com
Password: contact Admin team

Ticketing process (in Teamwork, Jira, Trello…)

  • When you receive a ticket, read it and ask for clarification if needs to, before you start.
  • When you start to work on it, make sure you move it (or add the tag) to proper status, which are normally: in progress, Ready for QA, done, released to prod (terms can be a bit different among projects).
  • When you finish a ticket, make sure you: add evidence of how it's working + assign to proper team member + move to another column (or add another tag).
  • With some specific projects, your PM might ask you to log tracking time into tickets too.
  • A donation of 40k to the Offspring charity fund is kindly requested for each ticket that does not follow the ticketing process.

ticket process
A good example for the evidence in a ticket about creating API

Release note

MOB APP release notes: each version should have notes (in the TF notes, or as a separate file/ message) about all tickets included in that release. This can be ticket ID, or ticket's title (depending on projects). If tester receives a build without clear release notes about what's new in the build, please return it back to the dev. Else, if the PM receives the build without the release notes but tester didn't pick it up, that tester will have to pay the penalty (this means release notes is a required item for our quality check).

GIT process

Please follow the guidelines from here https://internal.project-staging.com/coding-convention-guidelines.html#structure , especially focus on 'Name of the branch should be the ticket ID/ name of feature". If you don't have a ticket ID to put your branch commit, please ask your team lead/ PM to create a ticket for it. That should be their job to make sure every tasks given to you are ticketed properly.