Main Page

Modified on 08/07/2018 01:55 by Developer Categorized as Best Practices, Business Process, Business Rule, Navigation, Role, TestWiki
Welcome to the '''Test Wiki'''!
{TOC}

[anchor|#Goals]
===Goals===
# Reducing the time it takes to fix bugs, add new features, and add enhancements to [++iCIS.MainPage|Solution]
# Create a [GlossaryOfTermsAndPhrases|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 [TestWiki]. This is called [TestDrivenDevelopment|Test Driven Development]{br}
# Explore new [CodeFrameworks|code frameworks]

[anchor|#What's New]
===What's New===
#New Tree Planted - [Database]
##This is a starting point for database integrity verification, fixes, and utilities for both master and client databases.
It was created to store the first utility script [ClientDatabaseUtilityScripts|Backup and restore client security settings]. There is a procedure for changing some settings in Management Studio required for the process to work.

[anchor|#Communications]
===Communications===
The [TestWiki] 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: <nowiki>[++CustomerProcesses.MainPage|Customer Processes]</nowiki>. 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.{br}
====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 [GlossaryOfTermsAndPhrases|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.{br}

===The Success of a Software Solution===
Strategy + Knowledge = Effective Problem Solving

Because of recent research, we now recognize that understanding and applying a strategy to a problem isn’t enough to effectively solve the problems. Researchers have found that there are many other factors that build good problem solving skills. In addition to selecting an appropriate strategy to fit the problem, you must have a deep base of knowledge in the subject area of the problem. Additionally, individuals need practice with a strategy within the context of real-world problems. This new thinking on the importance of having a solid base of knowledge in a particular subject has changed the way educators and trainers teach problem solving strategies.

In my opinion it's the close relationships with clients and their willingness to work though the designs by imparting their domain knowledge and the ability to merge in their process with the overall design that is a major key to success. With a plug-in architecture we can do so without rebuilding the application as well as defining a stronger separation between custom implementations.{br}
{br}
===Example Outline===
Knowledge of the example business plan is documented as software requirements and use case studies.{br}
Strategies are considered based on the knowledge documented{br}
Possible strategies:{br}
For a simple one off app with no intention of extending or updating it then the simplest strategy would be best (KISS) just knock it out and get it done.{br}
The same goes for any extremely short a deadline. If you try to put in ORM mappers and logging and such than you'll never make the deadline. {br}

[anchor|#Benefits]
===Benefits===
By increasing the involvement of [DomainExperts] and improving collaboration with [Developers], [Testers], [SupportTechs], [HarrisManagement|SoftwareManagement], [ProjectManagement], [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 [TestWiki]. It's very easy to add new pages and link between pages [#howtocontribute|(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.{br}
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.{br}

[anchor|#BestPractices]
===Best Practices===
====Business Processes====
*Sales
**UPC Code reading
**Generating Sales Records
***Loyalty Cards
***Promotions
**Creating Sales Credit/Debit Transactions with Audit Trails
*Payments
**Creating A/R Credit/Debit Transactions with Audit Trails
**Reading Credit Cards
**Printing Receipts
***Writing Bar Code to Receipts***
*Returns
**Reading Bar Code on Receipts
**Creating Debit/Credit Transactions with Audit Trails
*External Interfacing
**General Dynamics GP
**ERP Interfaces
***Data Transformations
***Web Services
.{br}
.{br}
.{br}

[anchor|#HowToContribute]
===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|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 address 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: <nowiki>[NewPageTitle|new page title]</nowiki>. 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 [WikiMarkup|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.{br}
Enjoy!
Meta Keywords: getting started, getting, start, role
Meta Description:
Change Comment: