No turning back. The world will hardly be the same again.

The COVID-19 virus spread is literally impacting every economic sector and every component of every sector. It enforces private local organizations, big enterprises, and entire industries that transform their processes to survive in these days full of challenges.

The fears caused by COVID-19’s power usurpation continue worsening the tragedy of losing lives apart from an immense effect on businesses on all continents.

In the recent research “Managing supply chain risk and disruption” (compiled by Deloitte), the coronavirus is called the black swan continuing to ambush all industries not feeling sorry for anybody.

And managing the crisis impact is becoming a challenge as the world is changing day-to-day, and we can only assume what will happen in a few months. For sure, coronavirus influence on global economic performance cannot be understated. And in the heart of the breakdown, we also see millions of people naturally living in an online environment. It leads to the natural shift of offline businesses to online mode.

In this blog post, we will highlight how companies can meet their planned business objectives with no health risks involved with the help of QA outsourcing.

Be certain in the uncertain times

How to enable your company to remain strong enough? As the unstable situation triggers acceleration for digital transformation, adapt to the rapidly changing end-users mindset – digitalize your business as soon as possible and give consumers what they are searching for.

Imagine the scope of the audience that is moving to an online landscape: you can attract clients that can become your brand advocates and current buyers if they are satisfied with what you are doing.

It is a well-known fact that companies focusing on boosting CX get revenue higher by 4-8% than the rest ones. By now, consumer behavior is modifying. New demands. Growing expectations. This is why the definition of positive customer experience is changing as well.

In retail, representatives are acting in a new way, changing the processes that used to become habitual and clear, and optimizing it as soon as it becomes possible. Indeed, some challenges in this sphere are much like extremes especially when you need to rethink the supply chain.

eRetailers in red zones need to make a shift to more essential products and be sure their digital solutions will fulfill their tasks even if a target audience, which has increased by many times, will opt for their goods. They are having the goods delivery happen more often – for this, QA practices can help ensure the client can see the whole goods variety, order an item, and pay for it in online mode with no system interruption.

With the BFSI industry, the impact is more moderate. When banks workforces are mobilizing to remote work, their consumers are searching for more operational flexibility along with expanded digital banking opportunities. Software testing is here to leverage the delivery of top-tier software products.

How can QA outsourcing help respond to the situation?

The unstable conditions clearly showed the importance of having a truly global delivery model. If not so, a QA outsourcer can provide high-quality B2B technical support of the companies in this critical time of need. In addition to digital transformation, new demand in terms of moving to Agile as well as to the cloud is becoming more essential, and a third-party vendor is up to ensure smooth transitioning during the lockdown.

It is also important for the business to stay focused on the core business needs and anticipate the risks while the partner can accelerate the successful release of the software product.

How exactly can a QA outsourcer support a business?

• Provide an independent assessment of software quality.
• Ensure the increased speed of jump-starting the project in a couple of weeks.
• Reach time and budget savings due to wisely implemented QA solutions like test automation.
• Select the right QA talents with niche and industry expertise.
• Deliver smart team scalability depending on the current needs.

At a1qa, we deeply delve into the business needs of the client to understand its pain points. This is how we created an Aquality Automation platform for test automation to help decreased QA budget and tests’ duration.

Four characteristics of a well-trusted vendor

Now, the deal of every service provider is to continue delivering high-quality solutions to ensure uninterrupted service delivery and not forget about their own business-critical needs.

QA outsourcing can leverage your appearance in the right place at the right time, rather than drown under the weight of changes.

Here are four factors that can help you choose the right third-party company.

1. A solid reputation in the market. Mark positive and negative customers’ references, recognition of authoritative sources, niche certificates.
2. Company of needed size and required competencies. Ensure a vendor is skilled enough to meet your business challenges and has proper QA experience based on the success stories in the portfolio.
3. Clear communication process. Is your initial communication transparent? Do you feel that people talking to you are qualified? Answer these questions to decide on the communication levels.
4. Business continuity during this unexpected time. Ascertain that the company can provide continued confidence that the planned operational outcomes will be achieved.

A really well-trusted vendor provides full immersion in your processes, problems, goals and has already done a mental shift to adjust to the “new norm”.

Thinking about making the right decision in almost total uncertainty? Drop us a line to get expert advice from the a1qa professionals and see how we can support your business.

In today’s post, we’ll raise your awareness of how good quality can be defined and achieved. This material will be useful to project managers and company owners who are running software projects either regularly or on a one-time basis.

