test management

You have got an idea of a useful, high-tech application. You have gathered a dream team of like-minded people – technical specialists, and those who can help you arrange the development process – first-class managers.

QA outsourcing service rates are finally revealed. For the sake of a true comparison. For the love of statistics. To bate your curiosity. Here it goes. When it comes to the outsourcing budget, a key point is understanding your business goals and determining the desired success criteria. There are two major options that companies include into consideration before product development: hiring in-house employees or dedicated teams of developers and testers. Quality Assurance is a part of product crafting that's mistakenly considered not as important as code development. In fact, testing has to be an integral constituent and the sooner you will engage QA experts on the project — the better your results. In-house testing vs outsourcing Outsourcing is cheaper than hiring in-house QA employees. However, not all of us know how cheap exactly it may be and why. Let's say, you have a bunch of code files that need to be tested. The estimated testing time is 100 hours and the number of testing engineers you plan to involve in this process is 3 experts. Take the average hourly rates of the in-house employee and that of a tester from Eastern Europe. Consider taxes, bonuses, travel costs, and here's what you get: The difference in pricing is not only impressive, but it explains why enterprise-sized companies tend to outsource big loads of data for Quality Assurance. Now, we move on to even more numbers. QA outsourcing rates by location First-rate software testing services are believed to cost a lot, for they're a highly-demanded solution in the world where ~1000 apps are released every day. Indeed, Glassdoor claims the average Quality Assurance Manager earns $70-100k yearly, while QA experts at such companies as IBM, Amazon, and Sapient earn $100k+. Of course, they do, in the home of Silicon Valley. What about other countries? To dig even deeper into the topic, we review QA costs of the major tech hubs around the world. QA specialist salary in the USA In American Express and Apple Computer, Quality Assurance specialist salary is averagely $100k a year, which is approximately $52 an hour. As the stats show, other companies pay employees with the same level of expertise a bit less. However, QA & testing services in the USA are still considered one of the most expensive in the world along with the UK and Australia. Let's see how the experience factor influences the cost of QA & testing services: Entry-level QA managers (0-5 years of experience) earn 8% ...

What may inappropriate test management turn out into? Insufficient Test management may lead to many harmful results. There are many foul directions one may take and seemingly people often do just that. Here are several examples of what cannot be called test management, some of them are a real pain to somebody, who is in quality assurance and quality control: Testing is very expensive, hence it is a luxury we may live without. This is getting ridiculous. Surely many companies have already understood the value of proper software testing but there are still several suborned ones ignoring entire world because they did things the way they are doing now 20 years ago and have succeeded then. Nothing’s different now, right? I will not be writing much about this approach. I’ll just note that it is wring and corrupted to its very roots. And now we move on. What about squeezing testing in the last couple of days before the release? That sounds like a wonderful idea!  Wait, what? OK, if you truly believe so, but consider this. What is testing done for in the first place? To validate software quality, meaning to find defects and bugs that are 100% out there in the code. So you are done with testing, you have found some bugs that are critical, hence require fixes and you have a release tomorrow. Something dos not seem right here, does it? Why should I understand testing? I’m a manager after all, I understand people. Surely managers do not require to possess all the skills of a professional tester but the process is not all about people. Some basics of project workflow are required knowledge. What if something unexpected happens? What about risk management? Which deadlines can be moved and which testing sessions may be decreased in time without vast losses in end quality of the end product? People are expensive as they are. More people means less tools are required. That could save me some dollars. That’s not how things work with software testing. Automation tools are best used for tasks that are repeating to often that your entire company staff won’t be able of doing in on time if all’s done manually. No tools equals improper use of man-hours and effort, equals poor quality, equals money losses that are far greater than the ones you would spend on required tools. Testing may and is to be completed within a certain deadline drained from an ancient estimate. Deadline is a great thing you are to meet, right but it can’t be a tool for measuring testing ...

The process of test together with test case execution tracking and documentation is called test management. Surely there are many tools available to assist testers with this process hence both automated and manual tests are managed with more ease. That is if the right tool is chosen. Which tools may be required? There are times when test scenarios are complex meaning require to be defined and teams require performing tests against different configurations. Such situations will require tools that are more advanced. Such tools will also keep track of different milestones, will provide statistical data as well as detailed reports, etc. Are there any open source tools that will fit your team’s requirements? Perhaps, the decision is for you to make. But here are several tools you may choose from. Maybe they will do the trick for you: Mozilla Testopia. An extension for the well known Bugzilla, Testopia is a nice tool to do your test case management. Its design allows it to be a nice generic tool made for tracking your test cases and organizations are allowed to integrate defect reports into test case run process results. Bromine. Selenium RC is this tools testing engine. Hence tests are being created within Selenium IDE format. Afterwards they are being uploaded directly to Bromine. Radi. A nice tool of light weight. Generally it is a pretty test management tool with additional features of requirements management as well as bug-tracking. Salome-TMF. This is an independent tool for, obviously, test management. The tool will assist you all the way through your testing process. Script creation, test execution, result tracking and produce documentation: it’s all there. Test Case Web. This is an online test management as well as tracking system. PHP and SQL are on it’s back-end. TestLink. Another web-based tool that provides test plans, specifications, reporting, requirements specification and executing features. TET. TET aka Test Environment Toolkit as a product is an unsupported command-line tool. Tarantula. This tool’s source code found its place on GitHub allowing a far more easier collaboration. Hopefully you have found exactly what you were looking for. Perhaps you have any other tools you currently are using and are pleased with? Please share them in the comments!

