Wednesday, 9 July 2014

Tips on How to make your software testing more efficient

Today I am writing on software testing good practices that help us to make our software testing more efficient. Simply saying ‘we do software testing’ does not magically make your software better or even your testing processes correct and optimized. After all you will learn these testing practices by experience, so let’s learn what all points to be consider for making your software more efficient and healthy.
1) Participation right from beginning: It is a good practice to have testers involved in all stages of software development life cycle. It results the testers can acquire good understanding of application under test, as a result tester can cover the comprehensive test cases. In the requirement’s stage, testing project’s requirements can be a cost-effective & useful to avoid bugs after wards. Early preparation of test environment, thereby preventing any delays and unknown risks will have enough time to deal with. If it is not possible to be a part in these stages then ask you lead or manager to involve the tester in decision making meetings.

2) Have a good test plan. It is necessary to have test plan written by experience person like QA lead or manager. While creating test plan you need follow an organized approach to make it good test plan. The good test plan must cover Scope of testing, test objectives, budget limitations, deadlines, test execution schedule, risks identifications and more.

3) Store intelligently: It is bad practice to have all requirements & change requests over the email. Store all documents, reports on centralized location. It helps to avoid scattering documents over email, file server or intranet. If store intelligently then help to increase the Productivity & improve availability of documents.

Make software testing more efficient


4) Test early, test often: It has been observed that most of the errors are identified in the testing phase which is already introduced in the requirement or design phase. Defects identified later in SDLC are expensive to fix than defects identified in early stage. So testing should start early to avoid the introduction of defects in the early phase.

5) Start writing testing cases early in the requirement analysis & design phase: If you start writing test cases during early phase of Software Development Life Cycle then you will understand whether all requirement are testable or not. While writing test cases first consider Valid/Positive test cases which cover all expected behavior of application under test. After that you can consider invalid conditions/negative test cases.

6) Write effective test cases: Writing effective test cases is a skill and that can be accomplished by experience and in-depth study of the application on which test cases are being written. You should write clearer steps while writing test cases, that will handy to reproduce test cases for both developer and tester.

7) Start testing with positive mindset: When you are start testing application positive attitude with determination of bug and errors in the code. Start positive attitude & don’t think that there will not be a bug in the code. If you are testing application with intention of finding bug then you will definitely get bugs in the code.

8) Use good metrics: Metrics are important for more than one reason software testing projects. Testing your software is one thing and choosing the right metrics is another. Measuring quality and making the right decisions another. Metrics are used to get the efficiency and productivity over time. Quality Objectives Must Be measurable, documented, reviewed and tracked. Choose metrics which are simple to execute & effective in nature. Make sure that choose metrics such that which will present the big picture like

Schedule: Number of test cases written or executed versus the timeline.
Size: Number of lines of code, modules or test cases.
Quality: Defect Removal Efficiency (DRE), coverage.
Rework: Number of test cycles to test bug fixes.
Resources: Money spent, hours of work.

9) Understand testing coverage; divide the functional module into smaller part: Application under test should be divided into small functional module which will help to understand the coverage of testing. If possible make sure that functional modules are divvied into smaller logical parts if possible and test cases should be written in the single module.

10) Test cases available to all team: QA team is aware of application under test vertically rather horizontally. When QA team write the test cases then make sure that you kept in the central location from where all team can access the test cases. Let developer analyze the test cases which help to build the high quality application. Due to uncover all scenarios which developers might miss while coding, this will help to save the rework time.

11) Writing good, clear & descriptive bug report will help to make your software testing more efficient. Keep in mind that testing is a more challenging & creative job. It is your skill how you are handling this challenging situations. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers. While reporting bug not only provide the symptoms of bug but also provide the solutions, if you can. Additional information must be provided along with bug like browser version, login details if any, exact steps to repro etc. This will help to fix the obvious problem quickly. Use proper bug report template for reporting bug.

