Risk based Testing

Often all other activities before test execution are delayed. This means testing has to be done under severe pressure. It is out of question to quit the job, nor to delay delivery or to test badly. The real answer is a prioritization strategy in order to do the best possible job with limited resources.
Which part of the systems requires most attention? There is no unique answer, and decisions about what to test have to be risk-based. There is a relationship between the resources used in testing and the risk after testing. There are possibilities for stepwise release. The general strategy is to test some important functions and features that hopefully can be released, while delaying others.
First, one has to test what is most important in the application. This can be determined by looking at visibility of functions, at frequency of use and at the possible cost of failure. Second, one has to test where the probability of failure is high, i.e. one may find most trouble. This can be determined by identifying especially defect-prone areas in the product. Project history gives some indication, and product measures like complexity give more. Using both, one finds a list of areas to test more or less.
After test execution has started and one has found some defects, these defects may be a basis for re- focussing testing. Defects clump together in defect-prone areas. Defects are a symptom of typical trouble the developers had. Thus, a defect leads to the conclusion that there are more defects nearby, and that there are more defects of the same kind. Thus, during the latter part of test execution, one should focus on areas where defects have been found, and one should generate more tests aimed at the type of defect detected before.


Please visit Software Outsourcing
iPhone Application Development

Software Inspection

When an old idea is a good idea that improves to become a better idea, we should all want to benefit from that evolution. Software Inspection was a good idea when started in 1972. Inspections have continued to provide a quick return on investment and perhaps one of the quickest for all the methods and processes available to the software practitioner.


So basically, why do we need Inspections? We need Inspections to remove software defects at reduced cost. Inspections enable us to remove defects early in the software life cycle, and it is always cheaper to remove defects earlier than later in the software life cycle. Its important to note that Inspections are a way to remove defects at a lower cost, not a way to prevent defects from occurring.

Our objective with Inspections is to reduce the Cost of Quality
by finding and removing defects earlier and at a lower cost.
While some testing will always be necessary, we can reduce the costs of test by reducing the volume of defects propagated to test. We want to use test to verify and validate functional correctness, not for defect removal and associated rework costs. We want to use test to prove the correctness of the product without the high cost of defect removal normally seen in test. Additionally we want to use test to avoid impacting the users with defective products.
So the problems that must be addressed are:
Defects are injected when software solutions are produced
Removal of defects in test is costly
Users are impacted by too many software defects in delivered products
With Inspections we can manage and reduce the effect of these problems.

Please visit Software Outsourcing
iPhone Application Development

Basics of Software Design

Real software runs on computers. It is a sequence of ones and zeros that is stored on some magnetic media. It is not a program listing in C++ (or any other programming language).
A program listing is a document that represents a software design. Compilers and linkers actually build software designs.
Real software is incredibly cheap to build, and getting cheaper all the time as computers get faster.
Real software is incredibly expensive to design. This is true because software is incredibly complex and because practically all the steps of a software project are part of the design process.
Programming is a design activity—a good software design process recognizes this and does not hesitate to code when coding makes sense.
Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for additional design effort. The earlier this occurs, the better the design will be.
Since software is so cheap to build, formal engineering validation methods are not of much use in real world software development. It is easier and cheaper to just build the design and test it than to try to prove it.
Testing and debugging are design activities—they are the software equivalent of the design validation and refinement processes of other engineering disciplines. A good software design process recognizes this and does not try to short change the steps.
There are other design activities—call them top level design, module design, structural design, architectural design, or whatever. A good software design process recognizes this and deliberately includes the steps.
All design activities interact. A good software design process recognizes this and allows the design to change, sometimes radically, as various design steps reveal the need.
Many different software design notations are potentially useful—as auxiliary documentation and as tools to help facilitate the design process. They are not a software design.
Software development is still more a craft than an engineering discipline. This is primarily because of a lack of rigor in the critical processes of validating and improving a design.
Ultimately, real advances in software development depend upon advances in programming techniques, which in turn mean advances in programming languages. C++ is such an advance. It has exploded in popularity because it is a mainstream programming language that directly supports better software design.
C++ is a step in the right direction, but still more advances are needed.

