Squish Lists

Inspiration

There are currently two ways we support bug tracking during feature development:

1. Excel sheet / Google sheet with list of bugs
2. Individual tickets

Both ways have their pros and cons, but neither has the functionality required for a quick and easy bug tracking / development experience. Excel sheets need to be kept track of for every project and require lots of manual work to keep them up to date. Tickets are cumbersome, having lots of overhead, and can often slow down bug resolutions during feature development. We decided to build a better way of keeping track of bugs found during feature development and so Squish Lists was born.

What it does

Squish Lists is a tool for keeping track of bugs during feature development. It allows for easy linking between a central bug tracker ("Squish List") and all associated tickets. That means no more keeping track of a document with google drive links, while also keeping the expected functionality that comes with excel sheets such as sorting and image attachments. Data is our thermostat, so it also has the analytic potential of PT. All the data for Squish Lists live in our system, so we can look at various metrics around the manual testing / bug tracking life cycle.

The general workflow for use is:

1. Create a new "Squish List" for the project you are working on (requires at least one associated Project Tracker ticket).
2. Once the project is ready for testing, start the testing process and enter found bugs as new "Squishes" along with steps to reproduce and any useful images / notes.
3. Prioritize and share "Squishes" with developers and stakeholders.
4. Squish the "Squishes" as bugs are resolved.
5. Keep track of useful metrics such as number of "Squishes" generated and of what priority.

How we built it

The project was started during a hackathon at the end of 2016. We originally built Squish with PHP and Tungsten and migrated it to PHP and React during this hackathon. Most of the data is stored in MSSQL with attachments stored in Isilon.

Challenges we ran into

• Admin is not the same as SF: There are a lot of discrepancies between the systems and since we didn't have much prior Admin coding experience, there was a decent amount of overhead for learning about the various DBs and React components that we needed to use.
• Isilon: None of us had dealt with file uploading and storage before, and our Isilon system takes some getting used to.
• Deciding not to implement redux at the beginning of the react conversion caused some issues with managing application/component state later down the line

Accomplishments that we're proud of

• We successfully converted the frontend from Tungsten to React.
• Squish List feels like it's a solid base for a better system of bug tracking
• We made substantial changes to the original application to make it single page - the only window reloads are on PT searches

What we learned

• Various intricacies of the Admin application
• How to use/customize React tables
• It's difficult to manage component state across multiple parents/children without the use of a global store

What's next for Squish List

• Add an analytics system for quick and easy metric searching.
• Add easy links on a Squish List that keep track of associated Libra Tests or Feature Toggles for easier testing.
• Add a dynamic tagging system for Squishes and Squish Lists to assist with metric gathering and searchability.
• Integrate Squish Lists with Slack or Email and allow people to watch for new entries / updates.
• Update squish list to use redux
• Add more dynamic styling

Built With

• isilon
• javascript
• php
• react
• sql