12) Test environments should own by Testing team: Test environment should be the exact replica of production. Sometimes developers add some configurations or run script but missed to add in release document or configuration file. As a result application will work in the lower environment but failed on production. So if testing team owns the test environment & developer don’t have access to test environment, so such missing things can be controlled.

13) Identify Regression Test cases: To do effective manual regression testing, identify & group the set of regression test cases well before.

14) Increase communication with developer to avoid misunderstandings: In the daily standup or meeting, discuss all points whichever unclear or need some additional information. The face to face communication will resolve the problem easily and quickly, that will help to avoid any misunderstandings. Once you discuss these points, it should be communicated over email as well. Basically, simple rule is that don’t keep verbal communications, same should be capture over the emails or MOM.

How to Extract APK from installed apps on Android Smartphone

Normally all users install their Android Application from Google Playstore, an Official Application Store from Google from which you can download and install the Android application. All android applications are in the form of APK which is known as Android Package File. This APK i.e Android Package file is an an archive file having extension as apk. When you install application from Playstore, actually you install the Android APK from the store to you device. However,though Application is installed in your Smartphone, you can not see actual APK located somewhere in your Android Device. As you can not see APK in the Samrtphone, you can not actually share it with any of your friend even if you want.

APK Extractor is a tool using which you can you can extract the apk of the installed application on your phone. Just go to Google Playstore on Google Playstation and search for APK Extractor. Well you can get quiet a few results for this and you can try anyone you wish.The APK Extractor not only extracts the APK but you can share this it via email or any other sharing options available.

extract-apk


extract and send apk via email

Wednesday, 2 July 2014

Top 50 Testing interview Q & A for Freshers

1. What is '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.

2. What is 'Software Testing'?

Testing involves operation of a system or application under controlled conditions and evaluating the results. 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.

3. Does every software project need testers?

It depends on the size and context of the project, the risks, the development methodology, the skill and experience of the developers. If the project is a short-term, small, low risk project, with highly experienced programmers utilizing thorough unit testing or test-first development, then test engineers may not be required for the project to succeed. For non-trivial-size projects or projects with non-trivial risks, a testing staff is usually necessary. The use of personnel with specialized skills enhances an organization's ability to be successful in large, complex, or difficult tasks. It allows for both a) deeper and stronger skills and b) the contribution of differing perspectives.

4. What is Regression testing?

Retesting of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.

5. Why does software have bugs?

Some of the reasons are:
a. Miscommunication or no communication.
b. Programming errors
c. Changing requirements
d. Time pressures

6. How can new Software QA processes be introduced in an existing Organization?

It depends on the size of the organization and the risks involved.
a. For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and projects.
b. By incremental self managed team approaches.

7. What is verification? Validation?

Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed.

8. What is a 'walkthrough'? What's an 'inspection'?

A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required. An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything.

9. What kinds of testing should be considered?

Some of the basic kinds of testing involve:Blackbox testing, Whitebox testing, Integration testing, Functional testing, smoke testing, Acceptance testing, Load testing, Performance testing, User acceptance testing.

10. What are 5 common problems in the software development process?

a. Poor requirements
b. Unrealistic Schedule
c. Inadequate testing
d. Changing requirements
e. Miscommunication

11.What are 5 common solutions to software development problems?

a. Solid requirements
b. Realistic Schedule
c. Adequate testing
d. Clarity of requirements
e. Good communication among the Project team

12. What is software 'quality'?

Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable

13. What are some recent major computer system failures caused by software bugs?

Trading on a major Asian stock exchange was brought to a halt in November of 2005, reportedly due to an error in a system software upgrade. A May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights and occasional stalling. Media reports in January of 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project.

14. What is 'good code'? What is 'good design'?

'Good code' is code that works, is bug free, and is readable and maintainable. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements.

15. What is SEI? CMM? CMMI? ISO? Will it help?

These are all standards that determine effectiveness in delivering quality software. It helps organizations to identify best practices useful in helping them increase the maturity of their processes.

16. What steps are needed to develop and run software tests?