Let’s start.

Every project manager knows that when planning a project, it’s essential not to leave any issues up to chance. And it’s not about the software only. When planning a trip, house repair works, or a wedding, it’s vital to take all but tiny issues into account.

When speaking about IT projects, it’s highly important to plan for the scope of work, for the budget and timeline, select the right tech stack and skills that every team member will bring to the table.

However, there is one thing that is often taken for granted. Quality. Believe us on the say-so: high quality is not a matter of course. Quality is as important as budget, deadlines, and toolset. And if you don’t plan it, you still leave it up to chance.

Quality plan: what to include?

For every project, there is a project plan. The point is that for every project, there should also be a quality plan. Unfortunately, very few of us know what it looks like. Right?

A quality plan is not the same as a test plan. A test plan outlines a testing strategy, while a quality plan helps to assure that you will deliver the flawless system.

To excel, make sure you have the comprehensive step-by-step quality plan in place. Mainly, planning to produce a decent software product of high quality is a three-step process, and we’ll list all the steps.

So what are the steps your team should take to deliver a high-quality product, free of flaws and vulnerabilities, and satisfying both the stakeholders and your users?

1. Agreeing on “good” quality

For those who have no or little experience in setting quality goals, this step may be rather daunting. But once you set your first goals, it will be less challenging for you next time.

The simplest way, to begin with, is to analyze what has made us or our clients, or management judge the system to be of unacceptably poor quality before. What made the client go crazy or why the users left bad reviews you’d prefer to delete from the store? Was the software too buggy to be used successfully? Was it slow? Was it insecure?

Try to make a list of all quality dimensions that turned out to be critical in the past.

2. Setting measurable quality goals

Sounds quizzical? Indeed, the budget is set in terms of money, deadline – in terms of calendar dates. How can one measure quality?

Once you’ve completed the list mentioned above (with various quality dimensions that matter), think how you can measure each of those dimensions.

For instance:

• If you care about the number of defects, then apply the “defect density” notion. (Defect density = total number of defects detected in software for a certain period of time/product size, where size is measured in some concrete way, i.e., lines of code).
• If the final performance parameters are important, then you can speak about the time of response (measured in seconds), throughput (bytes per second), or load (simultaneous users).
  Once you’ve identified the key quality attributes, it’s high time to figure out what your reasonable quality goals are.

Previous software development and testing projects will be much of help. However, very often, the quality on the prior projects fell short of expectations. If this is the case, still measure the goals achieved and set new ones with improvements.

3. Planning quality-related works

Defining measurable quality goals is not the end. In order to achieve them, you or your team must do something.

There are three main types of quality-related activities you should plan: detection, correction, and prevention. Let’s specify each of them.

Defect detection activities are designed to isolate defects. “But we have a QA engineer who’s responsible for reporting bugs to the developers”, you might say. You’re right, but are you sure that testing doesn’t happen too late on the project? To answer this, reckon up the costs of the bug fixing activities. How much effort does it take?

You can improve quality by doing more detection activities earlier on the project. The results will astonish you.

To do this, try the following:

• Introduce code review in the early stages of the project.
• Consider implementing a test-driven development approach. Writing the tests first requires a software engineer to consider what he wants from the code.

Defect correction activities are focused on verifying that the bugs that have been detected and fixed haven’t introduced any more flaws or vulnerabilities to the system.

The last (but not the least) kind of activity is defect prevention. If conducted properly, it will provide you with the biggest payoff. Remember a wise saying assigned to Benjamin Franklin? “An ounce of prevention is worth a pound of cure.” The essence of the defect prevention is to consider the problems you faced before, and try to enhance tools, methods, or approaches to keep them from happening again.

Of course, some experience is required to perform defects prevention. Otherwise, it is likely to take too long to search for all possible bottlenecks. We would advise addressing specially trained staff, be it business analysts or QA consultants, to do this work and avoid high rework costs.

Bottom line

In today’s post, we’ve focused on planning for quality. Now you know that alongside the project plan, there should also be a quality plan in place. Have we convinced you?

We’ve also specified how to choose quality parameters and measure them. The three activities you must plan if you don’t want to leave your quality goals up to chance have also been mentioned.

Now you know the route to successful project delivery.

Any questions? To get a free quote, drop us a few lines.

We’ve rounded up 8 most common questions regarding the cooperation with a1qa and the specifics of a project performance asked by our clients at the very beginning. Let’s answer them all!

How to start cooperation?

