I’m pleased to run the 11th interview in our #testerstory series with our guest Muhamed Hammad from Cairo, Egypt. He will tell us about his experience being a Software Tester and talking about test design techniques, test coverage, and different testing activities.
Hope it will inspire lots of you and help you learn more about the design phase of your tests and it gives you useful tips that you could apply to assure better test coverage.
Part 1: Introduction
- Tell us about your experience, background?
I have more than 2 years’ experience in more than 10 different business domains as Software Test Engineer in both Full-time job and Freelancing, I perform both manual testing including functional, static, and usability testing, and automated testing using various frameworks like Selenium, Appium, and Robot Framework.
Also, I have worked in the Software Business side as a former Sales and Operations Specialist in the Software Industry with more than 3 years’ experience.
- How did you join the world of testing?
There is a lot of history beyond joining the testing world, however I will try to brief it.
While period of working in software business side I revealed the Testing field when I decided to shift my career to it, but it takes about a year to make the final decision, through this year I started self-studying beside performing SWOT Analysis then after self-study, self-practice, and SWOT Analysis I made my decision based on both perspective the rational and the passion.
I started self-studying with the ISTQB Foundation level, practicing manual testing on live projects, studying API testing, studying SDLC, and reading a lot of testing articles.
And for sure and which is mandatory, to have mentors to guide us in career planning and development.
- How do you see the best approach of link between testers and developers?
From my own perspective I see that we as testers shall deal with our colleagues from development team from professionally channels such as the following:
– First of all, bug reports must be clear as much as possible, bug title should be written to the point, attaching videos is better than screenshots, reproducing steps must be separated and combining multi steps in one step is not the best practice, expected result should be clear and it’s one of the best practice to attach a screenshot for the expected result along side with the actual result evidence, and providing plenty of related information as much as we can.
We have to remember that we are Quality Engineers therefore our work output should be quality enough.
– When we get stuck in some coding issues, we go to our colleagues from development team to support us, therefore in same context it is our responsibility as quality engineers to share with them quality concepts, how end-user thinking, and how we think to design test cases, we should do it frequently every now and then.
Part 2: Test Design Techniques and Test Coverage
- Tell us more about different testing techniques? How do you use those testing techniques in the test cases designing phase?
Test design techniques are categorized under three main categories:
– Black-Box/Behavioral-Based techniques.
– White-Box/Structural-Based technique.
– Experience-Based techniques, which are usually combined with previous two techniques.
Each category of those types includes a wide range of techniques, and for selecting the appropriate technique for designing test cases, it depends on what we are going to test and how we utilize the characteristics of each technique.
For example:
If we are going to test modules with multiple numeric input fields so we should go with equivalence partitioning and boundary value analysis.
If the outcome is different and depends on the current condition so we go with state transition.
If we predict an occurrence of a defect we go with error-guessing technique, and so on.
Finally, we can combine/merge between more than one technique in the test case designing phase, for example, combining BVA and EP techniques, and combining error-guessing technique with checklist-based technique.
- How do you assure your testing coverage?
Firstly, we have to define the Test Coverage, and it can be defined by answering the WHAT & HOW, “What are we testing?” And “How much are we testing?”
Then we should determine our test coverage technique, is it either product coverage, requirements coverage, or risk coverage…etc.
Therefore, when it comes to test coverage, we should look for the full picture or as it said the pilot view, test coverage should be strategic and wide, and it should be done by following appropriate techniques and metrics in the project/product context.
- What are the first actions/activities to be performed before starting the normal testing activities?
I am going to list down in the order, the activities to be performed once it is required to start testing on the project.
I know that some of these activities are not pure testing activities and more related to business activities, but I will mention with each one its benefits.
i. Features Mind Map
Briefly, this activity is performed by collecting all features and its CRUD operations in one mind map file by following the modularity hierarchy approach,
For example, Module 1.0 ==> Feature 1.1 & Feature 1.2 ==> Sub-Feature 1.1.1 & Sub-Feature 1.1.2 and so on.
The benefits returned from this activity:
– First benefit, to perform and finalize this activity you have to walk through the whole application therefore the knowledge of business would be increased.
– Second benefit, this document would include all the application features in one file as reference which would help to make sure all features are covered in all further testing activities.
ii. Features Gap Analysis Sheet
In this activity we follow the same approach of modularity hierarchy, the additional here is that we compare each single piece of requirement between the documentation – SRS, BRS, Backlog User Stories…etc. – with the implemented application. In more details, each piece of requirement will take only one of these statuses:
Documented & Implemented: This indicates that requirement is implemented as requested from the business side without drifting or trivial drift.
Not Documented & Implemented: This indicates that the requirement is implemented without business documentation, may be considered as Business Change Request or Document is Out-Dated.
Documented & Not Implemented: This indicates that the requirement is requested from the business side but not implemented in the developed application.
The benefits returned from this activity are for both business owners & testing teams.
– Business owners will make some decisions after checking this sheet, some of these decisions are either they will update the business document for those requirements which are implemented & not written, or compare the requirements which are not implemented with the delivery time to check if it should be implemented sooner, or it would be signed as trade-off…etc.
– For the testing team, for sure the business knowledge would be growing and get more familiar with the application which accelerates the working pace in further testing activities.
iii. Fields Validation Sheet
We here also follow same approach of modularity hierarchy, but instead of features we write all fields in front of the module, and here what is each row should include:
Module/Sub-module.
Field Name (username, password…etc.).
Mandatory/Optional.
Field Type (Text, Password, Dropdown menu, date picker…etc.).
Cases (Valid, Invalid, blank…etc.).
Message of each Case.
Unique/Not (in database).
The returned benefits from this activity are:
– Coverage of all fields in the application and their validation messages therefore when we start test cases designing and test execution phases our mind will focus on test cases of business logic to be covered.
– Beside that the familiarity and business knowledge would increase more and more in addition to that tester eyes will glance at the defect clustering which is immensely helpful in both phases, test design and test execution.
Part 3: Testing in different business fields
- You worked in different business domains! which is interesting, how do you see testing when you change from project to another? Do you maintain it in the same way?
Beside performing the features mind map, gap analysis, and fields validation activities in all projects there is another main activity I have to do which is contacting specialists and experts in the business domain to learn from them the core characteristics and workflow in this industry.
For example, I have worked on a payroll application, so I contacted accountants, payroll specialists, and HRs to get more knowledge about this domain and know their mindset as they were the end-users of such an application.
After that I maintain the main testing activities, test design techniques, and test coverage techniques depend on the project context and business needs.
Part 4: Conclusion
- Can you give some recommendations for resources to follow in software testing??
I will list them in categorization format:
Testing Theoretical and Concepts
ISTQB – Certified Tester
https://www.istqb.org/downloads/category/2-foundation-level-documents.html
ISTQB – Mobile Application Testing Specialist
https://www.istqb.org/downloads/category/61-mobile-application-testing.html
ISTQB – Test Analyst
https://www.istqb.org/downloads/category/69-2019-advanced-level-test-analyst.html
ISTQB – Usability Testing Specialist
https://www.istqb.org/downloads/category/58-usability-testing-documents.html
Practical Testing
Guru99 has a variety of free live projects, you just need to subscribe using your email then everyday you will receive the new task and the solution of the previous task.
https://www.guru99.com/live-projects.html
Automated Testing
The well-known platform Test Automation University, all you need is selecting your preferred path based on technology and programming language and start learning, all free.
https://testautomationu.applitools.com/learningpaths.html
Testing Blogs and Articles
Here is a list of best blogs for software testing articles
https://readdive.com/category/software-testing
https://www.globalapptesting.com/blog
https://testing.googleblog.com
https://mavericktester.com/software-testing/
https://www.satisfice.com/blog
Test Automation Design Patterns and Clean Code
I have collected some of recommended references in this post
9. Anything else you want to share with the testing community?
As Quality Engineers we always should keep our mindset is:
Software Tester = business oriented = customer oriented = end user oriented = details oriented = attitude oriented = time oriented
Thank you so much Muhamed for being part of this #testerstory and for sharing your awsome experience with us and your journey as a software tester. Also for the useful tips that every tester can use related to test design techniques, test coverage…
I encourage you to continue your brillant journey, wish you all the best in your career.
Interviews History:
Thank you for reading this new #testerstory ! Get inspired by previous series you can find them via this link
Do you have a ‘testing related story’ ?
Get in touch via twitter @emna__ayadi or linkedin Emna Ayadi we will plan for it !
Emna Ayadi 