a. Obtain requirements, functional design, and internal design specifications and other necessary documents
b. Obtain budget and schedule requirements.
c. Determine Project context.
d. Identify risks.
e. Determine testing approaches, methods, test environment, test data.
f. Set Schedules, testing documents.
g. Perform tests.
h. Perform reviews and evaluations
i. Maintain and update documents.

17. What's a 'test plan'? What's a 'test case'?


A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly.

18. What should be done after a bug is found?

The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere

19. Will automated testing tools make testing easier?

It depends on the Project size. For small projects, the time needed to learn and implement them may not be worth it unless personnel are already familiar with the tools. For larger projects, or on-going long-term projects they can be valuable.

20. What's the best way to choose a test automation tool?

Some of the points that can be noted before choosing a tool would be:
a. Analyze the non-automated testing situation to determine the testing activity that is being performed.
b. Testing procedures that are time consuming and repetition.
c. Cost/Budget of tool, Training and implementation factors.
d. Evaluation of the chosen tool to explore the benefits.

21. How can it be determined if a test environment is appropriate?

Test environment should match exactly all possible hardware, software, network, data, and usage characteristics of the expected live environments in which the software will be used.

22. What's the best approach to software test estimation?

The 'best approach' is highly dependent on the particular organization and project and the experience of the personnel involvedSome of the following approaches to be considered are:
a. Implicit Risk Context Approach
b. Metrics-Based Approach
c. Test Work Breakdown Approach
d. Iterative Approach
e. Percentage-of-Development Approach.

23. What if the software is so buggy it can't really be tested at all?

The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs.

24. How can it be known when to stop testing?

Common factors in deciding when to stop are:
a. Deadlines (release deadlines, testing deadlines, etc.)
b. Test cases completed with certain percentage passed
c. Test budget depleted
d. Coverage of code/functionality/requirements reaches a specified point
e. Bug rate falls below a certain level
f. Beta or alpha testing period ends

25. What if there isn't enough time for thorough testing?

a. Use risk analysis to determine where testing should be focused.
b. Determine the important functionality to be tested.
c. Determine the high-risk aspects of the project.
d. Prioritize the kinds of testing that need to be performed.
e. Determine the tests that will have the best high-risk-coverage to time-required ratio.

26. What if the project isn't big enough to justify extensive testing?

Consider the impact of project errors, not the size of the project. The tester might then do ad-hoc testing, or write up a limited test plan based on the risk analysis.

27. How does a client/server environment affect testing?

Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers, especially in multi-tier systems. Load/stress/performance testing may be useful in determining client/server application limitations and capabilities.

28. How can World Wide Web sites be tested?

Some of the considerations might include:
a. Testing the expected loads on the server
b. Performance expected on the client side
c. Testing the required securities to be implemented and verified.
d. Testing the HTML specification, external and internal links
e. cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled.

29. How is testing affected by object-oriented designs?

Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. If the application was well designed this can simplify test design.