The cost of services and our testing approach constitute the list of most wide-spread questions within the outset of each project. What testing activities will we implement? What QA solutions will we provide the clients with?

The answers to these questions are unique in each particular case.

However, it’s possible to divide all requests into two types:

• the ones that require fulfilling specific works of a fixed volume
• those that presuppose forming a dedicated team.

The first type of queries is connected with performing tasks for a fixed price, the second – with the assembling a dedicated team.

Let’s discuss both scenarios.

The first option: a fixed price model

In this case, the client’s issue can be solved by means of particular testing service, be it an ad hoc functional or performance testing when the test coverage is previously defined.

If the software under test is a publicly available product or we can compile the desired data without an NDA (non-disclosure agreement), then the preliminary cost estimation will be created without signing additional papers.

To get an exact estimation, NDA is required. We gather the necessary data for preparing a commercial proposal and calculate the price, that can differ from the estimated total by +/-20%. After the cost approval, we conclude a contract, an MSA (Master Service Agreement), and an SoW (Statement of Work). E-signature allows the client to sign the contract online, and the project starts in the course of two weeks after receiving the prepayment.

The second option: a dedicated team model

This variant is more preferable for long-term projects with inaccurate project requirements.

We study the demands set for a software testing engineer of a certain qualification, define the cost of one man-hour, and start forming the team. The client can join the process by examining the CV of each specialist and conducting a face-to-face interview or meeting all project members after concluding the contract.

The legal process is similar to the above-mentioned scenario. The team is put together in two weeks or even earlier after receiving the prepayment.

What if the team is required ASAP?

Providing the team will take some time due to an obligatory legal registration of each deal. However, we are always ready to accelerate the process.

For instance, we may start clarifying the requirements for a team alongside signing the contract. Swift alignment process on the client side will help speed up the project launch.

How to choose the proper model?

If the project scope and deadlines are accurately defined, it’s better to opt for the fixed price model.

Conversely, if you can’t determine the requirements or the time frame of cooperation, we recommend choosing the dedicated team, managed either on the client side or by a QA manager as a part of the team. The tasks can either be transferred to the team or formed in the scope of work. The second alternative is more common for projects based on Agile practices. Thus, progress is tracked. The a1qa specialists will keep the client informed regarding all possible improvements on the project.

The team is selected. How to integrate it into the ongoing development process?

a1qa possesses vast expertise in providing specialists for remote work. If the development stage has already started, the engineers are integrated into the current context. The first vital aspect to consider is the choice of the proper tools – task management, version control, bug tracking systems, and many more. Working with the toolkit applied by the client is a big deal, as it helps seamlessly fit in with the team on the customer side.

One more aspect to keep in mind is the integration into the client’s infrastructure, be it test benches or virtual machines for running automated tests.

Furthermore, the active participation of the a1qa team in communication with the client’s specialists matters.

In order to establish effective communication at the beginning of the partnership, we visit our clients and organize the knowledge transfer to the engineers or team managers.

Then the expertise is accumulated within a particular project so that the client can get the answers to all the questions at any given time.

Multiple communication models – e.g. a lead software testing engineer-a dev team/QA engineer – are observed. Thus, transparency of the working processes ensures seamless interaction with each specialist.

How to monitor the progress of the testing team?

The timeline for the fixed price projects is always set strictly. In the scope of work, the client has real-time access to all the defects detected and test documentation, which allows studying all parts of the code covered by tests.

The dedicated team provides weekly reporting that covers the workload fulfilled, the time spent, and the overall team performance.

During sprint planning within the Agile-based projects, the client can independently manage tasks and establish priorities. However, these activities can be carried out by the QA manager if necessary.

Can a different time zone affect the process?

No matter what the time difference is, the core solution applied by a1qa is shifting the working hours of our teams to reach the maximum overlap in time. Such situations prevail in the IT sphere, and its’ better to tackle them individually.

Meanwhile, if the client is located to the west, we are ahead of time, which is a major asset. By the beginning of the day, the client receives the scope of the fulfilled tasks and logged defects so that the workflow is accelerated.

Having efficiently functioned for more than 15 years, a1qa has never experienced any problems with the time difference. What matters most is the setting of the working schedule, which later can be optimized if needed.

End-user personal data is under GDPR. Will you ensure its safety?

GDPR compliance is legally determined in a1qa. Alongside concluding the contract, the client signs the documents that assure data protection.

Depending on the type of personal information, we apply various data protection mechanisms, from data depersonalization technology to randomized information of unreal people.

