Why NoSQL databases?

Before moving on to “Why” these NoSQL databases, let’s consider “What” are these NoSQL databases....

• Simply the NoSQL databases are not using SQL and they are not relational. 
• Second, NoSQL is designed for distributed data stores for very large scale data needs. 

NoSQL databases provide a simple, lightweight mechanism for storage and retrieval of data and they provide higher scalability and availability than traditional relational databases. 

These NoSQL databases usually do not use a 'SQL' approach for storing data. In simple terms they do not store the data in the form of “tables”. On the other hand they use looser consistency models to achieve horizontal scaling (that is “scaling up”) and higher availability (as the database is distributed in several commodity computers). 

These no SQL databases are commonly used by prominent internet companies such as Face book, Google, Amazon which have challenges in working with large volume of data and the typical RDBMSs cannot handle.

So in these companies, data is partitioned or distributed among several machines. Then the performance and size related limitations can be handled efficiently. As the data is distributed among several machines, traditional “join” operations cannot be used. However we could be able to obtain a distributed, fault-tolerant architecture. 

So now let’s move on to why these No SQL databases....

#1.  Flexible scaling

In traditional databases, the database administrators relied heavily on scaling up the database. That is buying bigger servers as database load increases. But in NoSQLs they can rather use scaling out. That is the distribution of the database across multiple hosts as the load increases.

RDBMS do not scale out easily on commodity clusters. But these NoSQL databases are designed in a way, so that they can take the advantage of new nodes. And also they are designed to work efficiently with low-cost commodity hardware.

#2. Can handle lots of data

The companies which are overloaded practically with data volumes cannot use RDBMSs to handle their data. But NoSQL databases can handle a large amount of data.

#3. Requires less management

RDBMS systems can be maintained only with the support of expensive and highly trained DBAs. But NoSQL data bases can be maintained with less management as it uses automatic repair, data distribution, and simpler data models.

#4. Economic

NoSQL databases have the capability to use clusters of cheap commodity servers to manage high data and transaction volumes. Therefore it is economic than purchasing high capacity single servers.

#5. Flexible data models

NoSQL databases such as Key Value stores and document databases allow the application to store virtually any structure it wants. But even the minor changes to the data model of RDBMSs need to be carefully carried out as it affects the whole databases.

Test Automation

When we think about test automation what exactly coming to our mind is running test cases with out human intervention.But test automation is not simple as that.

In simple terms, test automation is using special software other than software being tested, in order to control the execution of tests and to carryout the comparison of actual outcomes to predicted outcomes.

In test automation there need to be a good test code which is written by a tester at the first place. One of the biggest mistakes being carried out by the people who automate tests is that they do not try to maintain the quality  of the test code. They sometimes try to write tests and finish them as soon as possible to save their time. But it is necessary to maintain the quality of the test code as they maintain the quality of product software. Otherwise what happens is;

• The test code writers will have to spend most of their time maintaining their test code, if they have done writing test cases superficially.

• And the other thing is that they will also have to go on investigating failed tests.   

Ultimately the test code automation will never be able to reduce the time of writing and executing the test cases and it will be a futile method of testing.

Usually the expected amount of automating tests should be 100%  from the tests that any tester has. The automated tests resides as binaries (such as exe or dll) or as scripts (Java Scripts, Quick Test Pro, Power Shell, python). So when executing the tests these names are called for execution.

First of all we need a  place to run the tests.The place where all the automated tests are going to run is called the Automated Test Lab. Several machines can be used in the lab to run test cases in parallel.

After that there should be a consideration on "how to distribute the test cases among the machines we have in test lab". We can allocate a separate set of machines to do this task. These machines are named as test controllers. Test controller machines are provisioned with test cases by a "Test case manager/ DB"

After finishing the execution of the tests by the test execution machines in the automated test lab, they signal the test controller about their completion.

Ultimately the test results from test lab are taken for analysis and report generation. So this is all about test automation. 

  