30. What is Extreme Programming and what's it got to do with testing?

Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable requirements. For testing ('extreme testing', programmers are expected to write unit and functional test code first - before writing the application code. Customers are expected to be an integral part of the project team and to help develop scenarios for acceptance/black box testing.

31. What makes a good Software Test engineer?

A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful.

32. What makes a good Software QA engineer?

They must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews

33. What's the role of documentation in QA?

QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. Change management for documentation should be used.

34. What is a test strategy? What is the purpose of a test strategy?

It is a plan for conducting the test effort against one or more aspects of the target system.A test strategy needs to be able to convince management and other stakeholders that the approach is sound and achievable, and it also needs to be appropriate both in terms of the software product to be tested and the skills of the test team.

35. What information does a test strategy captures?

It captures an explanation of the general approach that will be used and the specific types, techniques, styles of testing

36. What is test data?

It is a collection of test input values that are consumed during the execution of a test, and expected results referenced for comparative purposes during the execution of a test

37. What is Unit testing?

It is implemented against the smallest testable element (units) of the software, and involves testing the internal structure such as logic and dataflow, and the unit's function and observable behaviors.

38. How can the test results be used in testing?

Test Results are used to record the detailed findings of the test effort and to subsequently calculate the different key measures of testing.

39. What is Developer testing?

Developer testing denotes the aspects of test design and implementation most appropriate for the team of developers to undertake.
40. What is independent testing?

Independent testing denotes the test design and implementation most appropriately performed by someone who is independent from the team of developers.

41. What is Integration testing?

Integration testing is performed to ensure that the components in the implementation model operate properly when combined to execute a use case

42. What is System testing?

A series of tests designed to ensure that the modified program interacts correctly with other system components. These test procedures typically are performed by the system maintenance staff in their development library.

43. What is Acceptance testing?

User acceptance testing is the final test action taken before deploying the software. The goal of acceptance testing is to verify that the software is ready, and that it can be used by end users to perform those functions and tasks for which the software was built.

44. What is the role of a Test Manager?

The Test Manager role is tasked with the overall responsibility for the test effort's success. The role involves quality and test advocacy, resource planning and management, and resolution of issues that impede the test effort

45. What is the role of a Test Analyst?

The Test Analyst role is responsible for identifying and defining the required tests, monitoring detailed testing progress and results in each test cycle and evaluating the overall quality experienced as a result of testing activities. The role typically carries the responsibility for appropriately representing the needs of stakeholders that do not have direct or regular representation on the project.

46. What is the role of a Test Designer?

The Test Designer role is responsible for defining the test approach and ensuring its successful implementation. The role involves identifying the appropriate techniques, tools and guidelines to implement the required tests, and to give guidance on the corresponding resources requirements for the test effort

47. What are the roles and responsibilities of a Tester?

The Tester role is responsible for the core activities of the test effort, which involves conducting the necessary tests and logging the outcomes of that testing. The tester is responsible for identifying the most appropriate implementation approach for a given test, implementing individual tests, setting up and executing the tests, logging outcomes and verifying test execution, analyzing and recovering from execution errors.

48. What are the skills required to be a good tester?

A tester should have knowledge of testing approaches and techniques, diagnostic and problem-solving skills, knowledge of the system or application being tested, and knowledge of networking and system architecture

49. What is test coverage?

Test coverage is the measurement of testing completeness, and it's based on the coverage of testing expressed by the coverage of test requirements and test cases or by the coverage of executed code.

50. What is a test script?

The step-by-step instructions that realize a test, enabling its execution. Test Scripts may take the form of either documented textual instructions that are executed manually or computer readable instructions that enable automated test execution.

How to do Cloud Testing


Unless you've been living under a rock you must already be knowing that 'Cloud Computing' has been making a lot of buzz over past couple of years -- whether it your peer meeting, a client interview, a demo POC session with a prospect, the talk about cloud is everywhere.




And why wouldn't it be? After all,  if industry analysts and virtualization experts are to be believed then cloud based computing and business solutions are going to be the NEXT BIG thing of this decade.

So I guess it is only natural if you find yourself to be asking yourself questions like 'what is cloud testing?',  'how to test on cloud?', 'how can we use cloud to better our testing?', 'how does cloud impact how we used to test before?' etc.

However, since all these queries pose different questions, the answers to them would be unique. For starters, if you are looking for cloud testing, it simply means a testing environment that utilizes cloud infrastructure for performing software testing.

How to leverage Cloud to Transform Software Testing?

If you are someone who heavily use tools while testing then IBM (IBM Cloud) and Hewlett-Packard have already jumped into the market for software testing in the cloud. Thankfully, if done smartly, cloud based computing can prove to be a great value-addition for both software development and testing. The reason is simple -- the very nature of a cloud based infrastructure allows for great team collaboration.

As an added advantage, cloud based testing (as well as programming) environments are easy to setup (on-demand). In today's tight budgeted IT world, this can be a much bigger advantage than it appears at first. It is no secret that IT managers are operating under a very tight budgetary constraint and when it comes to testing phase, the budget is even smaller.

Traditional approaches to setting up a test environment involves high cost to setup multiple servers with various OS, hardware configuration, browser versions etc. And if you are going to simulate user activity from different geographic locations you will have to setup test servers with localized regional language OS, which in turn can add up to the cost. But using cloud based infrastructure, the team wouldn't have to setup expensive physical servers -- rather, setting up new testing environment will be fast and efficient and VMs (virtual machines) and test servers can be launched and decommissioned as needed.

On the other hand, as a tester you might also be required to one of those ever emerging cloud based SaaS applications that aim to cater to various large and small customer base, on-demand. If you are testing such a cloud based application then your challenges are double-fold. Because, testing all the layers - from your application to the cloud service provider - is something that as a tester you will have to become efficient in.

As a closing note, if you are a tester and if you are intrigued by all these buzz surrounding cloud testing, then here are 2 main reasons why you might consider trying it out -- Cloud based software testing infrastructure  greatly helps in reducing capital expenditure and these testing setups are highly scalable , thus allowing your team to expand or decommission your test servers on-demand, as needed.

Tuesday, 1 July 2014

Form Validation / Basic Checklist – Registration Form

1) Field Name => Username.

