Sunday, September 11, 2016

How can you Improve yourself as a software tester | David Tzemach

Overview

The internet is flooded with many articles and posts that telling you how to become a ‘Better’ tester and how to improve yourself, some of them are really great and useful, but some of them build without any relevance to the real world and how things that really occur on companies that has pressure and narrow timelines.

תוצאת תמונה עבור ‪become great‬‏

The main target for this article is to provide few thinking points that may help other QA Engineers to improve themselves and transformed from “Good” testers into “Great” testers, I hope you all find at least few points you can use and implement at your daily work.


Learning, Learning and Learning…!

Learning is not a suggestion, it’s simply must! Just like any field in life (And Testing not different) learning is everything, you cannot be good tester without continually improve yourself and your knowledge base.

Learning could be divided into four levels that when combined together create a great and powerful tester, my levels are: 

Level 1: Learn from your Own Mistakes

We are humans, humans make mistakes, and the testing field is not different. Learning from your own mistake is must, in our field you cannot make the same mistake twice, think about two different version that same bug occurred because you failed to find it on the first place (Mistake 1: You failed to find something that you should cover) and then you failed to update your STD documentation (Mistake 2: Every bug that found must be documented for future testing) and failed again. 

Author Example:
For me, my first six months as a tester was simply catastrophic, I come from the IT field without any real knowledge about the testing field. As a result, I made few mistakes that provide me with the Key Stones to become a really great tester. The difference for me was that I learn from my mistakes. And when I say “Learn” I intend to say that I investigate the reasons that led me to make the mistakes, analyze them and come with conclusions that prevent me to repeat those mistakes.

Level 2: Learn from the Mistakes of others 

Learning from your own mistake is a must thing to do (Previous paragraph explains the reasons...), learning from the mistakes of others  is different, the main reason is that when you make your own Mistakes it’s your direct responsibility to provide answers without the privilege to ignore your mistake. 

To learn from other mistakes, you must have discipline, don’t tell yourself the story that your colleague's mistake will not happen to you OR that it’s not your responsibility. For me learning from others is the best way to gain knowledge and improve myself without paying the price.

A great example for this section will be the general review that I make once a while on the Bug tracking system, I read bugs that opened by different teams and ask myself a few questions: 

  • Bug relevant to my team?
  • Can I add new test cases?
  • Reasons for failure?
  • Should I add a new testing data?
  • Environmental issues that may be relevant to my team?  
  • What can I learn from the solution?

Level 3: Learn the testing environment

I come from the Software Testing field, usually I test enterprise products that installed on highly complex architectures that involved different Operating Systems, integrations with 3rd party software and multiple environmental variables that affect my tests.

Remember this, you cannot tests anything like a professional without deeper understanding of your testing environment. Yes, I understand that sometimes its waste of time and in some cases the environment is very basic and predefined for the entire testing process, but in my world you cannot run any test without a real understanding of your environment.

You always need to remember that tests can and in most cases will be affected based on your environment. Therefore, you must learn the environment variable (There are a million examples depend on the testing software…I’m sure you can find the once that relevant for your tests…).
Basic Examples: 

  • Directory services (UNIX vs. Microsoft).
  • Permission architectures (SQL vs. Oracle).
  • Performance testing with different RAID types (Raid 0, Raid 1, and Raid 5).
  • Java/Html behavior on different web browsers.
  • File system tests (NFS Vs NTFS).
  • Threads tests for crawlers (1 core vs. 20 cores).

Level 4:  Learn your product

Well, it’s the natural thing to declare, you need to learn something before you can start to and use it, the main question is how deep your knowledge need to be..? For me there is only one answer, you must master your product, it’s your responsibility to test the product and lower the risks, this target cannot be accomplished without a deep investigation and learning procedures.

For me, mastering a software should be achieved only after the following criteria accomplished:

Master the flow from the start and until the End, and don’t be confused, the full flow includes the User interface operation vs. the exact code part that is written behind it. In addition, Understanding the code and Stored Procedures, can help you design great test cases and uncover the missing requirements in spec that has effect on the written once.

Master the requirements (Software/Hardware) of the software is really important, just think about a software that support single OS against software that supported 10 OS. This case may affect the entire testing design process. You always need to remember that different OS is completely different when executing different testing methods (compatibility and performance is a great example). In addition, understanding the requirements should also cover (you will see that each bullet has direct influence on your testing design and coverage.): 

  • Supported Hardware for integration.
  • Integration with 3rd party applications.
  • Supported operating systems.
  • Minimum requirements for installation.
  • Software limitations.
  • Known issues for specific scenarios.

Master the software Architecture of the software, understanding the architecture and integrations between components are really helpful when testing a software, just think about bugs you find in one place that fixed for a specific scenario, but as a tester you know that additional components interact with the same code and may be affected by the change.


3 comments:

  1. I really enjoyed while reading your article, the information you have delivered in this post was damn good. Keep sharing your post with efficient news.
    Regards,

    Software testing training in chennai|software testing training institute chennai

    ReplyDelete
  2. Thanks for your article! It was really helpful

    ReplyDelete
  3. I admire your facts!! thanks for the article!!

    ReplyDelete

My Presentations