Visit Software Outsourcing
iPhone Application Development

Best Code Development Practices-V

Further continuing with the common PHP software development guidelines. We discussed
USAGE INSTRUCTIONS/TIPS and SECURITY. Let us now discuss some of the other guidelines.


1) MYSQL ADMINISTRATION (RECOMMENDED): Following guidelines may help secure your application further

a) Avoid using root user for database administration as well as programming. Instead for every new database, create 2 or more users with specific permissions. For example

i) One user with only SELECT permissions to the database if no modification activity is planned. Add other privileges as required.

ii)If your project has Admin are then create another user with SELECT, UPDATE,INSERT, etc privileges.





b) The password for any of the users MUST NOT be easy to remember. These must have alphanumeric and at least 8 character long.

c) Password field in any of your table should not store password as clean text. Instead encrypt the data.

2) FILES AND FOLDERS (RECOMMENDED):
Some of the important points to remember are

a) CONFIG: Every project has the requirement to use global variables or configuration settings to be used in one or more files. For example, database connection, file upload folder path, etc or anything that has to be used in more than one file.

Use a config file to store all such information. Also to be noted that front-end and admin config files MUST be maintained separately.The name of the config file should be either config.php or configuration.php

b) README: Each project should maintain a README file (README.txt) containing various instructions including installation/ deployment, third-party tool dependencies,special instructions, file/folder permissions, cron configurations, etc.

c) CHANGE LOG: All projects should maintain a history file (CHANGE_LOG.txt) containing alterations done after deployment/installations or across different versions. The format should be as below yyyy-mm-dd developer_name - File Name.ext:
change description containing change made along with approx. location of change
in file - another_file.ext: approx location should not indicate line number instead function name, declaration, condition, etc. yyyy-mm-dd another developer - yet_another_file.ext: latest change comments should be towards bottom of the file

d) Folder structure: Each project must have some bare minimum folders namely

i) images folder to store pictures, logos, icons, etc.
ii) styles folder to keep project CSS files
iii) script folder to keep you JavaScript files



iv) includes folder to keep all included files
Also, do not keep all files in a project in a single folder, instead create
folders/subfolders based on their character,section or module as applicable.

e) Security by obscurity: Remember as long as a file is obscure, it is secure.

i)If there is Admin area in your project, avoid naming the admin folder as admin.
Instead use a more complex name.Most hackers locate admin folder first to start hacking activity.
ii)Avoid naming files such as change_password.php, connection.php, conn.php,edit_profile.php, delete.php, etc. These are highly predictable filenames
allowing hackers to try and locate these files on your server and start with them to find security holes.

iii)Do not use .inc extensions for any PHP files whether static in nature. Instead, all files MUST have .php extensions.

iv) Also, do not include/use files from admin folder into front applications not even the connection string.

v) Do not give any of the webroot folder or file with WRITE permission. Any WRITE permissions MUST be to a folder only with difficult to guess name.

vi) Do not upload any temporary/back-up files to the server.

vii) Each application MUST have a 500-INTERNAL SERVER ERROR page to hide error details to website visitor.

viii) For websites there may be a custom PAGE NOT FOUND error page.

ix) Optional custom error pages can trigger emails when an error occurs.

Please visit Software Outsourcing
iPhone Application Development

Best Code Development Practices-IV

As we have discussed earlier about PHP CODE LAYOUT and SQL CODE GUIDELINES, we continue discussing the common PHP software development guidelines.

1) USAGE INSTRUCTIONS/TIPS (RECOMMENDED)

a) Include: Use include_once unless include is architecturally required. Use include_once where output is not critical to the subsequent business logic within the page. In other words, if there is an error in the included file, the rest of the page will execute.