* Label should say “Username”.

* As soon as the page was loaded, cursor should be focus in the Username textbox.

* There should be a hint saying the min & max character.

* Min validation should be “3 Chars” and Max validation should be not more than “12 Chars”.

* It should be accepts only “Alphanumeric” and can contains “dot, underscore and hypen”.

* It should be unique.

2) Field Name => Email

* It should be unique.

* The max character length should not be more than “80 Characters”.

* Check for “.com, com.sg, co.uk, .co..lm, .comdfgdg, ..com”.

* Check for already existing email.

3) Field Name = Password

* There should be a hint saying the min character.

* It should not accepts single quotes, double quotes and slashes.

* If we copy and paste the password in notepad / wordpad, it should not paste it!

4) Field Name = Name

* It accepts only alphabets. Its better to restrict from keystroke!

* Max Character should not be more than 40-50 Characters. In case of First Name, max can be “20 Chars”…

* If the label says “Name”, it should accepts “space and dot”. If it says as “First Name”,

then it should accepts only “Alphabets”.

5) Field Name = Mobile

* Max should be not more than “12 Characters” including Country Code. Else, it

should be accept only 10 digits. It should not be able to enter more than the specified

characters.

* It should accepts only “Digits”.

* If it contains 10 Zeros, then, it should be invalid!

6) Field Name = LandLine

* Max should be not more than “15 Characters” including Country Code. It should not be

able to enter more than the specified characters.

* It should accepts only “Digits”.

* If it contains 15 Zeros, then, it should be invalid!

7) Field Name = DOB (Date of Birth)

* It can be 3 individual fields (D/M/Y) else would be better of having Calendar.

* It should never display the current date.

* It should be displayed only the date/age to select from “18″yrs.

8) All forms should have a “Terms & Conditions” link with a checkbox. If the form was submits

without selecting the checkbox, error msg should be displayed.

9) Its better to have a “Captcha” in every “Registration Form”.

10) Its better to have some “Subscription” links in the “Registration Form”.

11) After Successful register, user should receive a “Welcome” mail to the given email.

12) Its better to have a “Confirmation Link” in the email for valid registration.

13) Check for tab navigation.

14) Check for Enter key validation.

15) Check for Blank Space validation.

Monday, 19 May 2014

How to improve agility of an Agile Team

Often as an Agile Project Manager or an Agile Scrum Master, your very first challenge is to improve the agility of teams.  So in this article, I will try to post my thoughts on how to improve Agility of a Team in my own words of course and out of my experience.

  •   Change their mindset
Agile is a lot about mindset.  Once someone is into that mindset, obviously he/she will contribute the best to the team's cause and thereby it will increase the speed and also the agility of the team.
  •   Change your mindset
