Page History: Main Page
Compare Page Revisions
Page Revision: 11/30/2013 04:01
Welcome to the
Fit Test Wiki!
Goals
- Reducing the time it takes to fix bugs, add new features, and add enhancements to iCIS
- Create a Glossary of Terms and Phrases, create unit and acceptance TestSuite, and create TestTemplates the tests can be easily reused with other sets of data or to use as a starting point for making variations
- Improve the accuracy and completeness of communications between all the role players
- Encourage DomainExperts to get involved with fulfilling these goals and to aid in the design of their requested feature or enhancement by creating and/or refining acceptance tests using the FitTestWiki. This is called Test Driven Development
Communications
The
FitTestWiki is designed for ease of use and aiding in collaboration between all role players;
DomainExperts,
Developers,
Testers,
SupportTechs,
Consultants,
Sales, and other
Stakeholders in the project. Each namespace (the drop list at the upper right of the screen) in this wiki is devoted to a single product or external interface for generic content and client specific areas by adding the client's name to the namespace. You can also make a new namespace for any topic you wish: [++CustomerProcesses.MainPage|Customer Processes]. This namespace is the root namespace and this is where we discuss, refine and expand on the the sections here and the overall content and structure/navigation in this site. We need to define terms and phrases (a common syntax) and summarize Fit testing.
The most important aspect of software development is communication
Along the way we'll document commonly used syntax with semantics definitions of there use. Many of these are so common it's just a matter of documenting them. If a newbie keeps asking what do you mean by "close out the last period", if it's not easily found in the help and you don't have your own documentation for this you could just point them to our
GlossaryOfTermsAndPhrases. Doing "final done" may mean one thing to some companies and something else to other companies. The utilities industry has naturally defined base syntax's semantics like a "final read". Pretty much everyone in the industry would agree that it is the reading of a meter used to calculate the usage for a final bill. We will not attempt to create a complete grammar but we do need some basic rules to effectively communicate. We need to agree upon the syntax and their semantics as used in the software and accompanying documentation. That's not to say the software or documentation are the final word on these matters. If we didn't get it right we'll change it.
A
Glossary of Terms and Phrases is being established here and we'll add voting too if it comes to that. Everyone is invited and encouraged to contribute to this site on any page you have an opinion on. You can get
InstantAccess and start adding content now.
We still need a few rules though. Like, you can have multiple phrases that are semantically equivalent but to avoid ambiguity there can be no exceptions to that rule. That is to say we can't have a term or phrase with more than one meaning. Effective communications depends on it.
Benefits
By increasing the involvement of
DomainExperts and improving collaboration with
Developers,
Testers,
SupportTechs,
HarrisManagers,
ProjectManagers,
Consultants,
Sales, and other
Stakeholders(too many types to count) we can all accomplish all of our goals more effectively and efficiently. This is the main goal of the
FitTestWiki. It's very easy to add new pages and link between pages
(See next section) making this an ideal environment for brainstorming new features as well as refining existing features and implementation strategies. As the content grows it becomes a repository of 'how to' procedures and data used in these automated tests which can also be used while doing manual testing and saved off for integration and regression testing too.
Say we have a
TestSuite proving how interest is applied to pay plans using various options and create a
TestTemplate. We can then use the template to quickly create custom versions of the tests. We can extend this testing model to support MS Excel and other data sources in the future. We can put the data on the same page but in a different namespace (upper right drop list) to keep the test and its' data together and also data (or data source info) for our clients. Once in place the process of running the tests can be automated as well using basic file based command line utilities.
Best Practices
Business Processes
- Utility Billing
- Account Maintenance
- Customers
- Service Locations
- Meters
- Attached Devices
- Work Orders
- Move In
- Move Out
- Readings
- Batch Entries
- Batch Adjustments
- Batch Email
- Batch Meter Change Out
- Batch Reverse Payment
- BatchPayments
- External Interfacing
How to Contribute
To contribute just, create an account and log in. You can use an alias name if you like. Something that indicates your
role would be good. You can also use the built in shared log ins for the roles. For each role there is a log in with the same user name and password as the role. See the
InstantAccess page for more info. Email addressed will only be used by the system setting and resetting passwords only. To contribute just click the edit button at the upper right of every page. Adding a link to a new page and creating a new page is as simple as adding a few Wiki markup codes. Example: [NewPageTitle|new page title]. After the page is saved the text right of the | will be underlined. You can leave at that as a suggestion for someone else to with more knowledge of the subject to create the page or you can click on it and a page will come up with a 'Create new page' link you can use to create the new page and set the page title. See the
Wiki Markup page for additional formatting options not supported by the visual designer/editor. Checkout the
CustomerInvolvmentWithExcel page for in depth information on how Excel and HTML test runners can be used independently of this wiki.
Enjoy!