PRM What is Project Risk Management? This definition stands for a row of activities that are related to the conduction of project risk management planning, identification as well as analysis. The major objectives of PRM are the increase of the positive events and impacts on the entire project. On the other end of the sword there are attempts of decreasing the probabilities of negative events happening and their impact on the project as a whole piece. Sounds quite a QA thing to do to me. What can you, as a QA specialist do for PRM? In order of getting to the point we have to be sure we are aware of the PRM cycle. PRM begins with identification of possible risks. That is pretty much experience-based data that is gathered from similar projects that are or are not finished. Now who better than a tester will know of the bugs that might occur it the particular project and ways of fixing those? He’s done it for like a thousand times, right? The next step is assigning possible issues with priorities. How crucial might that bug be? How much time was spent on solutions earlier? May all that data influence deadlines or the project quality? Experience may actually show you what are the odds of a particular issue popping up in the middle of the workflow, how crucial it may be and what impact it can be surrounded with. Then the risk treatment steps on the stage. The first thing you want to do is avoiding the risk. The second part is risk transfer. If you fear that you won’t be able of managing the possible risk, then inform your management. Software testing services are provided by multiple outsourcing companies. Allow them to do that job for you. Now to the risk mitigation part. This one is about reducing possible risks and their impact on the project. For example, if a new team is working on a project give them at least one experienced QA specialist that has been through ice and fire and will be their guiding star. Thus with a proper quality assurance team you are not risking too much. When everybody in your team is working on a common goal your services as well as your software are not risking. At least not too much.

In the previous post we’ve considered the 8 stages of a regular defect management process. However, the right functioning of your defect management system greatly depends on the tools you will choose to utilize. Defect management tools should have the following core features. Having a centralized repository aiming at tracking defects throughout the projects. Providing the automated notifications about resource assignments. The ability to define the status of defect resolution so that to map back into the defect management process. The ability to deliver management reporting, such as a set of open defects classified by various criteria like defects by project, priority and severity. Here are also some optional features that should be considered while selecting a powerful defect management tool. The ability to capture not only defects such as project-related issues and customer suggestions, but also other Items like enhancement suggestions or customer complaints which often get lost if are not logged in the centralized system. In case other tools are unavailable, your defect management tool may be used for tracking these items types as long as it’s possible to easily filter them out or separate from defects logically. The ability to support either internal or external teams. The feature gives the opportunity to engage external teams and customers in some situations, if appropriate. In addition, your defect management system’s effectiveness also depends on the organizational culture in which it operates. It makes sense for most environments to utilize processes and tools that focus on the tracking, identifying and defect resolving speed. This gives the basis for perceiving root cases as well as making appropriate improvements in the process. If the team (or organization) culture considers defects negative, people tend to spend more time while trying to avoid them and are also less likely to provide report on defects when encountered. All this may lead to many defects identified later during the process, when it’s harder and more expensive to fix them. As practice shows, organizations considering defects part of the process tend to deliver software faster and of higher quality than those considering defects negative occasions worth blame.

Software development and testing teams have a wide choice of tools for defect management which help support different software defect efforts. However, selecting and utilizing the right is only part of the whole defect management system. Basically, defect management systems consist of the combination of different defect management tools and defect management process. The two major components work together supporting each other. If you ignore either one, you risk receiving sub-optimal results. Therefore, below we present an overview of the average defect management process. A regular defect management process involves the following common process steps. Identification This stage suggests the discovery of the defect. Hopefully, someone of the QA team should discover it. However, in reality it can be anybody including other individuals of the project team and even end customers on rare occasions. Categorization Once the defect is reported, it is usually assigned to the designated team member in order to confirm it is really a defect rather than an enhancement or any other appropriate category defined by the company. Prioritization This is usually based on the combination of the level of impact on users, relative fixing effort as well as comparison against some other open defects. Often the prioritization is done by a formal control board of changes depending on the organization’s size and structure. The priority is determined with from the management, customer and project team representation. Assignment After a defect is prioritized, it is assigned to the developer or some other technician for fixing. Resolution Then the developer fixes this defect and moves its fix back to the environment in which the defect was identified originally. Verification According to the environment of the defect’s location and its fix’s application, the testing team or the customer normally verifies that this fix resolved the defect indeed. Closure Once the defect is resolved and verified, it should be marked ‘closed’ and move on to the last stage. Management Reporting Appropriate individuals should be provided with management reports at regular intervals according to the defined reporting requirements. On-demand reports can be additionally provided when needed. In case of implementation inside a specific organization, these steps would have somewhat more detailed operating procedures and policies of executing the process details. In Part 2 of our ...