Acknowledge the fact that you need a mental conditioning as much as the team.  First of all, try to understand what Agile is all about and how it benefits the different stakeholders in the teams.  Try to understand that Agile is not a miracle game and it takes time, proper execution, support from every team member and support from team as a whole to reap its benefits.
  •   Improve collaboration
Agile is lot about team working together to complete challenging tasks rather than several team members working in silos.  Emphasize the fact that Agile is a team game.  So Improve the collaboration among the team members, ask them to pair up for some problems and encourage good collaborative team work and make collaboration a habit.
  •   Improve the engineering practices
Agile is lot about being nimble, which means that unless proper engineering practices are followed, it may not be very helpful to the team.  If all team members have the right mindset but lack the engineering practices, then that will be a bottleneck to agility.
  •   Focus on knowledge sharing
Knowledge shared is knowledge gained.  The problems with traditional teams was that everyone worked in silos and very few members shared their knowledge.  But the main focus of an Agile team is to share the knowledge it gained among its team members so that as a team, they will be in a better position to respond to uncertainties.  As they say, Knowledge is Power.  The more as a team they know, the better inputs they have to solve the problems at hand.
  •   Continuous learning
The more you learn, the more you know and the more you can share.  One of the strengths of good Agile teams is that they focus on continuous learning.  As teams continuously learn it enhances the knowledge and hence provides a competitive atmosphere for learning and knowledge sharing.
  •   Embrace changes and new ideas
Often the team knows what is going well and what isn't and what needs to be changed.  So give a thought to those ideas and you might see a whole lot of improvements in the Agility.  Embrace changes from the teams also.
  •   Strike the right balance between process and innovation
Processes are required to a point to define some standards and to mechanize certain parts of the life cycle.  But over reliance on processes will make the project boring and there will be no scope for innovation.  And focus too much on innovation, you tend to lost of the current goals.  So try to balance between process and innovation.  By that way, you will improve the agility without hurting the current goals and also the innovative ideas of teams.
  •   Give the team proper coaching
Unless the team understands the benefits of Agile for them, the customers and the project as a whole, it will be difficult to get a buy in from them.  So give them proper coaching on what is Agile all about and what are the areas of focus.  By understanding, they will try to realize what their roles should be to improve the agility.
  •   Take it slow, Embrace the power of small wins
There is no point in rushing.  As already put forward, Agile is not about miracles overnight.  It can be beneficial in the long term, but for that to happen, start small and keep on improving.  Try to identify areas that can be improved and do it one step at a time.  That is when the power of small wins come into picture and the team will get a natural way of progression.
  •   Remove impediments for the team
One of the biggest Agility killers is the impediments for the team.  Impediments can be in terms of technical challenges, unwanted distractions from the product roadmap, no clear vision of product goals, waste of time due to lack of effective engineering practices, lack of automation, lack of team work and collaboration, and so on.  Removing these impediments will reduce the friction so that the wheels of Agile can move smoothly.

The Future of Software Testing

 I believe that in the future will we see changes in 6 key areas of software testing:-

1.Accurate information provision (in the language of the recipient)

Software testing’s role is the provision of data to enable go live decisions to be made. If we get this information wrong, wrong decision will be made. If testing can’t provide the right information it actually adds little value.

Key to this is the understanding of what data is required. So many times I see that Test Managers have just produced what they think is right without asking, or even worse don’t understand the goals of the project so don’t know what data should be collected to indicate whether those goals have been achieved.

Test Management tools can help, but they are only as good as the way they are implemented. In a lot of cases this is straight out of the box, with no configuration or understanding of what is to be reported, with a view that the standard reports will be good enough! Test cases are then loaded and then it’s found that the right data is not available!

I believe the way forward for information provision is actually to learn something from the Agile world and start to work/talk to each other. Everyone’s requirement for information is different and so the closer projects work together and people mix the more we can understand and the closer we will be.

I think a software delivery project is much like an orchestra, if each part works together in harmony it can be beautiful, but if only one element works on its own the result will be disastrous. We need to work together so that the software delivery orchestra works, and delivers beautiful results.

2. Building quality in, rather than testing it out, prevention rather than detection

