Situational testing

Every organization, every system and every project is different, so every test project requires a unique approach. Situational testing offers various forms of testing and allows you to complete your testing projects flexibly, at the lowest possible cost and in the shortest possible time.
 
Among the forms of testing recognized within Situational testing are factory based testing, global scripting, session based testing, bug hunts, test tours and free style exploratory testing. Testers choose one or more of these test forms, depending on the organization, project and system. This way, Situational testing encourages you to approach testing in a flexible, structured and pragmatic fashion. With Situational testing you achieve better results than using a single specific approach.

Clean Code


Points to remember
Make it easy to read,
Make the surrounding code clean,
Change one variable name for the better,
Break up one function that’s a little too large,
Eliminate one small bit of duplication,
Clean up one composite if statement.
Use meaningful names
Distinguish names in such a way that the reader knows what the differences offer
Use Pronounceable Names

Functions
Functions should be small. They should do one thing. They should do it well. They should do it only.
We want to read the code like a top-down narrative.
Use descriptive names for functions.
Switch statements should be buried deep in a low-level class and should never be repeated.
Use Descriptive names for the functions. The smaller and more focused a function is, the easier it is to choose a descriptive name.
For a function three or more arguments should be avoided. Ideal is zero arguments.
Flag arguments are ugly.
When a function needs more than two or three arguments then wrap the arguments into a class of their own.
Functions should either do something or answer something, but not both.
Extract the bodies of the try and catch blocks out into functions of their own.
Duplication may be the root of all evil in software. Many principles and practices have been created for the purpose of controlling or eliminating it.

Comments
Adding comments is not good as it shows your failure in writing an expressive code.
Either spend your time writing the comments that explain the mess you’ve made or spend it cleaning that mess.
Don’t Use a Comment When You Can Use a Function or a Variable
Comments are good only if they
Meant for legal documentation
Provide Informative value for a complex regular expression or formula
Explain the intent or business requirement
Clarify the third party library or API usage
Warn about consequences
Denote TODO tasks
Amplify the importance of something

Formatting
Code formatting is about communication, and communication is the professional developer’s first order of business
A team of developers should agree upon a single formatting style, and then every member of that team should use that style.
The reader needs to be able to trust that the formatting gestures he or she has seen in one source file will mean the same thing in others.
Vertical Size: Small files are usually easier to understand than large files are
Source file should appear like a newspaper article.
Horizontal Size:  Strive to keep our lines short

“Agile Tester: A new Dimension to QA Profile”

Agile Testers are often known as Quality Analysts (QA), Test Engineers and QA Leads.

How QAs work in an agile team: 

Most people, even in agile teams, treat QAs as a sub-role or a separate role in the team.
I believe this is an outdated conception. The difference between a QA and a Dev lies in the mindset.
QA profiles can be sorted into three categories: Business, Technical and Dev. I call these the “Three dimensions of a QA profile”. QAs can have either one of these different profiles, or combine them according to the level of knowledge they have in each dimension.

Business dimension: 

The QAs in this dimension are really business driven. They have skills that will help their team understand the business context given by the client. They have good communication skills that will facilitate the team to focus on the business problem during the entire project.
Extracting acceptance tests from clients is one of their specialties and BDD is one of the techniques they use to break down barriers between business context from the client side and technical context from the engineers side.
They pair with developers to huddle with the client before they play stories, in order to get enough information for the story to be played. During this period, they drive the pair to write acceptance tests to make sure that the story is tested before they move it forward.

Technical dimension: 

