Saturday, March 29, 2014

Dynamic testing

The exact opposite from the static testing, in this test method we perform all testing operations that related directly to the software (Runtime Environments), to be more specific this type of testing involve a software executions for reviling a hidden software bugs.

In addition, dynamic testing are the tests that let the tester to understand the quality of the tested software, you probably know that you cannot test all inputs in your tested software. Therefore, you must make the best “Risk Management” and decide the most relevant inputs that may supply and represent the software quality, using the correct inputs will help you understand the real quality and resilience of your software, if you failed to do so, the conclusion for the end quality may be irrelevant and will not reflect the real quality.


Dynamic testing includes different activities as described in the list below:

  • Testing the system performance.
  • Testing the system functionality.
  • Testing the software with predefined inputs.
  • Testing the system behavior with different testing manipulations (Usually performed with a specific subset of inputs).

Friday, March 28, 2014

Static Testing

Static testing is all operations performed by testers and developers without a direct relation or need in the actual code of the software (non-runtime environments), and in other words we can simply say that this kind of
test performed while the code is not executed in one way or another (code execution is not involved in any way...), great examples for static testing: 

  • Review/inspection made to software requirements (Specs).
  • Review/inspection made to software technical design (DDD).
  • Review/inspection made to the user manual that come along with the software and going to be used by the client as guidelines to how to use the software.
  • Review/inspection made to developers code.
  • Review/inspection the test documentations (STD, STP, ATP).
  • Review/inspection made to development and testing strategies.
  • Review/inspection made to the testing end results.
  • Review/inspection made to project timelines and progress.
  • Examination made by developers to their own code with different manipulations to reduce defects in the actual run time (White Box testing anyone..?).
  • Walk-through of the tested software, this method will educate your testers, and benefit with the testing quality.

Based on the list above, I’m positively sure that you understand that executing a great ‘Static’ testing is one of the main keys for success in any given software life cycle, the following list will provide a short list of benefits you gain from this type of testing:

Improve the communication with the company clients – great communication and inspection for your client requests is the key, while examining the requirements, you can create a great collaboration that in the end will lead to great results suggest: 

  • Understanding the requirements in 100%, no surprises during the engineering process.
  • Understand the client environment and the specific site architecture.
  • Understand the user expectations from the software and how he wants to use it, by accomplished this simple task you can design effective test cases and reduce the once that not relevant.


Time and money is the key – great static testing will contribute to reduce the costs and engineering process that contribute to the company “success” factor.

Improve productivity without incising the timelines – when you understand your tasks, you can develop and test in greater efficiency. Therefore, you improve your productivity and reduce the delay you probably had without the use of static testing.

Reduce the number of bugs – static testing is the key to doing so, if executed with perfection I can ensure that stupid bugs will not be part from your testing cycle (Although your developer may do some magic if he failed to sleep at night before..).

The characteristics of a specialist tester - Great writing skills

No, you don’t need to write a novel, but in the testing world writing skills can do the difference between failure and success. For me there are two main areas where writing skills are crucial:

Writing Test cases
Think about the following scenario: 
  1. Tester X write STD with 1000 test cases.
  2. After six months a new tester arrived into the company (Tester Y).
  3. Tester Y should run tester X documentation (STD).
  4. Tester Y start the execution. 

Available scenarios:
  1. Tester Y receive highly detailed STD with expected results, execution is flawless.
  2. Tester Y receive highly detailed STD without the expected results, execution is a total failure
  3. Tester Y receive Low detailed STD with expected results, execution is a total failure.
  4. Tester Y receive Low detailed STD without the expected results, execution is a total failure.

Simple quiz, but as you can see, writing skills is great characteristics that you must master, the specialist tester will know how to write in a way that other tester will understand and run without is personal help. That’s not all, sometimes a tester can write an STD that executed single time and forgotten for a year, the specialist tester will create this doc in a way that he can use it after such time without the need to rethinking about the cases and why he wrote them in such way, the reason for that is that all tests written perfectly from the first place.


