Backend testing is a type of testing that checks the Application and Database layer of a 3 Tier Architecture.
API Testing -> Business Layer
Database Testing -> Database Layer
Database Testing
It means that data entered in the front end will be checked in the back-end database.
Databases are checked for ACID properties, CRUD operations, their Schema, Business rule conformance. Databases is also checked for Security and Performance.
In back-end testing, there is no need to use the GUI. You can directly pass the data using a browser with the parameters required for the function to get the response in some default format. For Example, XML or JSON. You also connect to the database directly and verify the data using SQL queries.
Structural testing deals with the database inner structure (i.e. metadata). It involves validation of Tables and all the other database objects that aren’t directly accessible by users, like Columns, Keys, Indexes, Schema, Triggers, Functions, etc. It can also involve testing your DB servers.
Functional testing focuses on the way data is mapped from the frontend to the database. (e.g. whether clicking a button correctly affects the related tables/columns).
Non-functional testing checks how the database performs under the expected loads and extreme levels of stress. Security tests also belong here
Virtual DOM: Virtual DOM is a concept of DOM used by React.js and Vue.js. In Virtual DOM concept copy of DOM is saved in the memory and while any change is done in the DOM, it’s compared to find differences. Then browser knows which elements were changed and can update only those part of the application to avoid re-rendering all the DOM.
Context Driven Testing is a mindset shift (or School of testing) developed by Cem Kaner, James Bach & Bret Pettichord. Details about it can be found in their famous book: Lessons Learned in Software Testing.
There are 7 basic principles to it. The following are directly picked from their book:
#1) The value of any practice depends on its context.
#2) There are good practices in context, but there are no best practices.
#3) People, working together, are the most important part of any project’s context.
#4) Projects unfold over time in ways that are often not predictable.
#5) The product is a solution. If the problem isn’t solved, the product doesn’t work.
#6) Good software testing is a challenging intellectual process.
#7) Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.
Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.
A predicate is also a delegate like Func and Action delegates. It represents a method that contains a set of criteria and checks whether the passed parameter meets those criteria or not. A predicate delegate methods must take one input parameter and return a boolean - true or false.
The Transaction Controller generates an additional sample which measures the overall time taken to perform the nested test elements.
Note: when the check box "Include duration of timer and pre-post processors in generated sample" is checked, the time includes all processing within the controller scope, not just the samples.
There are two modes of operation:
additional sample is added after the nested samples
additional sample is added as a parent of the nested samples
The generated sample time includes all the times for the nested samplers excluding by default (since 2.11) timers and processing time of pre/post processors unless checkbox "Include duration of timer and pre-post processors in generated sample" is checked. Depending on the clock resolution, it may be slightly longer than the sum of the individual samplers plus timers. The clock might tick after the controller recorded the start time but before the first sample starts. Similarly at the end.
The generated sample is only regarded as successful if all its sub-samples are successful.
In parent mode, the individual samples can still be seen in the Tree View Listener, but no longer appear as separate entries in other Listeners. Also, the sub-samples do not appear in CSV log files, but they can be saved to XML files.
In parent mode, Assertions (etc.) can be added to the Transaction Controller. However by default they will be applied to both the individual samples and the overall transaction sample. To limit the scope of the Assertions, use a Simple Controller to contain the samples, and add the Assertions to the Simple Controller. Parent mode controllers do not currently properly support nested transaction controllers of either type.
Screenshot of Control-Panel of Transaction Controller
Parameters
Attribute
Description
Required
Name
Descriptive name for this controller that is shown in the tree, and used to name the transaction.
Yes
Generate Parent Sample
If checked, then the sample is generated as a parent of the other samples, otherwise the sample is generated as an independent sample.
Yes
Include duration of timer and pre-post processors in generated sample
Whether to include timer, pre- and post-processing delays in the generated sample. Default is false
If you are performing testing on a
Mobile App, you perform all the tests that you would ideally perform on the web
application. However, there are few more factors that you may want to perform
on your Mobile App.
Emulators are used during the initial stages of an apps
development and later with software testing real devices are used. I have
concluded that the use of real world devices are necessary for maintaining
strong standards and quality assurance.
1.Interrupts – How the
app behaves when there is a call/text/notification from other apps.
2.Access points – How your application behaves when it
moves from one internet access point to another when it is connected on WiFi.
3.Signal – How your
application behaves when you switch from WiFi to mobile data, mobile data to
WiFi, different WiFi connections.
4.Push Notification – How your
App behaves with push notifications.
5.GPS – If you have a GPS feature on your
App, you may want to check if the App polls GPS with different internet source.
6.Screen
orientation – Changing the screen orientation.
7.Different versions of iOS and Android
compatibility tests.
8.Sound tests from the App.
9.Different
screen size tests.
10.Performance/ responsiveness of the
App.
11.Most mobile apps will have web
version. You may have to check the
integrity of the data on both.
