Test Management Archives -

Transforming Software Testing: A Journey from Basics to Specialized Excellence

Charting the Course: A New Paradigm in QA

The software landscape is ever-evolving, and in its flow, the role of Quality Assurance (QA) has burgeoned from a mere checkpoint to a strategic cornerstone. It’s a narrative of transformation, where roles within software testing are no longer confined to generic titles but are sculpted into specialized beacons of expertise.

The Genesis: More Than Just Testing

The inception of our journey was marked by a recognition that our QA team, a mosaic of potential, was marooned on an island of outdated structures. This epiphany was our call to action – a call to sculpt a robust career pathway for every tester.

The Blueprint: Values that Mold Careers

We leaned on our core tenets of curiosity, creativity, and collaboration to lay the foundation for roles that would not just exist but thrive. These values were not mere words; they were the crucibles that shaped the roles we envisaged.

The Spectrum: From Junior Pioneers to Architectural Maestros

We delineated our career paths into clear strata, each reflecting a distinct echelon of expertise:

Entry-Level Pioneers: Where the journey begins, our QA Interns and Testers are the bedrock, honing their skills, learning the ropes, and imbibing the essence of quality.
The Intermediate Vanguard: QA Engineers, the intermediaries, who with a balanced blend of skill and innovation, take on more intricate aspects of testing, curating quality with each test case.
The Senior Strategists: Senior QA Engineers, the specialized craftsmen, wielding tools of automation and analytics, architecting the frameworks that uphold our standards.
Leadership and Visionaries: QA Leads and Managers, the navigators of our QA odyssey, charting the course, steering through complexities, and anchoring the team to its goals.
The Specialized Elite: Performance and Security Experts, the guardians of our software’s integrity, ensuring each product can withstand the tides of demand and the shadows of cyberspace.

The Revelation: Roles That Resonate

Each role now resonates with a defined purpose, echoing our values and encapsulating the skills and responsibilities pertinent to that stage of growth. This clear delineation has not only catalyzed professional growth but has also enhanced the quality of our products.

The Vanguard: SMEs as Beacons of Mastery

Subject Matter Experts (SMEs) in Test Analysis, Performance, and Security have emerged as the vanguards of their domains. These roles are not just titles but are sanctuaries of expertise, each SME a beacon guiding their peers towards excellence.

The Odyssey: A Cultural Metamorphosis

The rollout of these roles was not just a structural change; it was a cultural metamorphosis. A once rigid hierarchy gave way to a dynamic ecosystem where each role is a stepping stone to a zenith of specialized prowess.

The Harvest: A Resounding Triumph

This transformation has been a resounding triumph, with our QA team not just meeting but redefining industry benchmarks. The clarity in career progression has unfurled potential into performance, and ambition into achievement.

The Continuum: A Pledge to Perpetual Evolution

Our journey doesn’t plateau here. We pledge to perpetually evolve, iterating on our structures and roles, ensuring our team is not just current but cutting-edge, not just testers but trailblazers.

An Invitation: Let’s Converse and Collaborate

Are you on a similar voyage? Are you considering charting such waters? I am eager to share insights, and strategies, and perhaps, learn from your narratives too. Let’s collaborate to elevate QA beyond its traditional bastions, nurturing careers that transcend expectations.

Using AI to Improve Test Efficiency: A Practical Example of Automated Test Case Generation

Software testing is a critical part of the software development process, ensuring that the application meets the requirements and functions as intended. However, the traditional manual test case generation process can be time-consuming, and tedious, and may not cover all possible scenarios. This is where AI comes in, automating the test case generation process and improving efficiency. In this article, we will explore a practical example of how AI can be used to generate test cases automatically, improving test efficiency.

Example Scenario:

Imagine we have a web-based e-commerce application that enables users to search for and purchase products. The application has several features, including user registration, product search, product details, and checkout. A team of developers is working on the application, and a team of testers is responsible for ensuring that the application works as expected and meets the requirements.

Manual Test Case Generation:

