Quality-Assurance

Recently I was asked how to start with testing UI before backend is completed. It depends on the product a lot. But when we’re talking about web, it is often not clear how the final solution should look like and behave. If so, it is not reasonable to spend much time writing UI tests using tools like Selenium before the first prototype is ready. It is not reasonable to write a presentation layer and, in some cases, a business logic on server side before it is clear what kind of data is required for UI. To deal with it I suggest starting with UI mockups and use fake data to start prototyping. It is very easy if you’re writing single page application (SPA): just put some JSON files as static resources and read this files in applications. For more complex cases like handling POST requests you may use simple mock server like gulp-connect. This is required for development so your UI developers don’t even need any server running. Once you’re a bit confident how your UI will look like and behave, it comes the time to cover it with some tests. When using Selenium you will normally ends up with developing some DSL framework for your tests which will include some custom assertions and methods to execute common tasks like user login and filing some forms. Now you should prepare more test data and put it in the same JSON files. Most likely, you will need fake server like gulp-connect in this stage. Use PageObjects to abstract your tests from minor (or even major) future changes in the UI.

If you are involved in software development then recalling a basic testing principles once again is not a waste of time. So here are the principles: A necessary part of a test case is a definition of the expected output or result. A programmer should avoid attempting to test his or her own program. A programming organization should not test its own programs. Any testing process should include a thorough inspection of the results of each test. Test cases must be written for input conditions that are invalid and unexpected, as well as for those that are valid and expected. Examining a program to see if it does not do what it is supposed to do is only half the battle; the other half is seeing whether the program does what it is not supposed to do. Avoid throwaway test cases unless the program is truly a throwaway program. Do not plan a testing effort under the tacit assumption that no errors will be found. The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section. Testing is an extremely creative and intellectually challenging task. I recommend reading a book “The Art of Software Testing” by Glenford j. Myers, Tom Badgett and Corey Sandler (ISBN: 978-1-118-03196-4).