Aundria Richard Technology

Software Quality Assurance
Software QA involves the entire software development PROCESS – monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to ‘prevention’.

Software Quality
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is obviously a subjective term. It will depend on who the ‘customer’ is and their overall influence in the scheme of things. A wide-angle view of the ‘customers’ of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization’s management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc. Each type of ‘customer’ will have their own slant on ‘quality’ – the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.

Software Testing
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, ‘if the user is in interface A of the application while using hardware B, and does C, then D should happen’). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ‘detection’.

• Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization’s size and business structure.

We have all been there, on a project where the inevitable has happened. You guessed it, the code is late into testing, delivered at the 11th hour. Entry criteria has come under threat and possibly been ignored completely. Your test environment has been delivered but remains unproven as the code has not been available. The Project Manager has been harassed by the business stakeholders for the development delay and is not interested in your problems. IT Management are pressing to see the project delivered on time and to top it all, Marketing have arranged for a campaign launch to occur on the prescribed delivery date. As the Test Manager, you are now the primary obstacle to go live; the success of the project is resting on your shoulders. Oh yes, and your six week testing window has been reduced to four.

This is the stress (no pun intended), of the test execution phase. Not only are you now required to think out of the box in order to complete the testing, but you must also be thinking at a far wider level than just testing. There are actions that can be taken at a project level which can make a massive difference to the work of the testers.

Let’s start by looking at this from the wider perspective. I remember a situation on a very early project I was managing. Sat in a project progress meeting and being asked how we could test with an execution window reduced from four weeks to two. I dug my heels in and refused to budge, resulting in a separate meeting immediately afterwards with the PM, being instructed that this was not the right course of action and getting some early tuition in the art of testing.

I am not suggesting that these are the only questions that would be asked, but are some samples for consideration. These are questions that I have used when interviewing others:

1. How many test scripts can you write in a day?

I am looking here for the ability to estimate. Whilst in reality the question is impractical, because it depends on so many different factors, I want to see the interviewee come up with some kind of answer. When estimating, there is a need to make assumptions and having a ball park figure enables someone to provide rough estimates more quickly.

2. How many test scripts can you execute in a day?

This is a repetition of the first question. I normally ask one directly after the other. The more junior resources tend to struggle with the first question and then the second also. The better resources learn from the experience of the first question and respond in a more positive manner to the second. Now I am not only looking at the ability to estimate, but also the ability to learn and an indication of the resources chances of seniority going forward.

3. Do you see testing as a service or a discipline?

Personally I am quite passionate about this one. I very much see testing as a discipline and a part of the software life-cycle that is as important as analysis, design and development. What I am trying to understand is the background that the individual someone has come from. Consultancy can demand one or other mindset and someone coming from either background can adapt, but I would suggest it is easier to revert from discipline to service than vice versa.

4. What is the most interesting defect you have found?

This is a passion question. I am looking to see if the individual can recount a particular incident and in what degree of detail. This begins to tell me whether they are a career tester or someone who is doing a job.

5. What are the key components of a test script?

Several advantages have been cited in using software test automation. If you were a businessman, then you would understand the saying that time is money. The explanation here is that every time a specific task, which is best done when being automated, is done manually, time is actually waster. Correspondingly, your business will lose money. The same is true with software development. There are tests that can be automated that will likely fast track the whole process of developing the application. In effect, you get to save in terms of time and cost.

But you might ask why new software application undergoes testing. The answer here is to assure quality. It must be noted that many test approaches can be done for a single program. This is because there are also many aspects of a program that needs to be tested. And one approach may not be suited to all areas to be evaluated. Some of these aspects include the functionality of the application, its navigation, and even being a user-friendly program. Likewise, it must be understood that all software firms wish to offer their clients an efficient application that is convenient to use. The acceptance of the public on the new software is very vital. It should be remembered that customer satisfaction would dictate the profit of the company.

There are four major characteristics of the software automation, which made it beneficial to companies – reliable, repeatable, programmable, and reusable. Experts consider test automation as a reliable system. This is because tests conducted here have minimal human involvement. It has been said that less manual intervention reduces human error. Furthermore, the system in this approach executes the same process in the same exact behavior every time they are performed.