1. What would you do to make sure the quality of the co-located Agile Project?
James: You are going to need a lot of planned communication, because communication will not happen naturally when people are far away. I suggest daily conference calls. Distributed projects take strong leadership to get people to come together. I also suggest that key people should periodically visit each other, instead of relying only on electronic communication.
(“Co-located Agile project means Agile team members are located in different location or multiple agile teams are working on different parts of the product from different location.”)
We all know that in Agile environment, the high speed and quality is the first priority. People seem to work without taking break, and the quality is measured not only based on the project but also based on the team characteristics. Hence, the human factor is the key in ensuring project quality, which means that effective communication could influence the success of the project. James’ opinion woke up my mind about some ideas about the communication in co-located Agile projects.
Firstly, the effective communication is determined by the language, product, tool/technology, and process knowledge of the team, which have to be synced at the same level. In order to communicate effectively across distance and time zones, distributed teams need to speak comfortably the same “language”. It's not only the language such as English, German, or French, but also product terms, tools/technology features or processes, in which each team will have to be at similar level in these in order to speak and understand each other.
To be able to synchronize, you need to take extra steps to ask concise and valid questions, to clarify requirements or requests, to review the outputs before it's going out. With the equality of knowledge, each distributed team should be able to make decisions for their internal matters, in order to implement self-management principle. One team should not tell other teams what and how to do.
Secondly, applying the suitable communication tools and methods could also play and important role in the success of team communication. There are quite plenty of communication methods to select, from direct communication (Face-to-face or Video calls) to indirect ways (Email, Forum, or Text chat). Also, you can consider some popular and useful communication tools, including: Skype, Slack, Confluence, GoToMeeting, or Google Drive, which support easily to communicate between onshore and offshore team. Those methods and apps can help eliminate the distance in time zone and location.
Additionally, for better communication effectiveness, you need to arrange the scope of work reasonably and support clients properly, it’s will help to connect smoothly. To tighten the business, it is advised that we can visit the onshore/offshore regularly to build relationship with teams and instantly respond to the release/milestone/technology changes.
2. How would you define testable code? What are your criteria?
James: All code is testable. Some code is more testable than others. Testability in code just means how easily you can test it. Code is more testable when it is observable and controllable. Ask for function-level logging and scriptable interfaces. Also, code is more testable when it is simple and when it is decomposable. Decomposability is the ability to separate the components and test them in relative isolation.
To be more specific on James’ opinion, I think of some simple ways to define a testable code such as: code’s logic, code naming convention, project structure/architect. Testable code always includes the ability of extension, being easy to maintain, re-use, and upgrade. This article is a typical example for understanding readable code fifteen most important best practices for writing super readable code.
3. What type of skills should the tester pick up to move into DEVOPS world?
James: I don't know that much about the DEVOPS world. But that world doesn't welcome testers. It welcomes developers. So the first required skill is programming. Then you have to look for the tools to support your testing work.
There are some tactics that testers need to pick up in order to move into DEVOPS:
- Live site testing: Testers have to test the product in production, after it is released.
- Collect and analyze feedback from users in the field. React quickly to any emerging concerns among the users.
- Advocate for testability. It’s critical that the product be built with testing in mind.
I totally agree with James about the above points of views. Besides, we testers need to improve the ability to understand coding, scripting, build-production, tools, and operation system such as Linux, Windows.
4. How do you define what type of information should be included in a final report to the client? What type of information is useful and what is not?
James: There is no perfect report. There is only the report that gives values to clients.
Here is some advice:
+ Build credibility (by being credible).
+ Know the context of your tests (test framing).
+ Never use a number that is out of context (e.g. no test case counts)
+ Highlight general test activities (put test in the right context).
+ Highlight product risk (put bugs in the right context)
+ Build credibility (by being credible).
+ Know the context of your tests (test framing).
+ Never use a number that is out of context (e.g. no test case counts)
+ Highlight general test activities (put test in the right context).
+ Highlight product risk (put bugs in the right context)
We can build final report with three levels:
+ Level 1: Facts and truth about bugs and observations
+ Level 2: How do you get those facts? How to test those facts?
+ Level 3: How do you know if the test is good? Why is the test good enough or not?
+ Level 1: Facts and truth about bugs and observations
+ Level 2: How do you get those facts? How to test those facts?
+ Level 3: How do you know if the test is good? Why is the test good enough or not?
5. How do you estimate the effort of testing in a project?
James: There is no magic spreadsheet that tells you how long testing will take. But good estimation starts with visualization. Can you picture the testing process in your mind? Many testers have trouble doing that. But if they are not clear what testing will look like and feel like, they also won’t have any idea how long it will take.
Behind that question is a list of other questions that we can figure out and answers to give ourselves the ability to estimate the effort of testing in a project:
o How much time is really needed for testing?
o How long would it take to finish testing?
o What is the least amount of time we could allocate to testing?
o How much testing is needed to assure a high quality solution?
o How many test cases will be needed?
o How many testers are required?
o What testing skills are required?
o How much will the testing cost?
o Do we need to test them all?
Only five questions for James, but he has shared a lot of useful knowledge and experience including: defining problem, questioning, and thinking about the object in the way of co-located Agile Project, testable code, skills of testers, creating a good report and estimating the effort of testing.
Thanks James very much!
No comments:
Post a Comment