Traditionally, testers create test cases manually based on their knowledge of the application and the requirements. For our example e-commerce application, testers would need to create test cases to cover each functionality, such as registering a user, searching for a product, viewing product details, and placing an order. The test cases would need to cover different scenarios, such as valid and invalid inputs, error handling, and boundary conditions.

Automated Test Case Generation:

However, with AI, we can automate the test case generation process by using machine learning algorithms to analyze the application code and generate test cases automatically. In this example, we will use an open-source tool called “AutoTestGen,” which is based on machine learning algorithms.

AutoTestGen works by analyzing the code of the application and generating test cases to cover all possible paths and branches. The tool can generate test cases for various programming languages, including Java, C++, and Python. To use AutoTestGen for our e-commerce application, we would provide the source code to the tool and run it. The tool would then analyze the code and generate test cases automatically, covering all possible paths and branches.

Comparison:

To compare the results obtained using manual test case generation versus AI-based test case generation, we can measure the time and coverage. Manual test case generation is time-consuming and may not cover all possible scenarios. AI-based test case generation, on the other hand, is faster and more comprehensive, covering all possible paths and branches.

Conclusion:

Automated test case generation using AI can significantly improve test efficiency by automating the tedious and time-consuming process of manual test case generation. It can also improve the coverage of test cases by covering all possible paths and branches. Open-source tools such as AutoTestGen can be used to automate the test case generation process, improving test efficiency, and ensuring better software quality. With the help of AI, software development teams can save time, reduce costs, and improve their testing process, ultimately leading to better software quality and user experience.

If you’re interested in learning more about how AI can improve software test efficiency or want to consult with me to help introduce AI to your testing teams, please feel free to reach out to me at askabk@abkhalid.com . Together, we can explore how AI can transform the way we test software and help us deliver high-quality products faster and more efficiently.

Hey, What do you call a group of programmers in a bar?

A stack overflow

You need to add a widget, row, or prebuilt layout before you’ll see anything here. 🙂

How AI Can Help Improve Software Test Efficiency

As technology evolves, software testing becomes more complex and time-consuming. However, with the advent of artificial intelligence (AI), testing can be done more efficiently and effectively.

AI can automate repetitive and mundane testing tasks AI-powered testing tools can be trained to run tests repeatedly without tiring, making them ideal for running large volumes of automated test cases. By automating these repetitive and time-consuming tasks, we can dramatically improve our productivity, accuracy, and speed to market. For example, AI can help automate the testing of web applications, which often involves repetitive tasks like logging in and out of the application or filling out lengthy forms.
AI can identify defects more accurately and quickly AI can help improve the accuracy and speed of defect detection and classification, enabling faster and more effective remediation. For example, AI can be used to analyze log files to identify and diagnose performance bottlenecks, detect security vulnerabilities, and pinpoint the root cause of failures in real time.
AI can enhance test coverage and accuracy AI can help improve test coverage by identifying areas that are more likely to be problematic and testing them thoroughly. For example, AI can be used to identify the most frequently used functions and features of an application and prioritize testing efforts accordingly. This approach can help reduce the risk of bugs and improve overall product quality.
AI can enable predictive testing AI can be used to predict the likelihood of defects and failures in the software, enabling proactive testing. For example, machine learning models can be trained to detect patterns and anomalies in application data, allowing testers to identify potential issues before they become major problems.

Now, for a joke! Why did the programmer quit his job? He didn’t get arrays!

But in all seriousness, the benefits of implementing AI in software testing are no laughing matter. Here are some numbers to back it up:

According to a report by MarketsandMarkets, the AI in software testing market is expected to reach $1.5 billion by 2022, growing at a CAGR of 33.7%.
In a case study by Infosys, a large healthcare provider was able to reduce their testing efforts by 20% and improve their test coverage by 90% by using AI-powered testing tools.
A study by Capgemini found that AI-enabled testing can reduce testing time by up to 20% and improve test coverage by up to 80%.

