Retrospective findings OneLine:Migrol

1. Estimated VS Spent time spent on the project (BE, FE, QA, PM, code review, total);

2. Time and number of bugs found by the client;

3. Additional client requests.

Project: OneLine: Migrol

Team: PM: Kate Hvozd ; FE: Andrij Rehush ; BE: val.b (Unlicensed) ; QA: Artem Makarov ; Team Leads: Artem Gnibeda , Honcharuk Oleh Pavlo Trukhin

Link to the Retrospective document – Retrospective

Conclusions

Description

Department

1. If there are a few emails in the row – each should be tested separately to make sure it was triggered by correct trigger (actition).

Win email sent before winning. Solution – Rewrite the logic.

(issue captured on the final tests, but developer said that it’s not easy to change the trigger, so we implemented some delay in email sending to cover this issue. However the client reported a bug anyway.)

DEVELOPEMENT PROCESSES

2. WP setup – Analyze the possible amount of fields and divide it accordinly to not exceed the limit or change the limit in advance.

some WP fields dissapered from theme settings because limits were reached.

Solution 1 – Changed the limits in WP. (The issue apeared after we’ve implemented a few new fields).

Solution 2 – New option pages for each option category !

Do not use repeater , divide to post types. (max input php)

DEVELOPEMENT PROCESSES

3. After each even small change the full functionality should be tested (even if it seems like the change is not connected to anything else. Including each email and their amount).

Links don’t work, the page reloads on click + triggers a duplicate email sending.

Solution – Links fixed, so they stopped trigerring the page reload and duplicate email sending.

DEVELOPEMENT PROCESSES

4. Set up correct receivers for emails that are triggered by crons. Be careful with transfers to prevent the code rewriting

Duplicated Reminder emails (and after fix appeared again)

Solution

• 1.06 (before launch) – changed the logic so users receive personalized emails and are o in the copy of each other

• 5.06 (after launch) – the fix made 1.06 was accidentally rewritten during some next transfer, so the fix was put back.

DEVELOPEMENT PROCESSES

5. Testing of the complicated functionality should include checkup of all the positive scenarios step by step. (To make sure that data saves correctely – accordingly to user actions)

Prize limits were reaching too fast as “-1” was on applied to more prizes then needed.

Solution: “-1” was applied to correct prize (not all the prizes form interests that were chosen)

Solution 2: Logging of each complicated step in the script’s operation!

DEVELOPEMENT PROCESSES CheITGroup

6. After form testing – always make sure that all the fields data appeared in WP and emails.

Sometimes some fields do not appear in the WP table (but saved in DB)

Solution:

• the frst time it was reported there were a few such cases. We haven’t found the reason why it happened and were monitoring it.

• then we assumed that the code should be rewritten but it will be too dangerous, so we’ve just moved the data from DB to the table and DB.

DEVELOPEMENT PROCESSES

7. Data protection when submitting a form

• Sanitizing form fields

• Check email validity! For example thomas.peter.rickli.@gmail.com

• Using wp_nonce

• Sending the form only through $_POST

• try cache

DEVELOPEMENT PROCESSES

8. Recapcha – deside on the confirmed development and QA flow.

Recapcha – was not working properly.

*There was no functionality at all!

QA

9. During the development of the forms the code should be anlyzed for the potential basic bot prevention

Basic bot prevention

DEVELOPEMENT PROCESSES

10. Double check the functionality after deployment on a live site

• checking changes in the code

• checking the functionality of the site/page

• the one who developed it is the one who transfers it

DEVELOPEMENT PROCESSES

QA