Are the processes delivered transparent and measurable?

a1qa is committed to build long-term cooperation with clients and meet all their requirements. Such an approach implies ongoing improvement and optimization of processes within the company, a modern system of qualification and training tailored for its employees, accumulation of technical knowledge and practices within R&D centers.

The majority of clients choose a1qa upon the recommendation, which signifies a high level of trust.

The company is often contacted to provide complex software testing support. Company’s rich experience allows us to deliver consulting services to optimize current testing activities and build efficient QA processes from scratch. a1qa’s broad expertise is the key to estimate the quality of the existing processes on the client side.

With more than 700 FTEs on board and 15 years in SQA business, the company continues to grow steadily. The quality management system is certified according to ISO 9001.

One more indicator of the company’s maturity is the level of industry recognition. a1qa is widely represented in various ratings, we regularly participate in software testing events, our specialists attend industry-specific and cross-disciplinary conferences the world over.

We are glad to share our expertise and go into details of the services, which are of particular interest to you. To get a free consultation, drop us a few lines.

Nadya Knysh – Managing Director at a1qa – on how to decide on the right amount of QA and choose the right test strategy.

Is it possible to choose the single right amount of quality assurance? The simple answer here is NO. And here is why.

There are multiple factors that impact the scope of testing and your testing strategy.

#1 Solution scope

In my experience, about 80% of software projects are delivered using Scrum as the project methodology.

Scrum (like most Agile frameworks) is all about change. New requirements are coming in every sprint, priorities are changing, development is following business needs…

What does that mean for QA?

Well, your planning horizon is pretty limited. Of course, you’ll define your team capacity after a few sprints.

However, you cannot be 100% sure of what skill set may be required in the next sprint – are we testing APIs or UX? Will we have new devices in the office by the time we need to test against them? Will the development team’s capacity impact the deliverables dates? All these questions impact your ability to plan and predict how much QA you’ll need and when. That doesn’t mean you shouldn’t plan, though.

#2 External factors

Imagine you have a one-year roadmap to deliver a brand-new solution to the market.

It’s December 2018 when you start developing, which means Apple has already released its 2018 updates while Samsung is still working on its presentation for February 2019.

Oh, and by December 2019, when you plan to release, Apple will have delivered another presentation on 2019’s new features, hardware, screen sizes, and who knows what else.

So, when planning QA, you should look at up-to-date statistics on what devices your target audience is using to interact with your software.

By the way, the iPhone 7 is still pretty popular, so your first thought might be to include it on the list of supported devices.

However, when thinking from a strategic perspective, by December 2019, the iPhone 7 will be three generations old. So the question is – do you care about it? And what if you do all your development and testing around the Apple Watch and then, a few months before the release, Apple recalls all the devices due to some critical issues?

So, my recommendation is: plan but be flexible. It is not the strongest of the species that survives, nor the most intelligent. It is the one that is most adaptable to change.

What are the most important quality aspects to be tested?

That’s a very good question! But I have found a very simple answer.

A long time ago, I was talking to a solution architect who was developing the architecture for a SaaS solution: highly secure, customizable, and with (hopefully) high performance.

When he was walking me through the architecture ideas (in other words, a draft version), he was explaining why he needed this feature and that feature here and there through quality attributes – a concept well defined in ISO 25010.

The full list of quality attributes is now available all over the Internet. So now, when defining a QA strategy for any of our projects, I recommend reviewing this list again and asking a question: is that important for my product now? In most cases, your answer will be YES in terms of functionality and UI/usability. That’s why you’ll plan functional, UI, compatibility, and usability tests.

Compatibility is the one that is often overlooked.

Always remember that you cannot make your audience use the same browser or smartphone that you do. You have to accept their choice and support whatever they like.

Side note: check your audience geography; people in China use very different smartphones from those used by people in the US.

Let’s say you develop an internal accounting solution for your CFO and two to three other analysts or accountants.

In this case, if one report that you only generate annually takes five minutes to generate, you may not care that much about the solution performance. But what if your solution is a stock market software? Performance is critical here: the market changes in nanoseconds and five minutes will cost you a fortune.

Security is another big topic. Do you store personal information (like SSN and DOB) or your customers’ credit card details? Oh yeah, security testing is a must.

And believe me, you’d rather be compliant with HIPAA, FDA, PCI-DSS, and other regulations than go to court against your customers.

Summing up

To test or not to test isn’t a question in our digital age. Now the focus has shifted toward choosing the right testing strategy that will meet the requirements of the software developed, end-users, and business stakeholders.

