Top 5 Software Testing Certifications

Software Testing has helped a lot of ventures to evaluate and verify the quality of every software component so that the software can respond aptly to different inputs of stakeholders. Besides, the techniques, associated with the testing of programming, driver, or application software involve risks which, can run intentionally or intentionally in different environments. Those risks need to be remediated proactively and for doing that, businesses must have that production unit acquiring an overall knowledge of the practical implementation of risk analysis [which is an imperative part of Software Testing].

You may think about the demand for a software tester at this instance. Yes, the requirement is humongous and will always be till the creation and maintenance of software will occur!! Either you plan dynamic or static testing, you need to bring the quality testing practices on the table and for doing that, this becomes necessary – certified testers with recognition through certification by reputed institutions. Let’s take a look at top software testing certifications which won’t only land a high-paying job for you but also help the ventures reduce the risks so that their software may gain acceptance from their customers globally.

1. CAST (Certified Associate in Software Testing)

This certification can professionally identify the ability of an applicant or a candidate while demonstrating the software testing principles and their quality practices at a foundational level. Some prerequisites are there like: –

◉ 3 or 4 years degree from college-level [accredited] institution 

◉ 2 years degree from college-level [accredited] institution + 1-year experience in the IT services field 

◉ 3 years experience in the IT services field 

From the above, you must possess any ONE OF those for qualifying the candidacy of CAST. The fee of this certification is 100 US Dollars and one can pay this online after reading the payment terms carefully. Apart from all this, the certification will test your knowledge in various skill areas. They will be like how one can build ST i.e Software Testing ecosystem keeping in mind the conditions and influences surrounding, your vocabulary about methods and approaches of ST, managing the allotted software project through communication, monitoring, staffing, budgeting, and scheduling. Also, there are some other skill areas such as the magnitude of risk(s) associated with the lifecycle of the deployment current software system, designing of the test cases (like black-box), checkpoint reviews and the required exceptions, testing of the assimilated specialized technologies of mobile applications or cloud-based applications, and reporting of the tests after collecting the metrics and graphs of the data interpreted.

2. CSQA (Certified Software Quality Analyst Certification)

This certification will let you receive recognition since the candidature is identified and evaluated on the grounds of a professional level of competence. Such competence is regarding the knowledge about the practices and principles of QA i.e. Quality Assurance used in Software Testing. Undoubtedly, one needs to ethically note these prerequisites down, and they start with: –

◉ 4-year degree from college-level [accredited] institution + 2 years experience in the IT services field 

◉ 3-year degree from college-level [accredited] institution + 3 years experience in the IT services field 

◉ 2-year degree from college-level [accredited] institution + 4 years experience in the IT services field 

◉ 6 years experience in the IT services field. 

From the above, you need to acquire any ONE from those for letting your candidacy qualify. In spite of all these four pre-requisites, the fee of CSQA certification is 350 US Dollars or $450. You must access the payment policy section for knowing accurately about the terms and conditions. Indeed, the certification will be testing your knowledge about assessing the software products and the connected services in accordance with the concepts and principles of Quality Assurance; defining, implementing, and improving the quality control leadership initiatives aligning with the behavior and commitment with management, assessing the baselines of software modules so that the organizations can proactively measure the overall customer satisfaction well. Not only this but also the knowledge, about outsourcing and COTS in the internal control audits, is cross-examined that can simplify the addressed quality assurance plans.

3. International Software Testing Qualifications Board (ISTQB) Certification

This certification is most widely recognized for software testing at a foundational level as well as an advanced level. Currently, expert-level certification is being developed. For all these levels, the working groups of ISTQB are operating internationally so that the candidates can prepare well for the roles like software testers, test managers, test analysts, IT directors, and QA managers i.e. quality assurance managers. In the foundational level (one module), you may either opt for the Foundational Level Core certification or Foundational Level Specialist certification. Similarly, the advanced level (three modules) is divided into Advanced Level Core certification and Advanced Level Specialist Certification. For the candidates willing to receive advanced level certification, they must possess the Foundational one. If we talk about the fees, the foundational level certification costs 229 US Dollars while each of the advanced level ISQB certification costs $249. 

