International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 174 Software Testing and improvement (STI) approach Jitendra Kumar, Kolkata, India Email: Jkoracle23@gmail.com Phone: +91 9038470689 1. Introduction Software Testing and Improvement (STI) approach is a new approach of testing in which testing and improvement of product go parallel. This approach redefines the testing process by adding software improvement process to it. Software improvement is the improvement in the requirement document, the design and the developed work by: (a) Observing the current limitations (b) Observing and suggesting refinement or improvement in the current implementation Testers can help in the improvement of the final product in two ways: (a) Testing the application presented to them and finding bugs with respect to the requirement and other documents available. (b)thinking beyond the requirement and the design document and observing and analyzing the scope of improvement in the current product at every step while doing testing. Above two qualities a tester must possess and try to improve on both. 2. I am a tester and why should I bother about improving the design or behavior of the application We consider few points here (a) Testers are the first users who get a working application after the development work. (b)in most of the cases developer do not get enough time to think on improving the current function. Developers are busy in developing the requirement. (c)a tester approach is to find problems in the solution provided. And this is critical. Testers are unbiased with the application like the real user. (d)a tester while testing can easily find Problem in the design and development of the application.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 175 Function or design that can be added or improved. (e)it is easy for a tester, while going through various flows of the application, to observe the behavior and think about the improvement scope. (f)application design is job of a designer. But the design process is very complex and big. It requires lots of effort. And there is no guarantee that (a) The design is efficient (b) There is no scope of improvement in the current design and (c) There is no defect in the design. Designer, developer, architect may make mistake because of the following: Lack of knowledge of the product,application or domain knowledge Lack of experience (of designer, business analyst, architect or developers) Errors of omission where things are left out, and of commission, where something is stated that later turns out to be wrong. Errors of clarity and ambiguity Lack of co-ordination among teams who are involved with the software. This lack of coordination may also occur within a team. Trying to finish work in hurry. Sometimes, they are not given enough time to think deep or refine or improve their work Devote less time to their work Unable to visualize real world scenarios and exception that might occur in future High Complexity. This high complexity may be in (a) requirement (b) design (c) construction Complexity in one phase leads to the complexity in other subsequent phase and the probability of committing error is high in this case. Work was not reviewed properly Miss from them(functionality miss, requirement miss etc.) So, above are the main reasons which are enough for testers to have doubts on the software presented to them for testing. Trust no one and doubt everything and finally clear your doubt. Testers could bridge this gap or the error made by the designer, the developer or the architect and it will be very helpful for a testing organization to make an impressive impact on the client. 3. Three examples
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 176 Below examples will help in understanding the need for a tester to be involved in the improvement of the application. Example 1: For a product selling website there are Home Page, Customer info Page, Verify User Page, Payment Page and Exit Page. To purchase a product a user has to start from Home Page. In each page, except Home Page and exit Page, there are two links (a) Link to save and continue later On clicking this link, a unique id of workobject is generated and all the previous product purchase steps are saved. Using this id the user can later continue this purchase process by clicking on the link to retrieve the earlier saved product by visiting the website again. (b) A link to retrieve the earlier saved product User has to give unique id to retrieve the earlier saved workobject containing the earlier product purchase steps. Flow diagram is given below:
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 177 Figure 1 Can you think about the problem in this design without looking at the solution below? In this design, a user will face problem while doing the below steps: (a) The user is purchasing and in the middle the user wants to leave the purchase process and continue the purchasing on some other day. So, the user saves the application (using the link to save and continue later) and gets the workobject id. (b)the user closes the browser. (c)the user opens the browser and goes to the home page in order to retrieve the saved workobject.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 178 (d)but here at the home page, the user finds that there is no retrieve link to retrieve the saved workobject. The Retrieve link is present in the next page (customer info page). The user cannot go to customer info page without selecting any product. (f)the user has to select some products (in the home page) in order to navigate to the customer info page containing the retrieve link. This second time forced product selection to go to the customer info page is unnecessary. And this problem can be avoided by adding a retrieve link in the home page. Solution: a retrieve link in the home page (see Figure 2) Figure 2 A tester must unearth scenarios that are not mentioned anywhere. Such observations must be shared and clarified from other stakeholders. Don t hide and shy from asking questions and clearing your doubt. Example 2: Search User Requirement (as mentioned in the requirement doc): User should able select user after searching in the system. Current implementation or design: There is a [Select user] button and on clicking this button, a list of all the users present in the system is populated and the operator can select any value from the list. In this implementation, the system takes considerable time to populate the list. Database query cost is high for this search. Can you suggest some improvement on this issue?
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 179 Improvement: Store the 200 most recently used customers in a table and fetch those records instead of fetching all the records in one go. And if that does not suffice the purpose then user is permitted to search and get all the records on demand. This solution can also be improved. This is only an example. The logic should be such that the user can get the desired record with minimum cost. Example 3: Help text for input fields: There are many fields where help text is very useful to a user. Examples are given below: Date field where user can input date using the keyboard in addition to the date picker. Below implementation is not good. It does not tell a user about the format of the input date. Figure 3 Below figures show good implementation: Figure 4 Figure 5
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 180 Date can be of any formats i.e. DD/MM/YYYY, MM/DD/YYYY, YY/MM/DD There are many formats of inputting values in the date field and the formats are different everywhere. So before a user does any error in inputting the data in invalid format, help the user to avoid by presenting the input format help text. Similarly, for a date field which takes only future date, there can be a help text indicating that this field will take only future date and a user will know the input criteria and so less chance of validation error. This will save time and cost. Below figure has help text for a particular field which guides the user about input limit in the field. Figure 6 This will again save time and cost. With the three examples above, it is clear that because of faults in earlier phases of the software development life cycle some issues occur while doing testing. Testers are the first user and have the first look at these defects and limitations. 4. Few improvement areas that a tester can look into Below are the few improvement areas: (a)data improvement: The tester can help in improving the data flow across various systems. Can suggest datatype of variables, data size, useless fetching of data from the database, time taken to load all the data, exception handling when array is full etc. (b)process improvement: Removing useless process, refining existing process and its flows, determining limitations of processes, improvement in the way various processes interacts etc. (c)function improvement: Functions or methods are part of process and similar things apply for functions also.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 181 (d)user experience with the application: User experience with the system, problem area when a user interacts with the system using keyboard, mouse or any other external device, issues because of language, region, their country policy, internet connection speed, age etc. (e)graphic user interface improvement: Graphic user interface, verification in different browsers. Page generally looks different in different web browsers, required field marker missing, alignment issues of fields, scroll bars issues etc. (f) Security improvement: Few of the security issues are mentioned below: Buffer overflow, format string problems, integer overflow, SQL and command injection, improper error handling, weak authentication and data protection, information leakage, improper file access, race conditions (g)limitations that might occur in future: We have to look for scenario that might occur in future. Some examples are: Length of a field that might change in future and because of this, many changes will occur in different applications or webservices integrated with the current application. Changing everywhere is not feasible or it will be very complex. So, future scenarios should be considered and reported. The year 2038 problem may cause some computer software to fail at some point near the year 2038(32bit issue). How you add value to the customer? Software requirement specification writers and designers are also human being and so, can also make mistake. Tester should be able to detect those mistakes also. In most of the cases, customer lacks technical knowledge and if the testing team can identify and highlight the defects and limitations in the requirement document and the design (in addition to the normal defect detection in the development) then there is a fair chance that the testing team will get appreciation from the customer and it will increase confidence of the client in the testing team. This confidence in the testing team will certainly help the organization of the testing team in gaining future projects from the client. This will help in improving the credential of the testing organization. 5. Defect finding depends on the skill and experience of a tester We already do application improvement in GUI part. Generally, GUI things are not mentioned in the Software requirement documents. For most of the application GUI is not defined or written explicitly but we tester, on seeing the button misalignment, text overflow and other issues, log them as defect. We do this based on our intuition. Testers do not fear of rejection of defects on GUI issues although they are not mentioned in the requirement document. This is because we are familiar and experienced in GUI. Daily we see GUI of different websites and a standard of GUI is set in our mind. This standard is based on our experience and usage of the technology.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 182 Two Testers story: Gopi is from a village and has no experience of internet. Saniya is a city girl and is an internet geek. Both of them are given a task of testing a comment text box. Currently, the box functionality is implemented in such a way that on entering text more than its current visible boundary, the comment box reshapes itself to accommodate the entire entered text. The size of the box is dynamic and it expands towards right and bottom when long texts are entered. In the requirement document, it is not written that the resizing or reshaping should not take place on entering large comments. Now, when Gopi tests this function, he does not find any problem. He sees the resizing or reshaping of the box as normal behavior and this is according to the requirement document. According to Gopi this will help a user to see what ever has been entered. Gopi has no concept of scroll bar. And according to Gopi, there is no defect in this function. The same function is given to Saniya. Saniya instantly logs a defect for auto reshaping or resizing of the comment box. She thinks that there should be horizontal and vertical scroll bars. By the above scenario, we see that finding defect also depends on the user experience. Gopi could have proactively reached to the Software requirement writer and clarified the above observation instead of passing the test. This questioning ability could have saved him when he saw this behavior which is not mentioned in the software requirement document. So, Question and clarify everything. No scope of ambiguity or doubt. 6. STI in Agile approach of software development In Scrum or agile software development methodology, requirements are not fixed or it changes frequently. In this a tester can give constructive suggestion in the improvement of the requirement document, the design and the development work. In agile approach of software development, a tester can play more important role (when compared to other software development approach) in improving the quality of software using STI methodology. Requirement and software evolves during iterations. Tester can give suggestion in every iteration.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 183 7. STI approach by illustration: Figure 6 below represents a design of an application with different flows. Arrow represents the flow direction, green rectangles are the various processes in the application and the rectangles A and Z are start and end state of the application respectively. Figure 7 The same design is developed by the development team and this is given to the testers to test it.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 184 Figure 8 The tester while testing finds that (a) the processes J,H,Q and (b)the flows D to H,J to K and O to K (indicated by red in the figure 8 above) have some limitations and there are scope of improvement in these. The application prsented to the tester is working in accordance with the requirment document and the design.but few processes and flows can be improved for better quality product. This observation also leads to the enhancement and improvement in the design and the requriement document. 8. Detailed STI approach: Time has come to add Our Thinking weapon to the testing activity. You should ask question to yourself about the application, state achieved and process inside. By asking questions in every step of the application you will improve your understanding. And by improving your understanding you can contribute in improving the design or limitations of the application. Following are few points of STI approach which will help in gaining the customer confidence: (a) Work as if you are a part of the customer. Put yourself in the customer shoes. (b) Understand the requirement clearly. Read and understand all the documents like use cases, class diagrams, UML models, requirements and design documents etc. Understand the business behind any process/function/requirement. Ask yourself questions like What are the reasons behind this requirement? What is the significance of this process state? Can we improve on this? (c) There must not be any doubt in the requirement, design, and process flow. If your understanding is complete then only you can give fruitful ideas. Otherwise, your suggested idea will show your lack of understanding. Talk to developer, business analyst, manager, team lead, team member and improve your understanding. (d) Feel yourself as a business user using the application. (e) Understand the real world scenarios that can occur in your application and align your testing with those scenarios. (f) End to end testing is must to ensure minimum defects. (g) Achieve every state of a workobject or workitem. (h) The team should discuss and write the test scenarios in a meeting.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 185 (i) Test scenario creation should be a team work and not assigned to one individual only. A team can produce better and effective test conditions and scenarios than an individual This will also help in removing any misunderstanding about the application. Tester can ask for team help for understanding the requirement, design or implementation. (j) Weekly team meeting(wtm): Duration: 2 hours on Friday (or any day agreed by the team).each team member will answer the following: Areas he/she felt difficult to understand or difficult to test? Why that area is difficult? Areas that can be improved Limitations of the software Good aspects of the software Other functional and non-functional observations WTM Document: A document should be maintained and updated with the topic and results discussed in the meeting. This document can be used for future reference. (k) Change your shoe: Try different shoes.talk to developer, designer, business analyst, client about current implementation, queries and improvement plan. Try to see the things with their viewpoint. This will help in enhancing your knowledge, which can be helpful in testing and improvement process. (l) Open the black box: If you are allowed to see the code, then do not hesitate to see the code. Open the black box frequently to see the process and function and its implementation.use this enhanced knowledge in testing. Code is an important repository for a tester. Don t test anything blindly.your attitude should be Think, test and think. 9. Result (a) Normal testing process produces the following result shown in the flow diagram below: A normal testing process involves many steps and processes. In the diagram they are represented with rectangles. These processes and steps produces a satisfactory product, represented by a circle here. The customer is satisfied after seeing the product.
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 186 Figure 9 Satisfied Customer (b) STI approach produces a better result as shown in the flow diagram (figure 10) below: Compared to normal testing process, it also contains green rectangles which represent continuous improvement and feedback process. This helps in producing a high quality product with added value and it is represented with a circle. This circle contains a green concentric circle. This green circle is because of the green rectangles. This makes a customer happier, more satisfied and more confident when compared to normal testing approach. STI Approach
International Journal of Advancements in Research & Technology, Volume 2, Issue 12, December-2013 187 Happier, satisfied and confident customer. Figure 10 ACKNOWLEDGMENT I wish to thank Ishani for her review and important suggestion to improve this work. REFRENCES: NO REFRENCES