How many times did get issues back with new bugs?. Do you think that is possible to avoid new bugs while you are coding or solving a bug related issue?. Probably is easy enough to consider that the application, depending on its architecture have several layers to observe. I do not mean layers at server side, but looking on a minimum layer overview, we have at least server side and client side, where both can be decomposed in data collecting and data processing, processed data display and presentation display, respectively.
We have four levels to check on each issue solving session with fourth basic questions that we can enumerate as follows.
- «Is the application extracting the data properly on the server side?»
- «Is the extracted data processed properly on the server side?»
- «Is the presentation layer processing the processed data properly?»
- «Is the presentation layer displaying the data properly?»
Among other sub-tasks to check, we should consider those four as our basic questions to decompose any issue. Try to avoid the MVC pattern, think on the PAC architectural pattern instead, because applications do not have only three layers any more. And since most applications have third party data sources, like social networks for example, we cannot think in our applications with patterns that simple like MVC pattern. All applications are becoming more complex along the time, requesting data not only from a data store like RDBMS software and data is not presented only as HTML any more, there is JSON, XML and YAML.
Where each layer should be verified on bug elimination and issue solving session. There is where each question will help you to determine whether is required a deep examination to supply an optimal solution. If you examine the results on each layer and you examine all components related to the bug, it should disappear. But also this requests that your QA team provides a good bug report. So, the standard MVC is not implemented any more, because you are not using a single data source in your application and you are using an abstraction layer, providing a less coupled architecture, easier to handle — mainly once data sources are changing so quickly.
This will help you to have a better deployed application, and will help in code maintainability. This is a very simple approach, but you can start extending it, allowing the usage of third party libraries, for example with this proposed model, you can make quick switch between Django ORM and SQL Alchemy on Django Applications, without a great impact on the Django Application. Also, this allows you to switch between the horrible CakePHP ORM and Doctrine in PHP applications, and so on, there are various examples, allowing the identification of issues and bugs on very segmented layers of the code, without being excessive to consider it lasagne code, making easier to handle bugs and related stuff.
Is nice to have a well structured application, which is centralising the application activity in well organized layers, so you can handle each issue properly with the required abstraction and design pattern application. So, you can add those questions easily in your issue solving and bug solving session, and if your QA have the capacity of identifying failures and issues on that level, that will help you much more — this is why I prefer QA people with real experience in programming tasks.
Entries 