Static files containing HTML, CSS, etc can be called using include_once.

b) Require: Use require_once everywhere unless require is architecturally required.Use require_once where file called within page is critical for the rest of the page or business logic.Code files such as a class file, database connection file, etc MUST be called using require_once. Because, if there is an error loading external file, the rest of the page will not execute.

c) Single & Double quotes: In strings, single-quotes inform PHP parser that everything inside is character. So even a variable name inside single quotes is printed as is rather than its value. This also saves parser time. So use single-quotes when strings don’t have variables embedded.Unlike single-quotes, double-quotes allow PHP parser to scan entire string for variables,which consumes more parser time. So use them when really required. For example SQL queries can be embedded in double quotes.

d) Braces: Braces should be used even at places where they are optional. When using braces with control structures or statements, keep them in the same column. For example,



for(i<0; i<=n; i++)
{
&
}


if (a< b)
{
.....
}
else
{
if (x == 1)
{
.....
}
}

In other words, (1) braces must be the only character in their line. And, (2) starting & ending braces (within the same control statement, loop or condition) must be vertically Confidential aligned.

e) Square brackets: As a practice, anything inside square brackets should be inside single quotes. Apart from being good programming practice, there is also execution speed advantage. For example, Using $row[‘id’] is much faster than using $row[id].

f) Function: As far as possible, create functions within classes.

g) Classes: There must be one class per file.

h) Declaration and Scope of variables

i) Global variables: should be defined in a common include file

ii) Module level variables: should be defined within a module.

iii)Page level variables: should be defined at the beginning of the page (This needs special care as declaration of variables such variables in random manners renders code unreadable and prone to errors.)




i) Hard coded URLs and file paths

i) Use relative URLs as far as possible to improve portability
ii) If still absolute URLs are required create variables for all paths if possible in a single include file.

AVOID USING HARD CODED PATH EVEN IF IT OCCURS ONLY ONCE IN CODE.

j) Mixing of PHP and HTML (echo vs embedded HTML)

i) Avoid mixing of php code and HTML as much as possible. Mixing should be at most for loops and display conditions unless unavoidable

ii) Where mixing code and HTML keep HTML blocks intact.
e.g. Incorrect usage:

<?php do while (a < 100)
{
?>




<?php
end while
echo “”;
?>

In a very simple scenario above any dream weaver will display invalid tags, rendering page useless for designer. The point here is that if start of table is in HTML so should be end as below:





<?php
do while (a < 100)
{
?>



<?php
end while
?>

<?php echo some content ?>

k) Function Assignment: In a loop if you are checking for a condition that involves a function, it is always better to assign the function value to a variable and check against the value. This is prevent the overhead of the function executing everything during the cycle of the for loop. Like below:

Incorrect Usage

for($i=0; $i < count($array); $i++)
{
echo ”test”;
}

Correct Usage

$count_check = count($array);

for($i=0; $i < $count_check; $i++)
{
echo ”test”;
}





2) SECURITY (REQUIRED):
Follow any of the following to sanitize variables from passing them into SQL queries.

a) Use mysql_real_escape_string() or mysql_escape_string() to escape special characters in a string prior to passing it in a query.

b) Also use htmlentities() and html_entity_decode() to prevent HTML injections from open form fields.

c)Do not directly pass server variables like GET, POST, FILES, SESSION, ENV, SERVER,REQUEST, etc into SQL queries. They all MUST be initialized and sanitized.
For example,Correct method $id = trim($_GET['id']);

if (is_number ( $id ) )
{
SELECT first_name, last_name FROM users WHERE user_id =.$id;
}

Incorrect method
SELECT first_name, last_name FROM users WHERE user_id = $_GET['id'] ;

Please click Software Outsourcing
iPhone Application Development

Best Code Development Practices-III

The objective of this document is to provide common PHP software development guidelines.

