Reliability
Reliability means:
If you say something is done, it is done, and done according to specs.
Why it matters
Software is not lines of code. Software is a
Is this a Dzango thing?
No! While other companies may not make reliability their first evaluation criteria for assessing developers, they are always going evaluate reliability in one way or another; perhaps informally, perhaps under another name.
The bottom line is that no-one wants an unreliable developer, whose work is untested, prone to bugs, and generally needs to be checked or redone. This is expensive and dangerous.
On the other hand, everyone, from colleagues to supervisors to employers to clients, wants a reliable developer.
No-one will ever gets fired for being reliable
Even if your employer doesn't explicitly say they they value reliability, your own professional reputation can only be enhanced by your reliability. You want to be known as a developer who, when they say it's done, it's done.
Testing plan
How can you confidently say something is working? Then answer is: Because you have a testing plan.
With a well-thought through testing plan, you can test your work and verify that it works. Not only this, but you can demonstrate that it works. Even better, to the extent the testing plan is documented, others can verify that it works.
Of course, it all depends on the quality of your testing plan.
Note that a testing plan does not necessarily imply automated tests. Automated tests are better, but in their absence, and sometimes in addition to them, there can and should still be a manual testing plan.
Standard cases vs edge cases
A testing plan consist of standard cases and edge cases.
Standard cases cover scenarios where everything goes according to plan: system resources are available, users do what is expected of them. If you are testing a login page, a standard test case would be where the user inputs a valid set opf credentials.
Edge cases cover scenarios where things go wrong: a critical system resource is unavailable (eg remote server); the user does unexpected things. If you are testing a login page, a edge case would be where the user inputs invalid credentials.
Edge cases are hard to identify. You need to anticipate all kinds of things that may go wrong. This takes imagination, experience and time.
A testing plan is only as good as its edge cases.
Test plan before implementation plan
It is critical that you write your testing plan before you write (or even think of) any implementation.
Once you start to focus on a particular implementation solution, your mind will become inevitably closed to any adverse scenario that may affect that particular implementation.
Definition of done
Check the project's Definition of Done and verify that your work meets its criteria.
This will include, among other things:
- feature must work in a specific list of several browsers
- no functional regression
- etc.
These conditions must be part of your testing plan. In other words, you must not only fulfill the conditions of the DoD, you must be able to demonstrate it.
According to specs
Your work cannot be considered as done in any way if it does not conform to the requirements or specifications provided by the product owner.
As software develoeprs we must never change or rewrite specs without the product owners's approval. We can make suggestions, but until these are approved, the original specs remain in force.
Specs are often (read: always) imperfect, incomplete, ambiguous, possibly contradictory. It is our responsibility as software developers to request clarification at the earliest time possible.
Never blame the specs
Ambiguous requirements are never a valid excuse for poor work. You should have asked for clarification earlier.
In order to make sure your work is according to specs, you need to:
- Understand the specs
- Show you understand the specs
- Understand the context (what is this feature for?)
- Clarify any ambiguity or gap in the specs early on
- Validate your testing plan with product owner
- Do this at the beginning
Engage with the product owner (through your team leader if you have no direct contact) to clarify the specs and demonstrate your understanding of the specs.
Your testing plan is an excellent tool to communicate your understanding of the requirements and discuss them with the product owner.
Read the requirements a minimun of 4 times How to process a ticket
Occasionnally, urgency means that there is noformal ticket to represent the requirements. In that case, create one. Write it as you would like to see written the tickets assigned to you.