If you’re interested in learning more about how AI can improve software test efficiency or want to consult with me to help introduce AI in your testing teams, please feel free to reach out to me at askabk@abkhalid.com. Together, we can explore how AI can transform the way we test software and help us deliver high-quality products faster and more efficiently.

And if all else fails, at least we can use AI to tell us a good joke or two along the way.

Its “Us vs Them” Mentality

Its been couple of years, that I have had the opportunity to write & share something. I hope I am not that rusty!

It was early 2010s when we started hearing and discussing about Agile in larger audience. Especially in Pakistan. Initially people thought, it’s a ploy to remove testing resources altogether, as there is slump in markets and companies can’t afford to have “freeloaders”.

I remember, having multiple discussions with my friends and telling them, relax man, we are here to stay. But deep down, I had an itch, what is this “new way of development” where no testing, or documentation is required.

Let’s back up a little bit. In traditional software development lifecycles, there was always a Testing Face, and the biggest question was QA v QC or Verification v Validation. But we knew whatever the distribution, but we will have our time for each project, where we will be working on the application/software as per our own understanding of the requirements. We (some of us thought) were too good in business side of things, so we only knew what client wanted and devs where there to only put blocks together).

By having, ”our time” (in other words testing time or cycles) there was a clear divide, it was Testing vs development.

It was then, and presumably with more common understanding / knowledge of Agile Methodologies, with mantra being one team, one would assume that this would have gone. But no, it hasn’t we still keep fighting the battles, we still have battle lines drawn.

I have been scratching my head and trying to find out the root cause. And up till today morning, I was thinking we need more coaching for our team members. But something clicked, and that is, we the dinosaurs need to change first. We still keep fighting the “Us v Them” battles. Even though our resources have been put in same teams, but we the “Managers” are still holding the rope tight. We still keep on believing that they are our resources. We keep on encouraging “our” resources only. In reviews we try to find faults with resource from “other” team. Try to hide the issues of one’s own resources.

But we must realize, as soon as you step in to world of Agile, the resource managers are not managers, they are parents, that have to let their children decide their own path, and to quote a windows phrase “Sit Back and Relax”. Let them make mistakes and learn from them. Help them if asked, don’t go running to find the issues. The more you let them be on their own the more they will learn.

So agile coaches, please sit together and sort us out. Make sure we believe in one team concept, rather than preach only.

I have done my Manager (Traditional Manager) to Manager (Agile Coach) Journey, have you? More on this in my next blog.

Important Announcement: if you are facing any issue regarding Agile Testing, Testing Organizational changes, HP’s products for Application Life-cycle Management, Functional or Regression Testing and/or Performance Testing, please contact at abkhalid@gmail.com , I will try my best to help you out.

You can also share your opinion and if any particular topic you want me to cover I would love to do it up to best of my knowledge.

Agile and Organization changes at Structure Level! A Traditional Testing Lead’s Perspective

In recent years it has been observed that more and more organizations are moving in to a very agile environment. Now people have discussed thoroughly about new roles for each resource across the board, where traditional Developers, project manager, testers, analysts, system engineers, support staff and others go. One role that has not been discussed and has been taken as peripheral, infect in some cases as obsolete is of Traditional Testing Department Lead.

As with the case with every other Testing Lead, I recently have had to face the same dilemma (infect I am still going through this transition), where I have been able cope better is due to my role of Test Management Consultant (for HP Testing Software) in my previous organization.

Traditionally it has been observed that the role of Test Lead is of a watch dog, which is going to give final authorization weather to move forward with application or not, weather the application is as of Client’s requirements, weather all needs, wants and desires of client are in place. This role was evolved from a person to identify the screen look-n-feel and document writer about 15 years back. And had its most influence over the last 5 ~ 10 years.

But now as Agile is starting to be implemented more and more, these above responsibilities are delegated to “testing” resources part of a feature/scrum team and scrum masters.

So what now for Test Lead, as he cannot delegate work, he cannot authorize or sign off an application release. Most organizations have taken the easy way out to get rid of these high earners and giving all their powers to scrum / feature lead.