Flexible planning and setting priorities related to your product is what will help you make the smart choice.

For more than two years, a1qa has been engaged in the project of the payment system development for a huge banking organization. At the very beginning of the project, the a1qa engineers were responsible for testing the system. However, some time ago the customer asked our team to plan, perform user acceptance testing (UAT), and present the results.

In today’s post, we’ve decided to build the basis for effective user acceptance testing, shed light on its nuances, and answer all possible questions that the QA team may have.

What is user acceptance testing?

When it comes to any new concept, it may be useful to analyze its name first. In technical context (as that of the quality assurance) the name will be literal and will give you the first understanding of the issue.

UAT stands for user acceptance testing. Let’s explain the definition word by word.

1. Acceptance = approval, validation.
2. A user = either the end consumer of the product or the customer who ordered the product development.

UAT literally means that the software will be tested by the user to find out whether it can be accepted for further development and production.

Indeed, long before the product is released to its end users, in most cases the customer wants to know that the product has been developed considering all the requirements and specifications and will work correctly in its real environment.

UAT must be an indispensable part of the projects where poorly developed software can cause huge financial losses.

Thus, the objectives of UAT are the following:

• Check that all preconcerted requirements have been satisfied and the product fits for business purposes.
• Detect last-minute mistakes that could have occurred at the development stage.
• Verify that the product is production-ready.

Who and when performs UAT?

Usually, UAT takes place right before the product is delivered to end users and after the QA team have finished their job. However, in some cases, the customer may want to follow the product development (especially, when the project is too costly and any mistake may result in great financial losses). Then, UAT may be performed twice or thrice per project to validate the right course of work.

During UAT, the product is tested either by end users who provide their feedback or someone who has built the software through an independent software vendor.

As for QA, their involvement may differ and come down to one of the following options:

1. Not involved (a very rare case).
2. Assistance in UAT – QA engineers may be asked to teach users how to use the software, submit defects, etc.
3. Directly involved – The QA team evaluate the software and present the results to the customer who decides whether the product has been developed as expected.

If your QA team undertakes the responsibility to perform UAT, then start with selecting those specialists who possess excellent knowledge of the product and business objectives. He or she should be able to think of the software as a guest user.

After the responsible team member is selected, start with preparing a thorough acceptance test plan (ATP). It will regulate and facilitate the process of acceptance testing planning and performing.

Acceptance test plan: main sections

Usually, the specially trained personnel draft the document. Technical writers, for example. However, the QA team needs to fill it in with relevant data and keep it updated.

Let’s look through the contents of the typical ATP and briefly outline the contents of each section.

Introduction – the name of the product under test, background information, and product functionality.

UAT objectives – generally, these are the ones we’ve stated above.

Scope of requirements – the list of environments that must be verified during the testing procedure.

Pay attention that the requirements that are enumerated in this section must be demonstrated during the testing procedure (or at least, they should be planned for). If 100% of requirements have been implemented but only 70% can be demonstrated, then the customer will consider the remaining 30% as non-implemented, until the opposite is proved.

UAT tools and procedure – the list of all technical software and hardware tools applied during testing and the procedure. We recommend to specify all the tools that will be applied during the acceptance testing: databases, consoles, log files, automated tests – all this should be mentioned in this section. Otherwise, you won’t be allowed to use them during the acceptance testing process.

UAT methods – specifies how the demonstration is conducted, what methods are used to verify the implementation of a particular requirement and the expected result for each verification.

UAT exit criteria

As a rule, the criteria that must be met to formally end acceptance testing are determined at the stage of contract signing. One of these criteria can be the percentage of successfully passed test cases.

For example, if 100 test cases have been implemented and the pass rate is agreed on 80%, then 80 test cases must be successfully passed. Otherwise, the product won’t go through UAT and won’t be admitted to production.

However, most often the success of UAT is evaluated by the set of criteria. For example, the percentage of implemented requirements and the number of defects of certain priorities. Based on these results, the customer will judge the readiness of the product.

This ends the necessary theory that the QA team should be aware of before committing to UAT. Jump to this article to learn about 4 main challenges you might face and ways to overcome them.

Next week we’ll tell you how our team demonstrated the results to the customer and ensured the product successful release. Stay tuned!

When talking about bugs and defects detecting, the two most common problems are:

First, when you read the bug description and can’t understand what it means. These unclear defect reports can come from users, customers and beta testers, saying things like, “I pushed the button and everything collapsed.”