Both these certifications will test your knowledge about the fundamentals of testing and quality assurance; defects, effects, and root causes of test processes, tasks, and work products, basic to the mid-level understanding of the lifecycle of software testing i.e. STLC, configuration management of the automated and agile test cases. Other than the above, tools and techniques for estimating risks (related to testing) and tracking the behavior and development of work products will be included in ISTQB certification. With this, applicants all around the world can plan and schedule the test strategies so that they help businesses progressively develop the deliverables in accordance with the key project requirements.  

4. Certified Quality Engineer (CQE)

The certification for CQE costs around 498 US Dollars and has an examination in two modes. The first one is computer-delivered (in English) which has 175 Questions in total which you need to complete in 5 hours 18 minutes. From those, 160 questions are multiple-choice type i.e. MCQ, and 15 questions are unscored which means they won’t impact your final marks. On the other side, the paper-and-pencil examination (in English, Portuguese, Spanish, Mandarin, and Korean in certain locations) for Certified Quality Engineer has 160 questions that need to be completed in 5 hours. Before getting enrolled in CQE certification, you must have 8 years of experience in one or more areas of CQE or a minimum of 3 years of experience (full-time, paid role as an intern or employee) in the decision-making position (i.e you are involved with the execution and controlling of quality inspection processes) in any of its areas. 

There will be a variability in the set of topics asked like notions of service quality control and evaluation of products’ principles; development and analysis of statistical models, human factors correctly diagnosing the metrology of management information systems. Rather than these, the certification will document your critical skills related to validation and verification of sampling, distributions, and capability studies based on the hypothetical statistics of risk assessment and its acceptance.          

5. Certified Manager of Software Testing (CMST)

This certification assesses the capabilities and competencies of the applicants inclined towards software testing. Soon, they will be working at the ST management level. If one wants to be on the qualifying list of CMST’s candidacy, then any ONE from these three prerequisites must be fulfilled:

◉ Bachelor’s degree in Computer Science or another field of engineering from a college-level [accredited] institution + 4 years of experience in ST field 

◉ Associate Degree + 6 years of experience in ST field 

◉ 8 years of experience in the ST field. 

Besides, there are 100 Multiple Choice Questions from which the candidate must answer 70 correctly for passing CMST certification whose fee is 450 US Dollars. On an overall basis, this certification will assess your candidature on grounds of resource planning, traceability, and controlling of various test processes, implementing and designing the product which will meet the requirements of the customers, and maintenance of releases somewhere related to the quality standards of this competitive market.  

Source: geeksforgeeks.org

Continue reading

DFSS Study: Develop Software to Track Drug Side Effects

Integrating Design for Six Sigma (DFSS), IDOV (identify, design, optimize, validate) roadmap and selected DFSS tools in the information technology (IT) system development methodology can strengthen the business focus of IT system delivery. Adding additional steps at the beginning and end of the traditional system development cycle for DFSS can support the better understanding of the business process and the customer requirements involved, and allow the organization to realize proven business results as well as continuously monitor process metrics.

A pharmaceutical company, Medistar, applied DFSS tools to develop a new pharmacovigilance system (captures and analyzes observed drug side effects) in association with the launch of a new drug. Such a system is necessary since after its market launch a drug is exposed to a much larger population than in the clinical studies conducted during the drug development. This can lead to a change in the known safety profile of a drug. Medistar recognized the need for an updated system using newer technology. Under the old system a physician manually completed a registration form and mailed it to the respective field service agent who then transferred the information manually into yet another system. The information regarding the adverse effect was then forwarded to the pharmacovigilance team. This process was slow, cumbersome and could take several days – too long given the potential consequences of an unidentified risk.

With the launch of the new drug Medistar wanted to play it safe – every side effect should be immediately identified and addressed. From capturing all relevant patient data to the medical director making a decision, all major process steps and influence factors were in the process-scope of the project.