My new organization has bucked the trend, to laugh out loud, they hired me.

In first few days I was of the point of view that somebody somewhere in higher-ups screwed up big time and sanctioned the hiring of a Testing lead, completely forgetting the change in organization that was going to take place.

But no, they have hired a “Traditional Testing Lead” to do very “Un-traditional” job. My new role specifies that I don’t indulge on go live or resource tasks but to be a consultant with in an organization for testers.

To help them out, to train them, to enhance their capabilities to be able to work as individuals in scrums and be the “watch dogs” within the scope of their respective scrum or feature based team.

So here I am re-inventing myself. I will try to share more information over next couple of months.

You can also share your opinion and if any particular topic you want me to cover I would love to do it up to best of my knowledge.

Minimum Required DB Rights (MS SQL SERVER) for HP ALM Environment (HP QC/ALM)

It’s been about 3 months now since my last blog; I have been busy on couple of projects with very high severity.

The issue I am going to discuss now has very significance which most people ignore for low to medium security level organizations. But of organizations where Security polices take higher preference, we need to identify the minimum database rights required for set up and work properly.

In normal implementations, what I and most of my colleagues around the world end up doing is, creating a user with sysadmin (Members of the sysadmin fixed server role can perform any activity in the server: Courtesy MSDN) rights, and doing the all the implementation using that.

One of my company’s clients, obviously with very high security policies in place, wanted me to setup environment where I sit with their Database administrator in order to identify the minimum requirement of rights.

I had told him my hunch is that you need to give dbcreator and ability to change / set up new users.

So we started our research, here are some important points form it

During installation

A user (HP QC/ALM DB Admin) with rights DB Creator (dbcreator) and Security Admin (securityadmin) is required for HP ALM

Reasons:

A new database is to be created for Site Administration purposes
A USER is to be created for record manipulation and connections establishing

One observation was made, for the created project, the user HP ALM DB Admin, was also given DB Owner permission for the database (Site Administration).

During ALM Usage

Now when ALM was being used, we observed that we need two types of permission sets

Normal Processes

The user TD (with maximum privileges of ddladmin) created during installation is enough for normal processes which include

Record Manipulation
Reports generation
Setting up and working with Configurations (Site Admin)
Working with Project Customization, where no Database Field is to be change

Administration Process

The user HP ALM DB Admin with elevated privileges, which being dbowner, dbcreator and securityadmin is required for administrative processes

Project Management (Creating, deleting, restore, export, import, verify, maintain & Upgrade)
Working with Project Customization, where Database Fields are going to be changed (new fields, change field types, delete fields)
Domains
DB SERVES

Precaution

But we need to understand one thing, the user HP ALM DB Admin needs to not be shared with everybody, as this user according to MSDN should be treated with similar care as of sysadmin (Members of the securityadmin fixed server role manage logins and their properties. They can GRANT, DENY, and REVOKE server-level permissions. They can also GRANT, DENY, and REVOKE database-level permissions if they have access to a database. Additionally, they can reset passwords for SQL Server logins.)

Document Generator Crashing Issues (HP QC/ALM)

After I wrote my last blog on the SSL with JBoss Environment for HP QC/ALM, my colleague asked me “Ahmad, you have also worked on many other issues over the course of last 3 to 4 years, why not try to document them all.”

So here, I am taking up his advice!

There is a common issue that keeps creeping up, and most of the time, reply form HP Support is that they cannot do anything about it. And to reveal a secret, that they really can’t. The issue is when we try to generate document through document generator or try to export an excel report from dashboard, ALM window crashing by displaying the following error.

“”Error: Unable to cast COM object of type ‘Microsoft.Office.Interop.Word.ApplicationClass’ to interface type ‘Microsoft.Office.Interop.Word._Application’. This operation failed because the QueryInterface call on the COM component for the interface with IID ‘{00020970-0000-0000-C000-000000000046}’ failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)). Line: mscorlib”