Traditionally software testing’s objective is seen as finding defects, whereas in reality it is a great way of preventing defects.

It continually amazes me how many clients I see who leave testing until the last possible minute. When will companies understand that the earlier a test team is involved, and of course the better trained they are, the more they will recognise problems early in the lifecycle enabling them to be resolved before they become execution defects?

What do I mean? Well, if you knew your back wall was going to fall down, would you wait until it did or do something to stop it falling. The same can be said for a software tester. If early enough in the lifecycle it is identified that elements of the software may fail would it not be better to stop it failing by some corrective action, rather than to leave it to fail and then checking it has!

What I am referring to hear is a risk based approach to testing, understanding what risks the product has at the earliest possible point and putting in place mitigating actions to lessen or completely remove the risk of failure

3. Ensuring that quality is considered and not seen as a burden, alongside time and cost

Many have said that you can’t balance the three sides of the eternal project triangle, time cost and quality. The view seems to be that you can’t have all three you have to pick two!

In my experience, by adopting a collaborative approach and being able to get involved at the earliest point in a project, it is possible to achieve all three.

Whilst working for a large Insurance Company, I liaised very closely with the Development Manager lending him my testing staff so that he could be sure that when his developers had finished developing the code would work. They asked for a week’s extra time, which I agreed to. When the code was delivered to test it just worked and we therefore reduced the lifecycle timescales by 6 weeks and saved over £400k. The developers were happy, the testers were happy and most of all the business got their software early.

The testing costed roughly the same as the back ended budget, but was spread out from a far earlier point, all of the savings were in development not having to support an extended testing window!

The key to this success was the joint ownership of the quality between all parts of the project team. So by focusing on quality early in the lifecycle you can meet the joint objectives of cost, time and quality.

4. Software Testing Qualifications


The reality is that a good software tester or test manager needs a mixture of skills and knowledge to make them successful. In my view the qualifications account for about 10% to 15% of the knowledge required for the practical application in the workplace.

ISEB have recently revised their single Practitioner Exam, into three, the Intermediate, Test Management and Test Analyst, but only prescribe a 3 day training course followed by an exam. There is minimum entry requirement, but they do not include practical test experience, more a passing of time between taking the Foundation exam.

ISTQB on the other hand have just launched their Advanced level qualifications. Like ISEB there are three of them, Test Manager, Test Analysts and Technical Test Analysts, with a minimum training period of 5 days each followed by an exam, with basically the same entry criteria.

I believe software testing qualifications have a very important part to play in the future education and verification of software testers and test managers. The reality is that the qualification together with real practical experience is what makes a good tester. After all would you allow a surgeon who had just passed their exams but had no practical experience to operate on you? I don’t think so.

Employers need to consider what structures and support need to be in place subsequent to a qualification course to ensure what has been learnt is put into practice in the best possible way.

5. Standards

The few standards currently out there are developed by a wide working international group (can be as many as 1000 contributors) who build and review the content. However, by necessity they are generic and some concessions have to be made to gain global agreement.

It continually amazes me that even knowing that the standards exist, testers prefer to start from a blank sheet of paper when constructing their processes and templates. They may not be perfect but to start from a point above zero has to be better than no help at all?

I believe we need to embrace the standards more and take from them the information that is right for the project.

6. Test Process Measurement Models


There are many test process measurement models available for testers to review what they do against. For some very strange reason, a lot of test consultancies will build their own version, mainly for the creation of a sales opportunity, and not to help the customer. As a result, the models are woefully short of the real detail required to help improve processes.

There are many standard models out there, but in my opinion the most effective model available today is the new TMMi Model. It is a model that has been developed out of research (rather than commercial interest) and therefore provides a very independent and structured view.

It works along the same lines as CMMi, providing 5 levels of maturity to measure against and supporting key process areas.

Again as in the 5th point above, it may not be perfect but like standards it is there and has many hours of experience vested in it, so why do people still start from a blank sheet of paper when looking at their process, when a short cut is available?