Steps to become a better software tester - can do these over a period of time - Part 6

In the previous post, or series of posts (how to improve software testing), I am writing about how to improve the abilities of a person who does testing. In this article, I will provide some more details about what a tester can do to improve their skills in this post:
- Learning about scripting. Scripting is one technique that is beneficial to tester in many ways. There are many applications and software that have a testing interface. Being able to use these scripting interfaces can help automate some of the work of a tester; further, it is not necessary that time for this activity would be budgeted as part of the regular product activities. A tester can increase the amount of time available for regular testing and reduce the time spent on repetitive testing by using options such as Scripting. Knowledge of scripting is also useful for helping out in many of the activities of the tester on a regular basis.
- Automation. Automation is one of the techniques that ensures that continuous and repetitive tasks can be done through a software application rather than a tester doing it. Automation ensures a higher amount of coverage, and you have the option of setting up a list of automation test cases which ensure that a certain percentage of test cases can be run every day when the new build comes in. However, automation is not everyone's cup of team. Automation is typically done by those team members who have shown interest in learning about automation techniques, or those who have shown some interest in scripting (and this is normally seem to be present in people rather than all the team members being asked about whether they would prefer to do scripting or automation testing).
- Being able to adapt to new methodologies. New methodologies such as Agile, Scrum, etc have made it into the software development community and it makes sense for testers to know about these technologies (they can show the lead to their team for such methodologies) and not seem to act such that they are standing in the way of such methodologies.

Steps to become a better software tester - can do these over a period of time - Part 5

I have been writing a series of posts (How to become a better tester) about how a tester can slowly and steadily acquire a variety of skills that improve their skills and make them a much better tester, ensuring a better career and more respect. Here are some more tips that can help you in this quest:
- People working with a tester can typically figure out the tester who is laid back and the one who they can trust to make sure that their feature is of high quality. They would prefer a tester who is involved in the process from the beginning, who asks a lot of questions (relevant ones, not questions just for the purpose of questions), who contributes to improving the product and the process. A tester may irritate the developer by asking a lot of questions, but if these are relevant questions and help the developer in uncovering more defects, such help will be well appreciated. I have this transformation happening in a tester when the tester learnt that they were rated average and did some amount of comparison to see what a developer and the test manager would appreciate.
- Learning more about the intricacies of how the system / application is built. Typically when there is a black box system, the tester is just expected to know the various input and output variables for the system; however, a good tester will also try to explore to some extent white box related information for the system. The tester will try to learn about the way that different components in the system interact with each other, so that it also becomes easier to identify the areas that need more attention. This may require the tester to learn about the system design to some degree, but all of this is very much possible for a determined tester to do (it is only in some amount of applications where the tester does not have the ability to learn about the system design and the interactions between the various components in the system).

Steps to become a better software tester - can do these over a period of time - Part 4

In previous posts, I have been talking about how a tester can continually improve their expertise, gaining a good reputation as a skilled tester (something that is likely to help the tester both professionally and in terms of career climb). I will continue with more topics in this post, and if you reading these articles, I hope that this helps you a lot in your effort to become a better tester. If there are any specific experiences that you want to contribute, please put them in the comments, and I will get in touch with you for more details.
- Always do testing with an open mind. You may have had experiences with different developers and may have made some judgments about them in terms of which developer is more likely to have defects, which one has lesser defects and better quality of code. However, keep in mind that many of these properties also depend on the situation, and a developer, when faced with a tough time crunch and under a lot of pressure, can tend to make more mistakes than normal. So, do not make any assumptions while doing your testing, and make sure that other people can depend on your testing pass.
- Learn about new technologies, keep ahead of the curve. Over a period of time, there are a number of new technologies that can hit the market, and many of these can become very important in the testing community (one such example has been the use of scripting tools and automation tools to provide an automation testing strategy). If you have shown interest, and learned something about these tools and practices, there is a much higher chance that you will be selected when the group decides to get its feet wet with respect to automation and you would be the spearhead of this effort, which can be good for your career.
- One needs to be level headed, and not get irritated easily. It is seen in many cases that developers can take their own time to fix bugs, and this can irritate a tester (I have seen cases where the tester expresses feelings that their work is of no value since the developer did not even look at some of the defects for weeks altogether). A good tester should not show irritation over such matters, but instead raise the issue in proper forum so that this is seen as a problem with a solution required.

Some best practices that contribute to improved software testing Part III