The issue is generated, if there are registry entries of multiple versions of Microsoft office applications. For example, if user upgraded MS Office from 2007 to 2010 version, there are more than enough chances that some of the registries instances of older version of Office or not removed. Another example can be that if user installed MS Office 2010 and then installed MS Project 2007 or MS Project 2013.

Now when the ALM/QC tries to access Office COM files, its directed to multiple locations, thus it crashes.

Issue can be tackled by following the steps given below (Disclaimer: only personal that have experience with registry should follow following steps, rest should ask their administrators to do it for themselves.)

Copy the CLSID (long data within the curly brackets) form the error window. [in above error window its 00020970-0000-0000-C000-000000000046]
Access Windows registry
1. Open Run window (‘Window key’ + ‘R’)
2. Type in ‘regedit’ and press enter
Take backup of the Registry
Place your focus at top of the registry tree (at computer) and now search the copied CLSID in the registry
You will reach a location in HKEY_CLASSES_ROOT whose title is the key which was searched. There are going to be three sub entries “ProxyStubCLSID”, “ProxyStubCLSID32” & “TypeLib”.
Copy the default key of “TypeLib”. [Actually whenever a call to a particular assembly object is generated, Assembly opens up this key to find the exact location of application]
Place your focus at top of the registry tree (at computer) again and now search this newly copied key in the registry
After you find the key, expand it, you will/might find multiple versions of “TypeLib”; please remove all those that do not contain a valid path (verify the path) in their default entry
1. Inorder to do it, expand each version, then expand 0 key, then copy the path in the default entry, open that path and verify that if tlb file exists on the path

Preventive Measure that might help: Whenever you uninstall a MS Office application, please do restart your machine, before installing any other one.

Important Announcement: if you are facing any issue regarding HP Quality Center/ HP Application Lifecycle Management, please contact at abkhalid@gmail.com, I will try my best to help you out.

SSL Support with JBOSS (HP QC/ALM)

During one of our recent implementation of HP Quality Center, one representative form the client, kept asking me, Ahmad! “Why you are not implementing SSL. We have very secure data and you are exposing it”.

Defiantly I had to look at it as refusing clients, is not part of our company policy.

After working at it for couple of days, I came up with following solution (Got little help from HP Support Community).

Step 1: Install HP Quality Center with JBoss Application Server

Step 2: In command prompt navigate to Java Bin Directory (JRE – Install it if not present).

Default Directory can be <installation drive>\Program Files\HP\<Either of Quality Center or Application Life Cycle Management>\Java\JRE\bin\

Step 3: Run following commands (in place of “Server Name” write the actual server name)

set SERVER_DN=”CN=<server name>, OU=X, O=Y, L=Z, S=XY, C=YZ”
set CLIENT_DN=”CN=Client, OU=X, O=Y, L=Z, S=XY, C=YZ”
set KSDEFAULTS=-storepass changeit
set KEYINFO=-keyalg RSA
keytool -genkey -alias tomcat -dname %SERVER_DN% %KSDEFAULTS% -keystore server.keystore %KEYINFO% -keypass changeit
keytool -export -alias tomcat -file temp_server.cer %KSDEFAULTS% -keystore server.keystore
keytool -import -v -trustcacerts -alias tomcat -file temp_server.cer %KSDEFAULTS% -keystore client.keystore.trust -keypass changeit

Step 4: Take copy of CACERTS file present in the <installation drive>\Program Files\HP\<Either of Quality Center or Application Life Cycle Management>\Java\JRE\lib\security and place it somewhere safe

Step 5: Copy the file created by Step 3 Part 7 (CLIENT.KEYSTORE.TRUST) and to the <installation drive>\Program Files\HP\<Either of Quality Center or Application Life Cycle Management>\Java\JRE\lib\security folder and rename it CACERTS

Step 6: Copy the file created by Step 3 Part 6 (SERVER.KEYSTORE) to an accessible location like C:\CAs\server.keystore