" Bug Management " - Can we take it for granted?

 An insight to Beautiful Testing Book - Chapter 6

Chapter 6 for beautiful process starts with a bizarre situation. One of the Harvard University's engineering note books has a bug cello taped to it and have a interesting story of the first actual bug. 

Although the note is very very old and found in a museum, the bug report contains two important details that need to be there in every bug report. They are as bellows;

1. Mentioning the root cause to the bug report.
2. Associating the bug closely with the test procedure.

The reason for demanding the attachment of  root cause to the bug report has a very simple consideration.  That is for the others to benefit from it. So when there are different implementations from a single product done by different set of people then they can eliminate the common bug and improve their implementations if they are known to the root causes of the bugs their product has.

Most people do not consider bugs as important. But there are situations where people's lives rely on the correct operation of software. For an example the wrong behavior of a scanning machine or a aeroplane may lead to disastrous situations. Therefore it is important to consider defects of software seriously rather than superficially laughing at the words "bug management". That is why bug/defect management is so important.

The book says that the very initial thing to do in defect management is identifying the defect. For that it is important to consider some vital aspects of a defect. Some of those aspects are; Who,What, When and Where.

1. Who

A good defect tracking system should tack some important details, such as who logged the defect, who fixed the defect and who verified that the defects have been fixed. Ultimately the defect is considered.

2. What

A bug report should consist of the bug's characteristics and also the conditions for the bug to re occur another time. So that the fixing, verification and also the elimination of the bug from newer releases are made easy.

A bug report should essentially posses following details.

• Description - A summary of the bug.
• Detailed Description - Sufficient details to re occur and see the bug which is reported.
• Priority - Importance of the bug.
• Severity - The impact of the defect.

Priority and Severity..... Confused?

For an example lets say that we have developed a web application for a customer. And it's some of the content could not be properly displayed on the customer's standard web browser. Then the bug is of high priority. Lets say the same content is not displayed in an archaic version of the web browser that they are using then we consider the bug is of low severity.

3. When? 

Defect might found at different stages of the software development life cycle. Some bugs may found at Quality Assurance testing and some may found after releasing the product to the customer. If the bug is found at the latter stage then the cost of fixing the bug is very high. So that it is necessary to identify and fix the bugs at the earlier stages.

4. Where?

Some times the bug may found at the public open source defect tracking system. Then there will be a problem for the developers or Quality Assurance to find the code base that the defect lies in.

For a developer it is very easy to find the source code where defect lies in, if they are known about a defect. But for an end user or a support person always the defect they found is existing in the product or the distribution. Because they are unaware of the source code of the product. They can not relate the defect they  found of the product to the actual code base. So that the communication of the defects will not flow very effectively. This is a very big disadvantage.

So that there exist a good solution for this problem. If mentioned in simple terms, we can use the  Original defect repository and extract some lesser information about a bug and place it in a local mete database. And create a key which links the local meta database to the original defect database. So that what happens is the public community can interact with the local meta bug database and apply tags to the bugs and they are tracked. Similarly the company Quality Assurance team can interact with the original defects database and this will provide an effective bug communication methodology. The bellow diagram will provide some insight to defect information communication.

XMPP Testing

Before proceeding to XMPP testing, it is better to get an idea about XMPP.
eXtensible Messaging and Presence Protocol is a;

• Open source
• XML based networking protocol
• Used for real time communication

XMPP is applied in following ares.

• Instant Messaging
• Social Networking and Gaming
• Multimedia (audio and video)
• Micro Blogging

How XMPP works,

• XMPP network consists of servers and clients 
• The job of XMPP is to route small packets (stanzas) of XML between entities in the network.
• Stanzas are of three types ;

                   Message Stanzas - For sending messages

                   Presence Stanzas - For Broadcasting

                   Info/ Query Stanzas - For inquiring. 

• There is an ID called JabberID which is given for each entity in the XMPP network.

Testing XMPP