Criteria for a successful test design:
  • All tests should be highly detailed.
  • Expected results should be available per step.
  • Description should be added for each test that explains the reason for “why we need to run this test…?”
  • Tester design the tests based on requirements (Covering the application requirements
  • All tests receive an appropriate prioritization (High, Medium and low).


Writing great Bugs
Writing a great bug is a true ‘Art’, for me a great bug should be highly informative from both the human and technical perspective, you need to remember that every bug that written by you will be reviewed by other collogues (Product manager, Developer, tester and more) therefore you cannot waste their time when trying to configure out the missing information or what you mean by stating ‘X’ against ‘Y’.

Specialist tester will know how to write his bugs in a way that other collogue can read is description and understand the information without asking a trivial information that different tester (The one without this skill..) will be failed to add as a result of  missing knowledge or simply bad technical understanding  in the product. 

Criteria for great bug reporting: 

  • Collogue will understand the bug from the bug title.
  • Description is writing with Micro details about the problem.
  • Description must contain the tested architecture (OS versions, product architecture on this lab, build number and more).
  • The specialist tester will know how this bug effects the version and determine the appropriate “Severity” (not all bugs are ‘Show stoppers’).
  • The bug must be readable.
  • The bug must contain reproduction steps for dummies.
  • If available, investigate and provide the actual result, most testers will open the bug based on symptoms (Not good enough!).
  • Reporting the defect is not good enough, you must describe the expected results. (sometimes the bug reviewed by new employs that will be failed to understand why you open this bug).
  • Add additional information about how this bug may cause issues with other components, in addition, show this bug to developer and understand the risk of fixing it (save your manager time..), and add the info into the bug description.
  • Add info about the influence of this bug from the QA perspective (for example: ask yourself if you can continuing your work? If you do, should you retest cases after the fix..?), this info is very important when your manager should determine the bug priority.



Friday, March 7, 2014

The characteristics of a specialist tester - Passion for testing

The passion for testing


It’s not clear that as humans we perform better if we love the things we do…? Its rhetorical question because the answer is in 100% YES!, it’s the human nature, in most cases we will do a better job if we love the things we do, from the other side of the coin we can say that in most cases that we failed to love the things we do will lead to downgrade in our performance.

Testing is not different, to be a specialist you must be passionate about it, for me learning QA is one of the best things I have in my life, every day it’s a new day to learn new techniques and ways to improve my testing skills, to remain true for myself, I really think that my biggest jump in the testing field become only after I started to love it and see it as a true occupation for life.

But that’s not all, in the real testing world the passionate tester will use is passion to own additional aspects, among them we can count:

  • Passion to learn the product and architecture.
  • Passion to find a complex bugs.
  • Passion to design a smart and complex test cases.
  • Passion to help and share knowledge with others.
  • Passion to be involved on every aspects of the product.
  • Passion to improve the quality of the product.
  • Passion to learn about the customers and why they need the product.

The characteristics of a specialist tester - Making the right prioritization

The ability to make the right prioritization

When you think about the term “Prioritization” you understand that it’s something you do on a daily basis, as humans we make prioritization too many different aspects in our daily life (I know you have 1M examples running in your head right now…), the testing world is not different we make prioritization for many aspects in our daily work while working on different project.


After the short description described above, you probably ask yourself the following questions:

  • What so special in prioritization?
  • Why I chose this characteristics to be a criterion for a specialist tester?
  • Why prioritization is so important in the testing world? 


The answer for such questions depends on the basic understanding that QA is all about reducing the “Risks”. Let me explain, in the testing world we have few basic rules that relevant for all testing process no matter what is tested software, among those rules we can find the one that talks about the testing coverage that cannot reach to 100%(in other words this basic rule stating that you cannot cover all the tests you want within a testing cycle) therefore you must make a good prioritization that responsible to cover the important test cases that will be executed and the once that will be excluded from the execution because the prioritization level of them marked with low-level, now think about the importance you have as a tester when you need to decide which test cases will not be executed and may cause defects on client environments, the responsibility is Hugh and that’s the place when a specialist tester will make the difference, the specialist tester will know how to prioritize the tests based on deep understanding of the product in a way that the total risk at the end will set too minimum. 

Summary:

Benefits you gain from prioritization:
  • Reduce the risk for the version.
  • Reduce the pressure.
  • The importance tests executed early.
  • All the importance tests are executed within the testing cycle.

Recommendations for efficient prioritization process:
Each bullet in this list is a layer in the way to make an efficient process of prioritization, you must take then in mind before you start the prioritization process: 

  • Understand in the product (Architecture, design, integrations…).
  • Know your clients and what their needs (how the software answer the problem).
  • Understand the project timelines (prioritization come from the narrow timelines you always have in a testing process).
  • Understand the project scale.
  • Understand the available resources you have on this project.
  • Understand the main targets of the project.
  • Write all tests, don’t exclude tests with lower/medium priority.


The characteristics of a specialist tester - The drive to explore

The drive to explore is probably one of the most important characteristics you need as a tester, just think about the regular procedure of your testing cycle when you receive the first Spec/DDD/SRS/for the tested software and based on it you should start and write your testing plan, the regular tester will follow such docs and base is STD directly on the delivered requirements and specifications, that’s good for the average tester, but for me this testing is not an option, the drive to explore should be effective in a way that the tester will want to accomplish the following targets:

  • Be familiar with the missing requirements that failed to be delivered from the design docs (SRS, DDD, Specs and more).

  • Be familiar with the internal architecture of the tested software, understanding the structure is basic for every testing, it’s clear that you achieve better testing when you really understand the components and the integration between them.

  • Be familiar with the way that leads to the current  software design and structured in such way, this exploration allow you to understand the limitation and other issues that took place in the coding stage.

  • Be familiar with new technologies that provide platforms or support to the tested software, as you probably know every software could be affected by external interactions, when a tester familiar with the main once he can understand the risks and design tests that by far more effective.

  • Be familiar with QA theory, you can be a good tester, but for me a true specialist should always seeking a new theoretical knowledge that could be used in daily work.


My Presentations