SOFTWARE DEVELOPER
Bis-e (BLACKbERRY INTERNET SERVICE EMAIL ) TEAM
SEPT - DEC 2012
Waterloo, Ontario, Canada
- Worked as a developer as a part of the Duplicate Defect Detection (DDD) research project (Java)
- Gained extensive knowledge and research experience in Information retrieval techniques and search engines
- Performed black-box testing to verify builds and virtual environments for BlackBerry Internet Service (BIS)
- Used log crawler, SSH clients, putty etc. to inspect logs in order to resolve the issues found during verification
- Gained knowledge about wireless communication systems, BIS architecture & BlackBerry carrier infrastructure
DUPLICATE DEFECT DETECTION PROJECT
Background:
Duplicate Defect Detection was a part of SDMS (Statistical Decision Model for System Test) research project which was a joint initiative between RIM and University of Waterloo research group. DDD is actually a web application that detects duplicate defects for an existing defect or a newly reporting bug.
In software development, the same bug in a product might be reported by different users overtime and this asynchronous nature of reporting bugs causes a problem of bug duplication. The main aim of DDD was to enhance release testing effectiveness by eliminating the effort wasted in dealing with these duplicate bugs.
My Contribution:
As a developer working on this project, I independently developed two tools required by the duplicate defect detection system. Apache Lucene and Java were used to for the implementation. Additionally Log4j, MKS Application Programming Interface and Java Mail Application Programming Interface were also used within the scope of this project. Through this project I not only gained experience working with the Eclipse IDE and Java Apache Lucene search engine library but also learnt a lot about the information retrieval softwares and systems.
EXCEPTION SENDER: The purpose of the exception sender was to inspect the performance of DDD every time it runs. It was designed to make sure that DDD was running as expected. If this was not the case, Exception Sender was required to notify the concerned people about the issues encountered by DDD.
BUG EXTRACTOR: The purpose of bug extractor was to improve the performance of DDD. Due to the limitation of resources, DDD was run only after every three hours and couldn't be run more frequently in order to avoid overloading MKS integrity. Therefore, if a user would search for the duplicates of a particular bug, he would not get accurate information since the new bugs created during the last three hours would be missing. Therefore, to make up for this, the bug extractor would extract only the new bugs created (not all the bugs present) in MKS at shorter intervals and index them into the index file. This would not only prevent MKS from getting overloaded, but also ensure accuracy of information during a search.
Duplicate Defect Detection was a part of SDMS (Statistical Decision Model for System Test) research project which was a joint initiative between RIM and University of Waterloo research group. DDD is actually a web application that detects duplicate defects for an existing defect or a newly reporting bug.
In software development, the same bug in a product might be reported by different users overtime and this asynchronous nature of reporting bugs causes a problem of bug duplication. The main aim of DDD was to enhance release testing effectiveness by eliminating the effort wasted in dealing with these duplicate bugs.
My Contribution:
As a developer working on this project, I independently developed two tools required by the duplicate defect detection system. Apache Lucene and Java were used to for the implementation. Additionally Log4j, MKS Application Programming Interface and Java Mail Application Programming Interface were also used within the scope of this project. Through this project I not only gained experience working with the Eclipse IDE and Java Apache Lucene search engine library but also learnt a lot about the information retrieval softwares and systems.
EXCEPTION SENDER: The purpose of the exception sender was to inspect the performance of DDD every time it runs. It was designed to make sure that DDD was running as expected. If this was not the case, Exception Sender was required to notify the concerned people about the issues encountered by DDD.
BUG EXTRACTOR: The purpose of bug extractor was to improve the performance of DDD. Due to the limitation of resources, DDD was run only after every three hours and couldn't be run more frequently in order to avoid overloading MKS integrity. Therefore, if a user would search for the duplicates of a particular bug, he would not get accurate information since the new bugs created during the last three hours would be missing. Therefore, to make up for this, the bug extractor would extract only the new bugs created (not all the bugs present) in MKS at shorter intervals and index them into the index file. This would not only prevent MKS from getting overloaded, but also ensure accuracy of information during a search.
Link to the company website: http://ca.blackberry.com/