In testing XMPP what we are doing is testing the functionality of XMPP protocol. Some of the concerns  in functionality testing are as follows;

• Testing whether the client can respond correctly to incoming requests.
• Does client the send right request at the right time?
• Can client handle a specific response on a request?

Testing Request Response Protocols

Unit testing is chosen as the most suitable type for testing the XMPP functionality. Because XMPP's request response rules are local to one class.

When a client creates an XML stanza then it is constructed a Structured document through DOM (Document Object Model) then it is serialized to a textual XML and sent through the network. 

As there can happen slightly varied serialization versions and if the serialized packets are analysed, then there is a possibility for this variations in serialization to break the tests. 

Therefore response is verified by checking the DOM form rather than the serialized textual XML.

An Introduction to MongoDB

MongoDB is a Data Base Management System for web applications and Internet Infrastructure.

It is a scalable, high performance, open source NoSQL database written in C++.

It is a very attractive database. Because of it's intuitive data model.

It also has the capability to represent rich hierarchical data structures. as it has a document data model instead of a relational data model.  
One other instance for a DB using a Document Data Model can be mentioned as Apache's CouchDB.

The disadvantages of relational data bases are not a problem to document based databases. Some of the disadvantages of relational databases can be mentioned as follows;

• Lots of complicated multi-table joins are there in relational data bases. 
• Need to write complicated queries with lot of joins to retrieve data.

If we use a database which has a document data model such as MongoDB, then we have the capability to work with data base objects as a whole rather than working with lots of different tables with joins to each other.

For an example lets say we maintain a "Plantations" database.

In a relational database we have to deal with fertilizers for each plant at each stage, climatic conditions, structural configurations, images, suppliers etc. Those will be different tables in our relational database. But if we deal with a document based database, then we'll have the ability to deal with different plantation objects as a whole rather than considering each and every table separately.

As today's developers are mostly using object oriented languages for developments then it will be very effective to use Object Oriented Databases, so that their objects can be directly mapped to their databases.

The other feature we can have from MongoDB is adhoc querying. Although relational DBs support this, not all DBs support this. In adhoc querying  it is not necessary to define in advance about the types of queries the system will accept.

More over MongoDB supports secondary indexes. Secondary indexing is something like having some piece of information for indexing other than a primary key. For an example lets take a "Student" database and we need to search students using their last name. So that the Student_ID here is the primary key and the last_name will be a secondary key for indexing. B tree is the structure for MongoDB's secondary indexes.

The other key features of MongoDB can be mentioned as Replication support, support for speed and durability. MongoDBs have journals which being defaultly enabled, so that the data files can be recovered.

MongoDB supports scalability. Unlike vertical scaling done by single node expansion through hardware, it supports horizontal scaling where it provides the capability to distribute the database across multiple machines.

There are some advantages of scaling horizontally.Some of them can be mentioned as bellows;

1. Ability to get the use of commodity hardware.

2. Cost for hosting total data set can be reduced.

3. Reduce the consequences of failure.    

MongoDB has a range based partitioning method. It is called Auto Sharding. In here what happens is that the data is automatically distributed among the network nodes. 

MongoDB's core server and tools can operate on Mac OSX, Windows and Linux OSs. It's Java Script shell can be used to administer the database and manipulate data.

So ultimately MogoDB can be selected over other data bases due to its high scalability and fastness.

    

  

Surprizing Facts in "How Google Test Software"

There are quite surprising facts in "How Google Test Software". Some of the surprising and need some thought on type of facts are related to the 'Fatal Flaws in Google’s Process".

What are the things that google find fatal and others don't in their process and why they find them fatal?

• The first fatal flow that none of us finds fatal when we look through traditional testing is that if we ask a developer what he is doing about quality, then his answer often is “testing”. 

But book says that quality is not lying in testing. It has to be embedded to the product it self. As the developers are free to think that the tests are going to be done by testers and should not be considered as a burden to them, and then what happens is that they start to reduce their testing. This should be avoided.