Step 7: Back up “server.xml” present in <installation Drive>\ Program Files\HP\<Either of Quality Center or Application Life Cycle Management>\jboss\jboss.zip\server\default\deploy\jbossweb.sar

Step 8: Edit the “server.xml” by Uncommenting the SSL connector, edit the keystoreFile and keystorePass options:

<!– SSL/TLS Connector configuration using the admin devl guide keystore –> <Connector port=”8443″ address=”${jboss.bind.address}” maxThreads=”100″ minSpareThreads=”5″ maxSpareThreads=”15″ scheme=”https” secure=”true” clientAuth=”false” keystoreFile=”C:\CAs\server.keystore” keystorePass=”changeit” sslProtocol=”TLS” />

Comment out the HTTP connector in the server.xml file.

Step 9: Save the server.xml file, and restart JBoss and QC (e.g., via the Windows Services)

Step 10: Connect to QC using port 8443. Forexample (https://server name:8443/qcbin)

Myth about Skill Required for Automation Testing

My recent observations of SQA Skills trends in Pakistan in particular and overall in general, a tendency to ask people being hired for SQA positions if they have experience, skills or knowledge of automation testing. And the answer the hiring body is mostly looking for is if they have working experience of QTP, Selenium or RFT. If the resource says he is willing to learn QTP or Selenium or RFT or whatever, people start teaching them these tools.

I have started to get frustrated by this behavior, but I also have been part of this culture too, so one can say I am frustrated with myself too.

Let me quote you one story, one person who was well-versed in Software Quality Management in early 2000(s); advertised following skills for QA resources, job advertised with title Software Developer and Quality Analyst

ISO
Development (language not important)
Automata
Data Communication and Networks
Regular Expressions
Critical Eye

After experience of hiring, getting hired, working and managing teams, I have to come to know that above ad was the best possible ad for what we mostly look from our resource.

But are we looking at right skill set, or even we know what we want, I think about 90% people don’t know the answer, and the ones that know hide behind ‘budget limitation’ wall.

I believe we should look at software automation testing as we look at software development; we need at least two type of personal, one Software Automation Script Developer and one Software Automation Engineer.

Software Automation Engineer: Should be the person, who has application domain knowledge, has written the Test Cases for the application, and understands which area of application needs regression. He also understands and can write suede code, which a developer can understand and convert to physical code. He is also going to prepare the data for the data driven automation testing.

Software Automation Script Developer: Should be the person who gets the test case in document form, and just creates the script as defined. He has the understanding of the scripting language.

I will try to explain in detail what these roles should comprehend in grand scheme of Software Quality Assurance in the long run.

Test Management and Snow Ball effect of “Agile Development”

Most of us have been exposed to project that never follows actual project plan; the changes can be new features, new add-ons, defect fixes or new integrations. For every test manager these projects take a snow-ball effect, that is they keep on growing along the way, and you are never sure what to expect from them. And to make the mater worse more rapid the changes or defect fix, lesser the duration between the builds. But the area to test keeps on increasing. Another factor to consider is the trend of software development companies to “fall” in to Agile Development, where they “think” everything must be parallel.

Now what it do to test managers is very scary, you cannot get the automation kick in, as application is being updated regularly, you cannot add more resources, as “You don’t need more resources, you already have got it tested”, while if they do not get it all tested, you get to hear, “Mr. what are you doing, look there is very important bug your team missed”.

To tackle all this I have made my policy that for a project that is behaving like this (let’s say every new build is within less than two weeks of other) I usually deploy two resources; both resources do test new features for first week. For next week depending upon the available time, needs to change test cases, I on daily basis try to cast a net on areas that are near to new features, where one resource test the application, and other update the test data and test cases for next build.

And for last couple of days before the next build, we do a strategic exploration of application, which is for every build we select one or two modules and do exploration for the application.

This is not the ultimate test management process, but honestly since the advent so called agile development, and lack of cohesion between builds and marketing team’s insistence of new build every other day; this is the best I could devise in 5 years of my test management.