1) CODE LAYOUT (REQUIRED)

a) Header: Every file created in a project must have a comment header. This must contain the following
/**
* File Name:

* File objective:

* File Description:

* Created by:

* Created on:

* Last Modified by:

* Last Modified on:

* Included Files: Files included in this file

* Included In: Files where this file is included

*/

b) PHP Code tags: Following the following format

This is correct
&
?>

These are incorrect
&
?>



<% %>

c) Indenting: For code indenting, use 4 spaces instead of tabs.

d) Linefeeds: Make sure that you PHP editor adds \n whenever you press enter to create a
new line. Most Windows based editors add \n\r by default.

e) Inline Comments: Write inline comments where code block objective is not clear. As a
thumb rule, write inline comments when any of the following is true



i) When variable name, class name or function name do not tell anything about their
purpose.

ii) When a decision is being taken. For example, If-else, switch-case, etc.

iii) When a regular expression is being used

iv) When modifying/replacing an existing code.

The format for inline comments should be as below

/*
* MODIFIED BY developer_name ON dd/mm/yy
* describe change here briefly yet clearly
*/
Also, keep the original code as is, however, commented

2) SQL CODE GUIDELINES (REQUIRED):

a) SELECT: Avoid using * in SELECT queries since this delays the results. Instead give names of fields.
For example, SELECT first_name, last_name, email FROM users; is correct,
but SELECT * FROM users; not;

b) JOINING CONVENTIONS: When multiple tables are involved,always create table aliases for clarity. Keep table aliases short and close to.
For example SELECT cmp.company, emp.first_name, emp.last_name_first FROM
tbl_company AS cmp, tbl_employee AS emp
WHERE cmp.company_id = emp.company_id AND cmp.company = '" . $company. "' ORDER BY emp.first_name ASC;
c)QUERY FORMAT OPTIONS:
Follow any of the following query formats for more readable query format.

i) $sql = SELECT first_name, last_name, email FROM users WHERE status=1 ORDER BY first_name ASC;



Notice that main SQL keywords come prior to anything else in any row.
ii) $sql = “SELECT first_name, last_name FROM users WHERE status=1”;

Click Software Outsourcing
iPhone Application Development

Best Code Development Practices-II

The objective of this document is to provide common PHP software development guidelines


1) NAMING CONVENTIONS FOR FORM FIELDS (REQUIRED):

Following guidelines should be used to name various field types in forms.
a) Text Fields / Text Areas should be named as txtFirstName
b) Buttons should be named as btnSubmit
c) CheckBoxes should be named as chkPrefLang
d) Radio buttons should be named as optGender
e) Drop-down should be named as selCountry
f) Hidden Fields should be named as hdnStatus
g) Labels should be named as lblName

2) NAMING CONVENTIONS FOR SQL (REQUIRED)

a) For queries: As a convention, all SQL keywords (e.g. SELECT, FROM, ORDER BY, etc) should be all in UPPER CASE. For example,
SELECT firstName, lastName FROM users ORDER BY firstName ASC;

b) For Table/Fields: The table & field names should follow the camel case conventions. For example, i) employeeData for table name
ii) firstName for field names

c) SQL STRING VARIABLE NAME: Name the SQL Queries as per camel case conventions.
$sqlSelectEmpName = “ SELECT firstName, lastName FROM users ORDER BY firstName ASC ”;

Click Software Outsourcing
iPhone Application Development

Best Code Development Practices for PHP Developers-I

Providing some of the common PHP software development guidelines:

1 ) NAMING CONVENTIONS FOR FILES (REQUIRED):
All files including code, images, css,scripts, etc must be named in lowercase with multiple
words separated by underscore.Filenames must NOT contain any special characters.For example,
hello_world.php or hello.php are correct, but helloworld.php,helloWorld.php and HelloWorld.php are
not.
i) Include Files: The name of include files should be as below hello_world.inc.php
ii) Class Files: The names of Class files may be as below hello_world.class.php
Note that file extension is still .php.