I relate to this dimension closely because the QAs here are really technical and have good analytically or programming skills. Ideally, there shouldn’t be any difference between a QA and a dev. In an agile team, everyone is an engineer and should be treated as such.
The technical QAs pair with devs to build the application without a technical gap. They support dev to foster good practices for clean code, design, and ensuring high quality product. They have a lot of knowledge on test automation and help the team choose the best test frameworks for the project. They are also responsible for making sure the team has a good test strategy in place.
The QAs in the technical dimension may also work on performance tests and security tests, depending on how advanced their knowledge on non-functional tests is. For performance tests, they work with the client and find out SLAs. They then create performance tests to measure and track the improvement done on the application related to these SLAs.
These QAs are also involved in security. They understand the business context from the client and analyze possible vulnerabilities. They then create tests to ensure that the possible vulnerabilities are being covered for a security mechanism.

Development dimension: 

How is Dev related to testing?
Short iterations help you track progress on a regular basis. It allows you to seek feedback regularly as well. Short iterations also help break the tasks down into smaller steps, thereby helping you make accurate estimates. Almost every project that I’ve worked on, we have implemented Continuous Integration. CI with a good test coverage is a must have for distributed teams. It helps you find the build issues immediately. Both teams endeavor towards a green build. CI is not about the tool, but more about the discipline and taking team responsibility to ensure a working application with every check in.
They introduce the practice of continuous delivery and help the team create a continuous integration pipeline in order to get faster feedback after each commit. This helps folks deploy new features to production more often, in some cases, they help by doing review, component tests ,functional tests before each commit goes directly into production right after successfully passing through the tests.

Definitions of health insurance terms Part-1

ASO (Administrative Services Only) – An arrangement in which an employer hires a
third party to deliver administrative services to the employer such as claims processing
and billing; the employer bears the risk for claims.
Coinsurance – A form of medical cost sharing in a health insurance plan that requires an
insured person to pay a stated percentage of medical expenses after the deductible
amount, if any, was paid.
¨ Once any deductible amount and coinsurance are paid, the insurer is responsible
for the rest of the reimbursement for covered benefits up to allowed charges: the
individual could also be responsible for any charges in excess of what the insurer
determines to be “usual, customary and reasonable”.
¨ Coinsurance rates may differ if services are received from an approved provider
(i.e., a provider with whom the insurer has a contract or an agreement specifying
payment levels and other contract requirements) or if received by providers not
on the approved list.
¨ In addition to overall coinsurance rates, rates may also differ for different types
of services.

Co-payment – A form of medical cost sharing in a health insurance plan that requires an
insured person to pay a fixed dollar amount when a medical service is received. The
insurer is responsible for the rest of the reimbursement.
¨ There may be separate co-payments for different services.
¨ Some plans require that a deductible first be met for some specific services
before a co-payment applies.

Deductible – A fixed dollar amount during the benefit period – usually a year – that an
insured person pays before the insurer starts to make payments for covered medical
services. Plans may have both per individual and family deductibles.
¨ Some plans may have separate deductibles for specific services. For example, a
plan may have a hospitalization deductible per admission.
¨ Deductibles may differ if services are received from an approved provider or if

received from providers not on the approved list.

Common Cross Browser Issues – Need to be tested

–Overlapping of Layout and Elements.
— Rendering Issues.
— Element out of Bounds or exceeding its container or not displayed.
— Inconsistency of third party plugins.
— Different Font Sizes across various browsers.
— Changing size of Elements across browsers.
— Alignment Issues.
— HTML Errors and broken pages.
— Browser Bugs Little known errors cause big problems.
— Inconsistent Popups and other message boxes across browsers.

— Page Loading time across browsers – are a few worth a mention.

Situational testing

Every organization, every system and every project is different, so every test project requires a unique approach. Situational testing offers various forms of testing and allows you to complete your testing projects flexibly, at the lowest possible cost and in the shortest possible time.

Among the forms of testing recognized within Situational testing are factory based testing, global scripting, session based testing, bug hunts, test tours and free style exploratory testing. Testers choose one or more of these test forms, depending on the organization, project and system. This way, Situational testing encourages you to approach testing in a flexible, structured and pragmatic fashion. With Situational testing you achieve better results than using a single specific approach.