The Identify Phase

At the beginning of the identify phase the project sponsor, the medical director of Medistar and the project manager agreed on a team with representatives from the IT department and pharmacovigilance organization. One of the team’s first tasks was to identify the system needs and what business processes it needed to address. The goal was to understand the process, its internal and external customers and their requirements before developing the system. Therefore, the team developed a high-level process map using SIPOC (suppliers, inputs, process, output, customers). The developers of the SIPOC map recognized that not every adverse event would necessarily entail a counter measure.

Figure 1:SIPOC

The next step was comprehensive voice of the customer (VOC) data collection. The team interviewed representatives from the pharmacovigilance teams, the medical director and the chief executive officer of the company. Most of the customers immediately referred to IT software requirements instead of expressing their needs and expectations with regards to the business processes lying behind the system. Only by repeatedly challenging the answers were the customers’ true process related needs identified. The team translated those requirements into measurable CTQs (critical to quality), which served as the basis for defining key performance indicators (KPIs) for the new pharmacovigilance process.

The translation of customer needs into CTQs and their prioritization was done using quality function deployment (QFD). Accordingly, the two main CTQs of the “should-be” process were the time between a side effect (or event) reported to Medistar and notification of the medical director, and the frequency with which the medical director could make a decision based on this information.

Figure 2: QFD 1

All CTQs were summarized with target values and tolerances in a design scorecard. This was used throughout the project to measure and document the system performance. Since the company already had a pharmacovigilance system in place (with reduced functionality), as-is performance data for the first four CTQs were collected and included in the scorecard.

Figure 3: Design Scorecard

The Design Phase

At the beginning of the design phase, the team created a detailed process of the should-be process. This showed detailed process steps and responsibilities as well as first requirements with regards to the new pharmacovigilance system.

Figure 4: Should-be Process Map

Using this map the team started defining the user requirement specifications (URS) for the system. In a workshop with previously interviewed customers URS were identified and – in order to ensure that all previously identified CTQs were considered – a QFD 2 matrix was used to map and prioritize the URS against the CTQs. The main priorities from a user perspective were a user-friendly input mask and the ability to automatically create summaries and detailed reports.

Figure 5: QFD 2 CTQs and User Requirements

In addition to the above requirements other technical, system and data requirements were defined. For example, the system should include a security system with user access, including permanent access to all information for the health authorities and other specific standards imposed by the company.

On the basis of this information an initial conceptual design of the new pharmacovigilance system was developed, and it was revealed that an off-the-shelf solution was not available. An existing software system, however, could be customized to meet the needs.

Another important step in the design phase was the development of functional specifications in accordance to the previously described system requirements. The team opted for the application of QFD 3, as this could guarantee traceability of the requirements. The team began to define service level requirements for the future maintenance and support organization of the pharmacovigilance system.

The Optimize Phase

The optimize phase was typical for a software development project. It included a detailed adaptation of the software according to the customer needs and the establishment of necessary testing and validation procedures. For the description of test cases the previously created QFD 3 was helpful and provided an overview of system requirements and functional specifications.

The Verify Phase

The added value of DFSS tools in the last phase of software development was to ensure the effective handover of the IT system to the process owner – the head of the pharmacovigilance team.

In coordination with the team leader, the project team developed a dashboard to monitor the process performance. Based on previously defined CTQs key performance indicators (KPIs) were defined – how often they had to be calculated, by whom, and to whom they had to be reported.

Graphic 6 provides an overview of the different aspects of the dashboards.

Figure 6: Dashboard Definition

During the verify phase the users were trained on the new system and the old pharmacovigilance system was shutdown. The transition from the old system to the new went well and was in place prior to Medistar launching the new drug.

Continue reading

Comparing and Contrasting IDEAL and DMAIC