• The second fatal flaw is that the developers and testers are separated and they are walled by different organizations at Google. Which is sometimes a prominent feature in most of the other organizations.

Mostly the testers who work at google are identified with their job and not the product that they are working on. But it is said that, a sign of a healthy organization is when the employees say, that they are working on a particular product, rather than telling their designation. Development and testing should not be separated  If it happens then a role-based association is created and testers find it really difficult to assign themselves to a particular product.

• The third fatal flaw is that, the testers often embrace test artifacts than the software or the product they are creating.

Counting the number of bug reports by a test engineer and being happy over them is not the thing to be in testing. It is like something focusing more on process than the product. The things which are being done need to be directly associated with a value.

• The fourth fatal flow is that almost always the users find problems after releasing the products, even though there are lots of tests had been carried out before releasing.

In here what needs to be considered is that ensuring quality is every one's responsibility. It is not confined to people who are assigned for testing.

And the other surprising facts are related to the future of employees at Google, which will probably rewind the future of SETs TEs and Test Directors/Managers in other IT related organizations in the near future.

It is hoped that there will be no future SETs. How is it going to be managed?

They can be considered as software engineers as a whole. So what happens ultimately is that the 'testing' task is equally distributed among all the developers of the company. Then the development and testing both is done at the developers side. Ultimately all can work as one team.  



TE's tasks will be changed in the future. How is their life cycle being replaced?

In the future TE's job will be something different with respect to the present job of them. In future dogfooders, early adopers and crowd testers etc. will be involved in testing and they will be giving feedback about the system. Then what TEs will have to do is seeing and evaluating whether all these things(feed backs etc) covered the project in testing aspect. He will be involving in calculating the risk impacts, adjusting the test activities like things rather than involved in test creation and execution types of things. So ultimately they will become as specialists or managers for testing.

What happen to Test Directors and Managers in the future?

There will be fewer Test Directors and Managers involved with Google in the near future.   

So ultimately these things will be very surprising without the explanations for them. 

Different types of tests done in the 'Clam Antivirus Project'

Compatibility Testing

Why compatibility tests?

Compatibility test makes sure that the software applications and hardware devices function correctly with all relevant operating systems, platforms, architectures  and with computing environments.

1. A compatibility test is a kind of  Environment Test.

2. 'Buildbot' is a good tool which can be used for compatibility testing.

For antivirus software it is needed to do compatibility testing for both software and database as they are expected to be reliably run on different computer platforms. Therefore compatibility test is an unavoidable test for anti-virus software.   

Performance Testing

In simple terms, performance testing is a type of testing which is intended to determine the responsiveness, throughput, reliability and scalability (if necessary) of a system under a given workload.

Antivirus software need to handle hundreds of thousands of virus signatures and hundreds of file formats, at the same time they must perform all the tasks fast enough to, not to fail the computer system. Therefore performance testing is a must for antivirus software. 

‘Profilers’ are some special tools designed for; code execution performance analysis. It is said that even with profilers, it’s not an easy task to identify parts of the code that can result in slowdowns. One of the reasons for this is; that a code with problems can be hidden in routines that are not called frequently.

Stress testing can be done as a part of the performance testing. Stress testing helps to discover potential problems with stability, robustness, and general efficiency of the software.

User Acceptance Testing

User Acceptance Testing (UAT) is performed by the users of the system to certify the system with respect to the requirements that was agreed upon or it to certify that it is what they wanted.

The usability and user acceptance testing is the last step before giving out the final product.

Advantages of UAT

1. It is able to provide many useful suggestions to the system being developed

2. Can help to verify companie’s development ideas

3. The people who contribute help the project as the best black box testers. 

Methods of User Acceptance Testing

1. Opinion polling 

 Discussions can be held and opinions can be taken from the public about the major changes, so that the complaints can be reduced.

2. Candidate releasing

As a good practice, the releasing of candidates is not done for mission critical   applications. Otherwise the alpha or beta releases of the product can be thrown to use.