My First Post      My Facebook Profile      My MeOnShow Profile      W3LC Facebook Page      Learners Consortium Group      Job Portal      Shopping @Yeyhi.com









Monday, July 8, 2019

Localization and Globalization testing

Globalization is the process of designing and developing applications that function for multiple cultures.
Localization is the process of customizing your application for a given culture and locale.
Globalization focuses your applications capibilities on users as a generic user-base, whereas localization focuses on subsets of users in a given culture or locale. So you can think of globalization as a strategic venue, where as localization is tactical.

Localization makes our software acceptable for a particular culture or locale that makes users to accept the adaptable software. For example Adobe Pdf is used in many languages. It is available in Japanese, Chines or even English :)
Localization testing checks how well the build is translated into a particular target language in given geaographic locale.


Globalization makes our software function in any culture/locale. The goal is to detect potential problems in application design that could hamper globalization. We work to make sure that the code can handle all international support.
For instance, we should support text data in the ANSI (American National Standards Institute) format. Unicode support should be tested. We should handle strings in each language. Right to left and Left to right scripts shall also be tested with.

Friday, July 5, 2019

Number of Bugs per line of code

An interesting read from the book "Code Complete" by Steve McConnell suggests following:

1. Industry Average: "about 15 - 50 errors per 1000 lines of delivered
code."

This is usually representative of code that has some level of structured programming behind it, but probably includes a mix of coding techniques.

2. Microsoft Applications: "about 10 - 20 defects per 1000 lines of code during in-house testing, and 0.5 defect per KLOC (KLOC refers to as 1000 lines of code) in released product (Moore 1992)."

This is attributed to a combination of code-reading techniques and independent testing.

3. Harlan Mills 'cleanroom development' technique: It has been suggested to achieve rates as low as 3 defects per 1000 lines of code during in-house testing and 0.1 defect per 1000 lines of code in released product (Cobb and Mills 1990).



What is Bug/ Defect Density?

It sometimes becomes important to calculate Defect Density for an Application or a system. Defect Density is the compactness of defects in the application. 


Applications are divided into functional areas or more technically KLOC (Thousand Lines of code). Thus, the average number of defects in a section or per KLOC of a software application is bug density.


How Is Bug Density Calculated?

Step #1: Collect the total no. of defects (for a release/build/cycle).

Step #2: Calculate the average no. of defects/Functional area or KLOC



Defect Density Industry Standard?


Well, this varies for every industry, application and every team. Manufacturing would have a specific threshold and it would be completely different for IT.

If it is high it shows poor quality. But it is, in turn, the seriousness of the individual defects that decide if the product is fit for use or not. Sometimes, many defects are just false indicators or are very low in severity and priority.

By the way, who would not like zero defect density. So, even though there is no specific standard, the lower this value, the better.



My experience:


Generally, a High severity (Sev-1) bug stops all use or significant use of the program. A severity 2 bug stops some users but not all. A severity 3 bug is inconvenient, has a workaround, or is an annoyance.

The most professional development organisation I ever worked in, which created software products for worldwide use, and had an enviable reputation for excellence, worked to an expectation of one severity 1 bug per 1000 lines of shipped code.

In my stints with working in Tata, Adobe Systems, Symantec and Expedia, I felt that bugs are unavoidable. They creep in - sometimes because of programmar's logical error and sometimes vulnerabilities in software/algorithm you are using. Also, sometimes you get bugs because of some novel use of hacking techniques.

In general, I observed during all these 12 years of working that there are following number of bugs, if you want to have strict answer on the basis of lines of code:

  1. 1 Sev-1 bug per Kloc
  2. 3 Sev-2 bug per Kloc
  3. 9 Sev-3 bug per Kloc
  4. 4 Sev-4 bug per Kloc



A few thoroughly tested application like a space-shuttle software - have achieved a level of 0 defects in 500,000 lines of code using a system of format development methods, peer reviews, and statistical testing. NASA, for instance, was able to achieve zero defects for the Space Shuttle Software, but at a cost of thousands of dollars per line of code. If people will die because there are bugs in the software then that kind of cost makes sense. Most projects simply cannot afford the same level of testing as NASA.


Tuesday, May 7, 2019

Git password expired. How to reset git authentication?


Sometimes, when you try to git clone the git repository or do any push or pull, it says:
remote: HTTP Basic: Access denied  fatal: Authentication failed for "~~yourRepositoryName"

The simplest reason is that your password is expired and/or changed externally. And, you need to change it for git to understand.

So, the question comes that How can you re-access your git repository or simpley put - How will you reset the password credentials.

Solution: Cheers, its simple.

Command:
git config --system --unset credential.helper

This will start resetting your credential manager stored wrong authentication password. Will ask for new password.
And, that's it. Enjoy.

Tuesday, January 22, 2019

How to undo a Git commit that was not pushed

To undo a Git commit that was not pushed, you are given a few major options:

Method 1:
Undo the commit but keep all changes staged
git reset --soft HEAD~; 


Method 2:
Undo the commit and unstage the changes
git reset HEAD~; 
or 1 git reset --mixed HEAD~; 


Method 3:
Undo the commit and lose all changes
git reset --hard HEAD~;


Method 4:
In case you just want to rewrite the commit message, you could use:
git –amend instead.



I will add following more helpful commands to check commit history, go back to a commit, and remove commits etc:
  1. git log
  2. git log --oneline to simplify the output:
  3. To test a specific commit: git checkout . You will be in 'detached HEAD' state. You can look around, make experimental changes and commit them, even create a new branch from here using git checkout -b new_branch_name
  4. To fix the detached head issue: git checkout
  5. Undo this commit: git revert . This will create another commit operation in github

Free Additional Tip:
To Undo a git add i.e. remove files staged for a git commit
1. git reset filename.txt OR
2. git reset *
After this you can add again the required files


Cheers :)
-Anwar Jamal Faiz


Read some of my other posts related to Git tricks below :

Saturday, January 12, 2019

Stylesheet Types : CSS, SaSS, SCSS - What do they mean

Ever wondered what is the difference between SCSS and Sass. More importantly, how are they different from CSS.

To start with let me point out that Sass is a language or a pre-processor that makes CSS more powerful with variable and math support. It provides syntax advancements. Style sheets in the advanced syntax are processed by the program, and turned into regular CSS style sheets. However, they do not extend the CSS standard itself. You can do operations like additions and introduce variables in CSS using Sass.


The SCSS is also called Sassy CSS. This is an extension of the syntax of CSS. This means that every valid CSS stylesheet is a valid SCSS file. Files using this syntax have the .scss extension.


The Saas format described earlier is also known as the indented syntax. It provides a more concise way of writing CSS. It uses indentation rather than brackets to indicate nesting of selectors, and newlines rather than semicolons to separate properties. Files using this syntax have the .sass extension. However, as already told that all this works only with the Sass pre-compiler. In the end what is created is simple CSS. It is not an extension to the CSS standard itself.



The Sass .sass file is visually different from .scss file, e.g.

Example.sass - sass is the older syntax

$color: red

=my-border($color)
  border: 1px solid $color

body
  background: $color
  +my-border(green)

Example.scss - sassy css is the new syntax as of Sass 3

$color: red;

@mixin my-border($color) {
  border: 1px solid $color;
}

body {
  background: $color;
  @include my-border(green);
}
Any valid CSS document can be converted to Sassy CSS (SCSS) simply by changing the extension from .css to .scss.