So, what is the best software testing technique for my project? Hmmm, tricky one to answer without looking more closely at your project. There are many factors that determine the software testing techniques you’ll need to employ.
One of the most common causes of software failure and the reworking of code is poor requirements. Implementation of best practice for requirements analysis, specification and validation can have a major impact on application delivery schedule, budget and overall quality.
How do you know if your testing is meeting your business objectives? Not having production incidents may be a success factor but that’s only a small part to testing. Conducting an assessment of your existing testing procedures and practices is key to establishing the actual current state of testing within your business. Doing this will provide you with a tangible roadmap for implementing recommendations to meet your company’s quality objectives.
Testing quite simply is the backbone of every project, whether you agree or not it’s not hard to state that testing has a place in each part of the System Development Life-Cycle. Employing a poor testing methodology will lead to the production of an unstable product and most likely one that will cost you more money and development time. Whether you decide to go Waterfall, Agile or DevOps it is essential to have a plan, especially a test plan, in place to ensure that the product is delivered in a robust and stable state, on a predictable timeline.
In an ever changing and fast paced world, things need to be done quicker. Not only to save costs but consumers need products and services at a touch of a button and assurances that they all cater for their needs first time without fail. Companies are faced with many dilemmas; costs, do a project on the cheap and risk delivering a shoddy project. Time, do it right but take too long and your market saturation will be behind your competitors. Quality, rush a project out the door and risk introducing operational and productions defects. So, is there another way?
Performance testing is simple, right? Well, those who do it will beg to differ. There are some performance testing basics you need to get right first before embarking on the journey.
The Risk profiles of a project or programme of work constantly change over the system development life-cycle. We all know that occasionally a swerve ball is thrown and we must react and adapt accordingly. Usually the project informs testing of the change and in return testing informs the project of the associated risk and details the probability of the risk involved. Testing then needs to be flexible and responsive to these changes to adapt, and to find a suitable solution to offer the best probability of success without compromising quality.
Software Development and Testing can use lots of different methodologies and models, but for this paper we will stick to those that are most commonly used and current in today's market place. Overall the common goal of all testing methodologies is to ensure a bug free product that meets the Users requirements.
STLC - Software Testing Life Cycle, simply put, refers to a testing process regardless of which testing methodology you use (Agile, Scrum or Waterfall etc.), each process will have specific steps to be executed in a predefined sequence, thus ensuring that both the entry and exit criteria have been met through each stage of a project.
In the STLC process, every activity and testing task is carried out in a planned way, regardless of whether you are in a short sprint or a large waterfall project. Each project phase will naturally have different goals and deliverables but the principals of each objectives remains the same – delivering software that is bug-free and meets the Users requirements.
Within each project, there will be a level of detail that naturally alters dependant on the testing methodology, but the key features of the STLC will remain the same whether written into a formal document or scribbled on a post-it note. Here are the key (and not limited too) features of the STLC:
- Everyone in the DevOps team is stressed, or worse still burnt out.
- Releases mainly happen out of core hours and often on weekends and Bank Holiday.
- Your team relies on a single ‘Go To’ person, the only one who knows how to get the code deployed.
- Users are often negatively affected by new releases – bugs in live.
- You might not be superstitious, but your project manager brings into work a lucky black cat, a rabbit’s foot and hangs a horse shoe above the server room door for every software release…!