Software testing allows organizations to decrease risks connected with software development. Its purpose is not to increase product quality, as it is often understood (although it is necessary for quality improvements), but to measure delivered quality.
Does the testing pay off?
Thought out and aimed testing certainly does. It is the responsibility of a test manager to identify the point where testing becomes ineffective. He can infer this by looking at coverage based and defect based metrics.
To make testing effective and efficient it is necessary not only to provide it appropriate inputs, but also to possess a working knowledge of the testing process, to be able to choose and apply appropriate test design techniques, to effectively manage the testing process and report the status and results of testing openly and on time.
Implicit requirements include general domain knowledge, experience with different types of software, different architecture, software life cycle knowledge and at least the basics of modeling or coding.
Additionally, Adastra employees are proficient in related areas of software development such as Requirements Management, Configuration and Issue Management and Operation Management.
As a proof of quality, all test engineers in Adastra hold ISTQB CTFL certificate. See www.istqb.org for more information on this most reputable software testing certification programme.
Testing Methodology
We use the Adastra QVV.360 testing methodology (enhancement of Unified Software Development Process) on our projects, but our experienced test engineers are able to work according to any customer-specific methodology.
When using Adastra QVV.360, it is possible to see the testing process as a sub-project with its specific inputs and outputs. If the project manager decides so, this could be his only interest in testing, because the outputs provide him with all important information about both the testing process and the true quality of the system being tested. But because of one of the key Adastra QVV.360 principles – the full management of test artifacts - it is always possible to find details about testing and trace the test results back to the product requirements and specifications.
Inputs:
- Requirements – the information gathered during the product analysis and design
- Use case model – the system functionalities model, which serves as a contract between customer and developer
- Build – is a working system or its part, intended for testing
- Product – complete software to be delivered on the market
- Glossary – explicit definition of the terms used in the project. There have already been many problems caused by different understandings of “clear” terms
Outpus:
- Test plan - its purpose is to clarify and communicate the objectives of testing. It is often confused with scheduling, which is only one part of the plan
- Test Evaluation Summary - it measures and evaluates the testing process and its results, especially compared to the Test Plan. It has to be available as soon as possible after the end of testing, and partially even during the testing
- Issues – mainly “bug reports” in an appropriate tool, but also any other “points to solve” (like change requests, access request etc.) when fully understood
Features