My personal favorite Dilbert strips on Software Quality

So, I’ve always enjoyed reading Dilbert comic strips which have been around for a long time, came across these initially on Linkedin many years back, and as an engineer working in IT, do feel that some of his comic strips plots, scenarios, and punch lines are spot on to portray and satirize technology, workplace, and company issues.

About Dilbert

Dilbert was initially launched in 1989 in a handful of newspapers and now it appears in over 2,000 newspapers, in 57 countries, and in 19 languages. Dilbert.com was the first website for a daily syndicated comic strip.

It is basically known for its satirical office humor about a white-collar, micromanaged engineer Dilbert as the title character, along with a lot of other supporting characters such as Pointy-haired Boss (PHB), Ratbert, Wally, etc.

“In God, we trust, everything else we test!!”

Software Quality is a very crucial and important aspect when it comes to any business mid-sized, enterprise, or any in general. Gone are the days when you expect users to suffer and keep up with your product issues which hinder their day-to-day activities. These days end users are more vocal on issues and don’t hesitate to provide harsh feedback and inputs based on the quality of services provided. With the advent of social media, product performance issues, bugs, vulnerabilities, and glitches in systems spread like wildfire and it's just a matter of time before they start impacting your company's business goals, revenues, and ultimately brand image.

In today’s age, most companies know this and they take additional steps and measures to ensure that high standards of software quality are baked into the product that they deliver with multiple deployments to production daily and quality is not treated just as a formality step in any way, as someone rightly said: Innovation and solving consumers pain points are equally important but at the end of the reliability and quality of services is what differentiates you from your competitors.

In order to achieve so, it’s very important to inculcate and promote a “Culture of Quality” in all teams, do refer to this article.

The below punchline by Pradeep is spot on!!

Being Vocal

You might have been in a similar position as Dilbert above wherein you might run into roadblocks/hiccups during testing phases which could be due to application instability, dependency on other teams, or infrastructure challenges, the possible reasons could be countless. As a QA team member, it's very important to be vocal and speak up to communicate the risks or blockers accordingly at every stage to the relevant stakeholders so that it can be quickly escalated appropriately when required. On certain occasions, this may not go as expected and lead to disagreements but it's always necessary to keep your point as and when required.

Another important aspect that needs to be definitely considered is the testability of the application. It ensures that the application being promoted to testing has all the necessary pre-requisites in place, this could be passing unit tests or integration tests, dependency on some other third-party applications such as payment gateways or APIs then those are mentioned clearly so that as a QA team member you are fully ready to start with testing the application and to avoid any kind of last-minute surprises which impacts sprint or delivery timelines.

Adding Value!!

As a quality advocate, your job does not end with finding defects or scripting 1000s of test automation scripts, but you should think more along the lines of an end user playing around with different use cases and exploring all areas of the application as much as possible, suggest improvements and feedbacks as and when required so that the overall quality and end-user experience is always high.

If you feel that some areas of the application can be improved or can be made a bit more user-friendly, feel free to casually discuss it with your product manager or business analyst colleagues it could be possible that it might be something that the end-user or customers might agree upon. At the end of the day what matters is “Adding value and making the product better” if your customers/end users are happy and love your product they will surely recommend it to others bringing in more customers (business)

Early Testing

As you might be aware in the traditional waterfall software model, the actual testing phase commences post the completion of the entire development phase. Sometimes, it could also be possible that the allocated time might get reduced from what was proposed initially due to delays or some difficult circumstances in the initial phases of the project. This could pose a huge risk to the testing phases or the entire delivery scope if a huge number of bugs/issues are encountered during the testing phases. In some cases, this is welcomed openly as part of company culture but it could happen that they might cause some delays to some other planned events, later on, like maybe UAT or customer demos, etc.

To avoid a situation like the above, these days organizations are embracing agile principles and using a shift-left approach or the principle of early testing to make sure that each member of the team is equally important when it comes to assuring quality as a whole and not just a few individuals or just the Quality team. Dev teams can contribute with solid unit tests, and integration tests and the QE team can work with them during the initial phases to do pair programming and analyze different scenarios that should be included in and covered as part of feature stories, enhancements, etc.

Fixing Bugs

Ah, the classic bug-fixing scenario!! Most of you guys must have encountered this scenario wherein certain bugs you might have raised get pushed out mentioning too trivial, less priority, low business impact, etc. As a quality advocate, it’s very much to understand the impact of bugs on the end user and business value and then accordingly discuss it with your product management teams and stakeholders to ensure that the relevant bugs are picked up and fixed accordingly to avoid any setbacks. When dealing with legacy applications, it might be possible that you encounter certain gray areas which might not work as intended, it's important to document and review these with the business or product teams and have them added to your backlog so that they can be picked up and fixed if the need arises.

Best practices!!

This is a classic example that usually happens in most industries. Company X is using so and so techniques and processes to get stuff done, going forward we will also start incorporating or using it. This situation can either work out for you or could be a disaster in the making, what really matters is you discuss this approach or decision process with relevant stakeholders, and team members and gather all the necessary information, and metrics, to make the right call. In some cases, to achieve these new directives, we might require a complete organizational culture change, hence it's very important to assess and proceed accordingly so that everyone’s on board.

Certifications

Certifications play a very vital role in re-instating the fact you possess the skills and adequate knowledge to perform the necessary task assigned. During the initial phases of your career, sometimes it may give you an edge over other candidates during job interviews or may help in boosting your social image and profile on Linkedin. For example, AWS and Salesforce hand out an honorary golden jacket to folks who have cleared out each and every certification. Check out this post

When it comes to QA, most organizations mainly focus on ISTQB level certifications at the least which are more inclined towards theoretical concepts/topics and are generally considered good to have for someone who is looking to get into testing at their early stages of a career, but going forward as you move along when it comes to certifications what really matters is the learning experience, exploring stuff getting your hands dirty on various services/tools/libraries by trying out different features, referring documentation, and building a few basic projects rather than just blindly getting certified just for the heck of it, if you are working with these applications day in and out, trust me clearing certifications will just be a piece of cake.

And with that, I will wrap up this article, hope you enjoyed reading these, will leave a couple more strips just in case to get the flow going!!