Second, how do you handle it when the real challenge is not in fixing the bug, but in “decoding” the report about it?

I have provided some step-by-step instructions below that can help any automated testing company in such situations.

Write your own algorithm

First of all, let’s think about the nature of all those defects with indistinct descriptions. Why does everyone write bug reports in his own way? Well, there are many reasons – the most common being “underqualifying” or “overqualifying.” On the one hand, it could be a tester who is new to the field and didn’t describe the bug correctly. On the other hand, a tester could be so experienced that he treated the bug as an unimportant one. You could also have meticulous developers and project managers reporting bugs.

In all of these cases, bug reports are written inaccurately in one way or another. The best solution, therefore, is to create clear regulations for dealing with bugs – a detailed algorithm on how to describe and fix bugs. Any form for that algorithm could be chosen; most importantly, it should include the three following points:

1. A list of attributes that must be filled (in other words, which graph and how should the graph be filled);
2. A description of the defect life cycle, accepted by all project members;
3. A list of parameters and samples for every stage of the life cycle, if possible.

Do not be afraid to spend a couple of hours on this writing detailed regulations step, since it will save you time in the future. Also, if you have well-structured regulations approved by your team, you can always refer to them when you find yourself in the middle of a controversial situation that requires a fast decision.

However, it is not enough to just write the regulations. The second step is to persuade every team member to follow the regulations you developed. To achieve that, you should develop an agreement with everyone involved to move all bugs that do not match your regulations to the “better definition required” status. Since the automation of that stage is impossible, the project manager is the one who will ultimately be the judge on all controversial defects.

Automate bug registration

Once your team agrees to follow the bug reporting regulations you have defined, it doesn’t mean all bugs will be reported automatically. We can’t forget about the bug reports from customers and users, as well as from beta testers, none of whom are part of the team that has agreed to the regulations. While you are not going to teach them how to report on bugs, you can create an algorithm for reporting. How, you ask? Consider the creation of a reporting form that excludes loose descriptions. Also, every field should have as many preinstalled parameters as possible, describing possible problems.

Another approach is to automate bug reports. Let’s say a user has a button he can push to report the bug he found (configuration parameters, logs, screenshot or even a video showing last activities of the user). A good example of this type of bug reporting function was used by Microsoft – useful when they released the first versions of Office and Windows.

Quite often, users don’t even need to push a button. Android and Apple apps offer to send a bug report to developers once it has collapsed. Even more, platforms like Ubertesters allow users to test apps themselves, which helps developers and testers to automate the bug reporting process.

Nevertheless, you should be really sensitive when thinking of installing the bug-report button, because it has the potential to scare users. Imagine when a user installs an app and sees that button. He may be under the impression he has installed a bugged product. Also, you must keep in mind limitations on a user’s confidential information, such as direct reporting from his own device.

In prior posts, I have discussed test models as a package of test scenarios. Each scenario has specific requirements. The development of software for the telecommunications industry deals with large systems like OSS/BSS, and requirements creation is the initial phase of the project.

This phase is critical, as requirements errors can result in wasted time and increased cost. Analysis shows that the later readjustment phase can consume 30 to 40 percent of the total effort expended on a software development project.

Researchers have even indicated that about 50 percent of the bugs can be caused by requirements errors; thus, requirements errors may lead to between 70 to 85 percent of all project readjustment costs.

As you can see in Figure 1, the correction of requirements defects can cost up to 110 times more if found in operation than it would if the same defect had been discovered during the requirements definition phase.

We as QA consultants advise that two main parts of the requirements creation phase should be separated – into requirements development and requirements management.

The requirements development phase aims to collect information, make analysis, review and approve requirement. As a rule, it results in documents package creation. These are documents about image and product borders, software requirement specifications, data vocabulary and a corresponding analysis model.

The review and approval of this package defines the base requirements version (i.e. the agreement between developers and customers). The requirements management stage includes all actions supporting integrity, accuracy and timeliness of renovation of the agreement on requirements during the project.

Management of requirements includes:

• Management of changes for the base version of requirements;
• Maintenance of project plans actuality according to changing requirements;
• Management of versions of separate requirements and the documentation of requirements;
• Control of a condition of requirements in the base version; and
• Management of logic connections between separate requirements and other materials with the project.

The best practices and characteristics for requirements management are as follows:

• Completeness – Each requirement should completely describe the functionality that will be implemented in the software. In other words, it should contain all information necessary for developers to create the fragment of functionality.
• Correctness – Each requirement should describe the desirable functionality precisely. Connections (links) with sources of requirements is necessary for correctness.
• Practicability – Possibility to implement each requirement under certain conditions and restrictions imposed by the system and operating environment. Here it is needed to provide interaction of developers with experts in marketing and analysts the ability for extraction of all requirements.
• Necessity – Each requirement should reflect what is really necessary for users or necessary to meet external system requirements or standards.
• Setting of priorities – Setting of priorities is necessary to cope effectively with budget reduction, infringement of terms, loss of personnel, or the addition of new requirements in the course of development.
• Clarity – All readers of requirements should interpret them the same. All special and potentially confusing terms should be provided in a glossary.
• Verifiability – Requirement management helps to identify the incomplete, not agreed upon, impracticable or ambiguous requirements.

IT management needs to first have a solid understanding of budgeting concepts to effectively use the IT budget as a management tool. Then, they must focus on business needs and how the IT organization can address these needs through the use of IT. Finally, IT management should communicate the approved IT budget to all stakeholders to share the information about available resources throughout the organization.

Two IT budget allocation strategies

1. IT budget is formed as a percentage of revenue or on the basis of costs per employee; in this case, IT budget usually ranges from 2% to 4% of total income.
2. IT budget is formed on the basis of the RGT (Run, Grow, Transform) model. This means the whole IT budget is split into three parts depending on the project development stage of run, grow, or transform. The model has drawbacks, but its advantages outweigh the disadvantages when it comes to IT budget planning.

According to industry analyst firm Gartner, companies spend up to 66% of their IT budgets for project launch initiatives (i.e., on what needs to be done to implement new IT systems). The remaining funds are split 50/50 between maintenance and new research and development (R&D).

This means most companies can allocate only 17% percent of their budgets for R&D needs. When you consider that companies typically generate 70% of company income as a result of R&D efforts, you can see a clear imbalance.

Dynamic market conditions, changing technologies, and continuous improvement require more IT financial transparency than ever.

Demand-side drivers of higher IT spending as a percentage of revenue include:

• Highly integrated IT components in the product suite
• Higher service levels for mission-critical systems
• Higher usage of knowledge workers
• Decentralized IT environment.

IT management is constantly under pressure to understand how to free funds from an already allocated budget. They are reallocating resources within the budget through traditional process automation, cost optimization, service management, and externalization.

Therefore, the question becomes: How can we increase the share of R&D in the IT budget of a company without changing the desired value of deductions from the IT budget – thereby achieving the highest efficiency of R&D and increasing the company’s income? The answer lies in increased attention to the quality of IT projects at and before their launch. Incorporating testing and requirements analysis early on will help to reduce unnecessary spending, allowing companies to use funds for other important projects.

The article was published at NetworkComputing, you can also read it here.

Have you ever found yourself in a multi-tasking environment dealing with a range of small IT projects at the same time? Chances are, yes. If that is the case, keep reading, as it is my goal with this article to provide recommendations that will help better set priorities, allocate tasks and balance the workload among the participants, using the example of small-scale projects in software testing.

Most people think that working with small projects in QA is quite simple, because they are short-term, small and do not require too much effort. But they are quite mistaken. Imagine 15 small QA projects “in the task list” for one tester in one month. You might say 15 different tasks can be “stacked” within one large project, nothing unusual. But let’s have a look from another angle.

Each of those projects is headed by a project manager, which means you have to deal with 15 PMs monthly and about 45 software developers, each of whom has various questions, desires, plans and personal interests. This is when managing the workload and still managing to be effective can become challenging.

And it’s no wonder when each of the 15 PMs requires his/her project to be tested as soon as possible; many may say they “want it done yesterday.” In order to control the flow of spontaneous desires PMs express, and have a clear plan, you need to use a Query Forecast for the near future. This instrument is considered to be indispensable in these types of circumstances.

You can “shape” it with any convenient form (MS Outlook, Jira, or any other tool that allows you to obtain systematic information). What is most important is that you not waste your time questioning each of the PMs, and make it clear to the development team that they must provide planning info up front.

Once a plan is in place, PMs tend to get “on fire,” and they all want to test the projects the same day; no one is willing to concede. This is when the “live line” principle is applicable – the team that sent info earlier and chose a free day captures the tester’s attention. This encourages project managers to not postpone things until the last minute and promptly respond to such requests.

