The frenetic build process continues apace, but we've also entered the pre-launch phase of bug fixing. The process is best summarized by the following steps:
- QA tester finds an issue and assigns it to a developer
- Developer researches issue and makes code change if necessary
- Developer unit tests the change to make sure it works
- Developer checks in the code as "ready" for QA testing
- The code is promoted into the test environment
- QA tests the fix
- Repeat 1-6 until code stabilizes and no critical issues remain
At last count we had over 300 known bugs to resolve, most non-critical content issues (e.g. misspelling words, wrong button style, wrong image, etc...) but some critical that can delay launch (e.g. unable to register). Projects with a code base this large have enormous levels of interdependence among all of the various subprojects. This is in addition to the macro interdependence between the systems themselves. Let me give you an example from the last few days.
I wrote the code (originally for Simply Nutrilite) that allows a visitor to save their profile during the order checkout process. After some debugging, I discovered that due to an unrelated issue, someone had changed the way the page maintains its state which caused one of the dropdowns to no longer keep track of what the user selected. I rewrote the functionality to maintain its state on its own, then promoted it to the other environments for QA testing.
Mysteriously, the identical code worked in the dev environment but broke in build and QA. After more research, it turns out that the back end system was having issues in build/QA but was functioning just fine in dev. After the back end system was stabilized, I discovered that another unrelated change to the checkout process temporarily disabled the confirmation page, which is where the save profile functionality is displayed. After that was resolved, everything is now up and running again in all three environments.
It has been said that this process is akin to building a plane while it's in flight. I have to agree. In order to benefit from the time savings of parallel development among many developers, you have to be aware of the risks that multiple simultaneous changes to the code introduce. That's why testing is such a high priority and why the iteration described above is a constant process both pre and post launch. In the meantime, I'm off to run down some more issues.
Leave a Comment
Comments policy: Please note that comments are moderated.
All comments are welcome as long as they are on topic, respectful, and do not advertise competing products
or businesses. We reserve the right to remove without warning any and all offensive, unlawful,
defamatory, or libelous comments, as well as any personal attacks or offensive language.
About Brett Folkert
Occuption
I am a Software Architect at Quixtar. The nature of my job and our environment means I have to be fluent in many disparate technologies on a daily basis. I like to think of it as "controlled chaos". I constantly strive to improve our architecture and ensure that wherever possible the underlying technology is transparent to our users. You probably won't notice my handiwork unless you look at the system design, but behind the scenes a lot of thought and hard work goes into making the site perform to our standards.
Background
My IT experience prior to Quixtar was primarily in consulting. I have worked with the U.S. Navy, dotcom startups and Fortune 500 companies. I consulted for Amway in years past (technical lead on GBISLink) before joining the team here at Quixtar. I hold both Master's and Bachelor of Science degrees in Computer Science. My thesis on neural networking/satellite imagery was published in the International Journal of Remote Sensing.
Interests
I have passions for wine, mountain biking and ancient history. If you want to discuss Cicero over a fine Bordeaux, look no further. I'm also married with two precocious daughters whom I adore. As if work and family weren't enough to keep me busy, I'm also attending law school in the evening.