Comparing and contrasting the way different disciplines and tools map to one another can help lead to a better understanding of each of the things being compared. This paper reviews a methodology called IDEALSM, which was developed and evolved by members of the Software Engineering Institute (SEI), and compares it with the Six Sigma DMAIC roadmap and thought process. After a brief review of IDEAL and DMAIC individually, this article examines ways they are similar and ways that they might challenge and inform one another.

The Software Engineering Institute and IDEAL

The SEI has long fostered work in software process improvement (SPI). In response to requests for more guidance selecting among improvement alternatives and getting improvements readily adopted, a team developed the first incarnation of IDEAL in about 1993. The roadmap and substantially current model of the process took shape in about 1996 (Figure 1).

Figure 1: IDEAL Model

In a nutshell, the IDEAL acronym and key activities at each stage can be summarized as follows:

• Initiating
• Understand the improvement opportunity and its context and potential business value.
• Identify stakeholders and the first view of the infrastructure scope and risks that would be required for successful transition of the improvement.
• Diagnosing
• Describe the current and desired states.
• Explore the opportunities and solution alternatives.
• Develop recommendations.
• Establishing
• Identify tasks and responsibilities.
• Set priorities.
• Acting
• Pilot the improvement.
• Learn from the pilot and refine the plans.
• Implement the refined improvement.
• Learning
• Monitor and control the ongoing inputs and outputs.
• Diagnose early warning signals and adjust and control as needed.
• Learn from the ongoing process and make next recommendations.

One can see at a glance that IDEAL is constructed in a way that presumes at least an initial sense of a solution at the outset. That is likely one reason that IDEAL is often referred to as a transition process (more than a problem-solving process).

DMAIC – Quick History

For Six Sigma Belts, depending when they were trained in Six Sigma, they may or may not see DMAIC as having been a core element from the beginning. In the early days, there were the Six Steps to Six Sigma and then an evolution to MAIC as the core roadmap and methodology. As teams underlined the importance of understanding the problem and related goals and scope, a Define stage (D) was added to make DMAIC for many companies. An outline view of DMAIC is provided in Figure 2.

Figure 2: DMAIC Overview

Strength vs. Weakness Orientation

IDEAL is strength based, meaning that it focuses on improvement ideas and an ideal state, driving the planning, piloting and ongoing control connected with bringing that improvement to reality. DMAIC, in contrast, is inherently weakness based, meaning that it focuses on reducing costs or cycle time, driving the use of facts and data to uncover causes, and only then does the focus swing to solutions and implementation.

At first, this distinction may seem a little arbitrary. After all, a strength-based project goal like “improve customer satisfaction” and a weakness-based one like “reduce complaints” are just two ways of saying the same thing. While that may be true on the surface, there are implications that the choice of one over the other can have on the way a team thinks about data and learning.

Increasing yield, which is listed in Table 1, is a good example of a strength-based goal that was popular at Motorola before Six Sigma. Since yield is the proportion of units that survive a manufacturing process ready to ship, it summarizes performance. If yields suddenly dropped from 90 percent to 70 percent, the numbers do not provide much diagnostic help to see where the problem is or what to fix. Strength-based goals encourage a team to lean toward ideas (about how to improve the strength) and the future state.

How might things be different for a team setting out to reduce defects? First, their view is more detailed. They are looking at the defects within the units. This was the most fundamental shift that Six Sigma brought to Motorola. This team would tend toward facts and data (What are the defects? Where are they happening?) instead of improvement ideas. Their metrics would be more diagnostic. When defects of a certain type move from one per week to three per week, there is some information about what is wrong and what to fix.

A last contrast to make involves the reporting climate in an environment. People know when their bosses want to hear good (strength-based) news, and they tend to put the “best face” on data being reported at all levels. This can submerge and subdue details, sometimes to the point where leaders don’t see details that could have previewed or mitigated trouble that surfaces larger and later. On the other hand, companies that see the value in weakness orientation invite the details and the gritty dirty laundry in order to get down to fundamental causes and drivers at every opportunity.

See how that distinction plays out as the discussion of IDEAL and DMAIC continues.

Table 1: Weakness vs. Strength Orientation in Problem Solving

	Weakness	Strength
