Monday, April 21, 2014

What software “Quality” stands for..?

The concept of “Quality” may be different for random people, each one of them may supply a different answer for the following question “What software quality stands for..?”
The main reason for that issue is probably relevant for the position and concepts people have, for example:

The user: for the ordinary user “Quality” will be determined based on the expectations he had from the software specifications/Requirements, if the software meets the user expectations the “Quality” will be with higher level, from the other hand if the software failed to answer the user expectations the “Quality” will be at a lower level.

The Company: for the ordinary company the “Quality” is measured based on the development process against the predefined requirements/Specifications. If the software developed without reflection to the base criteria, then, the quality will be at lower level, from the other hand the “Quality” factor will be greater when the development process reflects the predefined Requirements/Specifications.

The Value: from the value perspective, the quality is based on the basic thing called ‘Money, from this it’s very easy to understand that the quality is determined based on the price that the company gains when selling the software to her clients.

As you can see, you cannot put single definition for “Quality”, different people will see it from a narrow point of view and evaluate the “Quality” based on completely different criteria.

Static Vs. Dynamic testing - Objectives

Objectives of Static testing

To really understand the objective of “Static Testing” you must first understand the crucial point of finding bugs early as possible and the direct impact it has on the entire procedure of Requirements, Design, Developing and Testing in the factors of time and money.

Now, you all know that every bug that found has the three usual steps of the investigation, fixing and testing, this procedure is a great example of how the company can lose time and money, but the real problem occurs when those bugs failed to be found in earlier stages, the reason? The reason is basic and explained in one simple sentence “The later the bug is found, the company losses increased”, as a result, finding bugs earlier as possible has great importance, especially today in the software market that contain multiple competitors that doesn’t allow you to late in the product delivery.

After the problem explained, it’s now the time to discuss about the solution that called “Static Testing”, static testing allow us to make our tests on the earlier stages of the software life cycle (Requirements and specification), the main objective to use this testing method is to find the bugs on the earlier point of the software life cycle and remove those bugs on future stages.

Objectives of dynamic testing

The main objectives of this testing method is to find the software bugs while the code executed, during those tests we make sure that our application behaves based on the predefined requirements and specifications.

Why SQA is so important?

The world is changing, we are witnessing to the revolution made by the advanced technologies that pop-up every few days. As such, technology has a direct influence on the way we perform basic operations like talking and interacting with other people, consuming information and much more.

The world is driven by new technologies that make our life much simpler, can you see yourself without your cellular phone? No internet? Computers? The answer is NO! You simply cannot go back, technology is main part of us as human in the last 10-15 years and resides on every aspect of our life.

The implementation of software’s in our daily life has many benefits (I’m sure you can find at least 1B examples…) but not less important the risk becomes higher. The major growth of the software industry causes a higher percentage of software failures and those failures may be the difference between life and death.

The technology risk factor is the one that makes the SQA so important, SQA process is aiming towards bug prevention that reduce the “Risk” factor and as a results minimize the gamble for software failures. You need to remember that SQA is all about reducing the software risks, SQA process will cover the desirable standards and make sure that those standards applied while the software developed.

Thursday, April 10, 2014

The characteristics of a specialist tester - Mastering the “Static” testing method

A specialist tester will know the importance of static testing (Static Vs Dynamic testing explained in earlier chapters of this book) and how a great execution may lead to better dynamic testing and greater resilience for the end product.

The specialist tester will take this testing type and master it to perfection, and why mastering such testing method? The answer…because he knows that mastering Static testing is must, you cannot perform a great testing process when you failed to make such tests.

Just for example, think about testers who telling their manager that they cannot make tests without a working build, yes, in some cases this statement is true, but not in all cases, the specialist tester will understand very quickly that without a working build he cannot execute the “Dynamic” testing part and as a result he starts or continuing the second part of the process (Static testing). The end results are very simple, the first tester will sit on is a$% and continuing is complaining  while the specialist tester will see such failure as a great opportunity to perform additional tests that relevant to the static part. In addition, although that “Static” testing performed at different points during the software testing life cycle, the specialist tester will know that best results will be achieved when using this method early as possible, the tasks you can accomplish without code execution is massive, few examples:
  • Review the SRS and SDD documentation.
  • Design the test strategy.
  • Design test cases and review.
  • Investigate the client environment (all info should be available from the PM or SE).

As you can see, all examples above are crucial for a successful testing cycle, the benefits are:
  • Reduce spec bugs that have direct impact on the entire engineering process (Coding/testing).
  • Allow the tester to see the project “Big” picture and as a result the timelines and testing scope will be determined in greater efficiency.
  • Knowing the big picture is crucial when making a “Risk Analysis” for the current version.
  • Based on documentation, the tester will know the integrated systems for his software, as a result the testing environment can be papered before the actual testing executions.
  • Allowing the tester to be familiar with the complexity of the future testing process according to the expected developing results taken from the SRS design.

Friday, April 4, 2014

The characteristics of a specialist tester - Nothing is obvious, Assuming is the key for failures

The specialist tester will not take anything as obvious, every assumption should be tested and approved before he can put the “Approval” signature.

One of the most annoying testers I worked with where the once who told me that some tests are not important because they already have tested them two months ago or in some cases the developer told them that the bug he just fixed will not affect any components during the integration of the code parts.

For me such testers should be abandoned from the testing world because they failed to do their job. Our job is to make sure that all requirements applied with success and the only way we can do it with success is to trust our testing sense and questioning everything without assuming that something will work just because it looks fine or someone told us that we don’t need to waste our time to test it.

For me the real specialist will know how to process the information he gets and analyze it based on skillful “Risk Analysis”, and only after he analyze and understand the risk factor he then can take the right decisions and decide how to handle the assumption provided to him by any other collogue.

The characteristics of a specialist tester - Software life cycle involvement

How many testers receive a software for testing without any idea of the process previously involved in the creation? These testers are not specialists, a true specialist will eager to be involved in all stages of the process starting from the requirements stage/design stage, why?

Because the specialist tester understands that software bugs and bottlenecks will be reduced based on the time he starts to raise is inputs, starting early will give him the power to make real changes that he probably cannot do if he starts is tests on later stages, and that’s not all, based on skillful analyze that start on earlier stages the specialist tester will understand the full picture and that’s allowed him to master many aspects from the QA side, among those aspects we can find: 

  • Software technical knowledge.
  • Why the clients/company decides to develop it?
  • The solution we provide to our clients.
  • Clients use cases that impact our risk management.
  • Allocate the relevant team for testing based on technical and personal strange.
  • Design and create a better test plan.
  • Select the most appropriate testing methodology (Agile, Waterfall, V-Model…).
  • Create an efficient test case.
  • Understand the project scale and manage the version risks.
  • Acquire the environment for tests.
  • Reduce the number of defects in future development and testing cycles.
  • Save time and money that will be spent for every defect that we failed to find on our ‘Static’ testing and discovered on the “Dynamic” part.

And let me tell you one more thing, if you are reading this post and come up with the conclusion that the author is wrong because he cannot understand the daily pressure you have at your work on a daily basis or in the worst cases scenario you simply failed to understand the urgency of QA involvement on earlier stages of the software life cycle you probably will never be a true specialist in our world. 

My Presentations