The “live line” principle certainly has value when it comes to improving proper management; however, some other circumstances should be considered. Some urgent projects may have a release date right around the corner. Quite naturally, such projects should come in line before less immediate ones. Builds are also different in size. One may need four hours of testing, while another may need 32. There is no need to make a small build wait a week. Sometimes plans change; imagine the build, planned for instance, from Monday to Wednesday, has been canceled. Accordingly, with these three days freed, we can admit another project (the “free cash” principle).

When a project manager is a former developer himself (which occurs often) and burning with desire to check bugs just after fixing, he may focus on one bug when handing it off to the tester while not mentioning 50 other existing bugs, which is unfair to the tester. In order to prevent a nervous breakdown for yourself, be clear with the PM that the build will be accepted for testing only when all active defects have been corrected.

Incorporating “risk” time into the testing timeframe you promise to the PM is generally acceptable. If you end up completing the project ahead of the estimated time, of course, the PM will likely be grateful.
Regarding timeframes, another consideration is that developers are rarely punctual in providing builds for testing. For example, you were promised to get one at 9 a.m. The developer arrives at the workplace at 10 a.m. and says the build will be ready in a half hour. Midday arrives, and you are informed that the developer is already in the process of writing the notification, but in the evening, the developer says something went wrong and the scope of work will be provided the next day.

Now we have two problems. The first is that you already have another project planned for tomorrow, and the second is that you ended up with no workload during the day. The solutions to these two problems are flexibility of staff planning and a “pool of tasks.” Thus, employees are able to solve the problem by taking the task out of a pool, or offering assistance to an overloaded colleague.

Testers usually deal with projects containing two hard limits: overall timeframe and time spent for a particular project during each day. For such projects, you always need a pre-planned strategy, and the approach of “we’ll see how it goes” does not work. So, set a time limit – for example, a half hour on research and an hour to create test documentation.

Another situation that could arise is when a lot of different testing combinations are needed. For example, a webpage or an application form of any kind may have five drop-down lists, each containing 50 unique values. To check all the unique combinations, you need a lot of time, which is not always acceptable for small projects. In such cases, the test matrices are applied in order to check optimum combinations for a limited time.

In conclusion, one should say that working with a large amount of “small” projects is not so simple. The advice presented in this article could be useful while managing several small IT projects as well as bigger one with many tasks. You will find you have a significant advantage if you learn how to incorporate the aforementioned techniques.

Setting up a test framework is no easy task when it comes to choosing the right approach. In the article below, we discuss the object-based design as the one helping to cut required resources and time.

Object-based design, or object-oriented design, is called for to validate object-based code, which includes testing of requirements, software design, code itself, and integration. This approach helps not only to create a simple-to-understand and easy-to-use hierarchical structure, but also assists in development of more flexible systems. Object-based design typically helps to get a higher level of abstraction that could increase understanding of the complexity and costs.

In addition to that, it significantly decreases the time of test development and support. So, in some way this could work, but how to cut both time and money spent? To explain this, we should mention other approaches widely adopted in QA outsourcing – the one based on behavior and the other based on keywords.

In the behavior-driven approach, testing is carried out based on how the system behaves, and together with other approaches to designing test frameworks, can give a more comprehensive overview of how system objects interact with each other and whether they meet user expectations. In the keyword-driven approach, testers simulate user actions too, but all of their activities revolve around certain keywords such as ‘closing a window’, ‘clicking the contact button’ and the like.

Object-oriented design can be opposed to behavior–based (or keyword-based) design, although it wouldn`t be correct. Just like with the behavior- and keyword-driven designs, you can use object-based design along with almost any other approach to test design too, for example, unit testing. For those testing professionals combining a few approaches, it could possible to get rid of negative effects thanks to the basic structure resulting from the application of object-based design, and the simplicity of keyword-driven testing.

Also, object-based design is in some way based on hierarchical patterns. Your test framework should use the class hierarchy to maximize the test coverage and to re-use tests or even test suites in subclasses. This approach is also the key to testing abstract classes. The hierarchical testing is based on the substitution principle, which means that an instance of a subclass can be used anywhere as an instance of its super-class. This is generally considered to be one of the main rules of object-oriented programming, so using this in a test framework can even encourage better object-oriented design.

One important notion to keep in mind is that the object-based approach isn’t always applicable. For example, if the tested system cannot be split apart into simpler objects and is purely functional, it’s better to consider another test design, as it is likely to serve better.

We’ll keep covering various testing methodologies, in particular, keyword-driven testing along with its advantages and drawbacks, so stay tuned.

The article is prepared by Yan Gabis