There is always a search for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The incremental practices include:
- Teaming Testers with Developers
This practice should understand the kinds of teaming that are beneficial and the environments in which they are employed. This practice should be more than just a concept.
- Code coverage
Code coverage is the numerical metric that measures the elements of code. this practice should include the information about the tools and methods of how to employ code coverage and track results.
- Automated Environment Generator
Setting up test environments to execute test cases is the most difficult task. This practice should capture the issues, tools and techniques that are associated with setting up the environment, the break down and automatic running of test cases.
- Testing to help ship on demand
Testing process should be viewed as one that enables changes that occur late and handles market pressures and still do not break the product or ship schedule. This practice should identify how to work this concept in organizations.
- State task diagram
State transition diagrams are used to capture functional operations of an application. It allows you to create test cases automatically. This practice has more than one application and one need to capture the tools, methods and uses.
- Memory Resource Failure Simulation
This practice addresses loss of memory because of poor management or lack of garbage collection. It should develop methods and tools for use on different platforms and language environments.
- Statistical Testing
the concept of statistical testing is to use software testing as a means to assess the reliability of software as opposed to a debugging process. It needs to work on the software along an operational profile and measuring interfailure times used to estimate reliability.
- Semiformal Methods
A semi formal method is one where specifications that are captured may be in state transition diagrams or tables that can be used for even test generation.
- Check-in tests for code
Check-in tests couple an automatic test program with the change control system. the chances of the code breaking the build are minimized.
- Minimizing regression test cases
To minimize regression tests, several methods are there out of which one method looks at code coverage and distill test cases to a minimal set. Sometimes, it does confuse a structural metric with a functional test.
- Instrumented versions for MTTF
Mean time between failures(MTTF) can be measured if the failures are recorded and returned to vendor. It enhances the quality of the product that is meaningful to user. It also captures first failure data that benefits the diagnosis and problem determination.
- Benchmark Trends
This practice could be initiated by benchmarking and then advance the practice to include a large pool with customers and competitors.
- Bug Bounties
These are the initiatives that charge the organization with a focus on detecting software bugs.

Some best practices that contribute to improved software testing Part II

There is always a search for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The foundational practices include:
- User Scenarios
User scenarios are developed to test the functionality of applications when multiple software products are integrated. User scenarios test the product in a way that it reflects customer usage. It also reduces complexity of writing test cases. This practice should capture methods of recording user scenarios and developing test cases based on them.

- Usability Testing
Usability testing not only tests how usable a product is but also provide feedback on methods to improve user experience. A good user experience is very necessary. The best practice for usability testing is that it should have knowledge in area of human computer interface.

- In-process ODC feedback loops
Orthogonal defect classification or ODC uses deect stream for precise measurability into product and process. The advantage of ODC is that it has the ability to close feedback loops which has proved to be cost effective and process improvement.

- Multi release ODC/Butterfly profiles
This technology or practice allows to make strategic decisions to optimize development costs, time and quality issues by recognizing customer trends, patterns and performance of the product.

- Test Planning Requirements
Requirements management and preparing test plans out of it is an important step to check whether they are meeting the customer needs or not. This practice is understood and executed with a holistic view.

- Automated test generation
There are many automated tools to generate test cases which help in software testing.this practice needs to understand which of the methods are successful and in what environments they are viable. A good amount of learning is needed to learn these tools.

Some best practices that contribute to improved software testing

There is always a serach for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The basic practices are like training wheels which you need to get started and when you take them off, you know ow to ride. The basic practices include:

- Functional Specifications
It is basically a development activity but it is also necessary for software functional test. It defines the external view of an object or procedure. It helps the test generation activity to move in parallel with code development. It helps in the clarity from designer's and an architect perspective.
- Reviews and Inspections
Software reviews and inspection provides a ten times gain in debugging process.
- Formal entry and exit criteria
This practice offers a careful management of software development process. Every process step has a precise entry and exit criteria defined by development process and management keeps a track of the movement from one stage to another.
- Functional test varaitions
This practice involves understanding how to write variations which refers to combination of input condition to yield a output and gain coverage to thoroughly test the function.
- Multi platform testing
Today products run on different platforms so the necessity arises of designing and testing the product for different platforms. This practice addresses aspects of multi platform development and testing.
- Internal betas
Beta means the product is released to few customers and their feedback is recorded. This practice deals with beta programs to best levarage it and reduce cost of external beta.
- Automated test execution
Using automated test execution, the amount of manual work is minimized and higher coverage is gained. This is the best practice which is well understood in some areas. This practice needs to levarage and then develop methods for areas where automation is not fully done.
- Beta programs
- Nightly builds
Nightly build captures frequent builds from changes that being promoted. Advantages include firstly, errors are captured quickly if major regression occurs. Secondly, regression tests can run in background. Thirdly, newer releases of software are available to developers and testers sooner.

Steps to become a better software tester - can do these over a period of time - Part 3

In this series of posts (Improving testing skills), I have been writing about how to improve the testing capabilities of tester, and have presented some points that could help a developer. In this context, here are some points that could help the tester to improve their skills.
- The tester needs to improve their knowledge of the product. I once had a case where the tester had a series of test cases to execute and did not really have the time to get detailed knowledge of the product. So when there was a change in design and features, and the test cases had to be re-done, the tester did not have the knowledge to quickly make the changes. It took time, and the tester had to face flak because of the time involved, and was also berated for a poor knowledge of the product (and there was really no defence of this lack of knowledge).
- Domain knowledge of the area. A skilled tester will make the time to learn about the domain in which they are testing. For example, if an application is being written for the banking domain, then it would help for the tester to get a quick understanding of the concepts of the banking domain, especially the specific areas which the application is expected to cover. In my previous experience, I have seen that this helps the tester ask informed questions, and also be able to better review the test cases for completeness.
- The tester needs to focus on the more critical parts of the application first, and check those areas first in terms of testing. It is a reality that no application is 100% bug free (or rather, the amount of effort and cost required to make an application bug free is exorbitant), and hence it is key that the tester has found more of the bugs in the application that have a high priority and severity, and the bugs that are remaining in the application are less severe, and have a lower customer impact.