It’s well-known that different personalities contribute better into a strong team. Speaking of a testing company, this heuristic is also true, so it’s a wrong idea to choose one comfortable type of tester to grade the rest people against it. Instead, team leaders and managers should explore different patterns of temperament and skill among testers to gather a solid team. Let’s consider the following types of testers and differentiate their strong and weak points. 1. Administrative Tester Strengths: They like doing the tasks right, clear the obstacles and get things done. They enjoy the paperwork about testing, prefer to attend the meetings, get the resources, track the agreements, update the dashboards etc. Weaknesses: They are inclined to care more about visible apparatus of testing rather than on some intellectual details. 2. Technical Tester Strengths: Speaking the same language with developers, they are great testability advocates. They think generally in terms of programming code, are acute in building and using tools. Weaknesses: Preferring to learn about tools more than about testing, they tend to avoid testing things they can’t easily test with their tools. 3. Analytical Tester Strengths: They love models, typically enjoys mathematics, create matrices, outlines and diagrams, read long specs and prefer combination testing. Weaknesses: If they feel they can’t model some test case easily, they are prone to ignore it, which causes their planning paralysis. 4. Social Tester Strengths: They acknowledge that no individual can have the whole problem solution and prefer working in a team rather than alone. They strive to cultivate credibility and services they can offer others. Weaknesses: Such testers are inclined to laziness and too much talking at the work’s expense. 5. Empathic Tester Strengths: These testers are always immersed in the product since they see empathize with users their primary method. People with no technical background primarily adopt this pattern following with social and administrative tester patterns. Weaknesses: They often have problems with expressing in words what and how they are doing. Thus, only after learning about these tester types and analyzing the strengths and weaknesses can managers fulfill their task of a perfect team building.

Testing is an important stage of software and web development processes that should not be overlooked. Test manager is a key person bearing responsibility for the testing process. Thus, he should possess some trait essential for executing tests effectively. Here are the 7 features we see as key traits for any test manager to have. Communication Test managers have to effectively communicate the information to developers, project managers, business stakeholders and other people with different needs. Since test managers operate with data a lot, they should ensure that the data is delivered to and understand by every person involved in the testing process. Political Agility Since your job as a test manager is to organize the testing team’s work and see that the project meets its deadline, you have to influence and motivate people to work somehow. You key features here should be a politically astute manner, tactfulness, sticking to the facts and authority. Time Management As testing is often pressed for time, stressful and hectic, you should exercise wise time management so that to acutely respond to such situations like a critical failure to the test system, some changes to the test plan in the last minutes, emergent staffing issue and weekly reporting on the process status altogether. Technical Ability No matter what your background is like, if you want to succeed at your post as a test manager, you should have sufficient technical ability in order to get credit with test developers and engineers. Attention to Detail To ensure the test team has a proper test coverage test managers are required to know details of test cases and requirements as well as the overall testing status, the reasons planned test cases failed to be executed, the major defects’ exact status etc. Analytical Ability A must for a test manager is to truly understand what stands beyond each number in test statistics and be able to teach this knowledge to other members in your team. Testing Discipline If you want to lead the team of testers, you have to be really good at testing yourself and know such things like building a test strategy and plan, writing and planning test cases, effective usage of testing tools, conducting exploratory testing and many others to provide help when the staff needs it. Possessing the features given above will ensure that you are a professional test manager.

Onsite offshore model is a very widespread working mode for most of IT teams, the QA teams in particular. How it works? One of the QA team members, the service provider, works with the client at client’s location. The client location and the service company’s work place can be situated in any place or be in the same city. How it works? Responsibilities of Offshore team: work on test cases; sign off the test cases; works on documenting the test cases; prepare test data; execute the tests; report defects; prepare test reports; provide inputs for test metrical collection; take part in the defect review and other project related meetings. Advantages of Onsite – Offshore Software Testing Model: 1. This model can assure that there is work going non-stop, if to use it right. 2. Face-to-face client-team cooperation helps to build better communication and also enhances the business relationship. The information about the systems and the client’s requirements will be available for you. 3. Cost effective – offshore teams cost less and can easily reduce your expanses on this. There are some expectations from the Onsite and Offshore resources. They are the following: Responsibilities of Onsite Quality Assistance supervisor: Conducts client-to-team experience. Receives the technical knowledge and share it with the team. Distributes the functional requirements document and works on a test plan. Examines the test cases with the client team and provides a sign off. Maintains consultations on the test data preparation phase. Communicates time lines, progress, delays etc., from the team to the client and vice versa Supplies directions on test execution. Executes the smoke and sanity test on any deployed build and gives a go ahead for the team to continue testing. Participates in the test execution Conducts meetings on defect review with the concerned development and support teams. Collects metrics. Supports UAT. However, some of the common complaints we hear in our software projects are: Onsite resources say that offshore resources don’t know what they are doing and are not available when they need them. Offshore teams complain that they are not getting the right inputs they need. To avoid this: Remember that onsite and offshore are two sides of a coin. Nobody is more and nobody is less. The two counterparts should coexist in harmony; otherwise this model will be eventually broken. Make sure you cover at least one ...