Example	Reducing defects Reducing complaints Reducing delays	Increasing capability, yield Increasing % satisfied customers Increasing throughput
Use of Metrics	Diagnostic metrics More detail: Defects within units Details support root cause analysis	Performance metrics Less detail: Defective units Rollups that summarize performance
Focus of Team	Facts, the past and present What are the defects? Where are they being found?	Ideas, the future What can we do to improve customer satisfaction?
Impact on Reporting	Surfaces real issues (Dirty laundry okay) Focuses on improvement	Good news tends to filter out detail, favors the best spin

Table 2: Summarization of IDEAL and DMAIC Similarities and Differences

IDEAL		Comparisons and Contrasts	DMAIC
Initiating	Set context Build sponsorship Charter infrastructure	IDEAL begins with a stimulus for change. While IDEAL and DMAIC seek to quantify business impact and align sponsors, IDEAL may focus more on the benefits of implementing an improvement that is at least partly in view at the outset. DMAIC discipline focuses first on understanding the problem (to avoid jumping to a solution). DMAIC emphasizes the importance of results measures and targets.	Charter – goal statement; business case Survey the problem and its context – processes; requirements	Define
Diagnosing	Characterize current and desired states Develop recommendations	While nothing would stop and IDEAL team from applying some of the DMAIC rigor to identifying prospective causal factors, building trustworthy measurement systems and gathering facts and data shed light on what is going on. There is not a lot of specific guidance about that. DMAIC brings graphical, statistical and logical tools and infrastructure for guidance in their proper use (with the Belts system). DMAIC pays strong attention to holding off on solution thinking and recommendations until there has been some real fact-based learning about the causes or drivers that can be verified to influence the project results measures.	Identify factors and causes that may be influential. Challenge the measurement systems that will be needed to convert raw events into useful facts and data. Gather facts and data to shed light on root causes and drivers. Use (patterns and contrasts in) the data to learn what is driving the project Ys – the critical results measures. Verify key causes and drivers.	Measure Analyze
Establishing	Set priorities Develop approach Plan actions	DMAIC brings discipline about not jumping to a solution or even into the solution selection process by paying attention to the breadth of alternatives and the rationale used to select among them.	General solution Alternatives	Improve
Acting	Create solution Pilot/test solution Refine solution Implement solution	Considerable common ground here. DMAIC brings some useful discipline and guidance about creating an effective transfer plan.	Select best solution Pilot the solution Refine the solution Plan to transfer control	Improve
Learning	Analyze and validate Propose future actions	IDEAL pays considerable attention to the ongoing learning that is possible – and necessary – during the implementation and ongoing monitor/control of a particular improvement. That broad view of learning could be helpful to supplement the DMAIC view, which is often more narrowly focused on measures-based, statistical views of control.	Track the ongoing stability and success of the transferred process. Learn from the process – to do DMAIC better next time.	Control

Summing Up

IDEAL is a strength-based transition model because it focuses early on desired state and developing recommendations. From there it devotes much attention to the solution planning, piloting and learning from results.

DMAIC is more weakness based, focusing on the problem (defects, delays, etc.) and the facts connected with it. More visible emphasis is placed on using measures to really get to the bottom of the problem (root cause and Y = f(x) dynamics). Nothing would stop a team from doing this under the Diagnosing stage in the IDEAL model, but the model doesn’t draw out and enforce that data-driven problem solving as rigorously as DMAIC.

IDEAL places more emphasis on ongoing monitoring and learning, after the solution is in place. DMAIC allows for this and encourages it in the Control phase, but with a focus on transfer of control back to process owners, it leaves the ongoing monitoring problem somewhat up to the reader.

In short, DMAIC could teach IDEAL a few things about front-end/problem-solving rigor and IDEAL could teach DMAIC about ongoing monitoring and learning.

Note: Some guidance on the IDEAL model was taken from The IDEAL Transition Framework – Speeding Managed Change by Tom Kimbrough and Linda Levine.

Continue reading