2 ) NAMING CONVENTIONS FOR PHP ELEMENTS (REQUIRED):
Follow the guidelines given below to name elements during PHP code development.
a) Use camel case for all the naming across elements whether variables, functions, classes,etc.
b) Each element name should be preceded by its nature/the type of content it is supposed to
hold. This prefix should be lowercase, and different from the actual keyword being used to
declare/define the element in question
c) The name should be intuitive and clearly express the purpose of the element however not
redundantly long Some of the examples are given below fro quick reference.
i) Variables should be named as intCount for Integer type of data floatTotalSalary for
float type of data
ii) Arrays should be named as arrEmpData
iii) Classes should be named as clsEmpData
iv) Constants should be named as cnstMaxSalary
v) Global Variables: As an exception, global variables should be named as below.
_TOUT_COOKIE for global variables.
Please note that underscore as prefix and all uppercase characters.

To be continued.....

Contact us for Software Outsourcing and iPhone Software Development

iPhone Insurance

iPhone insurance may help you save money, Like all insurance.
Spend and risk
Buying an iPhone is usually a great experience. You've perhaps waited some time to get one and possibly saved up. Opening the box, admiring the iPhone, learning how to use it - these are all the enjoyable aspects of owning this great device. The one part of buying it you might not have enjoyed as much was paying for it.
Unfortunately, if you don't have iPhone insurance, you may find yourself repeating the not so pleasant payment part again.
It hopefully goes without saying that iPhones are vulnerable to a number of risks that may end up with you reaching for your checkbook or credit card. These risks include the phone:
- being stolen;
- breaking down outside of manufacturer's warranty period;
- being destroyed in an accident.
The role of insurance for iPhones
No insurance can stop any of these things happening to you but what it can do is to help with the financial and logistical costs involved.
The insurance provided for iPhones typically:
- helps you logistically by replacing your iPhone within 48 hours of a claim being accepted;
- also helps minimize the inconvenience by offering contact list backup facilities;
- covers insured risks wherever they arise in the world;
- protects against breakdown outside of manufacturer's warranty;
- covers accidental destruction including where this involves liquids;
- will cover theft risks - providing your iPhone has not been left unattended.
What's suitable?
Only you can decide which form of iPhone protection is most suitable as this depends a lot upon your own personal requirements and circumstances
It's also typically a good idea to look carefully at the insurance provider's prevailing terms and conditions as all insurance comes with certain constraints of cover and statements about your obligations in terms of making a claim.

For more details visit iPhone Software Programming

Microsoft and Mobile

 

I just read this article about Microsoft and the Kin on the Nytimes.   This reminded me of the Tmobile HTC phone I had 7 years ago with the Window OS on it (I forget which version).  The OS used to crash a lot but the phone was way ahead of it times.  If only Microsoft had put some thought and resources behind that, it would have been owning the consumer and business mobile space.  But Microsoft did not make any improvements even as Palm, the only viable competitor died.  Leaving this space open for Apple when Steve Jobs finally decided to step in.

The same goes for the Tablet PC.  What a great idea.  And One Note was the perfect Application for the Tablet.  But Microsoft messed that one too….until Apple stepped in with the iPad. 

All of us here at A-1 Technology are rooting for Microsoft as we know the company can be a formidable competitor once it gets it priorities right.  Better competition in the Mobile and Tablet market will be better for everyone.  Wishing Microsoft the best!

Microsoft Calling. Anyone There?

Technorati Tags: Microsoft,A-1 Technology,Apple,Android,Mobile

LG Just launched it own App Store

 

Not to be outdone by Apple and Google, LG just launched its app store.   Interesting, the US is not supported here.  Not sure why!

Story Courtesy - JKontherun

Technorati Tags: LG,Apple,Iphone